[nicesplice]+[nicesplice-magic-folders] On box video editing

[MymsMan]

So, if it can't do so, there is probably some ffmpeg invocation that should be applied when cropping with more than 2 bookmarks. This makes a .ts with no jump that is playable except by the Humax:

ffmpeg -hide_banner -copy_unknown -fflags +genpts -i discontinuous.ts -map 0:u -c copy -mpegts_m2ts_mode 1 -mpegts_flags +system_b continuous.ts

And ffmpeg doesn't like the AD stream either (hence o:u: select "usable" streams).

I think this is just a special case of the unsolved problem "make a .mp4 into a Humax-playable .ts with sidecars". See also Post #37:


So possibly also to match the .hmt and/or .nts.

I have wondered how difficult it would be to either:

• Replace nicesplice entirely with some sort of ffmpeg calls but:

1. Probably couldn't handle time shift buffer capture
2. Not sure how to dynamically add crop points for detectads chaserun processing

• Update/rewrite nicesplice to generate proper timestamps in the output files

But I am a chronic procrastinator and haven't got around to investigating either option seriously

 

[/df]

In another bulletin from the procrastination club:

[ffmpeg command to make timestamps continuous] makes a .ts with no jump that is playable except by the Humax:

In fact the resulting .ts not playable with the original sidecars, nor after re-creating the .nts, but it is playable as a bare .ts. You can run the Create Sidecars function to bring it into the Humax world, then copy essential details from the original. Finally, perhaps, touch the bundle with its broadcast timestamp so that it sorts by date correctly. I wonder if the fake sidecars would acquire useful data from EPG information in the trimmed, joined and renumbered .ts if the nicesplice options retained it.

AIUI there are two functions of nicesplice that aren't obviously easy to script with ffmpeg, as you identify above:
1. adjusting the in/out points to the nearest previous/subsequent key-frame
2. extracting the current/previous timeshift programme.

And an orthogonal feature: nicesplice is ~15 times smaller than ffmpeg (and that's ignoring the ~30MB of ffmpeg libs).

As to 1. above, some web noise (more reliably, https://trac.ffmpeg.org/wiki/Seeking) suggests that ffmpeg's stream copy automatically starts at the next key-frame, such that subtracting, eg, half the key-frame interval from each in-point should result in similar behaviour to nicesplice in align mode. However, maybe what those sources (and/or nicesplice) mean by "key-frame" is actually "I-frame"; depending on encoding parameters, predictive frames following an I-frame may reference previous frames unless the I-frame is marked as Instantaneous Decoder Refresh, and so there could be corruption at the start of a clip even if it starts with an I-frame. I haven't checked to what extent that's possible with MPEG encodings used in DVB-T/T2.

For 2. the timeshift buffer presents itself like a "recording" bundle named 0, except that 0.hmt.bak is being updated rather than 0.hmt. The hmt output for the buffer "recording" shows all the shows that have been on the live channel since it was "tuned in" in the EPG Blocks list. If the buffer is 20GB, maybe more than the current and previous show could be found in the buffer? The nicesplice code should reveal how the buffered shows are being found.