[mythtv-users] Lossless cut error - last video segment not included in resulting video file

[HP-mini]

On Thu, 2012-11-01 at 16:41 -0400, Doug Vaughan wrote:

> 1) With h.264 video encodings I remember reading that Avidemux v2.5x 
> tended to cut to the keyframe earlier than what was marked in the GUI. 
> Not sure what that meant but I occasionally had to adjust acut where the 
> end point caught a bit of a commercial.
> 
My Avidemux build (grunsters 2.5) does not identify any keyframes..& the
frame cut point counts do not match ffprobe (out by +/-30 ). This is
after correctly the frame/field count error.
I find avidemux to be next to useless on H264 ts files.

> 2) With mkvmerge "deciding" on which keyframe to cut, the translation 
> from a MythTV seek table keyframe to a mkvmerge time code is not 
> exact.Lossless Cut calculates to the full ninedecimal digits 
> (nanosecond) that mkvmerge can accept. Even at that their may be times 
> where mkvmerge is using a keyframe not in-sync with what MythTV had 
> determined to be a keyframe.

Quote from author:
"All of mkvmerge's different "--split ..." methods cut before the first
following key frame after the the split point has been reached. They all
operate on the timecodes after all processing has been done safe for
writing to the actual output file" 

> I further speculate that the reason that 
> ffmpeg show significantly more video artefacts at cut points is because 
> it will only accept six digits of time code decimal accuracy so its 
> selection of a keyframe show even more variation.
> 
ffmpeg only cuts at keyframes unless you use videofilters (transcoding)
ffmpeg -segment seems to work quite well here. 

> What would be best is if Avidemux 3.0, ffmpeg and mkvmerge all accepted 
> keyframes numbers as cut points along with time codes. Although the 
> stable version of Avidemux 2.5x still uses keyframe numbers it cannot 
> edit HDPVR h264 1080i recordings and seems to have video file size 
> limits. The next release of Avidemux 3.0 is resolving those issuesbut has 
> switched to time code cut points.

Yes I had read that it was moving to timecodes..If it wants to handle
variable rate video it has no choice.

I believe the lossless_cut offset error (for my H264) has a root cause
in the first video frame PTS > audio PTS (as expected really).
Video packets precede audio pkts for decoding reasons.
At any point in file;  video pkts PTS is higher than audio PTS. 
time_offset=1st_vid_PTS - 1st_aud_PTS

Observing VLC playback suggests it uses audio frame PTS at video start
timecode. I expect mkvmerge to do the same.

I tried (badly) to ask "mosu" a question about this.

Brett