MKV container

I know it’s not a big deal but I would like to have MKV as the container. It’s super convenient, and it also has the ability to copy audio from the original video to the upscaled video without re-encoding the audio.

I second that, MKV is the most powerful container nowadays and its free and available in ffmpeg, so it should not be too much effort to include…

Addition, since it was mentioned some times: Many ffmepg/Container/codec options will be made available in the future (via JSON Files was the info from Topaz a few days ago)…

1 Like

The issue of Mkv is that it’s not handle by all video editor out there, and i don’t know for the others here, but most of the time, i edit in my video editor the videos upscalled… that would mean i’ll / we’ll have to encode from Mkv to Mp4. Best would be to maybe have it as an “option” as a save format.

Avidemux will remux MKV to MP4 without re-encoding.

then its remuxing, not transcoding.

1 Like

no one said. “abandon all others, make MKV exclusive…”

its about adding it as an option for those who can make use of it (which - otuside the realm of commercial video editors - are A LOT of usecases)

1 Like

They almost certainly do. Any modern video editor worth its salt will handle mkv containers. I would hazard a guess based on my own experience that outside of mp4, it is the most popular container.

“almost”… (experimental, and it’s like that since 2 or 3 years).

Just remux with Xmedia Recode. Takes seconds and doesn’t waste developer effort on VEAI.

the benefit of mkv would be the support of any thinkable streamtype and number of streams, as well as much better handling of odd framerates… This would add to many other problems at the moment (audio, sync, remoux, copy stream, etc…)…
Implementation shouldn´t be to hard - ffmpeg sits under the hood, if one remuxes on stream into another, its merely changing ONE argument - so it can´t be that hard to implement in VEAI :slight_smile:

No one said it was hard, but it’s not what is preferable to have VEAI devs working on. Unless you’re happy with the current state of the upscaling capabilities. I for one am not, and hope they focus ONLY on that until it actually works well.

I get your point - but it would be naive to think that Topaz would not adress any issue or feature other than the upscaling part (models, inference engine, etc…) and leave evrything as it is…

I too think that there is a lot to improve in the models. BUT: It always will be. There is no point of “now its done”, it will always improve…

The whole point of this forum section is to gather requests and give an overview of what people think is important. It will eventually result in a list of “todos”, including many small changes done along the way of the big masterplan: “improve the upscaling”…

Since a lot of issues (lost tracks when processing, sync problems, no stream copy, boekn video-files with crashes) etc… are related to the output container - including MKV could solve a lot.

If you have ever used ffmpeg on a command line, you know that changing the output container is only ONE argument changed in the commandline - hardly anything that is “keeping anyone from doing something more challenging”…

Arguying that a proposal like that should not be considered, because it would consum too much valuable developer time would instantly render the whole section here useless, being replaced by only one request: “Make upscaling better”… :slight_smile: Every other request here is more difficult to implement…

Don´t get me wrong, I am not the advocate for MKV. I personally could care less if its implemented or not, I know my way around issues. And I am fully with you that the main usecase of VEAI should be the focus for the main part instead of adding completely new features all the time and end up with a bundle of half.baked functions in one package.

I just want to point out what the benefits would be and how much effort it would be to implement it

You have to look at it in the context of the track record the product has so far. Even the simplest of “fixes” end up rolling on through version after version, supposedly fixed, then not fixed, then fixed, then not fixed, and most end up staying on the “not fixed” pile. The more “features” you add, the more “not fixed” things you end up with. Oh well, it looks like the ship has sailed. I’d suggest holding onto every version that comes out from this point.

:slight_smile:
I am fully aware of its history , still remember the very first versions :slight_smile:

I don´t disagree… some issues are still not fixed…

So do we treat missing MKV support as issue not being fixed by now or a new feature ? :slight_smile:
Anyway… As I said above - if we follow tht apath of argumentation → the whole “feature request” section would be useless and could be replaced by “simply fix everything up to this point and improve models”…

Let´s go back to topic - this thread is about MKV support and gathering votes for its implementation. Good points were made about the pros and cons.

I mean, it’s definitely a feature request. That point isn’t really debatable because it’s not in the software at all.

I for one LOVE the idea of “simply fix everything up to this point and improve models”. That would be like Christmas morning.

that was actually a joke :slight_smile:
Of course, its a feature in the literal meaning / sense of the word - but given the very little work it would need to implement… I still see no problem here…

I think we said everything there is to say up to this point…