Which pixel aspect ratio applies to Huffyuv?

[usually_quiet]

I see a "video encoder" as a special case or subset of the larger generic term "compression" ; unlike winzip/rar/7z etc, you cannot get the original compression back if you started with a lossy compression scheme, whether or not if you use lossless or lossy to encode the original file with afterwards. Because video encoding requires decoding (to uncompressed), before video encoding .

That is a poor argument. If a lossless form video encoding is used, decompressing it gives you back the original. If a lossy form of data compression, like JPEG, is used you won't get the original back when it is decompressed, merely a reasonable facsimile of it. (I know there is lossless JPEG too, but that is not the kind I mean.)

This is wrong.

Lossless encoding of the source video gives you uncompressed when it's decompressed, not the original compression .

e.g. If you start with the DivX file (lossy), encode it with Huffyuv (it's actually decoded to uncompressed, then encoded to Huffyuv), then you can never get the original DivX compression back. If you try to encode it with DivX again, it will be worse than the original. The "losslessless" nature of lossess video compression refers to comparing to the uncompressed video state .

Thanks, the example helped.

[Edit] After further thought, it is still a poor argument. In both cases, you are getting back what the compressor actually started with. If you used winzip/rar/7z on a DivX file, yes, you would get the original DivX file back. ...but once decompressed, it won't be the same as the original source video used to create the DivX file, and compressing it with DivX again will make it worse.

And yes, after decoding the file created by Huffyuv, you would get a an exact copy of the decoded, uncompressed video from the DivX file, but that is what HuffYUV really started with, not a DivX file. I don't know of any video encoder that can encode a compressed video source directly.

The real difference is that video encoders/compressors require an uncompressed video stream as input, but generic file compressors don't care what kind of file is used for input.

How is this a "poor arugment?" You're reiterating what I said .

The key difference is that last line, that's the "argument" I'm making. That' s what distinguishes a video encoder.

I see a "video encoder" as a special case or subset of the larger generic term "compression" ; unlike winzip/rar/7z etc, you cannot get the original compression back if you started with a lossy compression scheme, whether or not if you use lossless or lossy to encode the original file with afterwards. Because video encoding requires decoding (to uncompressed), before video encoding .

I'll try to explain again why comparing WinZip to a lossless video encoder as you did makes no sense.

If I compress an MPEG-2 video file with WinZip, and then unzip, I'll get the same MPEG-2 video file. ...but WinZip can't give me back the original source used to create MPEG-2 video file, because it never had that file in the first place.

A video encoder is designed to work with uncompressed video input and nothing else. Once decoded, losslessly encoded video will give you back the an exact replica of the uncompressed video input the encoder received. But like WinZip, it can't give back what it never had.

MPEG-2 video has to be decompressed first before it can be used as input for a video encoder, but the decompressed video sent to the encoder will not be the same as the original from which the MPEG-2 file was created. If a lossless video encoder never received the source file used to create the MPEG-2 video file, how can it give you back that file? ...and it can't give you back the MPEG-2 video file, because it won't accept MPEG-2 video as input, so it never had that either.

[poisondeathray]

I'll try to explain again why comparing WinZip to a lossless video encoder as you did makes no sense.

You don't have to explain to me, remember I was the one that explained it to you LOL

You're just repeating everything I said.

I'm making the distinction between a "video encoder," which is a special case of applying compression vs. winzip and other generic compression utilities . That is my "argument" which you said is "poor" but you're actually supporting

Because video encoding requires decoding (to uncompressed), before video encoding .

That's why winzip isn't a video encoder

If I compress an MPEG-2 video file with WinZip, and then unzip, I'll get the same MPEG-2 video file. ...but WinZip can't give me back the original source used to create MPEG-2 video file, because it never had that file in the first place.

Exactly. You seem to understand that now.... The video encoder requires decoding of the input source, before encoding

You seem to be agreeing with me, but arguing for the sake of arguing .

[sanlyn]

I'll try to explain again why comparing WinZip to a lossless video encoder as you did makes no sense.

Of course it doesn't. And it isn't a "video encoder". I was being facetious (Who? Moi?) about semantics.

But you'd be amazed how many posts seem to imply that the writer doesn't know the difference.

[usually_quiet]

I'll try to explain again why comparing WinZip to a lossless video encoder as you did makes no sense.

You don't have to explain to me, remember I was the one that explained it to you LOL

You're just repeating everything I said.

I'm making the distinction between a "video encoder," which is a special case of applying compression vs. winzip and other generic compression utilities . That is my "argument" which you said is "poor" but you're actually supporting

Because video encoding requires decoding (to uncompressed), before video encoding .

That's why winzip isn't a video encoder

If I compress an MPEG-2 video file with WinZip, and then unzip, I'll get the same MPEG-2 video file. ...but WinZip can't give me back the original source used to create MPEG-2 video file, because it never had that file in the first place.

Exactly. You seem to understand that now.... The video encoder requires decoding of the input source, before encoding

You seem to be agreeing with me, but arguing for the sake of arguing .

That is because it seemed to me you were saying something else entirely than what you said in this post.

If you had just said something like "Although both Winzip and a lossless video encoder use forms of lossless compression, Winzip is different from a lossless video encoder because, because video encoders (lossless or lossy) only accept and work correctly with uncompressed video input, but generic file compressors accept any kind of file (compressed or not)", that would have been much clearer. Your examples just muddied the waters for me. Clearly, I always understood the difference myself.

[usually_quiet]

I missed this post somehow.

I get that idea because the O.P. apparently thinks that fully decoded and lossless AVI has a display aspect ratio flag of some kind (which the O.P. seems to be confusing with the "pixel aspect ratio"). So perhaps someone can clearly explain to the O.P. why video "compressors" (like MPEG2) can have a pixel aspect ratio that can differ from the display aspect ratio, while losslessly compressed huffyuv does not.

I think jagabo and Cornucopia already did explain it.

I also get the idea that the O.P. doesn't get that an MPEG2 video of 200,000 frames doesn't contain 100% of the original data for all 200,000 complete images, while a huffyuv losslessly compressed video of the same video does indeed contain data for 200,000 fully decoded, full-size images.

The difference between lossless and lossy video encoding has been discussed at length in the course of this thread. At this point, I'm pretty sure he does understand the difference .

[Cornucopia]

Aww, come on! Wouldn't you like me to explain it all in detail again?

Scott

[usually_quiet]

Aww, come on! Wouldn't you like me to explain it all in detail again?

Scott

I admit I enjoy reading your posts, but I do not think your previous explanation could be improved upon.

[brassplyer]

I get that idea because the O.P. apparently thinks that fully decoded and lossless AVI has a display aspect ratio flag of some kind (which the O.P. seems to be confusing with the "pixel aspect ratio").

?

I was referring to the pixel aspect ratio. I didn't originally mention flags of any sort. Since the plugin asks the user to choose a pixel aspect ratio I wanted to determine which is the correct one.

It's not clear to me why if AVI doesn't have pixel aspect ratio flags, they want you to specify one. I don't even know if the regular (non mpeg) version of Virtualdub works with anything *but* AVI.

[jagabo]

It's not clear to me why if AVI doesn't have pixel aspect ratio flags, they want you to specify one.

Even if there is no flag the pixels still have an aspect ratio. Since the deshaker plugins involves translations, rotations, and zooms it needs to know the PAR to work accurately.

When the AVI spec was developed nobody considered the need for non-square pixels. The ODML extensions add AR flags but nobody uses them.