ffv1 - lossless codec?

HLW · 15th March 2004, 13:51

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 · 15th March 2004, 15:09

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 · 15th March 2004, 15:20

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 · 15th March 2004, 20:40

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 · 15th March 2004, 20:46

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 · 16th March 2004, 23:22

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 · 16th March 2004, 23:55

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

HLW · 17th March 2004, 09:39

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 · 27th April 2004, 09:48

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 · 27th April 2004, 12:28

Quote:

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 · 27th April 2004, 13:20

Hi again!

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

virus · 27th April 2004, 14:16

Quote:

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 · 11th December 2004, 19:01

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 · 11th December 2004, 19:26

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

Atamido · 12th December 2004, 07:05

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 · 12th December 2004, 13:10

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

Atamido · 15th December 2004, 15:10

It's bloody unstable?

Gatak · 16th February 2005, 22:52

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

akupenguin · 16th February 2005, 23:49

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.

15th March 2004, 13:51	#1 \| Link
HLW Registered User Join Date: Mar 2004 Posts: 23	ffv1 - lossless codec? 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

11th December 2004, 19:26	#14 \| Link
CruNcher Registered User Join Date: Apr 2002 Location: Germany Posts: 4,926	be sure to use Fast Recompres with VirtualdubMod Virtualdub 1.6.x ouptuts only YUV in Fast Recompres __________________ all my compares are riddles so please try to decipher them yourselves :) It is about Time Join the Revolution NOW before it is to Late ! http://forum.doom9.org/showthread.php?t=168004

15th March 2004, 15:09	#2 \| Link
MfA Registered User Join Date: Mar 2002 Posts: 1,075	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.

15th March 2004, 15:20	#3 \| Link
HLW Registered User Join Date: Mar 2004 Posts: 23	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?

15th March 2004, 20:40	#4 \| Link
duartix Registered User Join Date: Oct 2001 Location: Outside the Bush INSanatory - Lisbon Posts: 330	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.

15th March 2004, 20:46	#5 \| Link
MfA Registered User Join Date: Mar 2002 Posts: 1,075	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.

16th March 2004, 23:22	#6 \| Link
Atamido Señor Member Join Date: May 2002 Location: Austin, Texas Posts: 915	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.

16th March 2004, 23:55	#7 \| Link
MfA Registered User Join Date: Mar 2002 Posts: 1,075	Dunno about ffvfw, but ffmpeg supports RGB coding now (well it still codes in another colorspace, but the colorspace transform is reversible).

17th March 2004, 09:39	#8 \| Link
HLW Registered User Join Date: Mar 2004 Posts: 23	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?

27th April 2004, 09:48	#9 \| Link
HLW Registered User Join Date: Mar 2004 Posts: 23	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?

27th April 2004, 13:20	#11 \| Link
HLW Registered User Join Date: Mar 2004 Posts: 23	Hi again! The ffdshow output dialog box can't be changed in ffv1 mode. You mean under "configure" and "encoder"?

11th December 2004, 19:01	#13 \| Link
Atamido Señor Member Join Date: May 2002 Location: Austin, Texas Posts: 915	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.

12th December 2004, 07:05	#15 \| Link
Atamido Señor Member Join Date: May 2002 Location: Austin, Texas Posts: 915	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.

12th December 2004, 13:10	#16 \| Link
TEB Registered User Join Date: Feb 2003 Location: Palmcoast of Norway Posts: 363	i saw the same problems.... with both mjpeg lossles, ffv and huffy... whats up with ffdshow?

15th December 2004, 15:10	#17 \| Link
Atamido Señor Member Join Date: May 2002 Location: Austin, Texas Posts: 915	It's bloody unstable?

16th February 2005, 22:52	#18 \| Link
Gatak Registered User Join Date: Sep 2004 Posts: 21	Is there really a "reversible" RGB 2 YUV mode? How would you be able to store the lost colour data?

16th February 2005, 23:49	#19 \| Link
akupenguin x264 developer Join Date: Sep 2004 Posts: 2,392	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.