[FFmpeg-cvslog] h264dec: Dont display trash before a keyframe.

[John Stebbins]

Hi,

On 09/17/2011 05:31 PM, Michael Niedermayer wrote:
> On Sun, Sep 18, 2011 at 02:19:32AM +0200, Reimar Döffinger wrote:
>> On 17 Sep 2011, at 22:02, git at videolan.org (Michael Niedermayer) wrote:
>>> ffmpeg | branch: master | Michael Niedermayer <michaelni at gmx.at> | Sat Sep 17 19:59:48 2011 +0200| [a64b028aeb6579636e578ceb73f69b468bddb2f0] | committer: Michael Niedermayer
>>>
>>> h264dec: Dont display trash before a keyframe.
>>> Fixes Ticket472
>>> This may (or may not) cause problems with files that have no keyframes.
>>> Plese open a bugreport or mail me if you have a file for which this fails.
>>
>> I strongly dislike this. The user might prefer that "trash" (which fore some streams might be fairly good quality, and for streaming trash is a whole lot better than having to wait several seconds before anything happens at all), and FFmpeg shouldn't just decide what is better.
> 
> Do you have such a stream, so i can improve the code?
> 
> 
>> Even more since I think H.264 is now the only codec that does this, IMO this is an inconsistent mess.
> 
> mpeg1 + mpeg2 behave this way since 3 years and noone complained
> 
> commit 9bd005bdbcb6494557cff7392a141fb3f9c3c761
> Author: Michael Niedermayer <michaelni at gmx.at>
> Date:   Sat Jan 5 01:14:09 2008 +0000
> 
>     Drop non key frames before the first key frame.
> 
>     Originally committed as revision 11411 to svn://svn.ffmpeg.org/ffmpeg/trunk
> 
>  libavcodec/mpeg12.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> 
> 
>> There are many simple and more useful ways of solving this, I suggested several like adding an error flag to the context or to AVFrame but nobody showed real interest, instead it's such a "oh, let's break it for the _other_ half of users I instead" solution :-(
> 
> Better solution is welcome, but default should be no trash because
> this is what a non geek user would expect. And it is what any kind
> of professional would require. Also think of editing
> 
> [...]
> 
> 

Since I'm not a regular around here, my opinion probably doesn't count
for much, but I mildly disagree with this as well :p. I do agree that
this this is something that belongs at application level (or as an
option that can be disabled).  We do this in HandBrake for instance. And
I've implemented set-top box based players that required the opposite
behaviour (so that channel changes "appeared" to be faster).

On a related note, this patch alone will not eliminate all cases of
garbage at the beginning when the first "keyframe" is a recovery point.
As implemented, ffmpeg flags the frame where the recovery point is
initially seen as a keyframe.  But a fully reconstructed frame will not
exist till frame_num == h->frame_num + h->sei_recovery_frame_cnt % (1 <<
h->sps.log2_max_frame_num).  Here's a patch for this if it interests you.

-- 
John      GnuPG fingerprint: CADFA1DB594CA50EB79427284617578AADE759A1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffmpeg.recovery-point.diff
Type: text/x-patch
Size: 2054 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-cvslog/attachments/20110917/f935bfde/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-cvslog/attachments/20110917/f935bfde/attachment.asc>