<html><div style='background-color:'><P><BR>Thank you for the email Foxy! It will be interest to doing some measurement when I get more time.</P>
<DIV>
<DIV class=RTE>
<P>Best regards,</P>
<P>Jingyi Hu<BR><BR></P></DIV>
<DIV></DIV>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #a0c6e5 2px solid; MARGIN-RIGHT: 0px"><FONT style="FONT-SIZE: 11px; FONT-FAMILY: tahoma,sans-serif">
<HR color=#a0c6e5 SIZE=1>
<DIV></DIV>From: <I>"Foxy Shadis" <foxyshadis@hotmail.com></I><BR>Reply-To: <I>x264-devel@videolan.org</I><BR>To: <I>x264-devel@videolan.org</I><BR>Subject: <I>[x264-devel] Re: [PATCH] Forcing frame coding as IDR</I><BR>Date: <I>Tue, 05 Jun 2007 01:47:45 -0700</I><BR>><BR>><BR>>Jingyi Hu scratched,<BR>>><BR>>>1) I think if every scenecut detection you use a IDR, it will cost <BR>>>more than use other methods (like I-Blocks), all reference data <BR>>>are lost! Really it depend coding trade-off.<BR>><BR>>Most scenes don't really seem to gain anything being able to use <BR>>previous scenes as references (unless you have lots of references <BR>>and scenes that switch back and forth several times a second, rather <BR>>rare, or spurious IDRs are being inserted), but seeking
gets a lot <BR>>harder. Do you have video that demonstrates a real gain?<BR>><BR>>Crank --min-keyint or lower --scenecut to test this.<BR>><BR>>>2) Think about a live content feed system, everything is <BR>>>automatic.<BR>><BR>>Are we talking about x264 the commandline encoder, or a separate <BR>>software linked against libx264?<BR>><BR>>>4) You talk about a perfect world with fix fps. How about other <BR>>>conditions?<BR>><BR>>This would require the frontend to understand VFR, which it doesn't <BR>>anyway. Framerate is only signaled and not really used; everything <BR>>related to zones (and stats/qpfile) is based on frame #s.<BR>><BR>>Both of these are related to the frontend, and neither seems to <BR>>apply to the commandline frontend. The backend already has the <BR>>capability of supporting
this, the interface just doesn't exist. <BR>>They would be more at home in something like VLC, which can manage <BR>>streaming and frame timing in ways the commandline was never meant <BR>>to.<BR>><BR>>Making qpfile a little more flexible would be nice, though.<BR>><BR>>-JB<BR>><BR>>><BR>>>Thanks.<BR>>><BR>>>Jingyi Hu<BR>>><BR>>><BR>>><BR>>>>From: Loren Merritt <lorenm@u.washington.edu><BR>>>>Reply-To: x264-devel@videolan.org<BR>>>>To: x264-devel@videolan.org<BR>>>>Subject: [x264-devel] Re: [PATCH] Forcing frame coding as IDR<BR>>>>Date: Mon, 4 Jun 2007 23:57:03 -0600 (MDT)<BR>>>><BR>>>>On Mon, 4 Jun 2007, Jingyi Hu wrote:<BR>>>><BR>>>>>It all depend on the clips and output frame location:<BR>>>>>1)If all clips contents
are not all related, the separate <BR>>>>>encoding will make more efficient in coding mv search, reference <BR>>>>>frame search etc.<BR>>>><BR>>>>If clips contents are not related, then x264's scenecut detection <BR>>>>will trigger and put a keyframe there anyway. The purpose of <BR>>>>forcing keyframes is if the chapter break occurs somewhere that's <BR>>>>not an obvious scenecut. e.g. frade to black, chapter break, fade <BR>>>>in next scene.<BR>>>><BR>>>>>2)If you do not have a IDR interval parameter setting and clips <BR>>>>>scene changes a little, you will not have a IDR for a while. In <BR>>>>>this case, it will big offset between IDR and require frame #.<BR>>>><BR>>>>Say in english please?<BR>>>><BR>>>>>3)Usually end user
do not have accurate idea about exact frame #. <BR>>>>>If you force set the frame # become IDR, it will increase stream <BR>>>>>data overhead.<BR>>>><BR>>>>If the user doesn't know the exact frame numbers, how is he <BR>>>>supposed to split the video either? And if you want some algorithm <BR>>>>to find scenecuts, what's wrong with the current one?<BR>>>><BR>>>>>4)The best approach to give the time duration or output bitstream <BR>>>>>size. Let program determine which frame numbers are and carry the <BR>>>>>extract output.<BR>>>><BR>>>>How does time duration differ from frame number? Just multiply by <BR>>>>fps.<BR>>>>And splitting by output bitstream size is a completely different
<BR>>>>goal.<BR>>>><BR>>>><BR>>>>P.S. please don't top-post, and please don't break threading.<BR>>>><BR>>>>--Loren Merritt<BR>>>><BR>>>>--<BR>>>>This is the x264-devel mailing-list<BR>>>>To unsubscribe, go to: http://developers.videolan.org/lists.html<BR>>>><BR>>><BR>>>_________________________________________________________________<BR>>>Play games, earn tickets, get cool prizes. Play now–it's FREE! <BR>>>http://club.live.com/home.aspx?icid=CLUB_hotmailtextlink1<BR>>><BR>><BR>>_________________________________________________________________<BR>>Don’t miss your chance to WIN $10,000 and other great prizes from <BR>>Microsoft Office Live <BR>>http://clk.atdmt.com/MRT/go/aub0540003042mrt/direct/01/<BR>><BR>>--<BR>>This is the x264-devel
mailing-list<BR>>To unsubscribe, go to: http://developers.videolan.org/lists.html<BR>><BR></FONT></BLOCKQUOTE></DIV></div><br clear=all><hr> <a href="http://g.msn.com/8HMBENUS/2734??PS=47575" target="_top">Need a break? Find your escape route with Live Search Maps.</a> </html>
--
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html