MKVToolNix v24.0.0 released

[Selur]

getting a bit confused now ;)
When using --default-duration with H.264 raw, can we still use i.e. --default-duration 1:25fps for a 25i stream of do we have to use 50fps?

[Mosu]

You have to use "--default-duration 1:50fps" if you know that the stuff that ends up in a Matroska block is only a field. I'm not certain what all those descriptions like "50i" refer to, therefore I cannot answer this directly.

[Selur]

to clarify: with 25i I ment 25 interlaced frames = 50 fields

[Mosu]

Then the answer is probably 1:50fps.

[sneaker_ger]

Well, I'm talking about progressive material. This is totally incoherent with older versions. And why would you offer "24", "25", "30", "30000/1001" and "24000/1001", when these field rates are totally uncommon? Also the "standard duration" is now different between 24/1.001 files muxed without manually entering the fps and files where I am now supposed to enter "48000/1001".
Please just return to the old behavior instead of defending accidental changes so stubbornly.

[Mosu]

No, I won't. In fact the new code doesn't require you to enter the default duration at all. Also the "old" way was totally broken for mixed content, for streams in which the SPS changed midstream or where different SPS with different timing information were present, and for files in which the source container provided timecodes for only some of the fields/frames (e.g. a TS file that only provided a timecode for every second field).

As for mmg: I can easily add double the values that are already present.

[Mosu]

I understand that you want an option that "just works" for the user. This option is supposed to be NOT to specify the default duration at all.

[sneaker_ger]

That would still leave the problem of incoherent behavior between manually specifying "48000/1001" (resulting in standard duration = "20854166") and automatically letting mkvmerge detect it (resulting in standard duration = "41708333").

[Mosu]

Look. It's like this. In Matroska the "default duration" is the duration that applies to a "Matroska block" if that "Matroska block" doesn't specify another duration. For h264 progressive content this is one frame. For interlaced content this can be a frame or a field.

The h264 bitstream always contains the field rate even for progressive content -- if it contains timing information at all. mkvmerge uses this field rate as the default duration. Meaning that the duration of a single h264 output unit (field or frame) can be twice the field rate (for a frame) or simply equal the field rate (for a field).

However, mkvmerge is trying to be smart as well. If it detects that the stream only contains frames and not fields then it will use twice the field rate as the default duration. This is done by calculating the most often used duration between the first two key frames. That one is used as the "default duration".

Now to mmg and specifying the default duration manually. There are two possibilities here:

1. The current method. The user has to specify the field rate as the default duration for h264 content. This can result in what you've describe: an inconsistency between what you enter and what you see in the final file if e.g. the content is progressive.

2. I could make the "FPS" in "--default-duration" be interpreted as the number of frames. Meaning mkvmerge would internally use double its value for fields. However, this could lead again to two undesirable situations:

2.1. I use what the user provides as "--default-duration" literally. This means that if the user says "25 FPS" and the content is interlaced with one field in a Matroska block then each Matroska block would have a duration that's different than the default duration. This requires that, on the file level, each Matroska block needs an explicit "duration" element. This also means that "SimpleBlock" elements cannot be used. This results in higher overhead.

2.1. I still detect whether or not fields or frames are usually output and adjust the header value for "default duration" accordingly. This can again lead to the same discrepancy as shown in "1." above: the user specifieds "25FPS" (which corresponds to a default duration of 40000000) but mkvmerge detects fields and writes "20000000" into the track headers.

I don't see any way to make this a) use the least amount of overhead possible while b) not being prone to discrepancies. Unless you do not specify the default duration at all and let mkvmerge decide itself.

[Selur]

Another question regarding --default-duration is the interpretation of fps as fields per second only for H.264 raw content or also for other i.e. MPEG-2 raw content ?

[Mosu]

Another question regarding --default-duration is the interpretation of fps as fields per second only for H.264 raw content or also for other i.e. MPEG-2 raw content ?

At the moment only the handling for h264 has changed. For MPEG-2 it is still "frames per second", more or less, but there are known issues with interlaced MPEG-2 content (e.g. https://www.bunkus.org/bugzilla/show_bug.cgi?id=672 ). However, MPEG-2 doesn't have a high priority for me anymore.

[sneaker_ger]

Look. It's like this. In Matroska the "default duration" is the duration that applies to a "Matroska block" if that "Matroska block" doesn't specify another duration. For h264 progressive content this is one frame. For interlaced content this can be a frame or a field.

The h264 bitstream always contains the field rate even for progressive content -- if it contains timing information at all. mkvmerge uses this field rate as the default duration. Meaning that the duration of a single h264 output unit (field or frame) can be twice the field rate (for a frame) or simply equal the field rate (for a field).

However, mkvmerge is trying to be smart as well. If it detects that the stream only contains frames and not fields then it will use twice the field rate as the default duration. This is done by calculating the most often used duration between the first two key frames. That one is used as the "default duration".

Now to mmg and specifying the default duration manually. There are two possibilities here:

1. The current method. The user has to specify the field rate as the default duration for h264 content. This can result in what you've describe: an inconsistency between what you enter and what you see in the final file if e.g. the content is progressive.

2. I could make the "FPS" in "--default-duration" be interpreted as the number of frames. Meaning mkvmerge would internally use double its value for fields. However, this could lead again to two undesirable situations:

2.1. I use what the user provides as "--default-duration" literally. This means that if the user says "25 FPS" and the content is interlaced with one field in a Matroska block then each Matroska block would have a duration that's different than the default duration. This requires that, on the file level, each Matroska block needs an explicit "duration" element. This also means that "SimpleBlock" elements cannot be used. This results in higher overhead.

2.1. I still detect whether or not fields or frames are usually output and adjust the header value for "default duration" accordingly. This can again lead to the same discrepancy as shown in "1." above: the user specifieds "25FPS" (which corresponds to a default duration of 40000000) but mkvmerge detects fields and writes "20000000" into the track headers.

I don't see any way to make this a) use the least amount of overhead possible while b) not being prone to discrepancies. Unless you do not specify the default duration at all and let mkvmerge decide itself.

Sorry, that still doesn't make any sense to me, but let me get this straight:
1. What mkvmerge calls "--default-duration" and what you're intending to label as "default duration" in mmg, actually means "field rate" for h.264.
2. With mkvmerge, there will be no way to get a correctly set DefaultDuration (http://matroska.org/technical/specs/index.html#DefaultDuration) Track element for progressive H.264 content when manually choosing framerate/field rate/default duration.

[Mosu]

For h264: The "default duration" header element should contain either the field rate IF there are fields present or double the field rate = the rame rate if only frames are present.

Like I said, Matroska itself does not know anything about a "field rate" or "frame rate". It only knows about how long that content stored in a single Matroska block should be.

If the user insists on specifying this value then he must know exactly what his source file contains. Otherwise the value he enters as the default duration may not be the one that mkvmerge writes to the file (as it is now), or mkvmerge would have to be changed in this regard and then it would cause higher overhead in the file as each Matroska block would have a different duration that the default duration indicates.

Like I said, the correct solution is not to specify the default duration at all.

[sneaker_ger]

Like I said, Matroska itself does not know anything about a "field rate" or "frame rate". It only knows about how long that content stored in a single Matroska block should be.

If the user insists on specifying this value then he must know exactly what his source file contains. Otherwise the value he enters as the default duration may not be the one that mkvmerge writes to the file (as it is now)

No. Wrong.
Currently (416 pre) there is no way at all to use "--default-duration" on progressive content correctly. Try it!

I don't understand why you arbitrarily chose "--default-duration" to expect the field rate (and only for h.264 at that). Might as well let it expect the ... eh ... default duration (or the respective "fps" value).

[Mosu]

OK, let's assume I'll change how --default-duration works. What would you as a user want it to do?

Remember: the "default duration" header value should, in the end, contain the default duration of a single Matroska block. Otherwise the experience upon playback may not be what the user expects it to be! (E.g. if the user thinks "hey, I'll enter 25FPS even for interlaced content" and players use that value for each Matroska block -- even though each Matroska block only contains a field but not a frame. I've seen that happen.)

[sneaker_ger]

Well, let's just be consequent and let it expect the default duration in the Matroska sense:
For a 25p file: user chooses "25"s^(-1) in mmg or "40ms"
For a 25i file: user chooses "50"s^(-1) in mmg or "20ms"

Result: each block has the correct length and the "DefaultDuration" Track element is set correctly.
I would also be fine with either frames per second or fields per seconds, it's just that I consider pre 416's progressive muxing wrong.

[Mosu]

Well, let's just be consequent and let it expect the default duration in the Matroska sense:
For a 25p file: user chooses "25"s^(-1) in mmg or "40ms"
For a 25i file: user chooses "50"s^(-1) in mmg or "20ms"

After having thought about this I don't like a lot anymore. This would require that mkvmerge analyses what kind of a bitstream is present and converting the number from "frames per second" to "fields per second". At the moment mkvmerge's timestamping formula is pretty simple:

multiplier = current_block_is_a_field ? 2 : 1
timecode = previous_timecode + default_duration * multiplier

I have another suggestion. If the user specifies the --default-duration then mkvmerge always assumes that the user meant "frames per second". What the h264 code does internally doesn't matter: it would simply use the user-supplied value and use half of it for its default_duration internally.

However, this would mean that the default_duration written to the file may be different than the value the user supplied. On the other hand it would make it easier for the user: no matter whether or not the input is 25p or 25i the user only has to enter "25fps". And I could leave mmg's "FPS" field as it is, meaning it wouldn't be renamed to "default duration".

Thoughts?

[mbcd]

Muxing a progressive 23,976 fps h264-file: It seems to work fine here.

Duration is shown with 41708333 ms, thats correct.
VLC shows: Bildwiederholrate: 47.952047, but plays at correct speed.

You should implement all Framerates, as they are usualy given by frames. 25i is 50P, everywhere this is that way and it has ever been, at mmg it is 25, thats really confusing. Every program uses fullframes for definition, nor fields. If user defines manualy he has to know if source is progressive or interlaced.

If frame is progressive or interlaced is work of decoder / muxer.

25p is 25p.

So i would suggest for manual input:
23,976, 24/1001 = 41,708375041708375041708375041708
24,000, 24/1000 = 41,666666666666666666666666666667
25,000, 25/1000 = 40 -> 25P
29,970, 30/1001 = 33,366700033366700033366700033367
30,000, 30/1000 = 33,3
50,000, 50/1000 = 20 -> 50p / (25i) --> is 20ms per field = 40ms as block (frame)

so I think Im mostly dealing with sneaker_ger in that point of user-Input.
MMG still misses 50fps (25i) /60fps (30i) as userinput.

I you could find out if stream is interlaced or progressive there should not be a problem dealing with 50p(=40ms) on interlaced material:

multiplier = current_block_is_a_field ? 40/2 : 40/1

But it is still confusing:
You say that the duration is for every block, and a block can consist even fields or frames, so mmg splits "frames" if they are interlaced, so:
1 Progressive Frame = 1 block
1 Interlaved Frame = 2 blocks

am I right?

So "kick of" default-duration, say generally that the progressive (deinterlaced) Framerate is mandantory, otherwise you get in hell with progressive and interlaced.

[sneaker_ger]

After having thought about this I don't like a lot anymore. This would require that mkvmerge analyses what kind of a bitstream is present and converting the number from "frames per second" to "fields per second". At the moment mkvmerge's timestamping formula is pretty simple:

multiplier = current_block_is_a_field ? 2 : 1
timecode = previous_timecode + default_duration * multiplier

I have another suggestion. If the user specifies the --default-duration then mkvmerge always assumes that the user meant "frames per second". What the h264 code does internally doesn't matter: it would simply use the user-supplied value and use half of it for its default_duration internally.

However, this would mean that the default_duration written to the file may be different than the value the user supplied. On the other hand it would make it easier for the user: no matter whether or not the input is 25p or 25i the user only has to enter "25fps". And I could leave mmg's "FPS" field as it is, meaning it wouldn't be renamed to "default duration".

Thoughts?



Yes, that is fine, I guess. Better to make it work the same as the older versions than to arbitrarily switch to a different way, unless it offers any significant improvement. And it does indeed not matter what H.264 does internally.

[Mosu]

@mbcd: No, you suggested something else than sneaker_ger. sneaker_ger said that for 25i the user should have to enter "50fps". I don't like that. Like I said in my post after sneaker_ger's, I would suggest that the user enters "25fps" for both 25p and 25i content and 50fps for both 50p and 50i (and so on). mkvmerge would do the "right thing" with that information.

The only downside would be that for 25i content the "default duration" element would contain "20000000" meaning a default duration of 20ms which is only half the value the user supplied. However, there's always one downside. The advantage is that the user only deals with "frames per second" and not with the question whether or not the content is progressive or interlaced.

Muxing progressive content without the --default-duration given is working just fine, that's right.

[sneaker_ger]

Yeah, I think the "frames per second" is more user friendly. Or one would differ between durations (ms, ns...) and rates (fps). The former getting used exactly as specified and the latter being divided by 2 for interlaced tracks.

But my main complain never really was about in which format the user has to supply these values, but the fact that for progressive content mkvmerge writes the wrong "DefaultDuration" value. I still wonder if Mosu really understands what I'm complaining about: a bug!

[Mosu]

But my main complain never really was about in which format the user has to supply these values, but the fact that for progressive content mkvmerge writes the wrong "DefaultDuration" value. I still wonder if Mosu really understands what I'm complaining about: a bug!

This does not happen if you do NOT specify a --default-duration:

[0 mosu@tionne /ftp/.rip/mkv/h264] mkvmerge -o IcePrincess-nodefault.mkv IcePrincess.h264
mkvmerge v5.3.0 ('I could have danced') built on Mar 4 2012 17:24:24
'IcePrincess.h264': Using the demultiplexer for the format 'AVC/h.264'.
'IcePrincess.h264' track 0: Using the output module for the format 'AVC/h.264'.
The file 'IcePrincess-nodefault.mkv' has been opened for writing.
'IcePrincess.h264' track 0: Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 1920/1088.
Progress: 100%
The cue entries (the index) are being written...
Muxing took 3 seconds.
[0 mosu@tionne /ftp/.rip/mkv/h264] mkvinfo -s IcePrincess-nodefault.mkv|head -n 4
Track 1: video, codec ID: V_MPEG4/ISO/AVC (h.264 profile: High @L4.0), language: und, pixel width: 1920, pixel height: 1088, display width: 1920, display height: 1088, default duration: 40.000ms (25.000 fps for a video track)
I frame, track 1, timecode 80 (00:00:00.080), size 82504, adler 0xbc38e88e
B frame, track 1, timecode 0 (00:00:00.000), size 25210, adler 0xf56842b0
P frame, track 1, timecode 40 (00:00:00.040), size 28907, adler 0xeca776a4

However, you are right that if you do specify a --default-duration then it is wrong:

Track 1: video, codec ID: V_MPEG4/ISO/AVC (h.264 profile: High @L4.0), default duration: 40.000ms (25.000 fps for a video track), language: und, pixel width: 1920, pixel height: 1088, display width: 1920, display height: 1088
I frame, track 1, timecode 160 (00:00:00.160), duration 80.000, size 82504, adler 0xbc38e88e
P frame, track 1, timecode 0 (00:00:00.000), duration 80.000, size 25210, adler 0xf56842b0
P frame, track 1, timecode 80 (00:00:00.080), duration 80.000, size 28907, adler 0xeca776a4

I will fix that, of course, along with the changes we've discussed.

I think I'll stay with "--default-duration always applied to a full frame and the packetizer will have to use half its value if its calculations are field-based". Treating the --default-duration units "fps" and "ms" differently seems error prone from a usage standpoint.

[sneaker_ger]

Good, I agree, so we can end this discussion.
Anyways, mkvmerge automatically reading the fps of h.264 ES is a very good change. Those popup windows in mmg were annoying, setting the fps was tedious and now we will have less newbies asking about these problems. Batching also got easier as a small bonus.

[Mosu]

That was the intention :)

[sneaker_ger]

One small thing I forgot:
mkvmerge pre 416 writes the "DefaultDuration" Track element even when a timecode file is supplied, while it probably shouldn't write any value in that case.

[Mosu]

Even with a timecode file the default duration should still be set. This should be done by calculating the most-often used duration in the timecode file. I'll take a look at the current state.

[sneaker_ger]

You can use the file I posted yesterday:
https://forum.doom9.org/showthread.php?p=1563354#post1563354

For the hybrid file x264 used 120/1.001 Hz as the timebase and that is what pre 416 takes for the DefaultDuration value at the moment.

[mbcd]

@mbcd: No, you suggested something else than sneaker_ger. sneaker_ger said that for 25i the user should have to enter "50fps". I don't like that. Like I said in my post after sneaker_ger's, I would suggest that the user enters "25fps" for both 25p and 25i content and 50fps for both 50p and 50i (and so on). mkvmerge would do the "right thing" with that information.

Damn, is this shit complicated :sly: :cool:

Yes, thats what I meant ... Dealing with fullframes, so 25i IS 50(p)
If User has video of 25i he has to enter 50, thats usual
If User has video of 25p he has to enter 25, thats logic

Video is alway counted in Frames, not in Fields, so I wouldnt change that for mmg.


The only downside would be that for 25i content the "default duration" element would contain "20000000" meaning a default duration of 20ms which is only half the value the user supplied. However, there's always one downside. The advantage is that the user only deals with "frames per second" and not with the question whether or not the content is progressive or interlaced.

Muxing progressive content without the --default-duration given is working just fine, that's right.

But that it, If you have 25 interlaced Frames, you dont have 25 Frames per second, but 50 Frames. So you are not dealing with "Real-Frames", but interlaced Frames. And a Frame is never a mix of both frames, like they are packed as interlaced together in one "Frame".

I think that this is confusing the stuff a little bit. I woudnt do it that way, but its your decision, I think its a wrong interpretion as usual used.

But not to forget:
Thanks for the new features and your work on it !!!!! :thanks::thanks::thanks:

[Mosu]

Here's a new build with these changes (only listing the ones relevant to our current discussion):

2012-03-07 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: When using an external timecode file with AVC/h.264 video the default duration will be set to the most-often used duration in the timecode fi\
le.
* mmg: enhancement: Added the values "50", "60" and "48000/1001" to the list of commonly used values for the "FPS" input field.
* mkvmerge: bug fix: AVC/h.264 packetizer: The value given with "--default-duration" is now again interpreted as the number of "frames per second". The conversion\
to "fields per second" is done internally; the user doesn't have to think about it, though.

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/ build 417 and newer

[Mosu]

Damn, is this shit complicated :sly: :cool:

Yes, thats what I meant ... Dealing with fullframes, so 25i IS 50(p)
If User has video of 25i he has to enter 50, thats usual

Wrong. The "i" behind the value means interlaced. With "interlaced" the number before the "i" refers to the number of fields per second. Therefore this would actually mean "12.5 frames per second".

Also there isn't something like "25i". Yes, I used this wrong above.

See http://www.hdtvprimer.com/ISSUES/what_is_ATSC.html

Now to mmg. With build 417 the value entered is always interpreted as the number of frames per second. Therefore here are a couple of examples that should work correctly:

source is 25p: enter "25"
source is 50i: still enter "25"
source is 50p: enter "50"


I could also add more parsing code that would accept "number followed by either p or i", e.g. "25p" or "50i" and convert it accordingly.

[Midzuki]

I could also add more parsing code that would accept "number followed by either p or i", e.g. "25p" or "50i" and convert it accordingly.

Another possibility: just add a checkbox which says "the source is interlaced" or something :)

[Mosu]

I think that terms like "25p", "50i" are more common and would actually be of help.

[Mosu]

Here's a new build with these changes (only listing the ones relevant to our current discussion):

...

build 417 and newer

Actually, build 417 is working fine with progressive content (both with --default-duration, --timecodes and with mkvmerge's auto-detection). Unfortunately it was its problems with interlaced content if --default-duration is used (similar to how it had those problems with progressive content). Will investigate and fix.

[Mosu]

A new build is up, 418. It fixes the issue with --default-duration on interlaced content. It also introduces a new feature: being able to use "number postfixed with 'i' or 'p'" for --default-duration, e.g. "--default-duration 0:50i". mmg's corresponding "FPS" drop down box contains a lot of new default values as well: everything from "24p" down to "60000/1001i".

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/

I'd highly appreciate some testing.

[sneaker_ger]

Seems to work.
Though the drop down box is really long now. I'd remove all "48000/1001" values, as that is no common value. Same goes for all values without any letter at the end, because "no letter"=="p", I guess. Having both in there is too confusing for users.

The "DefaulDuration" for my VFR sample was set to "32999999"(~=30.3 fps) with timecode v2 file input, which can't be right for a VFR with a maximum of 29.97 fps. :confused:
Seems to work as expected when using timecode v1, though.

[Mosu]

Not quite right. Here's how mkvmerge calculates the default duration for a timecode v2 file:

First, it reads all the timecodes in the file and sorts them.
Second, it calculates each timecode's duration as the difference between the following one and itself.
Third, it records each duration's absolute probability.
The default duration is the one with the highest absolute probability.

For your file these are the absolute probabilities:

Debug> src/merge/timecode_factory.cpp:243: Absolute probablities with maximum in separate line:
Debug> src/merge/timecode_factory.cpp:244: Duration | Absolute probability
Debug> src/merge/timecode_factory.cpp:245: ----------+---------------------
Debug> src/merge/timecode_factory.cpp:253: 33000000 | 2052
Debug> src/merge/timecode_factory.cpp:253: 34000000 | 1187
Debug> src/merge/timecode_factory.cpp:253: 41000000 | 292
Debug> src/merge/timecode_factory.cpp:253: 42000000 | 709
Debug> src/merge/timecode_factory.cpp:256: Max-------+---------------------
Debug> src/merge/timecode_factory.cpp:257: 33000000 | 2052

Therefore 33000000 is the winner. Don't blame mkvmerge, blame your file :)

[sneaker_ger]

Eh...correct (except for "33000000" becoming "32999999"). Damn.

[Mosu]

I cannot reproduce the issue with 33000000 becoming 32999999. Anyway, I've removed a conversion from int64_t to double and back again in the v2 timecode factory. Pre-build 421 from www.bunkus.org/videotools/mkvtoolnix/win32/pre/ will contain that fix. mmg from the same pre-build will also only contain the "p" and "i" postfixed FPS values. The 48000/1001 ones have been removed as well.

Pre-build 421 should be available in shortly.

[sneaker_ger]

The rounding's working now with 421.

[Mosu]

Then I guess the Windows build was converting int -> double -> int differently than the Linux build. Happens. Anyway, no conversion, no problem :)

[Selur]

mkvmerge: bug fix: AVC/h.264 packetizer: The value given with "--default-duration" is now again interpreted as the number of "frames per second".
Okay, so the 'i'/'p' thing is dropped,... -> this does mean the 'fps' postfix is back, correct?

[Mosu]

OK, that changelog message was indeed confusing.

Now for "--default-duration": 'i' and 'p' are there to stay. 'fps' is also not going anywhere. If no unit is given then "ms" is assumed. mkvmerge always converts the value to "ns" internally as this is the resolution that Matroska works at (before applying timecode scale).

For mmg's "FPS" input field: If you enter a value without a unit then "fps" or "p" is assumed as both evaluate to the same. You can still enter "i" or "p" as a unit.

What the changelog message actually meant was: Before the change the h264 packetizer would interprete the value that was ultimately calculated for "--default-duration" as the duration of a field and not of a frame. That was the "arbitrary change" that several people here complained about, including speaker_ger.

After this change the value is again interpreted as the duration of a single frame. If the unit that the h264 packetizer outputs is a field then it will simply use half the duration.

For the user it means that he doesn't have to care about whether or not some part of mkvmerge thinks in fields or frames.

[Selur]

okay,.. to get this clear

for 50i (25 interlaced frames = 50 fields) would I use:
--default-duration 1:25ifps
or
--default-duration 1:25i ? (I guess the second)
and for 60p:
--default-duration 1:60pfps
or
--default-duration 1:60p
or
--default-duration 1:60fps
(I guess the later two are possible)

Cu Selur

[Mosu]

Normally you don't have to enter anything there anymore! mkvmerge will simply do the right thing itself. That was the whole point of the rewrite.

There is nothing like 25i. 25i would mean 12.5 frames per second. If your material is 50 interlaced frames/fields then you use 50i.

All values with 'p' as a unit are equivalent to the unit 'fps'. Therefore '25p' would be the same as '25fps' or '40ms'.

There are no units called 'ifps' or 'pfps'. There are only the units 'i', 'p' or 'fps' along with the time-based units 's', 'ms', 'us' or 'ns'.

See http://www.hdtvprimer.com/ISSUES/what_is_ATSC.html

[Selur]

That was the whole point of the rewrite.
I prefer to write it out to know what value was used when I log at my log files. ;)

Thanks for clearing the rest up. :)
(so for 50i I would use --default-duration 1:50i and be happy, right?)

[Mosu]

Suit yourself. Just don't complain if you use the wrong values then :)

[szabi]

Hi

I added global, video and audio tag info to matroska.
I do not know why, but audio tag is displayed in global area, by mediainfo (http://mediainfo.sourceforge.net)
Could anyone try it, for re-checking?

bye
szabi

[Selur]

probably a 'bug' in MediaInfo,..

[Liisachan]

It's not a problem of mkvmerge. I've experienced a similar problem for example when both video and audio tags have ENCODER_SETTINGS (it looks like the value of the audio one "overwrites" and hides the video's one). I've seen that both in MPC-HC and VLC but it's so minor it didn't bother me.

[Mosu]

I've released mkvtoolnix v5.4.0. It's a release that contains one huge improvement: the AVC/h.264 timecode assignment code has been completely rewritten. Users do not have to specify the default duration/FPS for such tracks anymore safe for the rarest cases. Apart from that there were tons of bug fixes, improvements regarding file type recognition, and a complete re-write of the (E)AC3 parsing code.

A note for package maintainers: Boost's rational library is now required.

Here are the usual links...

...to the home page:
http://www.bunkus.org/videotools/mkvtoolnix/

...to the source code:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-5.4.0.tar.bz2

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.4.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.4.0.7z

All of the Linux binaries that I provide have already been built and are available.

Here's the full ChangeLog since release 5.3.0:

2012-03-10 Moritz Bunkus <moritz@bunkus.org>
* Released v5.4.0.

2012-03-08 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed wrong calculation of the maximum number of ns per cluster in certain fringe cases if timecode scale was set to "auto" mode ("--timecode-scale -1"). Fix for bug 707 (https://www.bunkus.org/trac/ticket/707).

2012-03-07 Moritz Bunkus <moritz@bunkus.org>
* build system: The C++ compiler must now support the C++11 keyword 'nullptr'. configure checks for it. For GCC this means at least v4.6.0.
* mkvinfo: new feature: mkvinfo will output the track ID that mkvmerge and mkvextract would use for a track. This information is shown alongside the "track number" element in verbose mode and in the track summary in summary mode.
* mkvmerge, mmg: enhancement: The "--default-duration" in mkvmerge and the "FPS" drop down box in mmg now accept "p" or "i" as a unit -- as in e.g. "25p" or "50i". Several commonly used values have been added to mmg's "FPS" drop down box and others removed.
* mkvmerge: bug fix: When using an external timecode file with AVC/h.264 video the default duration will be set to the most-often used duration in the timecode file.
* mmg: enhancement: Added the values "50", "60" and "48000/1001" to the list of commonly used values for the "FPS" input field.
* mkvmerge: bug fix: AVC/h.264 packetizer: The value given with "--default-duration" (after internal conversion from the unit given by the user to duration in nanoseconds) is now again interpreted as the duration of a frame and not of a field.
* mkvmerge: bug fix: SRT subtitles: timecodes can contain the minus sign before any digit, not just before the first one.

2012-03-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Sometimes non-AC3 files were mistakenly for AC3 after the re-write of the AC3 handling code on 2012-02-26. This has been rectified. Fix for bug 723 (https://www.bunkus.org/trac/ticket/723).

2012-03-04 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: mkvmerge will keep the "enabled" track header flag when muxing. mkvmerge will also output its value in verbose identification mode as "enabled_track".
* mkvmerge: enhancement: MicroDVD text subtitles are recognized as an unsupported format instead of an unknown format.
* mmg: The warning that no default duration/FPS has been given for AVC/h.264 tracks has been removed.
* mkvmerge: bug fix: Complete re-write of the timecode handling code for AVC/h.264 tracks. Now handles several cases correctly: interlaced video, video with multiple or changing SPS with different timing information. The timing information is extracted from the bitstream. Therefore the user doesn't have to specify the default duration/FPS himself anymore. Fix for bugs 434 and 688.

2012-02-26 Moritz Bunkus <moritz@bunkus.org>
* build system: Boost's "rational" library is now required.
* mkvmerge: bug fix: Complete re-write of the (E)AC3 parsing and handling code. Dependent EAC3 frames are now handled correctly. Fix for bug 704 (https://www.bunkus.org/trac/ticket/704).

2012-02-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The width and height of h.264 video tracks with a pixel format other than 4:2:0 are now calculated correctly. Fix for bug 649 (https://www.bunkus.org/trac/ticket/649). Patch by Nicholai Main (see AUTHORS).
* mkvmerge: bug fix: Fixed file type recognition and frame drops for VC1 elementary streams that do not start with a sequence header but with frame or field packets instead.
* mkvmerge: bug fix: Fixed mis-detection as unsupported DV files (happened for e.g. PGS subtitle files).

2012-02-12 Moritz Bunkus <moritz@bunkus.org>
* doc: enhancement: Updates for option file usage and supported subtitle formats.

Have fun.

Kind regards,
mosu