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

[rmk]

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

[Carl Eugen Hoyos]

Isn't this a duplicate of ticket #3063?

[Elon Musk]

Replying to cehoyos:

Isn't this a duplicate of ticket #3063?

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

[Carl Eugen Hoyos]

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?

[rmk]

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

[Carl Eugen Hoyos]

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

[rmk]

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.

[rmk]

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

[Balling]

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.