Opened 6 years ago

Closed 6 years ago

Last modified 6 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

Description

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

Attachments (1)

720p_copy.ts (1.7 MB) - added by cehoyos 6 years ago.

Download all attachments as: .zip

Change History (7)

Changed 6 years ago by cehoyos

comment:1 Changed 6 years ago by cehoyos

  • Keywords h264 added
  • Version changed from unspecified to git-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 Changed 6 years ago by michael

  • Reproduced by developer set
  • Resolution set to fixed
  • Status changed from new to closed

comment:4 Changed 6 years ago by 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.

comment:5 follow-up: Changed 6 years ago by rmk

Confirmed fixed for the attached 720p sample.

comment:6 in reply to: ↑ 5 Changed 6 years ago by cehoyos

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.