[FFmpeg-devel] Two problems with MPEG2 decoder

[Joseph Artsimovich]

On 26/02/2013 19:23, Nicolas George wrote:
> L'octidi 8 ventôse, an CCXXI, Joseph Artsimovich a écrit :
>> 					 When I use FFMpeg's C API
>> (through libquicktime in this case), I get a frame shift, which is
>> even worse.
> I agree this would be worse, but are you absolutely sure that is what you
> get? Compare this:
>
> correct frame, pts = 1234
> correct frame, pts = 1235
> broken frame, undecoded
> correct frame, pts = 1237
> correct frame, pts = 1238
>
> and this:
>
> correct frame, pts = 1234
> correct frame, pts = 1235
> broken frame, undecoded
> correct frame, pts = 1236
> correct frame, pts = 1237
>
> A "frame shift" is the second one, and it is bad indeed, but the fact that
> the ffmpeg command-line tool produces a duplicated frame seems to indicate
> that the pts are correct, like in the first snippet.
I have to admit I didn't check for gaps in PTS. When working with 
QuickTime you generally don't check for such things, as QuickTime does 
allow variable-length frames. If there is indeed a gap in PTS, that does 
make the problem less severe.

Still, I'd like to see these kind of frames successfully decoded, and I 
am willing to contribute the code to make it happen. At this point 
though, it's not clear to me how to tell a redundant (and possibly 
invalid) picture header from a valid second one.

-- 
Joseph Artsimovich
Senior C++ Applications Developer
MirriAd Ltd