#2336 closed defect (invalid)
Incorrect seeking/decoding for AVCHD file
Reported by: | rmk | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | undetermined |
Version: | unspecified | Keywords: | h264 |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description (last modified by )
It appears seeking is incorrect and a frame gets duplicated when dealing with the attached AVCHD sample.
Please check the output for the attached small sample file for the two command lines (file is 25 FPS AFAIK it is a PsF file):
ffmpeg -ss 0.04 -i gh2-50i-psf.mts -vframes 1 frame-2-ss.jpg ffmpeg version N-50443-g454c5d1 Copyright (c) 2000-2013 the FFmpeg developers built on Mar 3 2013 11:03:34 with llvm-gcc 4.2.1 (LLVM build 2336.11.00) configuration: libavutil 52. 17.103 / 52. 17.103 libavcodec 54. 92.100 / 54. 92.100 libavformat 54. 63.102 / 54. 63.102 libavdevice 54. 3.103 / 54. 3.103 libavfilter 3. 41.100 / 3. 41.100 libswscale 2. 2.100 / 2. 2.100 libswresample 0. 17.102 / 0. 17.102 Input #0, mpegts, from 'gh2-50i-psf.mts': Duration: 00:00:01.38, start: 0.710178, bitrate: 46737 kb/s Program 1 Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 50 tbr, 90k tbn, 50 tbc Stream #0:1[0x1100]: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, fltp, 192 kb/s Stream #0:2[0x1200]: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090) Output #0, image2, to 'frame-2-ss.jpg': Metadata: encoder : Lavf54.63.102 Stream #0:0: Video: mjpeg, yuvj420p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 90k tbn, 25 tbc Stream mapping: Stream #0:0 -> #0:0 (h264 -> mjpeg) Press [q] to stop, [?] for help [h264 @ 0x7fd3093c6000] Missing reference picture, default is 0 [h264 @ 0x7fd3093c6000] decode_slice_header error frame= 1 fps=0.0 q=0.0 Lsize=N/A time=00:00:00.04 bitrate=N/A video:138kB audio:0kB subtitle:0 global headers:0kB muxing overhead -100.015517% and ffmpeg -i gh2-50i-psf.mts -vframes 8 frame-%d-vframes.jpg ffmpeg version N-50443-g454c5d1 Copyright (c) 2000-2013 the FFmpeg developers built on Mar 3 2013 11:03:34 with llvm-gcc 4.2.1 (LLVM build 2336.11.00) configuration: libavutil 52. 17.103 / 52. 17.103 libavcodec 54. 92.100 / 54. 92.100 libavformat 54. 63.102 / 54. 63.102 libavdevice 54. 3.103 / 54. 3.103 libavfilter 3. 41.100 / 3. 41.100 libswscale 2. 2.100 / 2. 2.100 libswresample 0. 17.102 / 0. 17.102 Input #0, mpegts, from 'gh2-50i-psf.mts': Duration: 00:00:01.38, start: 0.710178, bitrate: 46737 kb/s Program 1 Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 50 tbr, 90k tbn, 50 tbc Stream #0:1[0x1100]: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, fltp, 192 kb/s Stream #0:2[0x1200]: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090) Output #0, image2, to 'frame-%d-vframes.jpg': Metadata: encoder : Lavf54.63.102 Stream #0:0: Video: mjpeg, yuvj420p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 90k tbn, 25 tbc Stream mapping: Stream #0:0 -> #0:0 (h264 -> mjpeg) Press [q] to stop, [?] for help frame= 8 fps=0.0 q=0.0 Lsize=N/A time=00:00:00.32 bitrate=N/A dup=1 drop=0 video:1031kB audio:0kB subtitle:0 global headers:0kB muxing overhead -100.002084%
Two things seem to be wrong: The seeking (-ss) does not produce the correct frame (it's equivalent to the 8th frame of the second command) and if just dumping frames, it seems the first frame is duplicated.
I ran into this when I noticed that our application, written based on libavcodec/avformat did not work correctly when seeking in these files. This is only an attempt to make this reproducible with ff* tools, because I hope the reason for the incorrect behaviour of avformat_seek_file for these files is the same as for the described ffmpeg behaviour but I do not know that for sure.
Change History (3)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
Description: | modified (diff) |
---|---|
Keywords: | h264 added |
Resolution: | → invalid |
Status: | new → closed |
(Iiuc, you are reporting two independent issues, please don't do that, it makes following tickets impossible, open one ticket per problem.)
The sample you uploaded starts with a keyframe, the next keyframe is the eighth frame, so seeking a very small amount of time will seek to the eighth frame, this is the only way seeking can work if you need the complete frame, you can use -flags2 showall if you want to seek exactly to the given time and don't care about keyframes (this is what MPlayer does for performance reasons). Move -ss in front of the output file to get a completely different behaviour that imo cannot really be called "seeking", instead it decodes all frames until the specified time.
Regarding your second problem, I have to guess (missing information) but I suspect you are choosing an output container that only supports constant frame rate. To achieve constant frame rate for the given sample, the first frame has to be duplicated, use -vsync 0 to avoid this.
comment:3 by , 12 years ago
To make that clear, my real problem ist that avformat_seek_file does not work as documented for these files and I am trying to find a way to file a ticket that makes it easy for you to reproduce that something is wrong with seeking, so maybe I should not have reported the other (accidental observation about the duplicated frame) and probably I failed with this attempt.
Sorry for wasting your time. I will think of another way to make that problem reproducible and prepare the next attempt better. If you could not throw away the file for a few more days, I would reference it in a new report or shall I just re-upload it then?
Uploaded the file to /incoming/ticket2336/gh2-50i-psf.mts