ffv1 - lossless codec?

[HLW]

Hi!

I have read several places that the ffv1 codec is lossless. But as far as I can see, the codec has some form of quantization, and therefore by defenition can't be lossless. Have also done some tests with SSIM and PSNR, and these tests show that the codec is visually very good, but not lossless. Any opinions on this?

If ffv1 isn't truly lossless, which is the the best lossless codec then?

HLW

[MfA]

If the results arent lossless then you either have found a bug or a non reversible colorspace transform is being applied somewhere along the line.

The quantization is used when determining the context for entropy coding, it doesnt quantize the to be coded prediction error.

[HLW]

Thanks for answer!
It may be possible that there has been some kind of unwanted colorspace conversion. I'll have a check on that!

I'm not shure if I got what you meant by "The quantization is used when determining the context for entropy coding", can you explain that in other words? Doesn't all kind og quantizing lead to some kind of loss?

[duartix]

What (I guess) MfA means, is that somewhere there is a quantization process that looses quality, but the codec (and this is what makes it lossless) also keeps the error diference, so you can rebuild the original data.

[MfA]

Not exactly, it quantizes the already coded differences for pixels in a certain neighbourhood to determine the context for the present pixel ... it quantizes them because you need a small number of contexts, but that actual entropy coding is always lossless regardless of the context.

I said as much before though, if you want to know what it means then read up on context selection and entropy coding.

[Atamido]

It does however only work in the YV12 color space, so if you have a source in a different color space, you will be losing data.

[MfA]

Dunno about ffvfw, but ffmpeg supports RGB coding now (well it still codes in another colorspace, but the colorspace transform is reversible).

[HLW]

Pamel: It seems to me that it is possible to choose other color sampling as well in ffv1, e.g. 444p and 422p, even if I haven't tried them yet. By the way, does the "p" mean progressive?

[HLW]

Now I've dove quit a lot of testing on the ffv1 (ffdshow, 18. april build), and I can't find that it is completely lossless. My source material are in yv12, so there should be no mysterious color space conversions. I've tested with both SSIM and PSNR, and I get SSIM around 98-99 and PSNR over 50 dB. Very good vaules, but not lossless. I think there must be a bug somewhere! Or has anyone done some truly lossless encoding with this codec?

[virus]

Originally posted by HLW
Or has anyone done some truly lossless encoding with this codec?
yep. I've just managed to get lossless copies using both HuffYUV and FFV1. But be sure to disable all output colorspaces except YV12 in the ffdshow Output dialog. Without this step I got finite PSNR (which should be always the same for a given clip, regardless of the codec used: this means there's some conversion during the output). I'm using VDub and CompareYV12 to do the task.

@MfA:
do you know what reversible RGB2YUV transform ffmpeg uses?

hope this helps :)
virus

[HLW]

Hi again!

The ffdshow output dialog box can't be changed in ffv1 mode. You mean under "configure" and "encoder"?

[virus]

Originally posted by HLW
The ffdshow output dialog box can't be changed in ffv1 mode. You mean under "configure" and "encoder"?
No. Under ffdshow general configuration. From within VDub, you can try with configure -> decoder -> output. I don't know if this works though, since these values are only used locally and probably not for playback using DirectShow. I've set the general properties for playback using the Configuration shortcut on the shell, then Output. That worked for me.
Also, be sure to disable any postprocessing and use VDub's "Fast Recompress" mode for encoding.

[Atamido]

Using the Dec 05, 2004 build, if I select the encode colorspace to be RGB32, the decoded output is random purple and green static. It also outputs automatically to YV12. If I select RGB32 as the only output option in FFDshow, then it crashes on playback. YV12 seems to work fine.

I have a YV12 FFV1 encoded clip from 2004-10-29 that crashes too and causes VirtualDub to just close as soon as it tries to open. That isn't surprising as the codec is in an unstable development state. Oddly though, the YV12 encoded file is the exact same size, down to the byte, of the newer YV12 encoded file.

[CruNcher]

be sure to use Fast Recompres with VirtualdubMod
Virtualdub 1.6.x ouptuts only YUV in Fast Recompres

[Atamido]

But I don't want YUV. The source is RGB24, so that is what I am trying to test. I selected Full Processing Mode as I know that it will give the video to the codec in RGB.

[TEB]

i saw the same problems.... with both mjpeg lossles, ffv and huffy... whats up with ffdshow?

[Atamido]

It's bloody unstable?

[Gatak]

Is there really a "reversible" RGB 2 YUV mode? How would you be able to store the lost colour data?

[akupenguin]

No, you can't losslessy reverse a RGB->YUV transform.
FFV1's RGB doesn't convert to YUV, it uses the same colorspace as in Huffyuv: G' = (2*G+B+R)/4, B' = B-G, R' = R-G.