Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#3083 closed defect (fixed)

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

Reported by: rmk Owned by:
Priority: normal Component: undetermined
Version: git-master Keywords: h264
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no


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

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

Attachments (1)

720p_copy.ts (1.7 MB ) - added by Carl Eugen Hoyos 10 years ago.

Download all attachments as: .zip

Change History (7)

by Carl Eugen Hoyos, 10 years ago

Attachment: 720p_copy.ts added

comment:1 by Carl Eugen Hoyos, 10 years ago

Keywords: h264 added
Version: unspecifiedgit-master

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)

comment:3 by Michael Niedermayer, 10 years ago

Reproduced by developer: set
Resolution: fixed
Status: newclosed

comment:4 by rmk, 10 years ago

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.

comment:5 by rmk, 10 years ago

Confirmed fixed for the attached 720p sample.

in reply to:  5 comment:6 by Carl Eugen Hoyos, 10 years ago

Replying to rmk:

Confirmed fixed for the attached 720p sample.

Didn't you already confirm in comment:4?

Note: See TracTickets for help on using tickets.