[x264-devel] Re: [PATCH] Forcing frame coding as IDR

[Foxy Shadis]

Jingyi Hu scratched,
>
>1) I think if every scenecut detection you use a IDR, it will cost more 
>than use other methods (like I-Blocks),  all reference data are lost! 
>Really it depend coding trade-off.

Most scenes don't really seem to gain anything being able to use previous 
scenes as references (unless you have lots of references and scenes that 
switch back and forth several times a second, rather rare, or spurious IDRs 
are being inserted), but seeking gets a lot harder. Do you have video that 
demonstrates a real gain?

Crank --min-keyint or lower --scenecut to test this.

>2) Think about  a live content feed system, everything is automatic.

Are we talking about x264 the commandline encoder, or a separate software 
linked against libx264?

>4) You talk about  a perfect world with fix fps. How about other 
>conditions?

This would require the frontend to understand VFR, which it doesn't anyway. 
Framerate is only signaled and not really used; everything related to zones 
(and stats/qpfile) is based on frame #s.

Both of these are related to the frontend, and neither seems to apply to the 
commandline frontend. The backend already has the capability of supporting 
this, the interface just doesn't exist. They would be more at home in 
something like VLC, which can manage streaming and frame timing in ways the 
commandline was never meant to.

Making qpfile a little more flexible would be nice, though.

-JB

>
>Thanks.
>
>Jingyi Hu
>
>
>
>>From: Loren Merritt <lorenm at u.washington.edu>
>>Reply-To: x264-devel at videolan.org
>>To: x264-devel at videolan.org
>>Subject: [x264-devel] Re: [PATCH] Forcing frame coding as IDR
>>Date: Mon, 4 Jun 2007 23:57:03 -0600 (MDT)
>>
>>On Mon, 4 Jun 2007, Jingyi Hu wrote:
>>
>>>It all depend on the clips and output frame location:
>>>1)If all clips contents are not all related, the separate encoding will 
>>>make more efficient in coding mv search, reference frame search etc.
>>
>>If clips contents are not related, then x264's scenecut detection will 
>>trigger and put a keyframe there anyway. The purpose of forcing keyframes 
>>is if the chapter break occurs somewhere that's not an obvious scenecut. 
>>e.g. frade to black, chapter break, fade in next scene.
>>
>>>2)If you do not have a IDR interval parameter setting and clips scene 
>>>changes a little, you will not have a IDR for a while. In this case, it 
>>>will big offset between IDR and require frame #.
>>
>>Say in english please?
>>
>>>3)Usually end user do not have accurate idea about exact frame #. If you 
>>>force set the frame # become IDR, it will increase stream data overhead.
>>
>>If the user doesn't know the exact frame numbers, how is he supposed to 
>>split the video either? And if you want some algorithm to find scenecuts, 
>>what's wrong with the current one?
>>
>>>4)The best approach to give the time duration or output bitstream size. 
>>>Let program determine which frame numbers are and carry the extract 
>>>output.
>>
>>How does time duration differ from frame number? Just multiply by fps.
>>And splitting by output bitstream size is a completely different goal.
>>
>>
>>P.S. please don't top-post, and please don't break threading.
>>
>>--Loren Merritt
>>
>>--
>>This is the x264-devel mailing-list
>>To unsubscribe, go to: http://developers.videolan.org/lists.html
>>
>
>_________________________________________________________________
>Play games, earn tickets, get cool prizes. Play now–it's FREE! 
>http://club.live.com/home.aspx?icid=CLUB_hotmailtextlink1
>

_________________________________________________________________
Don’t miss your chance to WIN $10,000 and other great prizes from Microsoft 
Office Live http://clk.atdmt.com/MRT/go/aub0540003042mrt/direct/01/

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html