[mythtv-users] Current state-of-the-art for h264 cutlist processing?

[John Pilkington]

On 22/03/18 11:26, Mark Perkins wrote:
> 
> 
> On 22/03/18 08:26, Anthony Giggins wrote:
>>
>>
>> On 21 March 2018 at 03:36, John Pilkington <J.Pilk at tesco.net 
>> <mailto:J.Pilk at tesco.net>> wrote:
>>
>>     On 01/02/18 13:10, John Pilkington wrote:
>>
>>         Hi:  I rarely record DVB-T2 HD h264 recordings in which I want
>>         to make internal cuts, but it would be good to be able to do
>>         make them in a way that doesn't introduce glitches in playback.
>>
>>         I find that Mythfrontend does a good job in playing uncut
>>         recordings with cutlists, but uPnP then plays all the ads and
>>         skipping is painful.
>>
>>         My MythDVBcut script chops at videokeyframes; there may be
>>         glitches at cuts but there's no long-term loss of quality or
>>         a/v sync.  I've found other scripts that work similarly and
>>         are more elegantly coded. Frontend and uPnP glitches may
>>         differ in style and severity.
>>
>>         I've tried going via mkvmerge but at present see a/v sync
>>         drift and haven't found an mkv/audio format that my tv plays
>>         acceptably via uPnP
>>
>>         So, before I waste yet more time, has anyone found (or
>>         developed) a toolchain that is available and does this job
>>         properly?
>>
>>         Thanks,
>>
>>
>>     I posted that a few weeks ago.  There hasn't been much comeback,
>>     perhaps because multi-terabyte disks have become affordable, or
>>     perhaps through disillusionment, but I do now have a script that
>>     works reasonably well with UK DVB-T2 HD h264 recordings and might
>>     be useful elsewhere.  I have appended it to the MythDVBcut entry
>>     in the MythTV wiki; I've called it MythTScut.
>>
>>     It uses mythffmpeg, with mapping to give one video and one audio
>>     stream.  That could probably be changed, but I haven't tested any
>>     more.  I find that it needs two runs, the first with no cutlist,
>>     to discard unrecognised streams and get the cuts in (about) the
>>     right position.  At present the most successful commands seem to be:
>>     ============
>>     with no cutlist
>>
>>     mythTScut.sh /path/to/infile.ts R 1
>>
>>     mv infile.ts.old ... to somewhere else, say infile_orig.ts
>>
>>     establish editpoints showing wanted keyframes using the frontend
>>     editor
>>
>>     mythTScut.sh /path/to/infile.ts R 1
>>     ============
>>     The output may be either a Recording (R), replacing the renamed
>>     original file and clearing its cutlist and bookmarks, or a Video
>>     (V) which leaves these unchanged. The third parameter (1,2) is
>>     intended to define the way in which the input streams are synched,
>>     but I find that 2 is still rather unpredictable or prone to
>>     failure.  I have tried several ffmpeg options without getting
>>     anything that seemed better. YMMV
>>
>>     ffmpeg complains during both passes, which are primarily
>>     disk-speed-limited.  It still usually works.
>>
>>     Like my earlier scripts, this is intended for use from the
>>     desktop, giving feedback and creating a logfile that includes the
>>     position of the cutpoints in the output, and stream details from
>>     ffprobe.  The first page needs editing to define working
>>     directories and database access, and intermediate files are not
>>     all erased on exit.
>>
>>     I'm posting it as work-in-progress with no guarantees and no
>>     implied support, in the hope that it may be useful.
>>
>>
>>     > John P
>>
>> Thanks John,
>>
>> I'll give it a whirl, typically I just been avoiding recording h264 
>> channels where possible.
>>
>> Cheers,
>>
>> Anthony
>>
>>
> 
> This one is on my long term wish list to actually do properly, although 
> it may never happen with the way online streaming is going. I use a 
> heavily customised script that tries to be excessively clever (which 
> perhaps is another way of saying excessively complicated with minimal 
> benefit). But underpinning it is mythtranscode in FIFO mode piped into 
> ffmpeg which I have found to be excellent and pretty much flawless. I 
> must admit I haven't really looked to see whether any of my transcodes 
> have been from h264 or not but I just tried it on one and it appeared to 
> work without a noticeable glitch, and I think (maybe) it might be frame 
> accurate cuts as well. What sort of glitch do you get with your script 
> at cut points?

I can't really give a 'typical' answer because I haven't done many runs 
and changes have been made - but I've just played through 3 cuts in 'The 
Durrells' from itv HD and they weren't conspicuous.  -v playback showed 
recoveries from 'Video is n frames ahead of audio', where n was around 
12, 120, and 15.  That was processed with two 'R 1' runs.  I think the 
numbers looked smaller on an earlier recording when the second run was 
'R 2' but haven't rechecked that and its skew setting.  It looks as if 
the ffmpeg 'concat' protocol is perhaps not quite right, but I haven't 
yet ventured onto the ffmpeg lists.

ISTR that when I looked at the FIFO-mode approach it looked 
Ubuntu-specific or used a job-management feature that I have so far 
avoided.  Perhaps a mistake.  But I haven't made routine HD recordings 
anyway, and even few of those have needed internal cuts.


> 
> The biggest hold-up is checking the cut list. It is time consuming and 
> as you say with multi TB drives it has been easier to just add more 
> drives and use the skip keys. I have probably only bothered to transcode 
> a dozen programs this year.


>