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

Colin Ward lists
Sun Oct 23 07:53:08 CEST 2005

Rich Felker wrote:


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

   Regardless of what work the codec and/or container code has to do, if 
it isn't setting the pts of each frame that it decodes then it isn't 
doing its job properly!  And if the codec and/or container code doesn't 
set the pts properly then each and every programmer who writes a program 
based on FFMPEG is going to have to reinvent the wheel and calculate the 
pts himself, which isn't easy.

   Unless I have misunderstood what you have said?

[Hitman/Code HQ - 6502/z80/68000/604e/80x86/ARM coder - Amiga rulez!]
[VZ-200/VIC-20/MZ-700/c16/c64*10/c128*8/Plus-4/CPC464/CD32/500*2    ]
[600/1000/1200*2/A4000/SNES/N64/Dreamcast/Athlon 1100/AmigaOne      ]
[Assembly Language: The most fun you can have with your clothes on! ]

More information about the ffmpeg-devel mailing list