Opened 9 years ago

Last modified 7 months ago

#3087 open defect

Suspicion that valid random access point is not marked as keyframe in AVCHD samples from Panasonic Lumix GH1 (1080i material)

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

Description

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).

Attachments (1)

gh1_1080i_first2p5m.mts (2.4 MB ) - added by rmk 9 years ago.

Change History (12)

by rmk, 9 years ago

Attachment: gh1_1080i_first2p5m.mts added

comment:1 by Carl Eugen Hoyos, 9 years ago

Isn't this a duplicate of ticket #3063?

comment:2 by Carl Eugen Hoyos, 9 years ago

Keywords: h264 added
Version: unspecifiedgit-master

in reply to:  1 ; comment:3 by Elon Musk, 9 years ago

Replying to cehoyos:

Isn't this a duplicate of ticket #3063?

You did not reply in timely manner to question in that ticket.....

in reply to:  3 comment:4 by Carl Eugen Hoyos, 9 years ago

Replying to richardpl:

Replying to cehoyos:

Isn't this a duplicate of ticket #3063?

You did not reply in timely manner to question in that ticket.....

Which question?

comment:5 by rmk, 9 years ago

#3063 is fixed. The fix for it does not fix what's described here (see description). I asked whether I should open a new ticket for that case and now did so.

Your choice if you want to merge the two and reopen #3063. Both options are good for me.

comment:6 by Carl Eugen Hoyos, 9 years ago

Could you confirm that ticket #3063 is fixed? Preferably there in the ticket?
Thanks.

comment:7 by rmk, 9 years ago

Ups, my bad. I mixed up the numbers. I thought you meant #3083. No, this is different, i.e. not a duplicate. In that case (#3063) the parser correctly marks the frames as key frames but the decoder does not and Michael's fix only affected the parser. It's also a different camera.

comment:8 by Carl Eugen Hoyos, 9 years ago

Component: undeterminedavcodec

comment:9 by rmk, 7 years ago

I am offering a bounty of 200 Euro for a committed fix (I need an invoice though).

comment:10 by Elon Musk, 7 years ago

Keywords: bounty added
Status: newopen

comment:11 by Balling, 7 months ago

checked by cutting off the beginning of the file until the packet start of such a frame and it decodes fine

How can you be sure that it decodes fine? Does it decode BITPERFECT? Then it is not a recovery point, recovery point does not usually decode bitperct, just very close.

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).

This is just the same as soft telecine, PsF that is. Yet I think only HEVC has such a concept reintroduced, no? Anyway, we do not support such hevc files. Full stop. Someone recheck the avc spec.

Note: See TracTickets for help on using tickets.