[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