Suspicion that valid random access point is not marked as keyframe in AVCHD samples from Panasonic Lumix GH1

[rmk]

AVCHD files from a camera (Panasonic Lumix GH1) demux and
decode with libavformat/libavcodec detecting no other keyframe but the
first (both, the first video packet and video frame are marked as
keyframe), which is not what I would have expected for those clips as
the GOP structure of files produced by this camera is known to be
different.

I observed the following things when looking at the 720p sample:

• there are no recovery point SEIs or IDRs after the first frame
• before every I-frame/slice there is an SPS
• seeking in these files works fine in FCPX import dialog, so I guess they do not decode the entire file on every seek (they do however maybe use auxiliary AVCHD files to find these random access points)
• the stream decodes fine if one takes just the packets starting from a packet that contains an I-slice

[Carl Eugen Hoyos]

Uploaded a stream copy of the first 59 frames:

IDR - P - P - P - P - P - P - P - P - P - P - P - P - P - P - P - P - P - P - P - P - P - P - P - P - P - I - P - P - P - P - P - P - P - P - P - P - P - P - P - P - P - P - P - P - P - P - P - P - P - P - P - I - P - P - P - P - P - P
 1    2                                                                                              26  27  28                                                                                              52  53  54 

One IDR frame, 25 P frames, one I frame, 25 P frames, one I frame, six P frames.
Iiuc, FFmpeg sees recovery points at (the first frame), the 28th frame and the 54th frame, ie it does not seek to the I frames, but to the P frames immediately following the I frames (except with -flags2 showall)

[Carl Eugen Hoyos]

​http://thread.gmane.org/gmane.comp.video.ffmpeg.libav.user/11943

[Michael Niedermayer]

fixed in e0b2bdd37a019360117528dc08e8d16e8d83c08b

[rmk]

Great, thanks for the quick fix!

Shall I open a new ticket for the other (1080i) sample from the camera? There it still reports only a keyframe at the start although I can also decode the frame (and the following ones) without errors if I cut the file at any point starting at the packet containing an I-slize.

[rmk]

Confirmed fixed for the attached 720p sample.

[Carl Eugen Hoyos]

Replying to rmk:

Confirmed fixed for the attached 720p sample.

Didn't you already confirm in comment:4?