The reverse problem -- speeding up video (2x) to match audio

[hlygrail]

I have a bunch of .m2ts files that have AVCHD video shot from a Canon HF20 (I think). By all accounts, the video is 1920x1080 @ 25fps, with AC3 audio. The audio and video are perfectly fine in the individual source .m2ts files, but I need them joined together inside a single MKV (and oh, by the by, mkvmerge doesn't support M2TS -- arrggh). During the tsmuxer join, I can see:

SmartLabs tsMuxeR. Version 1.10.6 http://www.smlabs.net
Decoding H264 stream (track 1): Profile: High@4.0 Resolution: 1920:1080i Frame rate: 25
H.264 stream does not contain fps field. Muxing fps=25
B-pyramid level 2 detected. Shift DTS to 3 frames
Decoding AC3 stream (track 2): Bitrate: 256Kbps Sample Rate: 48KHz Channels: 2

...and success. The resulting joined .m2ts file (joined.m2ts) ends up being roughly the same size as the combined individual files, and the audio and video are synced just fine. So now I need an h.264 and an audio stream to shove into an MKV (remember, mkvmerge doesn't like .m2ts files), so back to tsMuxeR to break up the joined .m2ts file, using these options:

MUXOPT --no-pcr-on-video-pid --new-audio-pes --demux --vbr --vbv-len=500
V_MPEG4/ISO/AVC, "joined.m2ts", fps=25, insertSEI, contSPS, track=4113
A_AC3, "joined.m2ts", timeshift=160ms, track=4352

I don't have anything that can natively play the resulting .264 file alone (at least VLC won't play it, and Media Player Classic loads about half a frame of video and then stops), so I go ahead and push them into an MKV wth mkvmerge:

E:\HDMedia\joined>"c:\Program Files\MKVmerge\mkvmerge.exe" -o joined.track_4113.264 joined.track_4352.ac3
mkvmerge v2.9.9 ('Tutu') built on Nov 25 2009 21:13:31
'joined.track_4113.264': Using the AVC/h.264 ES demultiplexer.
'joined.track_4352.ac3': Using the AC3 demultiplexer.
'joined.track_4113.264' track 0: Extracted the aspect ratio information from the
MPEG-4 layer 10 (AVC) video data and set the display dimensions to 1920/1080.
'joined.track_4113.264' track 0: Using the MPEG-4 part 10 ES video output module.

'joined.track_4352.ac3' track 0: Using the AC3 output module.
The file 'all.mkv' has been opened for writing.
Progress: 100%
The cue entries (the index) are being written...
Muxing took 478 seconds.


Here's the suck part: The resulting MKV file plays at half-speed, and the audio (which is fine) ends exactly halfway through the audio. I've checked and re-checked options and settings. I'm not recoding or changing frames per second anywhere -- it's 25fps straight through. So is the problem that tsMuxeR doesn't know how to properly maintain an HD stream coming out of .m2ts, or is it the late-night stupidity kicking in?

Suggestions? Someone kick me....

[Baldrick]

Try set the framerate to 50fps in mkvmerge when you make the mkv. Any difference?

Have you tried skip the joining part in tsmuxer? Just demux a m2ts from the camera and import the video and audio stream in mkvmerge. Same playback problems then?

[hlygrail]

I've been trying a slightly different approach (pulling the finished .mkv back through mkvmerge and adjusting the run-time of the video stream via the --default-duration option), but that failed badly:

E:\HDMedia\>"c:\Program Files\MKVmerge\mkvmerge.exe" --default-duration 1:5100s -o all2.mkv all.mkv
mkvmerge v2.9.9 ('Tutu') built on Nov 25 2009 21:13:31
'all.mkv': Using the Matroska demultiplexer.
'all.mkv' track 1: Using the MPEG-4 part 10 (AVC) video output module.
'all.mkv' track 1: Extracted the aspect ratio information from the MPEG-4 layer
10 (AVC) video data and set the display dimensions to 1920/1080.
'all.mkv' track 2: Using the AC3 output module.
The file 'all2.mkv' has been opened for writing.
Assertion failed: Data != NULL, file ../../src/EbmlBinary.cpp, line 91

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

FireFox barfed itself at the same time, which never happens, so I re-ran and got a different error:

Error: memory.cpp/safememdup() called from file src/common/memory.h, line 126: malloc() returned NULL for a size of 74839 bytes.


In any case, to your questions:

1) I'm not seeing a specific "set the framerate" option for mkvmerge, or I would have used that. I did try doing that from tsMuxeR (CLI, since the GUI only lets you select from the drop-downs), though, with the same failures once it landed in MKV. The only thing resembling a framerate option I can see is the --default-duration option.

2) Testing with a smaller, unjoined .m2ts, here's the de-mux in tsMuxer:

SmartLabs tsMuxeR. Version 1.10.6 http://www.smlabs.net
Decoding H264 stream (track 1): Profile: High@4.0 Resolution: 1920:1080i Frame rate: 25
H.264 stream does not contain fps field. Muxing fps=25
B-pyramid level 2 detected. Shift DTS to 3 frames
Decoding AC3 stream (track 2): Bitrate: 256Kbps Sample Rate: 48KHz Channels: 2
Processed 3924 video frames
Demux complete.
Demuxing time: 12 sec

...and the mkvmerge:

E:\HDMedia\xxxxxxxxxxxxx>"c:\Program Files\MKVmerge\mkvmerge.exe" -o "tinytest.mkv" "tiny.track_4113.264" "tiny.track_4352.ac3"
mkvmerge v2.9.9 ('Tutu') built on Nov 25 2009 21:13:31
'tiny.track_4113.264': Using the AVC/h.264 ES demultiplexer.
'tiny.track_4352.ac3': Using the AC3 demultiplexer.
'tiny.track_4113.264' track 0: Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 1920/1080.
'tiny.track_4113.264' track 0: Using the MPEG-4 part 10 ES video output module.
'tiny.track_4352.ac3' track 0: Using the AC3 output module.
The file 'tinytest.mkv' has been opened for writing.
Progress: 100%
The cue entries (the index) are being written...
Muxing took 11 seconds.


Results: Weird... The audio doesn't even remotely match the video (different song), but yes, the video is still half-speed. So, yeah, the individual source .m2ts files are bad from an alignment standpoint, BUT, when I join them all together as an "AVCHD disk" in tsMuxeR and play the 000000.m2ts stream file, it has the right audio with the right video.... based on this, I'm going to postulate that whatever is decoding .m2ts on my machine (MPC with ffdshow behind it) /might/ be to blame for the half-speed playback effect, but that wouldn't hold true once it landed in MKV, so it can't be the final analysis.

[jagabo]

Highlight the video track. In the Format Specific Options tab set the FPS.

[hlygrail]

Set it to what? The GUI only lets you choose from the drop-downs, and you get 24, 25, 30, or 23.9xxx and 29.997-ish. And I don't see a tab called "Format Specific Options." Do you mean the "General track options" right below -- where the fps drop-down is? The one that won't let me enter another value?

I tried using the CLI version with a .meta file using

MUXOPT --no-pcr-on-video-pid --new-audio-pes --demux --vbr --vbv-len=500
V_MPEG4/ISO/AVC, "filename.m2ts", fps=50, insertSEI, contSPS, track=4113
A_AC3, "filename.m2ts", timeshift=160ms, track=4352

It didn't seem to make any difference... like tsMuxeR ignores any fps value not in its legal drop-down list already.

[jagabo]

MkvMergeGUI:

[hlygrail]

Well color me a (ignorant) turd.... at 3am, I didn't pick up that mmg.exe was the GUI. @#(*&@ing A. So it's absorbing the .264 and the .ac3 into a new MKV now at 50fps. Let's see what that does....

Status: Mission Accomplished! I now have an 85 min 1080i video with perfect audio sync.... Sweet.


Whose PayPal account am I sending the bill payment to? I don't recall seeing any mention of a freakin' GUI for mkvmerge in any of the author's docs, but it was 4am, and I haven't slept since.

Thanks a ton, guys!!


I am curious, though -- what is the command-line equivalent of setting that fps option in the GUI? I know I'll end up needing it again somewhere down the line.

[jagabo]

MMG: Muxing -> Show Command Line

[hlygrail]

Well, crap. Looks like "--default-duration 0:50fps" would have done the trick all the way around. I was using a time-based entry of "--default-duration 0:5100s" (85min), which I thought would accomplish the same objective.

I'm testing that on some of the original smaller/unjoined files, and it seems to work. The acid test, though, is that my WDTV Live media player can play the merged 9GB MKV file just fine, which was the end goal. Thanks, guys! You rock!!

[jagabo]

This whole confusion comes about because of stupid marketing. Originally NTSC video was called 29.97 fps interlaced. 29.97 refers to the frame rate and interlaced indicates that each frame contains two fields that are to be viewed sequentially, 1/59.94 seconds each. Marketers, of course, thing bigger numbers are better so they started calling that 59.94i or 60i for short. Now others are starting to use the terminology.