Demuxing MKV to MPF: Quality Loss?

[3NC0D3_Y0_A$$]

If I demux an x264 encoded video file in the mkv container, to an h.264 file in the mp4 container, is there a loss in visual quality?

Will the video bitrate stay the same?

I know x264 is contantly being updated with new intelligent video compression algorithms, yet h.264 as far as i know isnt being updated regularly.

so if i demux an x264 mkv to an h.264 mp4, surely I will see video artifacts that were not present in the x264 mkv, or the file size will increase to maintain such quality without artifacts?

[talen9]

I think you have to go back to your books ... especially about the "difference" between x264 and h264 :rolleyes:

Read here (http://forum.doom9.org/showthread.php?t=96059), for example ;)

[ajp_anton]

(De/re)muxing = moving video/audio tracks to/from containers without actually touching them = no quality loss.

h264 is a "language" for video compression. "x264" is the name of one of the programs that compress video into h264.

[Sharktooth]

h264 (or avc or MPEG-4 part 10... they're all the same) is a video compression standard. x264 is an opensource implementation of that standard.

[3NC0D3_Y0_A$$]

Ok thanks all, you've made it much clearer. cheers.

[3NC0D3_Y0_A$$]

so AVC has unique concepts like weighted prediction.

So if somebody wanted to add a new 'concept' for encoding, i.e ability to code straight(ish) edges as objects (pulling stuff out of my ass), this would require a completly new video compression 'language' or could you implement it into the current AVC language?

[Ranguvar]

It depends on whether the output stream would look the same. In other words, something like a more efficient way of estimating motion should not change the output stream, since it's all done by the encoder, the encoder is just making different decisions.

Something like a new way of ordering B-frames, though, (yes, I'm pulling things out of my a**) would not work since you need to maintain compliancy with the H.264 standard, you don't want to have to use a hacked decoder to make it work.

[cogman]

so AVC has unique concepts like weighted prediction.

So if somebody wanted to add a new 'concept' for encoding, i.e ability to code straight(ish) edges as objects (pulling stuff out of my ass), this would require a completly new video compression 'language' or could you implement it into the current AVC language?

As long as the output fits into the MPEG-4 Part 10 standard, the encoder can do whatever they want to get there. Differences creep in the methods used to get that standard output. Those differences can be huge (just look up a comparison of AMD's AVC encoder vs x264)

It is kind of like saying the same thing in a different way. I can say "Im going to the store" or "I'm traveling to Walmart" and the message would still be considered English and relatively the same. But if I said "Voy al Walmart" then the language has changed (IE different codec).

So, think of H264 as the language and x264 as a eloquent speaker of it. AMD's encoder would be a nearly incoherent speaker of H264.

BTW, a container can be considered the form the lanugage takes. For example, you can find english in books, over the phone, on TV, or through Braille. It is all still English just the way it is transported is different.

[Blue_MiSfit]

AMD's encoder would be a nearly incoherent speaker of H264.


Albeit a _very_ speedy one!

~MiSfit

[DeathTheSheep]

So if somebody wanted to add a new 'concept' for encoding, i.e ability to code straight(ish) edges as objects (pulling stuff out of my ass)...
Very nice. Though "talking about using the 'object' system that MPEG-4 ASP offers (which nobody else supports)" [DS] is a different story. ;)