[mythtv-users] mythcommflag prob (was How to transcode HD recording)
HP-mini
blm-ubunet at slingshot.co.nz
Fri Jan 24 22:25:12 UTC 2014
On Fri, 2014-01-24 at 21:39 +0000, John Pilkington wrote:
> On 23/01/14 23:53, John Pilkington wrote:
> > On 23/01/14 09:44, John Pilkington wrote:
> >
> >>
> >> Noted, thanks, I'll try a new build.
> >>
> >
> > Patched build of 0.27-fixes is working fine for me. I've updated the
> > ticket. Thank you!
> >
>
>
> The patched code works but the revised explanation seems to me to suffer
> from too many and conflicting negatives. I think this is clearer - and
> probably explains what is happening: :-)
>
> + // H.264 recordings from an HD-PVR contain IDR-keyframes,
> + // When these are present they are the only valid cut points +
> // for lossless cuts.
> + // DVB-S(2)/T(2) H.264 recordings typically do not contain
> + // IDR-keyframes & use non-IDR I-frames as keyframes.
> + // Initially we look for non-IDR I-frames.
> + // If we get far enough into the rebuild without having
> + // created any seektable entries, we assume that this
> + // setting is wrong, and so we rewind and
> + // look for IDR-keyframes as used by the HD-PVR.
>
> Cheers,
>
> John
>
AFAIK Broadcast DVB H264 does not use IDR or I frames as keyframes.
Keyframes are invariably periodic intra-refresh B frame sequences
signalled by SEI messages. There can be I slices but they are not
necessarily keyframes..
The "rewind & try again" logic should never be needed for HD-PVR or DVB
H264. It makes some sense to allow I frames as keyframes iff nothing
else can be detected/found.
The "first pass" thru' parser finds any IDR & SEI signalled keyframes...
More information about the mythtv-users
mailing list