[Ffmpeg-devel] mpeg4 avi, corrupted frames when CODEC_FLAG_TRUNCATED is set
Rich Felker
dalias
Fri Oct 21 16:02:55 CEST 2005
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
More information about the ffmpeg-devel
mailing list