Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > New and alternative a/v containers

Closed Thread
 
Thread Tools Search this Thread Display Modes
Old 29th March 2010, 23:22   #1501  |  Link
dragoncat852
Registered User
 
Join Date: Feb 2008
Posts: 1
Quote:
Originally Posted by Mosu View Post
??? I don't understand your problem. The installer requires admin privileges, so I don't see why the UAC coming up should be considered "does not work".
same situation as 73ChargerFan under win7 x64, I just uninstall it then dl .7z and unzip it works fine
the old MKVExtract GUI1.6.4.1 with 3.3.0 seems got some progress bar problem, it show nothing then done but demuxed sucessfully
anyway, thx for the update and cheers
dragoncat852 is offline  
Old 30th March 2010, 08:05   #1502  |  Link
asc28
Registered User
 
Join Date: Jan 2009
Posts: 31
Quote:
Originally Posted by Mosu View Post
Can you please upload a source file for me for testing purposes? It doesn't have to be the whole file, but it should be long enough that the speed problem becomes obvious. You can upload to my FTP server (see my signature).

Also I need some more information:

1. Which program did you use for extracting the MPEG2 from the DVD? Do you mux the .VOB file directly with mkvmerge or has the video been extracted to separate MPEG2 elementary or program streams?

2. Which program do you use for playback? We know that older versions of ffmpeg (and therefore ffdshow) contain a bug that causes it to play video too slow or too fast.

3. "Video speed is not in sync" -- do you mean that the video plays slower/faster than the accompanying audio track?
Uploaded a sample to ftp (sample.mkv). It was muxed by 3.2.0 and plays at the correct speed. Demux the streams and remux with 3.3.0 to see the change.

Did some more testing and it appears the problem happens with tracks demuxed with PGCDemux, but not with DVDDecrypter. Unfortunately, PGCDemux is the new de facto standard since it does sup subtitles and more "proper" handling on cutpoints. Here's a word about the differences between the files they produce, which might be of help:
Quote:
PGCDemux calculates the delay properly for remultiplexing the audio and video directly, or with the newer avisynth programs. DVDDecrypter and SmartRipper calculate the delay for the old dvd2avi which dropped video frames.
The vidoe bytes that are different are probably the gop timecode. Since there are no fixed offsets in mpg that's only a guess. Look for the header preceeding the bytes that are different, it will be 00 00 01 xx - the xx will tell you what header you are looking at. B8 is the gop header, which contains a timecode. Some rippers give you the option to reset the timecode to start at 00:00:00.00
from this thread: http://forum.doom9.org/showthread.php?t=84778

1. PGCDemux, Elementary stream m2v
2. Tested MPC-HC's built-in decoder, ffdshow, DScaler's decoder, Microsoft's decoder. Splitter is latest Haali's
3. Speed is faster, duration is shorter. For example, a 23:04 file shows up as 19:39.
asc28 is offline  
Old 31st March 2010, 03:55   #1503  |  Link
renqian
Registered User
 
Join Date: Jan 2010
Posts: 6
i using 3.3.0 to mux Truehd is too slow. HD speed is less than 15M/S
i use eac3to to extract the thd file .
renqian is offline  
Old 31st March 2010, 08:08   #1504  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,911
One of mkvtoolnix' disadvantages is that is is rather slow, yes. No, that will most likely not be addressed in the near future. My priorities are usually correctness & features, not speed.
__________________
Latest MKVToolNix is v51.0.0

If I ever ask you to upload something, please use my file server.
Mosu is offline  
Old 6th April 2010, 16:01   #1505  |  Link
Abradoks
Registered User
 
Join Date: Mar 2008
Posts: 71
Hi, Mosu.
Currently GUI parameter "Stretch by" is an alias for --sync. And as far as I understand both of them modify "Track: DefaultDuration" which seems to be somewhat hackish.
Why not to use TrackTimeCodeScale instead?
Abradoks is offline  
Old 6th April 2010, 16:11   #1506  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,911
Quote:
Originally Posted by Abradoks View Post
Hi, Mosu.
Currently GUI parameter "Stretch by" is an alias for --sync.
Correct.

Quote:
And as far as I understand both of them modify "Track: DefaultDuration" which seems to be somewhat hackish.
They don't modify any header value, they just modify the timestamps of each packet. This is the most compatible method.

Quote:
Why not to use TrackTimeCodeScale instead?
Because not every player supports that element (unfortunately).
__________________
Latest MKVToolNix is v51.0.0

If I ever ask you to upload something, please use my file server.
Mosu is offline  
Old 6th April 2010, 17:31   #1507  |  Link
Abradoks
Registered User
 
Join Date: Mar 2008
Posts: 71
Quote:
Originally Posted by Mosu View Post
They don't modify any header value, they just modify the timestamps of each packet.
Actually they do both. It changes "Track: DefaultDuration" which shouldn't be done for such purposes. Because for audio you have fixed frame duration according to codec used. Also, after muxing you can't easily detect if --sync was used.
Quote:
Originally Posted by Mosu View Post
Because not every player supports that element (unfortunately).
Current method works (in different ways) with Gabest and Haali splitter and with ffplay. It doesn't work with mplayer and VLC.

Actually, it works with VLC just as it should. VLC respects timecodecs and tries to add silence/cut audio respectively (I haven't looked at sources, so it's just a guess from user point). Other splitters detect difference between "Track: DefaultDuration" and real audio frame duration and modify timecodes. But it's the way, how TrackTimeCodeScale should work:
Quote:
It would also be possible to adjust the video to match the audio's speed. However, for playback, the only thing that should be counted on is the selected track(s) timecodes being adjusted if they need to be scaled.
I don't think things going to change until you make the first move in mkvmerge. Currently --sync is not usable for a/v sync as it only works with limited number of splitters (those which use hack to make it work).
Abradoks is offline  
Old 6th April 2010, 17:41   #1508  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,911
Quote:
Originally Posted by Abradoks View Post
I don't think things going to change until you make the first move in mkvmerge. Currently --sync is not usable for a/v sync as it only works with limited number of splitters (those which use hack to make it work).
It sure it, you just shouldn't use it on audio tracks. You can easily use it on video or subtitle tracks though. Using TrackTimecodeScale for audio tracks doesn't improve the situation by much because you still have the problem that there are more or less actual samples than fit the timecodes of the packets.

So no, I won't change that.
__________________
Latest MKVToolNix is v51.0.0

If I ever ask you to upload something, please use my file server.
Mosu is offline  
Old 6th April 2010, 17:41   #1509  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,911
Quote:
Originally Posted by Abradoks View Post
I don't think things going to change until you make the first move in mkvmerge. Currently --sync is not usable for a/v sync as it only works with limited number of splitters (those which use hack to make it work).
It sure is, you just shouldn't use it on audio tracks. You can easily use it on video or subtitle tracks though. Using TrackTimecodeScale for audio tracks doesn't improve the situation by much because you still have the problem that there are more or less actual samples than fit the timecodes of the packets.

So no, I won't change that.
__________________
Latest MKVToolNix is v51.0.0

If I ever ask you to upload something, please use my file server.
Mosu is offline  
Old 6th April 2010, 18:04   #1510  |  Link
Abradoks
Registered User
 
Join Date: Mar 2008
Posts: 71
Quote:
Originally Posted by Mosu View Post
It sure is, you just shouldn't use it on audio tracks. You can easily use it on video or subtitle tracks though.
Well, mkvmerge allows it to be used on audio tracks.
Quote:
Originally Posted by Mosu View Post
Using TrackTimecodeScale for audio tracks doesn't improve the situation by much because you still have the problem that there are more or less actual samples than fit the timecodes of the packets.
TrackTimecodeScale was created specifically for synchronisation of different tracks, wasn't it? As I understand, it allows modifying video/subtitle timecodes instead of resampling audio. So, if you agree that current method isn't suitable for audio, why not to use the proper one?
Quote:
Originally Posted by Mosu View Post
So no, I won't change that.
That's a pity. I'm not trying to force you to change it, but I still don't understand the reason.
Abradoks is offline  
Old 6th April 2010, 18:16   #1511  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,911
Quote:
Originally Posted by Abradoks View Post
Well, mkvmerge allows it to be used on audio tracks.
True, because I don't want to limit the user in what he can or cannot do.

Quote:
TrackTimecodeScale was created specifically for synchronisation of different tracks, wasn't it? As I understand, it allows modifying video/subtitle timecodes instead of resampling audio. So, if you agree that current method isn't suitable for audio, why not to use the proper one?
Because it wouldn't improve anything. You can use the current --sync method for video and subtitle tracks. You could use TrackTimecodeScale the same way for video and subtitle tracks. However, using TrackTimecodeScale on audio tracks would result in the same problems that using the current --sync method on audio track has. There's not much (if anything at all) to be gained.
__________________
Latest MKVToolNix is v51.0.0

If I ever ask you to upload something, please use my file server.
Mosu is offline  
Old 6th April 2010, 18:20   #1512  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,911
Ok, there is something to be gained. Playback applications could activate actual audio resampling. However, as I said before, this is not implemented at the moment. Yes, it's a "chicken vs egg" problem. No, I will still not do it; mostly because I don't want to spend the time on implementing this in a backwards compatible manner.
__________________
Latest MKVToolNix is v51.0.0

If I ever ask you to upload something, please use my file server.
Mosu is offline  
Old 6th April 2010, 18:28   #1513  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,911
Quote:
Originally Posted by Mosu View Post
Playback applications could activate actual audio resampling.
I take that back. The TrackTimecodeScale parameter explicitly only adds another multiplier for the timecodes. Its semantics do not imply that a track should be resampled in any way. So in order to find out whether or not the track has to be resampled the decoder would have to read a couple of packets, get their timecodes, compare the timecodes to the number of samples in respect to the sampling rate etc etc. This would all be guesswork and not be very precise.
__________________
Latest MKVToolNix is v51.0.0

If I ever ask you to upload something, please use my file server.
Mosu is offline  
Old 6th April 2010, 19:37   #1514  |  Link
Abradoks
Registered User
 
Join Date: Mar 2008
Posts: 71
Quote:
Originally Posted by Mosu View Post
True, because I don't want to limit the user in what he can or cannot do.
But it's completely not suitable for audio. Modifying audio frame duration is just wrong and it has nothing to do with the name of the option used for it.
Quote:
Originally Posted by Mosu View Post
Because it wouldn't improve anything. You can use the current --sync method for video and subtitle tracks.
There is already --default-duration for it.
Quote:
Originally Posted by Mosu View Post
You could use TrackTimecodeScale the same way for video and subtitle tracks.
Is there such option in mkvmerge or in mmg?
Quote:
Originally Posted by Mosu View Post
However, using TrackTimecodeScale on audio tracks would result in the same problems that using the current --sync method on audio track has. There's not much (if anything at all) to be gained.
Well, TrackTimecodeScale modifies only specific header parameter and not the whole timecodes. It doesn't require audio resampling. It's easy to recognize if this parameter was used. TrackTimecodeScale was designed for sync, it doesn't produce weird audio tracks and doesn't require to break spec compliance for proper playback. So the only problem is lack of support, which is partially caused by mkvmerge using some hack instead of this parameter.
Quote:
Originally Posted by Mosu View Post
I don't want to spend the time on implementing this in a backwards compatible manner.
What do you mean by "backwards compatible"? Yes, current --sync looks just like an alias for this parameter, and it would be better to change it's behavior. But you can add something like --TrackTimecodeScale instead and leave --sync unchanged.
Quote:
Originally Posted by Mosu View Post
So in order to find out whether or not the track has to be resampled the decoder would have to read a couple of packets, get their timecodes, compare the timecodes to the number of samples in respect to the sampling rate etc etc. This would all be guesswork and not be very precise.
Not at all. If player doesn't want to resample, then it just modifies timecodes of other streams to keep in sync. That's what some splitters do with current method.
Abradoks is offline  
Old 6th April 2010, 19:48   #1515  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,911
Quote:
Originally Posted by Abradoks View Post
There is already --default-duration for it.
No. --default-duration only sets the default duration parameter. The default duration is used if no timecode information is provided by the source (which is rare, e.g. raw h264 streams). Other than that --default-duration does not modify timecodes at all.

Quote:
Is there such option in mkvmerge or in mmg?
No.

Quote:
What do you mean by "backwards compatible"? Yes, current --sync looks just like an alias for this parameter, and it would be better to change it's behavior.
No.

Quote:
But you can add something like --TrackTimecodeScale instead and leave --sync unchanged.
That's exactly what I won't do due to limited free time. For proper support this would mean adding the parameter do mkvmerge, documenting it in the man page, in mkvmerge's help text, adding a control in mmg, adding the tooltip for it, translating all of the help texts into German (that's the one language I'm translating into myself). It's not done in merely five minutes, you know.

Patches are always welcome.

Quote:
Not at all. If player doesn't want to resample, then it just modifies timecodes of other streams to keep in sync. That's what some splitters do with current method.
That only works if only a single track has that parameter set. What if you have three tracks (audio, video, subtitles) and both the audio and subtitle track have different TrackTimecodeScale values set?

Anyway, like I said, I won't do this _myself_.
__________________
Latest MKVToolNix is v51.0.0

If I ever ask you to upload something, please use my file server.
Mosu is offline  
Old 6th April 2010, 20:15   #1516  |  Link
Abradoks
Registered User
 
Join Date: Mar 2008
Posts: 71
Quote:
Originally Posted by Mosu View Post
No. --default-duration only sets the default duration parameter. The default duration is used if no timecode information is provided by the source (which is rare, e.g. raw h264 streams). Other than that --default-duration does not modify timecodes at all.
Oh, so. Than you should correct docs:
Quote:
Forces the default duration of a given track to the specified value. Also modifies the track's timecodes to match the default duration.
Quote:
Originally Posted by Mosu View Post
Patches are always welcome.
That's much better answer than "I won't change that".

Quote:
Originally Posted by Mosu View Post
That only works if only a single track has that parameter set. What if you have three tracks (audio, video, subtitles) and both the audio and subtitle track have different TrackTimecodeScale values set?
It's pretty simple. Only audio timecodes are hard to change, so player multiples every active track's timecodes by (Own_TrackTimecodeScale/Audio_TrackTimecodeScale). For audio it will always be "1".
Abradoks is offline  
Old 6th April 2010, 20:50   #1517  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,911
Quote:
Originally Posted by Abradoks View Post
That's much better answer than "I won't change that".
On this forum this usually amounts to the same as there are almost no developers here that are interested in helping out. I'm always open to patches.
__________________
Latest MKVToolNix is v51.0.0

If I ever ask you to upload something, please use my file server.
Mosu is offline  
Old 7th April 2010, 14:59   #1518  |  Link
lamer_de
Member
 
lamer_de's Avatar
 
Join Date: Dec 2001
Location: somewhere far beyond
Posts: 270
There's quite an important bug in the header editor: When you try to edit a file that was generated with Haali's DS Muxer, both the cli mkvpropedit as well as the GUI in mmg crash with a cpp error:

Assertion failed: CheckMandatory(), file ../../src/EbmlMaster.cpp, line 138

Happens every time, content of the files doesn't matter. Seems the way the 2 programs create their headers is differently.
lamer_de is offline  
Old 7th April 2010, 15:18   #1519  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,911
Which mkvtoolnix version are you using?
__________________
Latest MKVToolNix is v51.0.0

If I ever ask you to upload something, please use my file server.
Mosu is offline  
Old 9th April 2010, 09:58   #1520  |  Link
lamer_de
Member
 
lamer_de's Avatar
 
Join Date: Dec 2001
Location: somewhere far beyond
Posts: 270
Oh, sorry: mkvtoolnix 3.3.0 from 24.03.10, WinXP 32bit, Haali gDsMux from 14.11.2009 (hm, maybe I should update that). EDIT: After updating Haali to the 27/03/2010 version, the error still occurs.

However, I found a case where it's not crashing: WMV1 video + wma2/divx audio. Files with MPEG4-ASP+MP3 crash, so do files with H264+AC-3 5.1 and MPEG4-ASP+WMA9 audio.
lamer_de is offline  
Closed Thread

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 05:20.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.