[FFmpeg-trac] #3087(undetermined:new): Suspicion that valid random access point is not marked as keyframe in AVCHD samples from Panasonic Lumix GH1 (1080i material)

FFmpeg trac at avcodec.org
Sun Oct 27 18:31:22 CET 2013


#3087: Suspicion that valid random access point is not marked as keyframe in AVCHD
samples from Panasonic Lumix GH1 (1080i material)
-------------------------------------+-------------------------------------
             Reporter:  rmk          |                     Type:  defect
               Status:  new          |                 Priority:  normal
            Component:               |                  Version:
  undetermined                       |  unspecified
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 This is a follow-up to #3083.

 The issue is very similar here, that I-frames that work as random access
 points (checked by cutting off the beginning of the file until the packet
 start of such a frame and it decodes fine) are not marked as keyframes by
 the parser.

 The heuristic introduced to fix #3083

 if(h->sps.ref_frame_count <= 1 && h->pps.ref_count[0] <= 1 && s->pict_type
 == AV_PICTURE_TYPE_I)
       s->key_frame = 1;

 fails here because both, h->sps.ref_frame_count and h->pps.ref_count[0]
 are 2.

 I understand too little of h264 internals to say how that may be changed
 but maybe the heuristic does not cover the interlaced case.

 I don't know if it has anything to do with it but this material is
 progressive segmented frame (i.e. progressively scanned but encoded as
 field pictures).

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/3087>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker


More information about the FFmpeg-trac mailing list