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

[Michael Niedermayer]

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 for 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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-cvslog/attachments/20110918/84803438/attachment.asc>