lossless codecs questions

[BabaG]

not sure if this is the right place for this but it seemed the most codec-
specific forum so here i am.

i'm working cross-platform and capturing a lot in huffyuv. i'd like to
save some disk space and find that, using avidemux to transcode the
huffyuv to ffv1 for archiving, i can cut the required disk space in half.
final cut pro will display the huffyuv on the timeline for rendering if
i need it. it will not display the ffv1 so ffv1 would only be for archival
use.

question is, if i end up, for whatever reason, having to go back and
forth, transcoding the ffv1 back to huffyuv for final cut use, will i lose
anything? how damaging will this be to the image quality given the
'lossless' nature of these codecs? in other words, how damaging is it
to an image to go huffyuv--->ffv1--->huffyuv? are the artifacts, if
any, visible, or are they mainly in a theoretical, mathematical realm?

thanks,
BabaG

[Dark Shikari]

As long as you stay in the same colorspace there will be no loss.

[BabaG]

wow! that was fast. thanks dark shikari.

do you know if, using avidemux at the defaults for these processes, the
colorspace is maintained?

thanks again,
BabaG

[easy2Bcheesy]

Isn't it the case that Huffyuv typically uses 24-bit RGB or YUY2 while FFV1 is using the lower YV12 colour space?

You should try other lossless codecs: Lagarith, UT Codec Suite or AMV Codec.

[Dark Shikari]

Isn't it the case that Huffyuv typically uses 24-bit RGB or YUY2 while FFV1 is using the lower YV12 colour space?

You should try other lossless codecs: Lagarith, UT Codec Suite or AMV Codec.FFV1 supports basically all the colorspaces that matter.

HuffYUV only supports YUY2 and RGB. FFVHuff supports RGB, YUY2, and YV12.

[nm]

do you know if, using avidemux at the defaults for these processes, the
colorspace is maintained?
Avidemux will convert everything to YV12, so unless that's the pixel format of your huffyuv video, there will be a conversion.

Use ffmpeg instead. It prints the input and output colorspaces and doesn't do conversions behind your back.
ffmpeg -i input.avi -acodec copy -vcodec ffv1 output.avi

[BabaG]

thanks for all the input on this. very helpful.

nm: would i just use the reverse to go back from ffv1 to huffyuv?

ffmpeg -i input.avi -acodec copy -vcodec huffyuv output.avi

when i tried that i got an error:

FFmpeg version CVS, Copyright (c) 2000-2004 Fabrice Bellard
Mac OSX universal build for ffmpegX
configuration: --enable-memalign-hack --enable-mp3lame --enable-gpl --disable-vhook --disable-ffplay --disable-ffserver --enable-a52 --enable-xvid --enable-faac --enable-faad --enable-amr_nb --enable-amr_wb --enable-pthreads --enable-x264
libavutil version: 49.0.0
libavcodec version: 51.9.0
libavformat version: 50.4.0
built on Apr 15 2006 04:58:19, gcc: 4.0.1 (Apple Computer, Inc. build 5250)
Input #0, avi, from 'KL_02_02_C_39800_ffmpeg_FFV1.avi':
Duration: 00:00:31.2, start: 0.000000, bitrate: -2147483 kb/s
Stream #0.0, 10.00 fps(r): Video: ffv1, rgba32, 2048x1536
Output #0, avi, to 'KL_02_02_C_39800_ffmpeg_back2huffyuv.avi':
Stream #0.0, 10.00 fps(c): Video: huffyuv, rgba32, 2048x1536, q=2-31, 200 kb/s
Stream mapping:
Stream #0.0 -> #0.0
[huffyuv @ 0x54340c]format not supported
Error while opening codec for output stream #0.0 - maybe incorrect parameters such as bit_rate, rate, width or height

using your original command converted to ffv1 without issue, but, coming back to huffyuv i got the
above error.

here's the output from the first conversion of huffyuv to ffv1:

FFmpeg version CVS, Copyright (c) 2000-2004 Fabrice Bellard
Mac OSX universal build for ffmpegX
configuration: --enable-memalign-hack --enable-mp3lame --enable-gpl --disable-vhook --disable-ffplay --disable-ffserver --enable-a52 --enable-xvid --enable-faac --enable-faad --enable-amr_nb --enable-amr_wb --enable-pthreads --enable-x264
libavutil version: 49.0.0
libavcodec version: 51.9.0
libavformat version: 50.4.0
built on Apr 15 2006 04:58:19, gcc: 4.0.1 (Apple Computer, Inc. build 5250)
Input #0, avi, from 'KL_02_02_C_39800.avi':
Duration: 00:08:44.1, start: 0.000000, bitrate: 382477 kb/s
Stream #0.0, 10.00 fps(r): Video: huffyuv, rgba32, 2048x1536
Output #0, avi, to 'KL_02_02_C_39800_ffmpeg_FFV1.avi':
Stream #0.0, 10.00 fps(c): Video: ffv1, rgba32, 2048x1536, q=2-31, 200 kb/s
Stream mapping:
Stream #0.0 -> #0.0
Press [q] to stop encoding
frame= 5241 q=0.0 Lsize=17124708kB time=524.1 bitrate=267669.5kbits/s
video:17124613kB audio:0kB global headers:0kB muxing overhead 0.000553%

i notice differing durations between the two readouts.

also, just curious, as these files have no audio, is the acodec parameter for audio? is it necessary?

thanks again,
BabaG

[qyot27]

You're using an extremely-outdated version of ffmpeg (built in '06, but the Copyright date is only to '04, which I assume means the revision was already a couple years old when it was built). That might be the problem more than anything else. Getting 'new' builds on OS X seems to rely entirely on compiling it yourself, though. I did it back in November, but I have no idea what the limits are there in terms of if Leopard/Snow Leopard can run stuff built on Tiger or whether anything in FFmpeg is miscompiled because Apple's version of GCC on Tiger is from the 4.0.x branch, if I recall correctly.

-acodec is indeed for audio. If there isn't an audio stream, it's not necessary (and if there was an audio stream, you could ignore it by using -an instead).

The options needed may have changed regarding colorspaces, as well as what was supported and when. A build that old may not support such conversions correctly.

EDIT: If I'm reading this commit entry from March '07 (http://git.ffmpeg.org/?p=ffmpeg;a=commit;h=22d7a54606110d7b434a0fc8ed23a1bb977d72d5) correctly, it is indeed the case that prior revisions didn't support encoding HuffYUV in RGB. You need a post-March 2007 build.

The build from November I mentioned doesn't have an 'rgba32' colorspace option (you should be able to see the supported colorspaces by doing ffmpeg -pix_fmt list). However, it does have both 'rgba' and 'bgra'. FFV1 only worked with 'bgra', but as long as it was 'bgra' it converted to and from FFV1 and HuffYUV just fine. Of course, that's the Windows build, not the OS X one.

If you want, you can download it here:
http://www.mediafire.com/?jo0ctjxqg5y

To be precise, it's a build of the Lagarith fork (http://repo.or.cz/w/FFMpeg-mirror/lagarith.git), so by the main FFmpeg git, it's outdated by about 4 months. Still better than 4-6 years, though. My reason for building it was that I simply wanted to test out the experimental Lagarith decoder, but that shouldn't affect anything concerning FFV1 and HuffYUV. It includes both OS X (Tiger, Intel) and Windows builds, so I guess if the OS X build fails to work, you could try running the Windows build with Crossover or Wine.

Note: because this isn't 'installed' in the traditional sense - nor is my OS X knowledge used enough to know where the PATH definitively is, you might want to rename the executable to ffmpeg-lagarith and then you'll need to start the command with a ./, so it'd look like ./ffmpeg-lagarith -i /path/to/input.avi -vcodec ffv1 /path/to/output-ffv1.avi - that should work, and won't conflict with the ffmpeg that FFmpegX installed. Those /path/to/'s can be omitted if the video files are in the same folder as the executable.

[BabaG]

thanks for the ideas qyot27.

tried the ffmpeg-lagarith idea:

ffmpeg-lagarith -i KL_02_02_C_39800_ffmpeg_FFV1.avi copy -vcodec huffyuv KL_02_02_C_39800_ffmpeg_back2huffyuv.avi
FFmpeg version UNKNOWN, Copyright (c) 2000-2009 Fabrice Bellard, et al.
built on Nov 22 2009 20:34:04 with gcc 4.0.1 (Apple Computer, Inc. build 5370)
configuration: --enable-gpl --disable-mmx --enable-pthreads
libavutil 50. 3. 0 / 50. 3. 0
libavcodec 52.38. 0 / 52.38. 0
libavformat 52.39. 1 / 52.39. 1
libavdevice 52. 2. 0 / 52. 2. 0
libswscale 0. 7. 1 / 0. 7. 1
Input #0, avi, from 'KL_02_02_C_39800_ffmpeg_FFV1.avi':
Duration: 00:00:31.20, start: 0.000000, bitrate: -2147483 kb/s
Stream #0.0: Video: ffv1, bgra, 2048x1536, 10 tbr, 10 tbn, 10 tbc
Unable to find a suitable output format for 'copy'

[qyot27]

ffmpeg-lagarith -i KL_02_02_C_39800_ffmpeg_FFV1.avi copy -vcodec huffyuv KL_02_02_C_39800_ffmpeg_back2huffyuv.avi

Why is that 'copy' (bolded) there? Delete that and try running it again.

[BabaG]

seems to be working now. will take an hour or so before i can see what it did.

ffmpeg-lagarith -i KL_02_02_C_39800_ffmpeg_FFV1.avi -vcodec huffyuv KL_02_02_C_39800_ffmpeg_back2huffyuv.avi
FFmpeg version UNKNOWN, Copyright (c) 2000-2009 Fabrice Bellard, et al.
built on Nov 22 2009 20:34:04 with gcc 4.0.1 (Apple Computer, Inc. build 5370)
configuration: --enable-gpl --disable-mmx --enable-pthreads
libavutil 50. 3. 0 / 50. 3. 0
libavcodec 52.38. 0 / 52.38. 0
libavformat 52.39. 1 / 52.39. 1
libavdevice 52. 2. 0 / 52. 2. 0
libswscale 0. 7. 1 / 0. 7. 1
Input #0, avi, from 'KL_02_02_C_39800_ffmpeg_FFV1.avi':
Duration: 00:00:31.20, start: 0.000000, bitrate: -2147483 kb/s
Stream #0.0: Video: ffv1, bgra, 2048x1536, 10 tbr, 10 tbn, 10 tbc
File 'KL_02_02_C_39800_ffmpeg_back2huffyuv.avi' already exists. Overwrite ? [y/N] y
[huffyuv @ 0x1003600]using huffyuv 2.2.0 or newer interlacing flag
Output #0, avi, to 'KL_02_02_C_39800_ffmpeg_back2huffyuv.avi':
Stream #0.0: Video: huffyuv, bgra, 2048x1536, q=2-31, 200 kb/s, 10 tbn, 10 tbc
Stream mapping:
Stream #0.0 -> #0.0
Press [q] to stop encoding


does it make any difference, theoretically or otherwise, that the original huffYUV
file said it was rgb32 and the output, as listed here, says it's bgra?

thanks!
BabaG

[qyot27]

does it make any difference, theoretically or otherwise, that the original huffYUV
file said it was rgb32 and the output, as listed here, says it's bgra?

thanks!
BabaG
Did it say it was rgb32 in the ffmpegx install or the one I just posted?

Either way, 'RGB32' can be either RGBA (24-bit RGB + 8-bit Alpha Channel) or simply a codename for 32-bit aligned RGB24. In ffmpeg, it's probably just a difference in terminology in how it gets printed (there are commits where rgba32 was deprecated and new labels were brought in).

My understanding/assumption of the difference between rgba and bgra (or rgb24/bgr24, etc.) is simply the way the color channels are ordered, like the difference between YV12 and I420 - both are YUV4:2:0, but the U and V channels are swapped. Otherwise they're the same.

[BabaG]

it takes close to an hour to run the file so i just grabbed the one that
was encoded to ffv1 by the ffmpegx install. tomorrow i'll try going both
ways using the ffmpeg-lagarith that you posted.

i do notice one oddity, perhaps also because of the version mismatching,
in the duration times listed:

Duration: 00:08:44.1 for ffmpegx huffYUV to ffv1
Duration: 00:00:31.20 for ffmpegx ffv1 to huffYUV
Duration: 00:00:31.20 for ffmpeg-lagarith ffv1 to huffYUV

thanks again,
BabaG

[nm]

i do notice one oddity, perhaps also because of the version mismatching,
in the duration times listed:

Duration: 00:08:44.1 for ffmpegx huffYUV to ffv1
Duration: 00:00:31.20 for ffmpegx ffv1 to huffYUV
Duration: 00:00:31.20 for ffmpeg-lagarith ffv1 to huffYUV

What's the correct duration and framerate? If the newer ffmpeg build does the same thing, maybe there's something wrong with your source AVI. If that's the case, you can force the correct framerate with -r <fps>

[zcream]

Hi easy. Do you know if AMV2 codec can be read on a Mac ?
I am using it to acquire from a Blackmagic Intensity but need to bring it to a Mac to edit.
Cheers!

Isn't it the case that Huffyuv typically uses 24-bit RGB or YUY2 while FFV1 is using the lower YV12 colour space?

You should try other lossless codecs: Lagarith, UT Codec Suite or AMV Codec.