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)…
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.
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)
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.
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
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”… 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.
I am fully aware of its history , still remember the very first versions
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 ?
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
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…
Nothing is lost by adding .mkv to the output containers. Mkv is extremely versatile, enjoys great acceptance across the world, is the de facto choice for muxing in .srt subs, for your media server, generates smaller output (less overhead) then .m2ts files, and is, in the non-mac video editing world considered quite a fave among the intermediate containers.
I almost pulled the trigger on this program like 3 times until I remembered I can’t use it for remastering shows like Battlestar Galactica from my Blu-Rays, because I lose DTS HD Master Audio 5.1.
Topaz should be making MKV support a priority, because compatibility on Output formats is more important than anything else for majority of retail users. Otherwise I can wait, especially since the program has to be bought yearly for every “major” improvement with no clear end in sight, target or roadmap.
I don’t see where is your problem with what you tell. Yes actually, audiopassthrough is not working, but in no way, the actual version of the software forbidd you to do what you want, unless you just want a one button software to remaster everything and do everything, what you tell is perfectly possible.
You can remaster your Bluray and still keeping your DTS HD track, but it needs a bit more effort from you. Extracting the audio track from the source, remixing it in an Mkv using the processed video, checking that everything is in Sync etc. if not you’ll have to demux the DTS track to separate Audio track, and redo yourself a 5.1 encoding (this is the worst case scenari because i don’t know actually any video editor available for people “like us” which can handle DTS HD as it is, but converting it to an AAC or Wav 5.1 or AIF is perfectly possible and re encoding it in DTS after.)
You really shouldn’t be dragging audio across your video editing process at all. VEAI is not a Blu-Ray authoring tool, but essentially just a fancy video filter (which happens to have a GUI). Demux your video stream, let VEAI do its thang, and recombine output with audio track remuxed back in.
While we’re on the subject, when you’re remuxing anyway, good moment to get rid of all those ‘wasted’ DTS-MA extra tracks, like French, German, etc, that are each like 7G each (for 24-bit audio). So, your final .mkv will only contain the one DTS-MA track of your choice.
I recommend mkvtoolnix-gui (freeware) for your easy remuxing jobs.
N.B. Converting DTS-MA can be tricky. Another free tool, like eac3to, can convert DTS-MA to Linear PCM (for lossless conversion), say, in WAV form, but why bother? Also, I do not know of a tool that can convert LPCM to DTS-MA – at least not without no doubt an expensive Dolby Digital license required. But again, why bother? You already have the original DTS-MA track to begin with.