Ticket #1273 (closed defect: fixed)
initial seek in msrle causes failure to display on some avi files
| Reported by: | DonMoir | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | undetermined |
| Version: | git-master | Keywords: | pal8 msrle seek |
| Cc: | Blocked By: | ||
| Blocking: | Reproduced by developer: | yes | |
| Analyzed by developer: | no |
Description
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.
Attachments
Change History
comment:1 Changed 13 months ago by 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
comment:3 Changed 13 months ago by 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.
The seek problem has not been noticed with any other file format and not all avi files. Has to do with msvideo1 and msrle I think.
comment:4 Changed 13 months ago by 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.
comment:5 Changed 12 months ago by cehoyos
- Keywords pal8 added
- Status changed from new to open
- Version changed from unspecified to git-master
- Component changed from avformat to undetermined
- Reproduced by developer set
I suspect this behaviour is expected for videos containing a palette.
comment:6 Changed 9 months ago by michael
- Status changed from open to closed
- Resolution set to fixed
comment:7 Changed 9 months ago by DonMoir
Fixes clock.avi but does not fix filecopy.avi which is CODEC_ID_MSRLE.
comment:8 Changed 9 months ago by cehoyos
- Keywords msrle added
- Status changed from closed to reopened
- Resolution fixed deleted
comment:9 follow-ups: ↓ 10 ↓ 11 Changed 7 months ago by DonMoir
This file also fails CODEC_ID_MSVIDEO1
comment:10 in reply to: ↑ 9 Changed 7 months ago by cehoyos
Replying to DonMoir:
This file also fails CODEC_ID_MSVIDEO1
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.
comment:11 in reply to: ↑ 9 Changed 7 months ago by cehoyos
comment:13 Changed 7 months ago by 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.
comment:14 Changed 4 months ago by michael
- Status changed from reopened to closed
- Resolution set to fixed
- Summary changed from initial seek causes failure to display on some avi files to initial seek in msrle causes failure to display on some avi files



