[Ffmpeg-devel] [Bad news]: MPEG Seek has failed to work in FFmpeg SVN

[Steve Lhomme]

M?ns Rullg?rd wrote:
> Steve Lhomme said:
>>
>> M?ns Rullg?rd wrote:
>>> Steve Lhomme said:
>>>> QuickTime wrote:
>>>>> Dear:
>>>> Hi Quicktime,
>>>>
>>>>> FFmpeg fails to decode video(avcodec_decode_video() never return
>>>>> picture) after perform SEEK on mpeg file format
>>>>>
>>>>> It seems that the seek&decode abiliity for mpeg files have been broken
>>>>> for 2 months(ealier than August )
>>>>>
>>>>> ffmpeg  -ss 00:00:10 -i test.mpg  -r 25 test.mp4
>>>>> .....
>>>>> Input #0, mpeg, from 'test.mpg':
>>>>>  Duration: 00:00:24.0, start: 0.346711, bitrate: 2314 kb/s
>>>>>  Stream #0.0[0x1e0]: Video: mpeg1video, yuv420p, 352x288, 2000 kb/s,
>>>>> 25.00 fps(r)
>>>>>  Stream #0.1[0x1c0]: Audio: mp2, 44100 Hz, stereo, 192 kb/s
>>>>> Output #0, mp4, to 'test.mp4':
>>>>>  Stream #0.0: Video: mpeg4, yuv420p, 352x288, q=2-31, 200 kb/s, 25.00
>>>>> fps(c)
>>>>>  Stream #0.1: Audio: aac, 44100 Hz, stereo, 64 kb/s
>>>>> Stream mapping:
>>>>>  Stream #0.0 -> #0.0
>>>>>  Stream #0.1 -> #0.1
>>>>> frame=    0 q=0.0 Lsize=     120kB time=14.8 bitrate=  66.1kbits/s
>>>>> video:0kB audio:114kB global headers:0kB muxing overhead 4.833664%
>>>>> .....
>>>> I've had similar problems (actually crashes) with some MPEG2 samples
>>>> (from DVDs) for a long time. Maybe if you can provide a sample and say
>>>> what platform you use, it could help.
>>> Yeah, if Steve hadn't refused to provide samples, maybe this had been fixed
>>> already.
>> Look at the message "Re: [Ffmpeg-devel] MPEG2 decoding problems" from
>> 2006-03-02 there is a chems1.vob sample. The URL should still work.
> 
> I have a copy of the file.
> 
>> It was not fixed because you need to seek at a specific place in the
>> file to crash. Maybe you can manage to do that by doing a
>> forward/backward seek in ffplay during a specific fraction of second
>> during playback. I proposed to modify ffplay to test it but it was
>> rejected...
> 
> We do not support modified versions of ffmpeg.  If this is really a bug in
> our code (and caused by your mods), it should be possible to trigger it by
> cutting that file of yours in the right spot.  Find this spot, and we'll
> look into it.  You can't expect us to do all the work.

I tried it. Unfortunately it not as simple as you write it. Our code 
uses AVSEEK_FLAG_BYTE when seeking in VOB files (since the timestamps 
may not be contiguous/accurate throughout the file). And neither 
ffmpeg.c nor ffplay.c use this flag to seek.

Cutting the original file to the seek point where it crashes for me 
didn't help. And modifying the ffmpeg.c to use this flag didn't help 
neither. Even when using our modified version that uses DrFFMPEG.

So the problem is dynamic. You need to read/decode frames before seeking 
for the crash to occur. That's why only trying with ffplay produces the 
crash. And only after modifying it (since it's dynamic it's almost 
impossible to seek to the location where you want it to crash).

Since AVSEEK_FLAG_BYTE is not used in the ffmpeg/ffplay code, does it 
means it's not supported and no bug report are considered ? Same 
question with dynamic issues (from a legitimate use of 
libavcodec/libavformat).

Steve