[mythtv-users] Lossless Cut (mythcommflag vs mythtranscode)

[Angela]

> > 1) The seektable is used to estimate the excact time (duration) into the
> > video where a cut should start or end. (seektable keyframe * frames per
> > second).
> > 2) The calculated cut point in time (HH:MM:SS.nnnnnnnnn) is passed to
> > mkvmergeduring the cut process. mkvmerge itself determines the nearest
> > actual keyframe in the video source correspondingto the given time and
> > makes the cut.
> >
> > If there is any inaccuracy between the datain the seektable and/or how
> > mkvmerge interrupts the video source the cut pointwill be inaccurate. In
> > a large way theLossless Cut scripts are a major hack but it was the only
> > way I found, when the scripts where written, to utilize Myth's
> > commflagging, cutlist editor and creating lossless cut recordings for a
> > HDPVR recording device.
> >
> > It was pure happenstance that the scripts worked with recordings made by
> > other recording devices.The accuracyof the lossless cuts points will
> > only get better if mkvmerge improvesbut the fact a translation between
> > MythTV's data and mkvmerge's own keyframe determination means it will
> > never be perfect. For example, mkvmergecannotaccurately handle variable
> > bit rate recordings (e.g. HDHomerun). That eliminates a whole series of
> > recording devices.
> >
> > Doug
> >

The Wiki documentation is great, however I would sum up possible
deficiencies as you described.

>From the Wiki: For the best lossless cut results use the "Edit the
Recording" instructions and always set your cut points to keyframes
As things get calculated and mkvmerge determines the nearest keyframe,
setting the cut points in the editor at keyframes seems not so relevant
then, or is my statement wrong ?

When the cut shifts are rather constant, as they seem after cutting 10
different recordings, it would be great to have an offset configured and
automatically added. I have to add 3 keyframes during cutting. 
Taking care for negative calculated values when shifting negative, using
min(0, keyframe + neg-shift).

For recordings with a subtitle the script generates "title: subtitle".mkv.
The colon is an unallowed character under Windows/Samba, therefor showing
cryptic filenames. Where can I change this character (using -m) ?
Similar when moving to mythvideo: generic=Review/%TITLE% - %SUBTITLE%

After several cuttings I noticed that sometimes the mkv total time was
incorrect and the overall bitrate (reported with Mediainfo) was very low.
The slider in vlc/wmp/mpc-hc is not manageable and starts hanging. This was
caused by DVB glitches in the recordings. The temporary mkv is already
defect (first call from your script).
Repairing with http://meteorite.sf.net/ and with the following didn't work
either:
mkvextract tracks defect.mkv 0:tr1 1:tr2
mkvmerge -o c.mkv tr1 tr2

Sure I could cut those glitches away, do you now another way to fix corrupt
mkv's or fix the mpg first ?

I noticed you call mkvmerge with " --attachment-description", as you don't
specify an attachment (eg. Jpeg) it won't have any effect, see the following
link for an example
http://manpages.ubuntu.com/manpages/oneiric/ja/man1/mkvmerge.1.html
Further noticed that temporary files are generated like
/tmp/lossless_cut/10017_20120929035500-%04d.mkv, I think the intention was
to replace %04d.

Angela 
 
>
mkvinfo -s defect.mkv
P frame, track 1, timecode 2632900 (00:43:52.900), size 85599, adler
0x13255908
B frame, track 1, timecode 2632800 (00:43:52.800), size 20043, adler
0x1f39e01d
P frame, track 1, timecode 2632820 (00:43:52.820), size 22687, adler
0xa9ce2950
B frame, track 1, timecode 0 (00:00:00.000), size 14316, adler 0x80aa0cac
P frame, track 1, timecode 0 (00:00:00.000), duration 2805266.000, size
14052, adler 0x9d3252b8
P frame, track 1, timecode 2805306 (00:46:45.306), size 8763, adler
0xce4f366f
P frame, track 1, timecode 2805326 (00:46:45.326), size 8599, adler
0xf312ba10
P frame, track 1, timecode 2805506 (00:46:45.506), size 93879, adler
0x2255705c
P frame, track 1, timecode 2805526 (00:46:45.526), size 88203, adler
0xc0fe851f
B frame, track 1, timecode 2805426 (00:46:45.426), size 18587, adler
0x49fc56bb
P frame, track 1, timecode 2805446 (00:46:45.446), size 21131, adler
0x4d67466f
B frame, track 1, timecode 2805386 (00:46:45.386), size 10660, adler
0x52cbf548
P frame, track 1, timecode 2805406 (00:46:45.406), size 7096, adler
0x3927f5fd
P frame, track 1, timecode 2805466 (00:46:45.466), size 7275, adler
0x3a662491
P frame, track 1, timecode 2805486 (00:46:45.486), size 7231, adler
0x1d6d2843
P frame, track 1, timecode 2805566 (00:46:45.566), duration 140.000, size
97831, adler 0x1c9082e6
P frame, track 1, timecode 2805706 (00:46:45.706), size 99123, adler
0x56f50e68
B frame, track 1, timecode 2805546 (00:46:45.546), size 519205, adler
0xc0f1e743
P frame, track 1, timecode 23994082 (06:39:54.082), duration 9374389.000,
size 16635, adler 0xe579abd0

> The new millisec duration data in the seektable is meant to help solve
> the problem of changing framerate. If this is done right (in mythtv)
> then you have the exact time cut-points for mkvmerge or ffmpeg.
> 
> The recorded seektable & the mythcommflag --rebuild & ffmpeg can be
> made
> to match see ticket 11435.
> My cutting script (byte/packet offset based) yields frame accurate cuts.
> The byte offset is from file start & not any assumed packet type.
> 
> A possible remaining issue is the start time of a file is it audio or
> video PTS. The mkvtoolnix author stated time starts on the lowest first
> valid PTS & that's going to be audio in a TS stream. This time delta is
> typ 1-3 sec or very likely about 3-4 keyframes offset..
> 
> 
> Because mkvtoolnix does not support LATM-AAC & mythtv does not support
> seektables in .mkv files ...I haven't tried LosslessCut after patches in
> ticket 11435.
> 
> Brett

Thanks Brett, I am not ignoring your statements, I left my reply to Doug as
is.
I will carefully watch the ticket 11435, as it I also have an issue with HD
playback skipping, as I updated mythtv recently and see how it can improve
lossless_cut.