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 2nd March 2010, 21:34   #1461  |  Link
Inspector.Gadget
Registered User
 
Join Date: May 2008
Posts: 1,618
Quote:
Oh, and yet another good reason for me to stay away from this app and quit giving it a try, which would've prevent me from wasting two hours for nothing today, thanks for asking.
I think I speak for everyone when I say that software developers' time is so much more valuable than the time of some forum troll that we haven't yet invented the numerical order of magnitude with which to express it. Hope this helps.
Inspector.Gadget is offline  
Old 2nd March 2010, 22:01   #1462  |  Link
fingershop
Registered User
 
Join Date: Mar 2009
Posts: 14
Quote:
Originally Posted by sneaker_ger View Post
You could also use AVIMUX Gui for that, it will the show the size of each video and audio track in MBytes (one decimal).
Thanks, I just tried that, and it does give you the track sizes in just a few seconds.

However, some of the track sizes are way off, by a factor of 17 in some cases, depending on the file you're checking. At that accuracy level I may as well just make my own guess :-)
fingershop is offline  
Old 3rd March 2010, 02:04   #1463  |  Link
falexak
Registered User
 
Join Date: Dec 2009
Posts: 2
Thank you very much for the news, I have been using MkvToolnix for a long time.
falexak is offline  
Old 3rd March 2010, 03:07   #1464  |  Link
Chumbo
Registered User
 
Chumbo's Avatar
 
Join Date: Feb 2005
Posts: 585
Quote:
Originally Posted by [)370|\|470!2 View Post
Just wondering if there's a way to make this crappy app to respect splitting filesize. 4499 MB instead of 4475 huh? If it's not too much to ask.
No one's forcing you to use this tool. You can always write your own to do exactly what you want. Maybe walking an inch in developers shoes would shed some light in that dark space between...[I better stop before I get banned ].

Every software has bugs and limitations and developers appreciate help when its done constructively. What exactly have you contributed to make this a better tool and discussion? Please we're all ears...but I guess so are trolls.
__________________
Chumbo
Chumbo is offline  
Old 3rd March 2010, 19:19   #1465  |  Link
[)370|\|470!2
dentist-experimenter
 
[)370|\|470!2's Avatar
 
Join Date: Apr 2005
Posts: 250
That's amazingly funny how fast someone starts hollering "troll" just as they smell a tiny bit of criticism airborne. Oh, and also there's a very nice remark once made by B. Shaw: “Although I cannot lay an egg, I am a very good judge of omelettes”.

And to conclude, since no one have added nor brought anything constructive conserning subject to shed a light on it, i'd assume there's nothing else remains to discuss.
__________________
gr33tz
[)370|\|470!2 is offline  
Old 3rd March 2010, 22:13   #1466  |  Link
nurbs
Registered User
 
Join Date: Dec 2005
Posts: 1,455
I told you the likely cause of why it doesn't split exactly where you want. It probably gave you 4475 MB because the next possible split point would have resulted in a size bigger than 4499 MB. Without telling anything about the file there is no way to know for sure of course.
Also you should try being polite to people sometimes. Maybe then people would be more inclined to spend their spare time helping you with your problems even though they have no obligation to to so.
nurbs is offline  
Old 9th March 2010, 17:30   #1467  |  Link
liquidskin76
Registered User
 
liquidskin76's Avatar
 
Join Date: Dec 2008
Posts: 233
Quote:
Originally Posted by Mosu View Post
mkvmerge discards AC3 cores in TrueHD tracks, yes. No, that won't change anytime soon (if at all).
Hi Mosu,

You're sort of right in saying that with ffdshow you can either bitstream truehd or decode it to lpcm, so why would you need the ac3 core.

One thing though... how does that relate if you're using spdif for instance? I didn't think spdif could handle the bandwidth of truehd decoded to lpcm, hence the need for hdmi?

I'd love the ability to include the ac3 core as an automatic fallback (without having to select another audio track).

Thanks!
liquidskin76 is offline  
Old 9th March 2010, 17:32   #1468  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,513
No, sorry.
__________________
Latest MKVToolNix is v13.0.0

If I ever ask you to upload something, please use my FTP server.
Mosu is offline  
Old 9th March 2010, 22:17   #1469  |  Link
rica
Registered User
 
Join Date: Mar 2008
Posts: 2,021
Quote:
Originally Posted by Mosu View Post
mkvmerge discards AC3 cores in TrueHD tracks, yes. No, that won't change anytime soon (if at all).

Quote:
The command line which i gave before creates a thd+ac3 file.
And i can watch the mkv (created by mkvmerge gui 3.2.0) with ac3 or with thd.
Disabling thd passthrough and enabling ac3 SPDIF encode mode in ffdshow must fix your issue. (you'll get ac3 in this case)
Enabling thd passthrough will bring thd bitstreaming back.
Dunno mossu how i get ac3 or THD separately???


_ _ _ _ _ _
rica is offline  
Old 9th March 2010, 22:43   #1470  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,513
Quote:
Originally Posted by rica View Post
Dunno mossu how i get ac3 or THD separately???
Not with mkvmerge. mkvmerge will always discard the AC3 core of a THD+AC3 file/track.

However, often a disc containing a THD+AC3 as a single track also contains another AC3 track, and you can use that as input as well.
__________________
Latest MKVToolNix is v13.0.0

If I ever ask you to upload something, please use my FTP server.
Mosu is offline  
Old 9th March 2010, 23:30   #1471  |  Link
turbojet
Registered User
 
Join Date: May 2008
Posts: 1,840
I see demuxing pgs is supported now, thanks, any news on muxing pgs?
turbojet is offline  
Old 10th March 2010, 08:21   #1472  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,513
Quote:
Originally Posted by turbojet View Post
I see demuxing pgs is supported now, thanks, any news on muxing pgs?
Partially. You can re-mux PGS tracks from one Matroska file to another (mkvmerge will use its general purpose "pass-through" packetizer), but you cannot mux it from PGS elementary streams. It's also not on the agenda just yet.
__________________
Latest MKVToolNix is v13.0.0

If I ever ask you to upload something, please use my FTP server.
Mosu is offline  
Old 11th March 2010, 09:12   #1473  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,513
This is a mkvtoolnix support thread, not a MakeMKV or "playback on hardware players" support thread. Please create a new one for such a question.

One thing to look into: indexes (called "cues" in Matroska terms). mkvmerge always writes them, maybe makemkv doesn't or doesn't reference them from metaseek elements.
__________________
Latest MKVToolNix is v13.0.0

If I ever ask you to upload something, please use my FTP server.
Mosu is offline  
Old 13th March 2010, 08:47   #1474  |  Link
sheck
Registered User
 
Join Date: Jan 2010
Location: Canada
Posts: 197
Mosu, in this release I noticed you added --parse-fully switch to mkvextract.exe. What does it add to the functionality ? I tried using it, but results seem to be the same as when not using it.
sheck is offline  
Old 13th March 2010, 10:28   #1475  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,513
Quoting the documentation (both mkvextract and mkvpropedit know this parameter under different names but it seems I've only added it to mkvextract's man page):

Quote:
-p, --parse-mode mode
Sets the parse mode. The parameter 'mode' can either be 'fast' (which is also the default) or 'full'. The 'fast' mode does not parse the whole file but uses the meta seek elements for locating the required elements of a source file. In 99% of all cases this is enough. But for files that do not contain meta seek elements or which are damaged the user might have to se the 'full' parse mode. A full scan of a file can take a couple of minutes while a fast scan only takes seconds.
Getting a bit more technical:

The 'full' parse mode starts at the beginning of the file and finds all level 1 Matroska elements. These are e.g. 'meta seek', 'cues', 'chapters', 'track headers' and most important 'clusters'. For each level 1 element it reads the ID and the size but not necessarily its content -- only if it has to (for the track headers, the rest depends on the extraction mode/editing mode). However, reading all cluster IDs and sizes takes quite a lot of time as there are a lot of clusters over the whole file.

BTW: The programs will fall back to 'full' if no index is found and 'fast' mode is selected.
__________________
Latest MKVToolNix is v13.0.0

If I ever ask you to upload something, please use my FTP server.

Last edited by Mosu; 13th March 2010 at 10:33.
Mosu is offline  
Old 15th March 2010, 01:07   #1476  |  Link
Foofaraw
Registered User
 
Join Date: Apr 2004
Posts: 126
At the risk of upsetting someone, mkvtoolnix does not function in isolation - it produces data from or for other products and as such one has to mention other things than mkvtoolnix... (if English is not your first langauge, let me underline this is not an attack or critique of mkvtoolnix)

So my question is in relation to mkvtoolnix.... (so please read it twice)

ProgramA outputs an mkv - we'll call it mkvA

If I now play mkvA in deviceB it has certain defects.

I now take mkvA and 'add' it to Mkvmerge Gui - uncheck a few items in MkvMerge Gui and output mkvB

If I now play mkvB it takes a while to play, but then it plays fine.

BUT

If I take Mkvcleave and extract all items from mkvA

And I then only add the items required to Mkvmerge GUI and output mkvC

Then mkvC starts playing fine right away.


So the question about Mkvmerge gui/mkvtoolnix is:

why is there a difference between mkvB and mkvC - they both contain the same(3) items - we just arrived at the content differently.

Does mkvmerge gui reuse the parts of the container (but not the contents) when you start out by using an existing mkv??? I would have thought it authored from scratch so there shouldn't be a difference? (But there is)
Foofaraw is offline  
Old 15th March 2010, 03:58   #1477  |  Link
73ChargerFan
Registered User
 
73ChargerFan's Avatar
 
Join Date: Dec 2006
Posts: 505
Ah... output files mkvB & mkvC are different just enough, so that they behave differently when played.

I've encountered something similar. I can have three non-identical copies of a video track (demuxed from .TS, or demuxed from .M2TS using eac3to, or extracted from .M2TS into .MKV using eac3to) and mkvmerge will accept all three tracks. But the output .MKV files don't play back identically in mpc-hc.

In my mind, Audio+Video->MKV should work no matter where I get the source files, but that isn't always the case. I don't have any samples handy now, however.
73ChargerFan is offline  
Old 15th March 2010, 05:30   #1478  |  Link
Foofaraw
Registered User
 
Join Date: Apr 2004
Posts: 126
Quote:
Originally Posted by 73ChargerFan View Post
In my mind, Audio+Video->MKV should work no matter where I get the source files, but that isn't always the case. I don't have any samples handy now, however.
Yeah, in my mind i agree with you. But perhaps there is something we don't know :-/
Foofaraw is offline  
Old 15th March 2010, 18:51   #1479  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,513
Summarizing Foofaraw's question:

Quote:
Originally Posted by Foofaraw
A.mkv -> (mkvmerge) -> B.mkv is different from A.mkv -> (mkvcleaver) -> elemental_streams.h264/.ac3/.mp3 -> (mkvmerge) -> B.mkv
mkvmerge has different paths for the same content depending on where they come from. You guessed as much from the evidence. There are several reasons for this, amongst them are:

1. It tries to re-use as much information as possible as can be retrieved from the source container. If you have a h.264 track inside a Matroska file then you have a lot more meta-information about it that you do when it is stored outside of a container as an elementary stream. Information that is reused includes but is not limited to the timestamps, track parameters like display width/height, track name, language etc etc.

2. What is not so obvious is that mkvmerge also reuses the framing. If you have a raw track type like MP3, AC3, AAC or h.264 elementary streams then mkvmerge has to determine how many bytes of the track to put into each Matroska block (also called 'frame' sometimes even though a Matroska block does not necessarily contain exactly one 'frame' in the way people think of frames). This process is usually called framing and has to be done by any raw -> container converter. If a track is stored inside a Matroska file then mkvmerge sometimes skips this process and takes the input file's framing -- one Matroska block in, one Matroska block out.

3. Another important thing to remember is that raw tracks outside of a Matroska file are not simply the concatenation of all the contents of all Matroska blocks. This is the case for some very simple track types (e.g. MP3, AC3, AAC, DTS) but for most others it isn't, especially for video track types like h.264. Elementary streams often contain special framing markers (think of '00 00 01' prefixes for MPEG-1/2 or '00 00 00 01' for h.264). Also some parts of the stream are not put into Matroska blocks but into the CodecPrivate element (e.g. SPS/PPS NALUs in h.264 tracks). The CodecPrivate almost always has some special kind of storage format that is always different than how that information is stored in an elementary stream. mkvextract and mkvmerge convert this data from one form into the other and back again. In the case of direct mkv -> mkv conversion the CodecPrivate element is kept as-is.

4. There are muxers out there that create invalid Matroska files. For example there are files with the CodecID V_MPEG4/ISO/AVC (h.264 video) that contain the elementary stream 1:1 including the '00 00 00 01' prefixes in each Matroska block. They also don't have a CodecPrivate element but store the SPS/PPS NALUs inside the first Matroska block. This not only violates the specs it is also incompatible with most playback software out there. So mkvmerge has yet another processing path for such tracks.

There are more cases, but I guess you get the drift. It is not possible to switch this behavior in mkvmerge -- it is hard coded for each and every combination of track type and source file format (and even for the same tuple "container & track format" there may be different paths as 4. illustrates).
__________________
Latest MKVToolNix is v13.0.0

If I ever ask you to upload something, please use my FTP server.
Mosu is offline  
Old 16th March 2010, 17:37   #1480  |  Link
Foofaraw
Registered User
 
Join Date: Apr 2004
Posts: 126
Thank you for the explanation Mosu.

I'm still fairly new to the mkv format (coming rather late to the party!)

Would you say its a good format for streaming video? (Via media players, not the internet)

Reason I'm wondering is because someone said we can't see how long tracks are but you have to scan the entire file to figure it out (i would have thought there was a header somewhere).
Foofaraw 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 21:55.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.