[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