<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 26 March 2016 at 05:52, HP-mini <span dir="ltr"><<a href="mailto:blm-ubunet@slingshot.co.nz" target="_blank">blm-ubunet@slingshot.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span>On Thu, 2016-03-24 at 10:07 +0000, Stuart Auchterlonie wrote:<br>
> On 23/03/16 03:10, Anthony Giggins wrote:<br>
> > This hasn't been a problem until recently but due to h.264 channels<br>
> > being pushed out in AU, I can no longer use the inbuilt mythtv<br>
> > transcoding for this recordings, I've<br>
> > found <a href="https://www.mythtv.org/wiki/Lossless_Cut" rel="noreferrer" target="_blank">https://www.mythtv.org/wiki/Lossless_Cut</a> which works but does not<br>
> > mark these recordings as "Transcoded" in the database, while I can<br>
> > manually mark these are recorded in the database I'd rather use a<br>
> > approved method (API or utility) is there any current API function or<br>
> > util that can do this?<br>
> ><br>
> > or even better has the inbuilt transcoder been updated (perhaps in<br>
> > master) to handling h.264?<br>
> ><br>
><br>
> Unfortunately not. It's on the todo list, but nobody has yet implemented<br>
> lossless transcoding for h264 recordings :(<br>
><br>
> I'd love to see it to, having far to many childrens shows in HD with<br>
> extra data i can't remove at this time<br>
><br>
><br>
> Regards<br>
> Stuart Auchterlonie<br>
> MythTV Developer<br>
><br>
> _______________________________________________<br>
<br>
</span>The beauty of transport streams & h264 is that transcoding can be<br>
avoided (unless you must use H265!).<br>
Non-transcode Cutting a 1 hour (5GB) file only takes 1-2 minutes on a<br>
core2duo while using cutlist editor on another file.<br>
<br>
Off topic background on LosslessCut..<br>
When it was first released it didn't get much attention outside of<br>
HD-PVR (US) because mkvmerge (mkvtoolnix) couldn't handle LATM AAC which<br>
is normally used with broadcast H264.<br>
Mkvtoolnix added LATM AAC support in Jan 2015.<br>
A user job script to remux LATM AAC to AAC was simple enough.<br>
Some effort was required to get mythtv's H264Parser frame/byte/usec<br>
accurate.<br>
<br>
OTA Broadcast streams have the audio data delayed w.r.t. video data to<br>
allow time for video post processing in memory weak devices.<br>
It can be seen that recording starts playback in VLC with audio & no<br>
video (for split second).<br>
<br>
Mkvmerge cuts at the keyframe on or after the chapter or timecode.<br>
Mkvtoolnix's "time zero" is the lowest time stamp found in stream which<br>
will be an audio packet with broadcast (& typically 0.5sec before<br>
video).<br>
MythTV's "time zero" is first video packet & should be keyframe if use<br>
Start-on-SEQ/SPS.<br>
It's fairly obvious how this can result in inaccurate cutting but it<br>
should be soluble by probing file for AV packet offset with mediainfo /<br>
ffprobe / mkvinfo? & adjusting the cut times for mkvmerge.<br>
<br>
I believe the author never saw this problem because of using HD-PVR<br>
device.<br>
<div><div><br></div></div></blockquote><div><br></div><div><div class="gmail_extra"><div class="gmail_quote"><div>FYI, I hacked a simple solution into the lossless cut script /usr/bin/lossless_cut </div><div><br></div><div>I just added the below after the $LAUNCHER $* line</div><div>echo "update recorded set transcoded = 1 where basename like '%.mkv';" | mysql -uUSERNAME -pPASSWORD mythconverg<br></div></div><br></div><div class="gmail_extra">please note you'll need to replace your username and password to the mysql database to make this work, please use at your own risk :)</div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Anthony</div></div></div></div></div>