[Ffmpeg-devel] mpeg4 avi, corrupted frames when CODEC_FLAG_TRUNCATED is set

[Rich Felker]

On Fri, Oct 21, 2005 at 02:32:15PM +0800, Colin Ward wrote:
> 
> Rich Felker wrote:
> >
> 
>   [Snip]
> 
> >Actually I think the issue is that XVID is incompliant with mpeg4,
> >probably using packed B frames or something idiotic like that..
> >Anyway, never use CODEC_FLAG_TRUNCATED with avi or any other frame
> >based container.
> 
>   I am using this because it was in the example program on which I 
> based my media player, and it was never sufficiently explained (like a 
> lot of things in FFMPEG) what it is and exactly when it is needed.
> 
>   This issue seems like the AVFrame->pts issue in that it is a bit of a 
> mystery to most people and aguably shouldn't be there anyway, as all 
> containers and codecs should work in the same way, from the user's point 
> of view.  ie.  It shouldn't matter if the codec is handling packet 
> boundaries or how it is calculating the pts.  It should "just work."

Then we'd have slow unusable bloated crap. For some broken formats
(like avi with B frames), obtaining pts is an UNBOUNDED operation. It
requires arbitrary demuxing into the future by max_b_frames (which
isn't known by the demuxer) and parsing of the codec-specific data to
determine which frames are I/P and which are B. How do you propose we
handle this? IIRC there was a flag to force the demuxer to always do
whatever is necessary to fully determine pts, but you have to manually
set it since it significantly increases overhead of demuxing..

>   So the great question is: If I have a media player that plays AVI, 
> MPEG, MOV, MP3 and OGG files, how do I know when this flag should be on 
> and when it shouldn't?

If you don't know when it should be set, then it should never be set.
:) AFAIK, anyway..

Rich