Which pixel aspect ratio applies to Huffyuv?

[brassplyer]

Which of these applies to HuffYuv - Square pixels (1.0) or Standard NTSC (0.912)?

For some reason a search on "pixel aspect ratio of HuffYuv" brings up squat.



Thanks

[jagabo]

Whatever the pixel aspect ratio of your source is. Avi doesn't really support aspect ratio flags. Huffyuv doesn't either. You just tell the editor that opens the video what the correct AR is.

[brassplyer]

Whatever the pixel aspect ratio of your source is. Avi doesn't really support aspect ratio flags. Huffyuv doesn't either.

By the source you mean the file that got converted to Huff? In this case 4:3 DV avi.

These are the options under the Thalen DeShaker filter for Virtualdub so I gotta tell it something.

[brassplyer]

Avi doesn't really support aspect ratio flags. Huffyuv doesn't either.

In what cases does pixel aspect ratio apply?

[sanlyn]

hufffyuv is a compressor, not an encoder. That's like asking which pixel aspect ratio is used by ZIP. "Convert to huff?" Ever hear anyone say they "converted" a file to RAR?

Pixel aspect ratio refers to the video itself.

[brassplyer]

hufffyuv is a compressor, not an encoder. That's like asking which pixel aspect ratio is used by ZIP.

Hmm. MediaInfo id's the codec as HuffYuv or more precisely HFYU. I see it referred to as a lossless codec, ergo I was under the impression it's another codec like DV, MJPEG, etc.

"Convert to huff?"

Yes. Take a DV file and convert it to HuffYuv for purposes of tweaking since it's lossless and DV isn't. Why do you seem to see this as incorrect terminology?

[sanlyn]

Okay, if you want to get complicated. Huffyuv and Lagarith are compressions codecs. DV, MPEG, DivX, etc., are encoding/decoding codecs.

[brassplyer]

Okay, if you want to get complicated.

I don't want to get complicated I want to achieve understanding.

Huffyuv and Lagarith are compressions codecs. DV, MPEG, DivX, etc., are encoding/decoding codecs.

What's the difference?

[El Heggunte]

There is lossy compression and there is lossless compression. Transforming the word "encode" into a synonym for compression OR for language-related things is one of the wonders of "modern" tongues such as the "technical" English

Anyway, sanlyn has been drinking less than he should, me thinks

[_Al_]

-if you encode video into DV, you loose quality at that point - you decompress and compress into something else, that is lossy
-if you just decompress and use some algorithm (Huffyuv) that makes it just smaller than uncompressed video (something like zip, rar, 7z), at that point you still have original

[sanlyn]

Video encoding and data compression are not the same thing. Video encoding uses code to decribe the differences between images in cycles of time; the information that describes the differences from, say, the initial key frame in a group of frames up to the last frame in the group. The only complete image in a group of frames is the key frames; the other "frames" in the group consist only of informationm about elements that have changed since the preceding key frame.

Data compression doesn't record differences between elements over time. It includes 100% of the data, but uses short code or descriptions for all elements that are alike. For instance, if an image consists of nothing but thousands of white pixels, the compression table will maintain only a single code for "white" plus information about how much white exists and where it is. Or, if you have an image that is a 640x480 solid green square, that file will be several kb in size as an uncompressed RGB image, but when zip'd it will be less than 20 bytes in size because all of the data in that image can be described with very few bytes of code. "Lossy" data compression makes decisions about how much of the original data to maintain; the decision is based on how much squishing or quality loss is requested by the user. Thus a 95%-quality JPG image will be a much larger file that a low-precision 30% job.

A similar quality situation occurs with lossy video encoding. Higher bitrates keep more information about more details; lower bitrates discard more information that the encoder decides is unimportant -- for instance, lower compression keeps far less data about movement from frame to frame, or about "details" within blocks of pixels, or about fine chroma values in large areas of gradation such as a blue sky whose color varies from dark blue to lighter blue, or less information about dark shadow details. And so forth.

Ah, but brassplayer already knows all that. He's just testing us.

[jagabo]

Whatever the pixel aspect ratio of your source is. Avi doesn't really support aspect ratio flags. Huffyuv doesn't either.

By the source you mean the file that got converted to Huff? In this case 4:3 DV avi.

As long as you didn't resize the frame the video still has the pixel aspect ratio of 4:3 DV. Pick "Standard NTSC (0.912)".

In what cases does pixel aspect ratio apply?

All digital video has a pixel aspect ratio.

[NoBuddy]

So, using a NTSC DV 4:3 file in VirtualDub, applying some filters or not and saving it as HuffYuv 640x480 (for whatever reason) - what am I doing?
compressing, encoding, or just being happy

[brassplyer]

In what cases does pixel aspect ratio apply?

All digital video has a pixel aspect ratio.

Can you reconcile the above with

Avi doesn't really support aspect ratio flags. Huffyuv doesn't either.

[sanlyn]

A video's phsyical aspect ratio (it's "frame size") is not the sme thing as an encoded "flag" that tells a player how the file is to be displayed.

ANd I just told the world that you secretly knew what "encoding" was. I take it back.

[usually_quiet]

Video encoding and data compression are not the same thing. Video encoding uses code to decribe the differences between images in cycles of time; the information that describes the differences from, say, the initial key frame in a group of frames up to the last frame in the group. The only complete image in a group of frames is the key frames; the other "frames" in the group consist only of informationm about elements that have changed since the preceding key frame.

Data compression doesn't record differences between elements over time. It includes 100% of the data, but uses short code or descriptions for all elements that are alike. For instance, if an image consists of nothing but thousands of white pixels, the compression table will maintain only a single code for "white" plus information about how much white exists and where it is. Or, if you have an image that is a 640x480 solid green square, that file will be several kb in size as an uncompressed RGB image, but when zip'd it will be less than 20 bytes in size because all of the data in that image can be described with very few bytes of code. "Lossy" data compression makes decisions about how much of the original data to maintain; the decision is based on how much squishing or quality loss is requested by the user. Thus a 95%-quality JPG image will be a much larger file that a low-precision 30% job.

No. Technically speaking, a compressor means something that encodes data into a smaller size, and an encoder means something that converts data from one format to another. All compressors are encoders by definition since they are capable of converting data to a different format from the original. Some compressors perform lossless compression but others perform lossy compression. Some forms of video compression only use intra-frame compression where each frame is compressed, but complete unto itself and others can use interframe compression, where frames require data from other frames to be decoded.

[jagabo]

In what cases does pixel aspect ratio apply?

All digital video has a pixel aspect ratio.

Can you reconcile the above with

Avi doesn't really support aspect ratio flags. Huffyuv doesn't either.

The aspect ratio isn't indicated by the container or the codec. I have a jar full of peanut butter. The jar doesn't have a label indicating what's inside. It's still peanut butter.

[Cornucopia]

sanlyn, you've gone off the deep end!
To most computer programmers & electrical engineers who deal with video & audio, compression/decompression & encoding/decoding are one and the same.
There's raw, uncompressed video images going into your camera (or being rendered by your softwares). From there it somehow has to be encoded (aka put into a standard form). Then, for playback, it has to be decoded. (Rarely does this refer to the encoding found in hidden/secure messages - for that, programmers use the term "encrypt"). Encoding doesn't necessarily have anything to do with Delta-frames, or any form of Inter-frame compression. I've been involved with digital video since the beginning (early '80s), when they didn't have that complicated a way of expressing the differences (via motion vectors, etc), and even then, they were calling it "encoding".

This "encoded" video can be left uncompressed, or it can be stored losslessly, or lossily compressed. And then of course decompressed upon playback.
Since it's unusual for "encoded" videos to remain uncompressed (because of their shear size), the idea of a video being both encoded AND compressed is standard. All the ones previously mentioned: Huff, Lags, DV, MPEG, MJPEG, DivX,... they are ALL encoders (and decoders) and they are ALSO ALL compressors (and decompressors).

@brassplyer,
ALL DIGITAL VIDEO has PAR (pixel), DAR (display) & SAR (storage - based on horizontal & veritcal dimension resolution), whether the codec & container system being utilized can correctly express them or not. That is basic to digital video.
Unfortunately, there are some codecs that don't natively mark ARs within their encoded bitstream, also some containers that don't natively mark ARs within the container's header-stream (aka metadata). AVI is notorious for being one of those containers without that ability. And as has already been mentioned, HuffYUV doesn't include that in its elementary video stream either, so you'd have a double-whammy using HuffYUV in an AVI.

All is not lost: Since you still (always) know the Horiz & Vertical dimensions, and you know the Golden Formula of video ( DAR = PAR * SAR), you can figure out the rest if you ASSUME one or the other elements. Assuming you're using Square Pixels? - then 1920x1080 is 16:9 DAR. Assuming you have a 4:3 DAR? - then your 720x480 video uses 8:9 PAR (or 10:11 if you use 601 scaling).
That's how you reconcile the two.

Scott

[sanlyn]

All compressors are encoders by definition since they are capable of converting data to a different format from the original.

Whatever you say. By that definition , if I zip a DivX file I can say that my video is encoded with WinZIP. But I don't think I would want to say that. What I was tryin to explain was the difference between lossy video encoding/compression (MPEG), lossy graphics compression (JPG), and lossless video compression (huffyuv). I do get the significance that video encoding is a change in format, but a change by reason of replacing the original data with a symbolic description of it.

[sanlyn]

sanlyn, you've gone off the deep end!
To most computer programmers & electrical engineers who deal with video & audio, compression/decompression & encoding/decoding are one and the same

No problem. Huffyuv is a video encoder. So is WinZIP.

[usually_quiet]

All compressors are encoders by definition since they are capable of converting data to a different format from the original.

Whatever you say. By that definition , if I zip a DivX file I can say that my video is encoded with WinZIP. But I don't think I would want to say that. What I was tryin to explain was the difference between lossy video encoding/compression (MPEG), lossy graphics compression (JPG), and lossless video compression (huffyuv). I do get the significance that video encoding is a change in format, but a change by reason of replacing the original data with a symbolic description of it.

Ever hear of MJPEG, a video format using intraframe compression where each frame of the video is a JPEG-compressed image? There is some overlap between video and graphics compression.

[usually_quiet]

sanlyn, you've gone off the deep end!
To most computer programmers & electrical engineers who deal with video & audio, compression/decompression & encoding/decoding are one and the same

No problem. Huffyuv is a video encoder. So is WinZIP.

No WinZip is a generic file compressor. It could be applied to a video file, but the reduction in file size would be minimal, or nothing.

[poisondeathray]

No WinZip is a generic file compressor. It could be applied to a video file, but the reduction in file size would be minimal, or nothing.

Minimally compressed or uncompressed video will usually reduce 40-55% . Even something like DV will compress ~8-10% with zip . Heavily compressed video sometimes actually gets slightly larger with zip compression




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 .

[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.)

[poisondeathray]

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 . In contrast, generic file compression utilties like winrar/zip etc.. will give you the original compression when unarchived (in fact it will be the identical file)

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 . ie. The decoded (uncompressed) image of the original DivX file will be identical to the the uncompressed image of a losslessly encoded file from that same DivX file

[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.

[sanlyn]

sanlyn, you've gone off the deep end!
To most computer programmers & electrical engineers who deal with video & audio, compression/decompression & encoding/decoding are one and the same

No problem. Huffyuv is a video encoder. So is WinZIP.

No WinZip is a generic file compressor. It could be applied to a video file, but the reduction in file size would be minimal, or nothing.

I see. So the terms "compression" and "encoding" do mean the "same thing" sometimes, but they don't mean the same thing at other times, depending on....depending on what? If compression and encoding are the same thing, why can't I call ZIP a video encoder if I use it on a video file?

OK, I really do understand what you mean. But in order to prevent confusion in my own use of the terms here in a video forum, I'll refer to stuff like huffyuv and RAR as compressors, and to MPEG and DivX and h264 as encoders. Otherwise I'll start sounding like the O.P. and will search the internet for days or weeks to find out how to change the pixel aspect ratio of a ZIP-encoded video file.

[poisondeathray]

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 .

[usually_quiet]

OK, I really do understand what you mean. But in order to prevent confusion in my own use of the terms here in a video forum, I'll refer to stuff like huffyuv and RAR as compressors, and to MPEG and DivX and h264 as encoders. Otherwise I'll start sounding like the O.P. and will search the internet for days or weeks to find out how to change the pixel aspect ratio of a ZIP-encoded video file.

I see no evidence of understanding on your part. All I see is you using your usual strategy for getting out of arguments, trying to give the impression that you are agreeing with someone and then saying something to the effect of "but I don't need to change what I say, since it is correct."

Video compressors/encoders only work correctly with uncompressed video as input, and usually not all forms of uncompressed video. ZIP is not a video encoder or a video compressor because it doesn't work only with video, even if it will sometimes compress video files.

Your idea that only software that performs encoding using lossless compression should be called a compressor is incorrect from a technical standpoint, which means you are perpetuating confusion, both for yourself and for anyone else you share incorrect ideas with.

[sanlyn]

I get the idea that the O.P. thinks huffyuv and ZIP and MPEG2 "compress" a video in the same way, the difference being a matter of final output size. Obviously they don't work that way. It's a common misunderstanding that you see here all the time. 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 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.