Opened 10 years ago

Closed 10 years ago

Last modified 8 years ago

#3063 closed defect (fixed)

Keyframes not reported as such for Panasonic GH2 Clips

Reported by: rmk Owned by:
Priority: normal Component: avcodec
Version: unspecified Keywords: h264
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description (last modified by Clément Bœsch)

Demuxing/decoding AVCHD files from this camera using libavformat and liavcodec gives inconsistent results regarding keyframes. For this particular type of clip certain video packets are marked as keyframe packets (consistent with what is known about the GOP size of the camera from other sources) but the decoded frames are not (with the exception of the first frame). This can be reproduced using ffprobe (see two command lines below). The file was shortened using DD but the behaviour is the same for the unmodified camera file except for the warning "PES packet size mismatch".

% ffprobe -select_streams 0 -show_frames gh2_1080i.mts | grep key_frame=1
ffprobe version N-57272-gc9a22d6 Copyright (c) 2007-2013 the FFmpeg developers
  built on Oct 20 2013 12:30:23 with llvm-gcc 4.2.1 (LLVM build 2336.11.00)
  configuration: 
  libavutil      52. 47.101 / 52. 47.101
  libavcodec     55. 37.102 / 55. 37.102
  libavformat    55. 19.103 / 55. 19.103
  libavdevice    55.  4.100 / 55.  4.100
  libavfilter     3. 88.102 /  3. 88.102
  libswscale      2.  5.101 /  2.  5.101
  libswresample   0. 17.104 /  0. 17.104
[mpegts @ 0x7fed4c00d400] PES packet size mismatch
    Last message repeated 1 times
Input #0, mpegts, from 'gh2_1080i.mts':
  Duration: 00:00:01.00, start: 0.710178, bitrate: 40960 kb/s
  Program 1 
    Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 25.58 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), 1920x1080
key_frame=1
[mpegts @ 0x7fed4c00d400] PES packet size mismatch
% ffprobe -select_streams 0 -show_packets gh2_1080i.mts | grep flags=K
ffprobe version N-57272-gc9a22d6 Copyright (c) 2007-2013 the FFmpeg developers
  built on Oct 20 2013 12:30:23 with llvm-gcc 4.2.1 (LLVM build 2336.11.00)
  configuration: 
  libavutil      52. 47.101 / 52. 47.101
  libavcodec     55. 37.102 / 55. 37.102
  libavformat    55. 19.103 / 55. 19.103
  libavdevice    55.  4.100 / 55.  4.100
  libavfilter     3. 88.102 /  3. 88.102
  libswscale      2.  5.101 /  2.  5.101
  libswresample   0. 17.104 /  0. 17.104
[mpegts @ 0x7ffe7100d400] PES packet size mismatch
    Last message repeated 1 times
Input #0, mpegts, from 'gh2_1080i.mts':
  Duration: 00:00:01.00, start: 0.710178, bitrate: 40960 kb/s
  Program 1 
    Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 25.58 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), 1920x1080
flags=K
flags=K
flags=K
flags=K
flags=K
flags=K
flags=K
[mpegts @ 0x7ffe7100d400] PES packet size mismatch
flags=K

Attachments (1)

gh2_1080i.h264 (2.2 MB ) - added by Carl Eugen Hoyos 10 years ago.

Change History (12)

comment:1 by rmk, 10 years ago

Uploaded sample to /incoming/ticket3063/gh2_1080i.mts

comment:2 by Carl Eugen Hoyos, 10 years ago

Keywords: h264 added

I suspect the concept of "keyframes" is difficult to apply to field-encoded streams.

by Carl Eugen Hoyos, 10 years ago

Attachment: gh2_1080i.h264 added

comment:3 by rmk, 10 years ago

Why? If a "keyframe" can be defined as a frame (or pair of fields) from which on decoding will be fine after a random access, I don't see that the concept does not work and it seems to work just fine for most interlaced stream we have been dealing with in our application but maybe I am missing something.

comment:4 by Carl Eugen Hoyos, 10 years ago

If one of the two fields can be decoded independently but the other field depends on earlier data, I don't think "decoding will be fine" applies in the general case, ie setting the key_frame flag would not be correct if you interpret it as "recovery point found".

comment:5 by rmk, 10 years ago

In that case it should of course set key_frame to 0 by my definition. I don't see what's the problem.

comment:6 by Carl Eugen Hoyos, 10 years ago

So is there an issue in your opinion or is FFmpeg behaving as you expect?

comment:7 by rmk, 10 years ago

I did some more debugging and IMHO there is an issue as in this case it seems the frame (although encoded as fields) is in one NAL unit and correctly announced as a recovery point by a recovery point SEI and the parser/demuxer treats it correctly as a keyframe packet (as documented in AVPacket), so it seems inconsistent that the frame decoded from that packet is not marked as a keyframe (regardless of whether it is field-encoded).

comment:8 by Michael Niedermayer, 10 years ago

Patch to fix this is on ffmpeg-devel, please test

comment:9 by rmk, 10 years ago

Yes, with patch decoder finds same number of key frames and the PTSs seem to be consistent with those of the packets marked as keyframes.

Thank you!

comment:10 by Michael Niedermayer, 10 years ago

Reproduced by developer: set
Resolution: fixed
Status: newclosed

comment:11 by Clément Bœsch, 8 years ago

Description: modified (diff)
Note: See TracTickets for help on using tickets.