[FFmpeg-trac] #2336(undetermined:closed): Incorrect seeking/decoding for AVCHD file
FFmpeg
trac at avcodec.org
Thu Mar 7 22:48:58 CET 2013
#2336: Incorrect seeking/decoding for AVCHD file
-------------------------------------+-------------------------------------
Reporter: rmk | Owner:
Type: defect | Status: closed
Priority: normal | Component:
Version: unspecified | undetermined
Keywords: h264 | Resolution: invalid
Blocking: | Blocked By:
Analyzed by developer: 0 | Reproduced by developer: 0
-------------------------------------+-------------------------------------
Changes (by cehoyos):
* keywords: => h264
* status: new => closed
* resolution: => invalid
Old description:
> 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.
New description:
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.
--
Comment:
(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.
--
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2336#comment:2>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list