initial seek in msrle causes failure to display on some avi files

[DonMoir]

If you do a seek prior to calling avcodec_decode_video2 at least once, then you will no longer get any video stream packets with the attached files. The seek works fine after you call avcodec_decode_video2 but not if you tried to seek prior to this. Reading a first video packet is not enough.

It can be any seek like -ss 0, --ss 1, etc.

The audio is ok.

[DonMoir]

ffplay -ss 0 clock.avi
ffplay version N-40301-gc1fe2db Copyright (c) 2003-2012 the FFmpeg developers

built on May 3 2012 11:42:19 with gcc 4.6.3
configuration: --disable-static --enable-shared --enable-gpl
--enable-version3 --disable-w32threads --enable-runtime-cpudetect
--enable-avisynth --enable-bzlib --enable-frei0r --enable-libass
--enable-libcelt --enable-libopencore-amrnb --enable-libopencore-amrwb
--enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-libnut
--enable-libopenjpeg --enable-librtmp --enable-libschroedinger
--enable-libspeex --enable-libtheora --enable-libutvideo --enable-libvo-aacenc
--enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264
--enable-libxavs --enable-libxvid --enable-zlib
libavutil 51. 49.100 / 51. 49.100
libavcodec 54. 17.101 / 54. 17.101
libavformat 54. 3.100 / 54. 3.100
libavdevice 53. 4.100 / 53. 4.100
libavfilter 2. 72.104 / 2. 72.104
libswscale 2. 1.100 / 2. 1.100
libswresample 0. 11.100 / 0. 11.100
libpostproc 52. 0.100 / 52. 0.100

[avi @ 012a0200] non-interleaved AVI
[avi @ 012a0200] max_analyze_duration 5000000 reached at 5008435
Input #0, avi, from 'clock.avi':

Duration: 00:00:12.00, start: 0.000000, bitrate: 55 kb/s

Stream #0:0: Video: msrle ([1][0][0][0] / 0x0001), pal8, 321x321, 1 fps, 1 tbr, 1 tbn, 1 tbc
Metadata:

title : CLOCK.avi Video #1

Stream #0:1: Audio: truespeech ("[0][0][0] / 0x0022), 8000 Hz, 1 channels, s16, 8 kb/s
Metadata:

title : Microsoft Waveform: 12TONEt2.WAV

[buffersink @ 012a8280] auto-inserting filter 'auto-inserted scale 0' between
the filter 'src' and the filter 'out'
[scale @ 012a81a0] w:321 h:321 fmt:pal8 sar:0/1 -> w:321 h:321 fmt:yuv420p sar:0
/1 flags:0x4
1336136307.52 A-V:1336136307.501 fd= 0 aq= 25KB vq= 31KB sq= 0B f=0/0

5.76 A-V: -0.245 fd= 0 aq= 22KB vq= 17KB sq= 0B f=0/0

[cehoyos]

Is this problem also reproducible with ffmpeg?

[DonMoir]

I tried ffmpeg -ss 0 clock.avi temp.avi and temp.avi was displayable.

ffmpeg -ss 1 clock.avi temp2.avi and temp2.avi had no display.

When I do a Seek to zero seconds (or any time) in my own app on startup, I don't get any display. It appears all processing is normal and I get finished frames etc, but it appears they are all black. If I do a seek after at least one frame has been processed, seek at any time works fine. Similiar to behavior seen with ffplay. Although ffplay has a problem displaying the clock.avi without -ss. The image is skewed. This doesn't have anything to do with the seek problem and the skew problem with ffplay may be a regression.

In my own app and other players the clock.avi displays fine (no skew problem) as long as I don't do a seek on startup in my own app.

[DonMoir]

For a work around, if the codec_id is CODEC_ID_MSRLE or CODEC_ID_MSVIDEO1, I am having to call av_read_frame until I get a video packet and then call avcodec_decode_video2 once. I can then do the seek and get expected results. I do this before I start up normal processing.

[cehoyos]

I suspect this behaviour is expected for videos containing a palette.

[DonMoir]

Fixes clock.avi but does not fix filecopy.avi which is CODEC_ID_MSRLE.

[DonMoir]

This file also fails CODEC_ID_MSVIDEO1

 http://sms.pangolin.com/temp/EVBPIC.AVI

[cehoyos]

Replying to DonMoir:

This file also fails CODEC_ID_MSVIDEO1

 http://sms.pangolin.com/temp/EVBPIC.AVI

Please open a new ticket for the sample that has different parameters, do not forget to add a failing command line together with complete, uncut console output.

[cehoyos]

Replying to DonMoir:

This file also fails CODEC_ID_MSVIDEO1

 http://sms.pangolin.com/temp/EVBPIC.AVI

This is ticket #296.

[DonMoir]

Ticket #296 is a different issue. The conditions in 296 are simply because there are not many keyframes. This issue (1273) is because any attempt to seek before the first avcodec_decode_video2 even to initial keyframe, causes failure to display. Completely different issues.

I have no problem with any of the files referenced in 296, but it's an awkward work around for issue 1273.

Just because EVBPIC.AVI is in both 296 and 1273 doesn't mean it's the same issue.