MKVToolNix v24.0.0 released

[Chetwood]

Edit: well I wouldn't call 50MB per episode (zlib-compressed) a "minimal factor" (2 sub tracks). I can compress the whole episode to less than 100MB in a way it will be watchable.
What resolution has the ep? Can't imagine that big subs on such a small file. Resize them or convert to ASS or something...

[Keiyakusha]

What resolution has the ep? Can't imagine that big subs on such a small file. Resize them or convert to ASS or something...

Ep is 720p. Of course I'm not going to use these subs with such video. This is just an example. But all possible conversions require a bit too much of effort. Especially OCRing. English maybe fine, but I have no much luck with Japanese subs. It is probably easier to rewrite them by hand than correct all OCR failures. Not to mention that I haven't yet figured out what to do if they are written vertically at the right side instead of horizontally at the bottom. But this is already offtopic here. Sorry.

[Liisachan]

Hi, Mosu!
This is not a real request, but something I happened to notice.

MMG can't transmux an existing Matroska file into a new one IF a track in the source file has an obsolete language code (scr, scc, or mol), unless the user explicitly selects a new language code for every one of such tracks. By default, an exsisting value is passed as --language to mkvmerge, and mkvmerge refuses an obsolete value. Those 3 codes got deprecated (http://www.loc.gov/standards/iso639-2/php/code_changes.php) (though not invalidated) by ISO in 2008. In my quick check, mkvtoolnix used scr/scc until 2009, mol until 2010. So files created a few years ago (or with old tools) may contain them. By default, mkvmerge itself just copies any langauge code, valid or invalid, when transmuxing Matroska to Matroska. The problem occurs only when an obsolete value is *explicitly* specified as --language, possibly by a user, but more likely by MMG.

I'd think that handling those tags in the mkvmerge level sounds reasonable (converting transparently "scr" to "hrv"; "scc" to "srp"; "mol" to "rum"), somewhat like when it handles "eng".
But this may be an unimportant, niche problem after all :)

Also, the language list box of MMG doesn't know what to do if the item it needs to show is not in the list. If that happens, it keeps showing whatever item it previously shows. Suppose you have an MKV file with track0=video, track1=audio, track2="scr" (sub), track3="scr" (sub). You open it with MMG and manually select "hrv" for the track2, knowing that this tag should be updated. The problem is, when you select track3, the language list says "hrv" as if the new value was already selected, when it isn't. The file won't mux, and the error message says "scr" is bad. You double-check track2 and track3, but they're both "hrv" on MMG. I was puzzled for a while.

Thank you again for your wonderful tool anyway!

[Mosu]

Actually mkvmerge does nothing special to "eng" at all. That's libmatroska -- to be more precise, "eng" is set as the default value in the library for the language element, and libmatroska generally checks all elements whether or not they equal their default value before writing them.

Your conclusions about what you've seen sound reasonable and correct to me; it's most likely mmg setting that value. I'll try to keep it in mind so that it can get fixed one of these days.

[Mosu]

Oh, and I've taken the liberty to open a bug report by copying your post: https://trac.bunkus.org/ticket/803

[Liisachan]

Thanks, Mosu. I thought about going to the tracker directly, but wasn't sure if this would be a valid bug report. BTW I was not complaining about "eng" - I know the repeated discussion about "eng" and the logic behind it.

[Mosu]

It's definitely a bug, more like two bugs: mkvmerge should change those values on the fly, and mmg should do the same. It might be enough to fix mkvmerge as mmg queries mkvmerge for a file's language, though.

[DragonQ]

Mosu, madshi reckons the MKVs I'm making have "50p" in the header, which is why they're not being deinterlaced by MadVR. I am setting all of these MKVs to "50i" when using MKVMerge so presumably there's a bug somewhere?

[Mosu]

The "50p" vs "50i" only tells mkvmerge how to calculate timecodes. No other setting AT ALL is affected by this. Meaning there is no "interlaced" or "progressive" flag, neither can the "default duration" be interpreted as the number of frames or fields per second! See https://www.bunkus.org/answers/?qa=205/why-is-the-fps-frame-rate-wrong

Perhaps you could ask Madshi to post in this very thread what he means with "50p in the header".

[sneaker_ger]

I cannot reproduce it, anyways. Setting "50i" makes standard duration 40ms as expected.

[DragonQ]

Perhaps you could ask Madshi to post in this very thread what he means with "50p in the header".

I have asked him to post here.

I cannot reproduce it, anyways. Setting "50i" makes standard duration 40ms as expected.

But does the sample I posted earlier work properly for you?

[Mosu]

I haven't played it yet, won't do so until Madshi chimes in here. Busy days at the moment.

[sneaker_ger]

But does the sample I posted earlier work properly for you?

50i -> 20ms standard duration for TS -> MKV

The remuxed MKV does not play properly for me. No deinterlacing and not fluid. (Jumping back and forth)
Maybe we should ask Nev and not madshi.

/edit:
How did you create the mkv?
Mine is different from yours if I create one from the TS myself. Yours is even bigger than the source TS.

[DragonQ]

50i -> 20ms standard duration for TS -> MKV

The remuxed MKV does not play properly for me. No deinterlacing and not fluid. (Jumping back and forth)
Maybe we should ask Nev and not madshi.

/edit:
How did you create the mkv?
Mine is different from yours if I create one from the TS myself. Yours is even bigger than the source TS.
It could well be an issue with LAV Filters, but MadVR seems to be affected worse than EVR so it could be an issue with just one or all three (mkvtoolnix, MadVR, LAV)! :D

My step for making the file is as follows:

- Open mmg and add TS file
- Set audio & video to language="eng" and default="yes"
- Set video to 1920x1080 and 50i
- Mux

Using latest Windows build.

[nevcairiel]

LAV just uses the DefaultDuration to create the FPS info. I know, its semantic does not necessarily mean "fps", but without any other fps info available, what are you gonna do. All other splitters seem to behave this way, and users complained when it didn't, so now it does. Its not my fault Matroska fails to actually have a FPS field.
If i turn this off, and let my code try to probe the FPS, it results in 25 fps and the file plays fine. But again, people complained when i had the probing active, i don't remember why though. Probably a problem with the H264 headers saying 24 fps but they remuxed it to 25 fps, or something like that.

I can run some tests some day to see if i find one of such files and see if it can be properly fixed.

DirectShow also says that the "AvgTimePerFrame" (DirectShows "FPS" info) in the media type is an optional element and should not be relied on (in fact, it specifically states it may be 0), so using it for anything critical is also a design problem.

[Zenitram]

LAV just uses the DefaultDuration to create the FPS info. I know, its semantic does not necessarily mean "fps", but without any other fps info available, what are you gonna do.

I am not alone :).
But it definitely fails, especially with VFR files (and you don't know if it is a VFR file, no flags). You must read the raw stream (H.264...) headers in order to have the FPS, as I do with my tool now instead on relying on DefaultDuration field.

[madshi]

Hey guys,

I'm wondering what practical use the "DefaultDuration" in MKV really has. I mean, if you can't use it to find out the (likely) FPS then it's pretty much useless. Why? Because DVDs and broadcasts video streams can often switch between different encoding modes. The encoder might encode some sequences as 24p with telecine flags, then some sequences as 30p without telecine flags, then some sequences as 60i (60 separate interlaced fields), and all of this can switch back and forth *in the same file*. So from my point of view, the "DefaultDuration" can't have any meaningful value for such files. I know what the MKV spec says, but most devs actually do treat "DefaultDuration" for getting a quick hint about which FPS this video file probably has. FWIW, I've always set "DefaultDuration" to the FPS when muxing mkv files in eac3to, and I've not heard of any problems with this approach yet. If you (Mosu) want to stick to the letter of the spec then I can understand that. In that case we should probably talk to the MKV spec guys and ask them to re-add a proper "fps" information field? I do believe that MKV files do need some sort of "fps" information header field. If "DefaultDuration" can't be used for that, then we need a dedicated field.

Anyway, from madVR's point of view, I have no direct contact to the MKV at all. So in theory it doesn't matter to madVR which value MKVs have their "DefaultDuration" value set to. However, since pretty much all MKV splitters out there read out the "DefaultDuration" and pass it untouched on to madVR as the "AvgTimePerFrame", it does matter to madVR after all. Because "AvgTimePerFrame" has a very specific definition to define the FPS. Ok, "AvgTimePerFrame" might sometimes be 0. But still, it's the easiest information field to look at when trying to understand what kind of FPS the video file has. madVR currently uses "AvgTimePerFrame" for 2 purposes:

(1) To find the correct display refresh rate to switch to (auto display mode switcher).
(2) To decide whether the source video should be deinterlaced or not. madVR only deinterlaces 50i and 60i content. If "AvgTimePerFrame" indicates 50p, madVR turns deinterlacing off.

Maybe I'll implement some complicated fps guessing algorithms in a future madVR version, but such guessing algorithms can always fail, especially if you need them to work quickly. madVR needs to decide which refresh rate to switch to right at the very start of playback, before the first video frame is shown. I can't switch display modes after half a minute of playback or so (users would very much hate that), so I can't use a (reliable) long term frame rate analyzer to find out the FPS.

[Mosu]

Hey guys,

I'm wondering what practical use the "DefaultDuration" in MKV really has. I mean, if you can't use it to find out the (likely) FPS then it's pretty much useless. Why? Because DVDs and broadcasts video streams can often switch between different encoding modes. The encoder might encode some sequences as 24p with telecine flags, then some sequences as 30p without telecine flags, then some sequences as 60i (60 separate interlaced fields), and all of this can switch back and forth *in the same file*. So from my point of view, the "DefaultDuration" can't have any meaningful value for such files.

An FPS field would have the very same issue. If such a hypothetical FPS field contained 30p FPS for such a file then it would be just as invaild for most sequences that use other material.

What the default duration does? It tells you how long to display a frame you've just read without having to read the next frame in the file. Similar to how the granulepos works in Ogg files (the granulepos tells you the end timecode of of the current package).

I know what the MKV spec says

It has said that forever. There has never been an FPS field in Matroska that was used.

but most devs actually do treat "DefaultDuration" for getting a quick hint about which FPS this video file probably has

And that is wrong.

In that case we should probably talk to the MKV spec guys and ask them to re-add a proper "fps" information field?

That would not solve anything. What would you put into that field for mixed content such as you've described above? And what information could a player gain reliably from such a field that it cannot get from the default duration?

And how do you suppose players should act when the timecodes do not match multiples of the FPS field anymore? Try to force timecodes to multiples (resulting in very jerky playback in case of FPS switching content)? Ignore the discrepancy, potentially syncing content to display frequencies of completely different FPSed content?

You can already derive the FPS from the combination of the DefaultDuration and the video content. Yes, it's ugly; I haven't said it's a nice way, just a possibility.

First method: analyse the bitstream headers and see which FPS is stored there. Obvious drawback: a) it somewhat violates the spirit of Matroska which says that container information has precendence over bitstream information (e.g. if bitstream says 24fps and container says 25fps, judging from the default duration, then the blocks will most likely be 40ms apart, and a player assuming 24fps would always find the blocks arriving a bit too early for its taste); b) the user wouldn't have a way of correcting wrong information at the bitstream level

Second method: combine default duration with frame/field type of first frame(s). Take the default duration. Look for the first video blocks. If they're fields then 1/2*DefaultDuration is your likely FPS; if they're full frames then 1/DefaultDuration is your likely FPS.

[nevcairiel]

If you follow the letter of the spec, you should not use DefaultDuration at all for FPS, and simply compute it from the frame timestamps, which is what ffmpeg/LAV can do, if i tell it to ignore the DefaultDuration (but caused complains before).
There is no guarantee that the DefaultDuration is related to the FPS at all. Its a implementation specific thing in mkvmerge that it happens to be related.

So the only two valid options for me are either to trust the DefaultDuration, or don't trust it at all, but trying to "guess" based on an implementation detail in mkvmerge seems even more fragile.
I'll most likely stop trusting it at some point, when i find the time to investigate properly how this affects files with different muxing "issues" (bitstream headers different to mkv headers, etc).

PS:
No matter how you determine a FPS value, in mixed content/VFR you fail in every case.

PPS:
Why is matroska.org broken anyway?

[Mosu]

PPS:
Why is matroska.org broken anyway?

No idea, I don't host the site. But thanks for noticing; I'll try to contact Steve about it.

[Zenitram]

And what information could a player gain reliably from such a field that it cannot get from the default duration?

The same reliably as the "duration" field = not a lot, but it is a good hint (especially in case of VFR, currently it is not possible to have any hint about FPS change without parsing Gigabytes of data, or did I miss something? I appreciate a lot mp4 files for this...). Surprise, "Duration" field is present ;-).
If Matroska specs are logical, "Duration" field would not exist, it is useless (or not) and reliable (or not) as FPS field is.

It is a design choice, why not, we only say it is a pain for developers: yes, FPS is useful, as duration field is. We can live without both, but both are good for a quick scan. Currently, with a quick scan, we fail to detect correctly FPS because the muxer (it does know the value at the end of the muxing) doesn't provide this useful piece of information and we must guess it (and we often fail if we don't accept, for performance reasons, to parse the whole file).

Don't worry, I'll live with it and I will continue to say to people complaining about errors that I can not guess correctly due to lack of data in the file during a quick scan :). Or do you have a method for detecting the average/min/max frame rate without parsing the whole file? I know how to do it with mp4 files, but I did not find for Matroska files.

[madshi]

An FPS field would have the very same issue. If such a hypothetical FPS field contained 30p FPS for such a file then it would be just as invaild for most sequences that use other material.
That would not solve anything. What would you put into that field for mixed content such as you've described above? And what information could a player gain reliably from such a field that it cannot get from the default duration?
The situation I talked about is a totally "valid" movie encoding which after running through a proper IVTC algorithm produces perfect 24p. Whether the encoder used 24p with telecine flags, 30p without telecine flags or 60i, the FPS information in the video bitstream will always be "30p/60i", because that's what you get after "honoring" the telecine flags. 24p with telecine flags = 30p/60i. So that's what the MKV "fps" field should contain. It would be *VERY* useful because it would allow the video renderer to automatically switch to the correct display refresh rate.

What the default duration does? It tells you how long to display a frame you've just read without having to read the next frame in the file.
I'm sorry but that just makes no sense for interlaced video. A proper video renderer will not display interlaced frames untouched. You first run them through a deinterlacer. So the "DefaultDuration" as officially spec'ed has zero practical use for interlaced video, from my point of view as a video renderer developer.

The way the source is encoded (24p + telecine flags, or 30p, or 60i) has no direct consequence as for how long the video renderer will display every "MKV frame". Depending on the content type every frame that comes out of the deinterlacer could be shown either for 1/24seconds or for 1/60 seconds.

And how do you suppose players should act when the timecodes do not match multiples of the FPS field anymore?
I don't know, but this conflict potential is always there. E.g. what happens if the timecodes do not match the video bitstream FPS information? I don't think that's reason enough to not have a valid FPS container header field.

You can already derive the FPS from the combination of the DefaultDuration and the video content. Yes, it's ugly; I haven't said it's a nice way, just a possibility.
Well, the problem is that not all MKVs are muxed the same. For MKV files created with the latest mkvtoolnix version that might work, but for other MKV files it might produce invalid results. Of course you could claim that those other MKV files are violating the spec, but that doesn't really matter in real life. The users won't care that half of their MKV files violate the spec, they just care about having everything work correctly.

First method: analyse the bitstream headers and see which FPS is stored there. Obvious drawback: a) it somewhat violates the spirit of Matroska which says that container information has precendence over bitstream information (e.g. if bitstream says 24fps and container says 25fps, judging from the default duration, then the blocks will most likely be 40ms apart, and a player assuming 24fps would always find the blocks arriving a bit too early for its taste); b) the user wouldn't have a way of correcting wrong information at the bitstream level
Looking at the bitstream headers is probably not a good idea. Most MKV files have audio muxed with the video. So if the container timestamps contradict the video bitstream FPS information then using the video bitstream FPS information for playback would likely make audio and video go async very quickly.

Second method: combine default duration with frame/field type of first frame(s). Take the default duration. Look for the first video blocks. If they're fields then 1/2*DefaultDuration is your likely FPS; if they're full frames then 1/DefaultDuration is your likely FPS.
This would produce wrong results for many many many MKVs already out there today.

[Zenitram]

TLooking at the bitstream headers is probably not a good idea. Most MKV files have audio muxed with the video. So if the container timestamps contradict the video bitstream FPS information then using the video bitstream FPS information for playback would likely make audio and video go async very quickly.

I don't understand this part: if you need syncrhonization, you play/read the whole file, so you don't need any FPS field: you read the time stamps, one per one, nothing else. Any FPS field would be an hint (as duration field is today) for display, nothing else.

[Mosu]

The same reliably as the "duration" field = not a lot, but it is a good hint (especially in case of VFR, currently it is not possible to have any hint about FPS change without parsing Gigabytes of data, or did I miss something? I appreciate a lot mp4 files for this...). Surprise, "Duration" field is present ;-).

A block's duration is very well defined in Matroska, and there's only one situation in which a block's duration could be undefined: if the track does not have a default duration and the very last block in the file does not have a "duration" member.

In all other cases a block's duration is well-defined by:

- For a BlockGroup: if "duration" is present then this duration it is. If it isn't present and the track has a "default duration" then use that. In all other cases the duration is the difference between the next block's start timecode and this block's start timecode. A block's duration also applies to the whole block, meaning to all laced frames. So if you have a BlockGroup with e.g. four laced frames and no "Duration" element, then the block's full duration is 4 * DefaultDuration.
- For a SimpleBlock element: as above, you just cannot have a "duration" child, so only the cases "track with DefaultDuration" and "track without DefaultDuration" are relevant.

Writing the "duration" member of a BlockGroup is only necessary if the block's duration does not equal the track's default duration (scaled to the number of laced frames). So "DefaultDuration" is a major space saver.

It is a design choice, why not, we only say it is a pain for developers: yes, FPS is useful, as duration field is.

I'm not arguing that Matroska's system is the best all around.[1]

I'm arguing against adding another header field whose semantics are not much better than what we have now. It wouldn't give you measurable gain in information and cause a lot of confusion, especially if the then similar fields "FPS" and "DefaultDuration" were obviously mismatched.

Don't worry, I'll live with it and I will continue to say to people complaining about errors that I can not guess correctly due to lack of data in the file during a quick scan :). Or do you have a method for detecting the average/min/max frame rate without parsing the whole file? I know how to do it with mp4 files, but I did not find for Matroska files.

There isn't. It's a design decision in Matroska: being able to recover most of the file even if essential parts are damaged. If the index in an MP4 file is damaged you can throw away the whole file because you don't know where the data blocks start and end for each track (same in AVI). The obvious disadvantage of not having a central index including all elements is having less information available at the start of playback.

[1] Far from it. I know how pretty much all other relevant containers work as I've written parsers for all of them. Matroska's system is better than a lot of them, and worse than others, often due to different goals in what those containers try to achieve. Examples:


All other containers whose timecodes are calculated by multiplying a set value in the header with an integral number (especially AVI): there's no way to account for arbitrarily-sized gaps in the stream. Think of 25fps video in which you have a 60ms gap for whatever reason in one track but not in the others. AVI is especially bad as it only has timecodes for video tracks, not for audio tracks, requiring the use of garbage data in audio tracks for such gaps.
Containers that lack proper container headers: it's... interesting to find out about the FPS of e.g. MPEG-TS requiring sending the stream headers periodically. Again, it's a design decision: MPEG-TS was designed for streaming. Matroska wasn't.
Central index pointing to all data blocks: very bad for streaming; requires splitting such indices into very small chunks (e.g. for every 400ms create headers & said index). The obvious advantage is in non-streaming situations: you have all information there is about a file before starting playback


etc. etc.

[nevcairiel]

Looking at the bitstream headers is probably not a good idea. Most MKV files have audio muxed with the video. So if the container timestamps contradict the video bitstream FPS information then using the video bitstream FPS information for playback would likely make audio and video go async very quickly.

Sync should always be based on the actual stored timestamps, and not some FPS information. Thats what we have timestamps for. :)
So the only thing that would go wrong is the detected FPS again, you should still honor frame timestamps as stored in the file.

[Mosu]

I'm sorry but that just makes no sense for interlaced video. A proper video renderer will not display interlaced frames untouched. You first run them through a deinterlacer.

Last I checked this was still optional in pretty much each and every player.

The way the source is encoded (24p + telecine flags, or 30p, or 60i) has no direct consequence as for how long the video renderer will display every "MKV frame". Depending on the content type every frame that comes out of the deinterlacer could be shown either for 1/24seconds or for 1/60 seconds.

The "DefaultDuration" is not concerned with how long a "frame" is. It concerns itself with the (logical) duration of a single Matroska block. Matroska is agnostic about the display system; it doesn't enforce a deinterlacer to be present, nor does it assume so. It could also be used for hypothetical formats in which frames are split up into more than two fields.

[Zenitram]

being able to recover most of the file even if essential parts are damaged.

???
Fail. If H.264 private part is damaged (few bytes inside Matroska headers), the whole file is unreadable. Matroska as exactly the same risk of loss of the complete file in case of damaged essential parts. If SeekHead + a cluster header is damaged, you lose all after the damaged cluster header (no sync magic value). And so on...
If recovering was the goal, the goal is not met.

I completely understand that you have different goals, my reaction is when you argue Matroska is better that other format for such specific point. In you example, MP4 and Matrsoka have the same exact point of potential failure (corrupted header), Matroska is not better thant MP4 for this. You can not use this argument.

Central index pointing to all data blocks: very bad for streaming; requires splitting such indices into very small chunks (e.g. for every 400ms create headers & said index). The obvious advantage is in non-streaming situations: you have all information there is about a file before starting playback

In the case of ismv (streamable MP4), index are sent every ~10 seconds usually, so I can parse all index relatively quickly (no need to read each MB of the file, for Matroska it is each frame header). We have different goals, MP4 fits better my (and my users') needs, maybe... Matroska as some advantages (e.g. it accepts lot of formats: PGS, srt... Very useful!), but recovering capability is definitely not one! (Ogg, with sync magic value before each frame, is better on this part...)

Matroska is good, but not for everybody :).

[Mosu]

???
Fail. If H.264 private part is damaged (few bytes inside Matroska headers), the whole file is unreadable. Matroska as exactly the same risk of loss of the complete file in case of damaged essential parts.

Well, it's more a theoretical advantage at the moment, I admit, but the specs clearly allow multiple copies of the whole track headers be spread throughout the file.

If SeekHead + a cluster header is damaged, you lose all after the damaged cluster header (no sync magic value).

Wrong, you can resync to all level 1 elements (e.g. clusters) pretty reliably. I have several damaged files in my test case repo for which this works rather nicely.

Matroska is good, but not for everybody :).

You could say the same for Ogg, MPEG-TS, MP4 etc. etc. etc.

But let's stop here and get back to the original problem, please.

[madshi]

Let's talk about practical use:

madVR needs a halfway reliable way to identify the likely FPS of any source video, including MKV. If the latest mkvtoolnix version insists on writing 20000 in there for video frames which have 50 interlaced fields per second then MKVs created by the latest mkvtoolnix version are not compatible to a very big number of MKVs already out there, for any software which guesses FPS by looking at DefaultDuration. All current MKV DirectShow splitters directly see DefaultDuration as the FPS hint, without looking at whether the "MKV blocks" contain one interlaced field or a field pair. And this has worked well so far. So if you insist on writing DefaultDuration the way you currently do, all currently existing MKV splitters need to be changed. And that would result in them breaking with many older MKV files. It would practically mean that splitters couldn't produce correct FPS guesses for all MKVs out there, when looking at DefaultDuration. Do you really think that is a good idea?

IMHO, the only proper way to solve this is to re-add a dedicated FPS field to MKV for which interpretation is totally clear, so every software will treat it the same way. This would result in that all newly muxed MKV files would be detected with the intended FPS written by the muxer. While for all old MKV files splitters could continue to interpret DefaultDuration as they do today.

[Mosu]

So I cannot convince you that such a field won't be added? Alright, I may be wrong. Please send that proposal along with your argument why this is needed in the first place to the Matroska devel mailing list so that Steve can chime in on it. See http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel

[madshi]

@Mosu, just for my interest: Did mkvtoolnix always write DefaultDuration like it is doing now? Or is it a recent change?

What do nevcairiel and Zenitram say? Am I the only one who things a dedicated FPS field might be useful/necessary?

[Mosu]

mkvmerge has long had bugs in which it didn't handle the default duration for AND THE TIMECODES for interlaced content properly. Users always had to say things like '--default-duration 20ms' (meaning they would have to figure out a) the FPS and b) whether or not its interlaced before muxing and tell mkvmerge the correct default duration). If they didn't then playback was pretty much always broken, no matter if things like madshi's video renderer were involved.

I've fixed that this year so that mkvmerge now does "the right thing" automatically and users do not have to specify --default-duration for most cases anymore. That was when I added "50i" etc. to be valid values to "--default-duration".

[madshi]

I see. But then which value did users manually set for default-duration in the past for e.g. a video file which was encoded as 50 separate interlaced fields? Did they set default-duration to 20ms or to 40ms? I rather think they used 40ms, or am I wrong?

[Mosu]

50 interlaced fields, meaning one field per Matroska block? The correct value to use would have been 20ms. mkvmerge wrongly used 40ms resulting in slowed-down display in pretty much all players.

Note that mkvmerge was not just putting 40ms into the header but using 20ms when calculating timecodes for the individual blocks. No. Old mkvmerge versions would use the 40ms for the timecode calculation as well (meaning "default duration" and the actual timecodes would have been consistent, but both consistently wrong).

[madshi]

So basically every 50i video file (with one field per Matroska block), muxed with any mkvtoolnix version, always has/had a DefaultDuration of 20ms. Is that correct? In that case maybe the MKV splitters (and mediainfo) could check which MKV muxer was used and interpret DefaultDuration accordingly to create an FPS hint? For mkvtoolnix muxed MKVs, for such 50i video files, DefaultDuration * 2 would be the proper FPS hint. For other MKV muxers, maybe DefaultDuration * 1 would be the proper FPS hint for such files, though.

Hmmmm... I'm wondering: What happens if the first 2 Matroska blocks have one interlaced field each, but for the rest of the file every Matroska block has a frame (field pair)? Which DefaultDuration are you using then in the latest mkvtoolnix?

I'm still wondering how the MKV spec should be interpreted. On a first check it seems clear. But when thinking about it, I'm not so sure, anymore. The MKV spec reads:

"DefaultDuration: Number of nanoseconds per frame ('frame' in the Matroska sense -- one element put into a (Simple)Block)."

But I find this is somewhat open for interpretation when talking about interlaced video, especially when telecine flags are involved. E.g. which value should DefaultDuration be set to when muxing a 24p/48i stream with telecine flags? The video bitstream header will say it's 60i. A sat receiver will send it as 60i to the display. A DVD player will either send it as 60i or 24p to the display (depending on settings). A DirectShow software decoder might simply ignore the telecine flags and output it as 24p. So which value should DefaultDuration be set to? 1/24? 1/30? 1/60? I really think the whole concept of "DefaultDuration" is not very useful for interlaced video and a "DefaultFPS" would have been much more useful. There's a reason why all video codecs (that I know) have an FPS header field, but no "DefaultDuration" alike header field...

[Zenitram]

Hmmmm... I'm wondering: What happens if the first 2 Matroska blocks have one interlaced field each, but for the rest of the file every Matroska block has a frame (field pair)? Which DefaultDuration are you using then in the latest mkvtoolnix?

DefaultDuration is... Default. so DefaultDuration is the duration of the field pair, and you have specific duration for the 2 other fields. It is explicitely described ("Default"), you can not blame specs for this.

I'm still wondering how the MKV spec should be interpreted. On a first check it seems clear. But when thinking about it, I'm not so sure, anymore. The MKV spec reads:

"DefaultDuration: Number of nanoseconds per frame ('frame' in the Matroska sense -- one element put into a (Simple)Block)."

But I find this is somewhat open for interpretation when talking about interlaced video

It was explicited due to my request to Mosu few months ago: "one element". Now, it is clear ;-).

There's a reason why all video codecs (that I know) have an FPS header field, but no "DefaultDuration" alike header field...

You know not enough ;-).
H.264 frame rate is optional, and I have several files without it.

"DefaultDuration" is 100% internal to Matroska, and it is a default, no more. When we discuss with Mosu, we need to be clear about the meaning of each Matroska field, else the discussion is impossible.

[DragonQ]

Just a quick note since it may be relevant: the "files with AAC audio" that I was talking about earlier also have MBAFF video, which is probably more likely to be the reason that they behave differently to the "files with AC3 audio" than the audio type itself.

[Mosu]

Hmmmm... I'm wondering: What happens if the first 2 Matroska blocks have one interlaced field each, but for the rest of the file every Matroska block has a frame (field pair)? Which DefaultDuration are you using then in the latest mkvtoolnix?

mkvmerge is deriving the most likely default duration from the source container and source bitstream. For blocks whose actual duration does not match that derived value anymore mkvmerge writes "BlockGroup" elements with properly set "Duration" children.

But I find this is somewhat open for interpretation when talking about interlaced video,

No, it isn't. DefaultDuration only has semantics for the Matroska block structure. That's why it is indeed hard to derive the display FPS from it...

especially when telecine flags are involved.

Correct, it is hard, but not DefaultDuration's meaning is perfectly well-defined no matter what the content of a block is. A field, a full frame, telecined or not. I understand where you come from. However, DefaultDuration is not a simple multiplier for display FPS. It always refers to one Matroska block (I'm always taking about a single block; laced blocks require multiplication where appropriate -- I just skip that in my explanation in order not to make it any longer than it already is).

You argue completely from the point of view of the displaying device. DefaultDuration was designed from the point of storage and still keeping information about each individual block, no matter the block's content.

Having an additional "display FPS" field might indeed be a good idea, hence me requesting you take that discussion over to the Matroska devel mailing list.

[madshi]

You know not enough ;-).
H.264 frame rate is optional, and I have several files without it.
I know that, I have such sample files, too. That the h264 FPS field is optional doesn't change my point.

You argue completely from the point of view of the displaying device. DefaultDuration was designed from the point of storage and still keeping information about each individual block, no matter the block's content.

Having an additional "display FPS" field might indeed be a good idea, hence me requesting you take that discussion over to the Matroska devel mailing list.
Will do.

[DragonQ]

So...are you guys saying that MKV just can't handle interlaced files properly? Lot of technical talk there, not entirely sure what the consequences are. :p

[nevcairiel]

Its not directly related to interlaced. The real problem is that MKV just has no reliable FPS info.

[DragonQ]

But I don't understand how this is only a problem with certain files - what is different about them? In the case of the interlaced files with AC3 audio, the only difference I can see between the working and non-working ones is that the latter are newer. :/

Look at these two MediaInfo screenshots - I can't see any difference between the two, yet one file plays perfectly and the other has timecode issues in both EVR and MadVR, and doesn't deinterlace in MadVR. :confused:

[Fullmetal Encoder]

Reading VobSubs from VOBs is not supported. And may never be. Some user started working on that, but I haven't heard from him in months.

Problem? Well in order to create the VobSub's idx part you'd have to parse the whole friggin DVD IDX files and stuff like that. Nothing I'm ever going to do myself.

I am still here. I am still working (slowly) on this. I had to spend a lot of time learning about DVD structures pertaining to chapters and subpictures. Then I had to learn to program. I also went a long time without being able to work on it due to having two jobs and various other life issues happening. But it's still my goal to give mkvmerge this functionality along with at least some basic chapter point detection for DVDs and blu-rays. But I need to carefully study your code to get a better idea of how to proceed.

[Mosu]

So...are you guys saying that MKV just can't handle interlaced files properly?

Not at all, and please read my answer in full and carefully.

Such a broad answer is simply wrong. Matroska can handle interlaced files just fine. In general playback works with current Matroska format, no matter if content is progressive, interlaced, telcined or a mix thereof. Millions of people watching files on a myriad of different devices and players are a testimony to that.

However, there are use cases for which the information stored in Matroska's file/track headers is not enough. One such use case is a special video renderer like Madshi's that has to work within the confines of its framework (DiretctShow): it cannot parse arbitrary amounts of the source file in order to determine the display FPS, it has to know it before receiving the very first frame. However, such renderers are not a prerequisite to watching Matroska files in general, therefore we do not have a general problem.

Madshi's specific circumstances and needs are the ones we're trying to address with a new header element. Note that this has nothing to do with the video content's type; it's the same issue for interlaced, progressive, telecined, mixed.

Now to the problem of your concrete example. This is something I have not looked into yet. It may be connected to the problems mentioned above, but it may also be a) a bug in mkvmerge or b) wrong usage on your end.

[Mosu]

Some of my TS files seem to be breaking when running them through MKV Merge. The original TS files play fine but the resulting MKVs aren't deinterlaced properly by MadVR and EVR has issues too (deinterlacing seems to work but the FPS says 46-48 instead of 50, the playback is jerky and the graph is dodgy also).

Original TS - Sample Clip
Dodgy MKV - Sample Clip

Original TS - EVR Stats
Dodgy MKV - EVR Stats

Any ideas?

I've downloaded this TS, remuxed to Matroska with mkvmerge without specifying any additional commend line arguments, and watched it with VLC. It plays back perfectly, with or without deinterlacing turned on. No dodgyness, no jumpding around. A/V sync cannot be easily judged from such a football game, though, so I cannot vouch for that 100%.

This was on Linux with VLC. So both mkvmerge and the file are fine, and your problems are again due to the special requirements certain video renderers impose.

Edit: current mkvmerge 5.8.0, remuxing simply with "mkvmerge -o out.mkv 'Broken 50i Clip.ts'", followed by "vlc out.mkv". Once again, there is no bug in mkvmerge. Those video renderers simply need information in order to work reliably that just isn't there in Matroska yet. However, that information is generally NOT required for playback as VLC proves.

Edit2: I also tried mplayer for playback (you know, the OSS project, not "wmplayer.exe"). It plays the file just as well.

[madshi]

Just for the record: madVR plays this file just fine, too, except that it disables deinterlacing because the framerate reported by the MKV splitter is 50p. This is not really a bug in madVR. It could be seen as a bug in the current MKV splitters which report incorrect FPS to madVR with this specific file. Or it could be seen as an MKV spec related problem because getting the right FPS information from this MKV file is rather difficult with the current MKV spec. In any case, it is not a bug in madVR. madVR is being told that the file is 50p. It's not an information madVR gets itself, it's reported by the upstream filters (splitter, decoder). So since madVR is being told that the file is 50p, why should it try to deinterlace it?

@nevcairiel, maybe you could add an option to parse/interpret the timecodes to get the FPS information for MKV files? I think you said you already had this implemented, but removed it again. So maybe an option would be useful?

[nevcairiel]

I try to stay away from options like this, too much confusion. I'll check my sample archives for files that may have issues with the probing, if i find any, and will see how/if that can be fixed so i don't have to rely on the DefaultDuration at all anymore.

[madshi]

@Mosu, maybe you can help out here? Is there an easy way to detect files where DefaultDuration might be different from FPS for video tracks? I suppose if the very first MKV block contains a single field, only, that would be one possible indicator? Anything else? Thanks!

[Mosu]

@madshi: not an easy one. I'm at work at the moment, don't have much time to talk, and I'm out of town tonight. Please expect a more comprehensive answer tomorrow.

[DragonQ]

I've downloaded this TS, remuxed to Matroska with mkvmerge without specifying any additional commend line arguments, and watched it with VLC. It plays back perfectly, with or without deinterlacing turned on. No dodgyness, no jumpding around. A/V sync cannot be easily judged from such a football game, though, so I cannot vouch for that 100%.

This was on Linux with VLC. So both mkvmerge and the file are fine, and your problems are again due to the special requirements certain video renderers impose.

Edit: current mkvmerge 5.8.0, remuxing simply with "mkvmerge -o out.mkv 'Broken 50i Clip.ts'", followed by "vlc out.mkv". Once again, there is no bug in mkvmerge. Those video renderers simply need information in order to work reliably that just isn't there in Matroska yet. However, that information is generally NOT required for playback as VLC proves.

Edit2: I also tried mplayer for playback (you know, the OSS project, not "wmplayer.exe"). It plays the file just as well.
If it's a renderer issue then are you saying even EVR has this problem then? Because when I do the equivalent thing ("C:\Users\Adam\Documents\Audio & Video\MKV Tools\mkvmerge" -o out.mkv "Broken 50i Clip.ts"), the MKV plays back incorrectly in MPC-HC using LAV Filters and EVR (see here (http://www.aotplaza.com/Files/HTPC/Screengrabs/Dodgy%2050i%20MKV%20Merge/Broken%20MKV%202.png)).

If I switch to MPC-HC Matroska Splitter, I get the same problem, so I guess that rules out a problem unique to LAV Splitter. I again get the same issue if I use MPC-HC's H.264 decoder and MPC-HC's AC3 decoder.

If I try to play the MKV in VLC, I get a green screen when using GPU acceleration. If I disable that, it uses ~35% CPU and doesn't play smoothly at all. Worse than MPC-HC, I'd say.

This might sound like a stupid question but are you sure it's playing back smoothly? Cos the sample I posted looks pretty good initially (in MPC-HC anyway) but in panning shots you can see it's not smooth (and the EVR graph proves this).

One thing I wanna try is playing the file in MediaPortal - that'd still use EVR and LAV decoding but the player and splitter would be different.