Need your help on some very basic video questions

[Booklet]

Hi,

I am completely lost. I am hoping someone can clear out my confusion on video/sound encoding/ripping/demuxing, cause I've been reading a few stuff, but I never seem to get the full picture. I don't want to sound demanding, but if you do take the time to read through this, please elaborate as much as possible, cause I want to understand everything, from the very basics to the most advanced. Thanks!

OK, so a video file is (at the beggining) a stream of still pictures, which alternate at a fixed or non-fixed rate of about 30 frames per second or more. However, since this file would be huge (taking account every pixel of every frame), we compress the individual frames with image compression algorithms, and the succession of the frames with video compression algorithms . However, since this makes things a little more complex, I wanted to ask you: Does it make sense to talk about individual frames AFTER the compression, or are they, now, an integral part of our video file, and therefore cannot be edited or manipulated individually?

A video file usually contains a video stream and an audio stream (and the occasional subtitles stream). Are these encoded/compressed separately?

OK, so for a video stream (I suppose the same things apply for the audio stream as well), we can use any of the seemingly infinite sum of encoders available. To play the file back, we need the appropriate decoder installed. Now, why would anybody want to use different encoders for different video streams? Can I see a list of available video encoders sorted by their Quality/Size ratio?

As if the encoder was not enough to worry about, we must also make sure that the file extension (aka container) will be playable on our machine! Why in hell are there so many different formats (or containers, or file extensions) for example, avi, mkv, mp4, flv, VIDEO_TS (with its .VOB files), etc., etc.?? Does the encoder enforce a certain container (format, file extension), during encoding?

[EDIT] I forgot to add this one question: Is it possible to generate (when encoding, for example) different file outputs by using different programs but using *the same* configuration (encoding options, etc.), and the same input file? Say, for example that I wanted to encode a movie with a certain codec, for example h.264. If I used two different programs with the same configuration would it be possible to get 2 different output files? Because, since the encoders are standarised, then the whole procedure is determined at the start, therefore I would expect that this should not be the case. I'm still asking this, however, because there have been cases where I've heard that a certain program can rip "better" than another (for example, with no/less errors, or giving a better quality, even though using the same codec). Is that possible?

I *think* OiNK had a policy (or a recommendation) on what program to use to rip your uploads, but don't take my word for it. I only mention this as an example (I wasn't even part of the community).[/EDIT]

That's it for now. I may add more questions as I remember them. Thanks for any help!

[jman98]

This is a really good post for only a 3rd post.

Yes, you can talk about frames after compression. Frame accurate editors do exist.

Yes, video and audio are encoded separately.

Sorry, there's no handy Quality/Size encoder list. H.264/X.264 generally gives the best quality for the smallest size (H.264 is valid for BluRay) but it requires the most processing power. Someone might use Divx/Xvid for example because even at HD resolutions there is not much demand for processing power during playback but you'll need a larger size with Divx/Xvid to approach the same quality as H.264/X.264. VC-1 is close to H.264/X.264 in terms of small file size and quality. MPEG-2 can provide excellent quality but requires very large file sizes to do so. H.264/X.264 are basically state of the art right now for quality.

AVI is an ancient container that Microsoft invented. Being an ancient container, it has limitations that some of the newer containers don't have. VOB was created by the group that came up DVD as MPEG-2 technology was the best option at the time for a home video format. FLV is an Adobe thing. MP4 was an attempt to provide a higher quality video format than MPEG-2 but the container specification left something to be desired. MKV was an attempt to provide a free container specification that could be implemented by anyone without royalty payments and without violating patents. Ogg has the same goals as MKV but I think that basically MKV tools reached maturity a lot quicker than Ogg tools did, hence MKV becoming ubiquitous and Ogg getting left behind. Encoders may enforce the use of specific containers, but that depends on the encoder.

Hopefully this helps some. Others may have things to add.

[edDV]

OK, so a video file is (at the beggining) a stream of still pictures, which alternate at a fixed or non-fixed rate of about 30 frames per second or more. However, since this file would be huge (taking account every pixel of every frame), we compress the individual frames with image compression algorithms, and the succession of the frames with video compression algorithms . However, since this makes things a little more complex, I wanted to ask you: Does it make sense to talk about individual frames AFTER the compression, or are they, now, an integral part of our video file, and therefore cannot be edited or manipulated individually?

Typical codec encoders work with dynamic compression within the frame (intraframe) and over a group of frames (interframe GOP) based on detected motion. For NTSC the GOP is typically 15 frames for high quality video but longer for highly compressed formats. Each GOP has an initial I frame containing full resolution followed by P and B frames that contain change information only. Frame rate is usually constant (e.g. 29.97 or 59.94 fps) but bit rate will vary with detected motion. This is called variable bit rate or VBR.

For decode editing, you can cut on I frames (1/2 sec accuracy for a 15 frame GOP) or decode the GOP to 15 full frames to edit to the individual frame.

OK, so for a video stream (I suppose the same things apply for the audio stream as well), we can use any of the seemingly infinite sum of encoders available. To play the file back, we need the appropriate decoder installed. Now, why would anybody want to use different encoders for different video streams? Can I see a list of available video encoders sorted by their Quality/Size ratio?

Codecs vary by purpose and by legacy. There are new codecs and older standardized codecs with hardware support.

[minerva.thegift]

I only dabble in the world of frames, so I'll let the previous post answer your questions (about I frames, etc.)

A video file usually contains a video stream and an audio stream (and the occasional subtitles stream). Are these encoded/compressed separately?

This one I can answer with certainty that yes, video and audio streams are encoded separately. For example, using the .mkv container (which I use most often) the program called mkvmerge GUI (part of the mkvtoolnix package) can mux/demux (group together or separate apart) all the audio, video, subtitle, and chapter pieces from within a .mkv file. I can, for example, encode a video stream with one program, two audio streams (say a main language track and a commentary track) with another program, and convert the subtitles with a third program and then use mkvmerge to put them all together into one .mkv file.

Can I see a list of available video encoders sorted by their Quality/Size ratio?

Sadly I have to agree with the other poster that it isn't quite that simple. Yes, the x.264/h.264 encoders are (in my opinion) the best out there right now but that is open to a great deal of discussion. You could probably find forum posts even here at videohelp that argue for or against various encoders.

Does the encoder enforce a certain container (format, file extension), during encoding?

Sort of - some containers can handle more variety than others. For example, the .avi container primarily handles the xvid/divx video codecs and .mp3 audio (as I recall, it's been a while since I used .avi much.) The .mkv container can handle just about every type of video I know of, from uncompressed Blu Ray video (VC-1 or similar) to x.264, you can put it in the .mkv container. The audio options are similarly varied - you can put the audio straight from a Blu Ray (AC-3) or you can encode it into .mp3, OggVorbis, or one of several other audio codecs. Each container has different options as to which formats it can store, and newer containers often try to add support for even more formats so the list is growing.

If I used two different programs with the same configuration would it be possible to get 2 different output files? Because, since the encoders are standarised, then the whole procedure is determined at the start, therefore I would expect that this should not be the case. I'm still asking this, however, because there have been cases where I've heard that a certain program can rip "better" than another (for example, with no/less errors, or giving a better quality, even though using the same codec). Is that possible?

Hmm, this one would be a bit tricky to prove. I say that because unless you're writing out your encoding scripts in a command line program, it's hard to tell for sure that two programs would use exactly the same parameters. For example, even within one program, say MeGUI, there are several 'profiles' that each throw in slightly different parameters. I don't know enough about the various options to know what each one does, but I do know that just because you have, say, a x.264 file at 1000kbps bitrate does not mean that you know all the encoding options that are being used.
That aside, I really don't know if when someone says another program is 'better' that that truly means it can outperform another program using the exact same settings. Perhaps 'better' means easier to use (fewer steps to set it up and get it going.) Perhaps 'better' means it includes, by default, more useful encoding options (the 'behind the scenes' ones) than another program does. Perhaps 'better' means it supports more input and output codecs. Who knows?


Well, there's my two cents on your questions. How's it coming along? Is it all starting to make at least some sense? Feel free to keep posting if you think of more questions.