Keyframes not reported as such for Panasonic GH2 Clips

[rmk]

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

[rmk]

Uploaded sample to /incoming/ticket3063/gh2_1080i.mts

[Carl Eugen Hoyos]

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

[rmk]

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.

[Carl Eugen Hoyos]

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".

[rmk]

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

[Carl Eugen Hoyos]

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

[rmk]

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).

[Michael Niedermayer]

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

[rmk]

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!

[Michael Niedermayer]

Fixed in 7ef01a7878149de43aa49e676a343ca67b24c6b2