[mythtv-users] 0.27 Some recordings immediately show end of recording dialog box

[HP-mini]

On Wed, 2014-01-01 at 09:36 -0500, Steven Adeff wrote:
> On Fri, Nov 22, 2013 at 5:09 PM, HP-mini <blm-ubunet at slingshot.co.nz> wrote:
> > skd5aner
> > Can you provide a sample recording (with beginning unadulterated) for
> > that ticket? First 60-100MB would be good.
> >
> > Steve
> > Does starting frontend with  "-O FFMPEGTS=1" fix the problem ?
> 
> after some testing, that it does! Is there anything I can provide to
> help contribute to a more proper fix?
> or is there some setting or something elsewhere I need to enable for
> how the HDPVR records?
> 
> thanks!
> 
A sample of first 100MB..(man dd)

Could try to build the recording seektable with mythcommflag.
Could try mythcommflag with "-O FFMPEGTS=1" override, I do not know if
this program accepts that option..

A possibly related commit, from ticket#11882, was made to master & 0.27
+fixes.

The HDPVR does create odd/strange H264 mpegts at HD resolutions.
There is a windows (3rd party) configuration tool that allowed changes
to H264 encoder specifics..
The linux HDPVR driver does not implement any of that.

AFAIK The only user recording option is a setting to make recordings
start on SEQ (could be dvb-t only).
The SEQ is the mpeg2video equivalent to SPS in H264.
IIUC That setting would (should?) have no effect, on H264, after commit
to ticket#11882.

SEQ is considered as any keyframe in H264. A problem is that mythtv
parser is coded to treat all HDPVR (seekable) I frames as keyframes.
This is wrong but works as intended.
Commits to #11882 at least make HDPVR recording start on real keyframe.
 
HDPVR generates HD H264 with widely spaced keyframes (about 2 sec for
720p60 128/60).
So HDPVR recordings can have up to 2sec of undecode-able (without
assumptions or reading SPS from somewhere) video at beginning.

This time/offset error probably causes some of the HDPVR cut position
errors in losslesscut script.

Brett.