Unexpected Negative Sync Behavior on Video Tracks in VOB #1774

Closed
optimiz opened this Issue Aug 31, 2016 · 3 comments

Projects

None yet

2 participants

@optimiz
optimiz commented Aug 31, 2016

Hello, when specifying a negative value lower than or equal to -143911 ms in the --sync option on the video track of a VOB container, mkvmerge stops muxing at the positive value of +143911 ms (02:24.032).

Example 1: --sync of -143911 stops muxing at +143911...

$ mkvmerge -o offset-issue.mkv -y 0:-143911 sample.vob

mkvmerge v9.2.0 ('Photograph') 64bit
'sample.vob': Using the demultiplexer for the format 'MPEG program stream'.
'sample.vob' track 0: Using the output module for the format 'MPEG-1/2'.
The file 'offset-issue.mkv' has been opened for writing.
Progress: 100%
The cue entries (the index) are being written...
Muxing took 2 seconds.

$ ffprobe offset-issue.mkv

Input #0, matroska,webm, from 'offset-issue.mkv':
Metadata:
encoder : libebml v1.3.3 + libmatroska v1.4.4
creation_time : 2016-08-31 18:11:18
Duration: 00:02:24.03, start: 0.000000, bitrate: 1980 kb/s
Stream #0:0: Video: mpeg2video, none(tv), 720x480, SAR 8:9 DAR 4:3, 59.94 fps, 59.94 tbr, 1k tbn, 1k tbc (default)
Metadata:
BPS : 5372560
BPS-eng : 5372560
DURATION : 00:00:00.200000000
DURATION-eng : 00:00:00.200000000
NUMBER_OF_FRAMES: 6
NUMBER_OF_FRAMES-eng: 6
NUMBER_OF_BYTES : 134314
NUMBER_OF_BYTES-eng: 134314
Stream #0:1: Audio: ac3, 48000 Hz, stereo, fltp, 256 kb/s (default)
Metadata:
BPS : 256000
BPS-eng : 256000
DURATION : 00:02:24.032000000
DURATION-eng : 00:02:24.032000000

Example 2: --sync of -143910 muxes as expected (same input file)...

$ mkvmerge -o offset-issue.mkv -y 0:-143910 sample.vob

mkvmerge v9.2.0 ('Photograph') 64bit
'sample.vob': Using the demultiplexer for the format 'MPEG program stream'.
'sample.vob' track 0: Using the output module for the format 'MPEG-1/2'.
The file 'offset-issue.mkv' has been opened for writing.
Progress: 100%
The cue entries (the index) are being written...
Muxing took 3 minutes 55 seconds.

TESTING NOTES:

  • Positive --sync values work on audio and video tracks from VOB.
  • Negative and positive --sync values work on audio tracks from VOB.
  • Negative and positive --sync values work on audio and video from MKV.
  • Only VOB input seems effected -- MKV and MP4 container inputs work fine.

Since negative and positive values work on the video track when read from MKV input, my workaround is to mux the VOB to a temporary MKV with no sync offset, then remux that temporary MKV with the negative sync desired to a final MKV. (I came across this behavior when attempting an offset of -165000 (2m45s00ms) directly from a VOB source.)

Thank you all the time and effort you put into all your software, I value and respect it.

@mbunkus
Owner
mbunkus commented Aug 31, 2016

Thanks for the detailed report. I can reproduce such behavior here with a VOB from a random DVD. I'll look into it.

@mbunkus
Owner
mbunkus commented Sep 2, 2016

I've just fixed this in e06d80f.

@mbunkus mbunkus closed this Sep 2, 2016
@optimiz
optimiz commented Sep 3, 2016

Thank you. The process and data flow you describe in the patch commit notes was very informative.

@mbunkus mbunkus added a commit that referenced this issue Nov 2, 2016
@mbunkus mkvmerge: handle end-of-input in "force pulling" function, too
Otherwise a situation may arise where a file still in a non-finished
state going into the force pull function and coming out of it in a
finished state. However, mkvmerge has to do some work on such a
transition:

• housekeeping (decrease number of unfinished packetizers for later
  decisions whether or not a file has been read)
• establishing deferred connections when appending

In such a case mkvmerge entered an endless loop.

This was a regression introduced with commit
e06d80f as a fix to #1774.
2e76c2e
@mbunkus mbunkus added a commit that referenced this issue Feb 19, 2017
@mbunkus Matroska reader: enqueue at most 128 MB and hold packetizers even whe…
…n forcing

The fix for #1774 caused a regression for sparse tracks in file types
where access to arbitrary packets is not possible (such as
Matroska). The change was to always force-pull a packetizer if all the
packetizers in a file are held.

The drawback is that the packetizer for sparse tracks (e.g. forced
subtitles with few if any entries) was called so often in force mode
that readers had to buffer the whole file content up to the point
where a packet for the sparse track was found. The result was huge
memory consumption.

For completely empty tracks this resulted in an endless loop.

This fix limits the number of enqueued bytes for the Matroska reader
to 128 MB by ignoring force mode in such a case.

Fixes #1893.
5dcc22e
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment