[mythtv-users] Lossles Cut marking recordings as "Transcoded"

[HP-mini]

On Thu, 2016-03-24 at 10:07 +0000, Stuart Auchterlonie wrote:
> On 23/03/16 03:10, Anthony Giggins wrote:
> > This hasn't been a problem until recently but due to h.264 channels
> > being pushed out in AU, I can no longer use the inbuilt mythtv
> > transcoding for this recordings, I've
> > found https://www.mythtv.org/wiki/Lossless_Cut which works but does not
> > mark these recordings as "Transcoded" in the database, while I can
> > manually mark these are recorded in the database I'd rather use a
> > approved method (API or utility) is there any current API function or
> > util that can do this?
> > 
> > or even better has the inbuilt transcoder been updated (perhaps in
> > master) to handling h.264?
> > 
> 
> Unfortunately not. It's on the todo list, but nobody has yet implemented
> lossless transcoding for h264 recordings :(
> 
> I'd love to see it to, having far to many childrens shows in HD with
> extra data i can't remove at this time
> 
> 
> Regards
> Stuart Auchterlonie
> MythTV Developer
> 
> _______________________________________________

The beauty of transport streams & h264 is that transcoding can be
avoided (unless you must use H265!).
Non-transcode Cutting a 1 hour (5GB) file only takes 1-2 minutes on a
core2duo while using cutlist editor on another file.

Off topic background on LosslessCut..
When it was first released it didn't get much attention outside of
HD-PVR (US) because mkvmerge (mkvtoolnix) couldn't handle LATM AAC which
is normally used with broadcast H264.
Mkvtoolnix added LATM AAC support in Jan 2015.
A user job script to remux LATM AAC to AAC was simple enough.
Some effort was required to get mythtv's H264Parser frame/byte/usec
accurate.

OTA Broadcast streams have the audio data delayed w.r.t. video data to
allow time for video post processing in memory weak devices.
It can be seen that recording starts playback in VLC with audio & no
video (for split second).

Mkvmerge cuts at the keyframe on or after the chapter or timecode.
Mkvtoolnix's "time zero" is the lowest time stamp found in stream which
will be an audio packet with broadcast (& typically 0.5sec before
video).
MythTV's "time zero" is first video packet & should be keyframe if use
Start-on-SEQ/SPS.
It's fairly obvious how this can result in inaccurate cutting but it
should be soluble by probing file for AV packet offset with mediainfo /
ffprobe / mkvinfo? & adjusting the cut times for mkvmerge.

I believe the author never saw this problem because of using HD-PVR
device.