I need help to convert videos to Lagarith MP4!

[Qyot27]

IFAIK, Super is based off ffmpeg/mencoder libraries which does not (yet) have lagarith support.
Only huffyuv and a few other lossless codecs specific to the ffmpeg library (wich are actually quite good, especially i like to use ffv1 for archives since its soo small) but if you want lagarith, you gotta go the virtualdub route

*technically in that it can encode RGB with an alpha channel however during the encoding process everything is converted to YV12 and then to the target colourspace, thereby killing any alpha channels. I forget if you can even have YUV+A in FFV1 but it would be interesting to see.

Explain this then, since it seems to completely blow that claim apart:
http://forum.doom9.org/showthread.php?p ... post612026

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.

And that was written back in February of 2005.

[Mister Hatt]

That was written back in 2005. The FFV1 encoder has been changed quite a bit by astrange in the past few months, and it was he who mentioned the internal conversion as why it fails at preserving alpha channels. Additionally, while it supports various colourspaces, none of the FFV1 encoders themselves do. I forget exactly where the conversion to YV12->Target happens but iirc it was part of ffmpeg rather than the encoding process itself, and that's why it hasn't been fixed. ffmpeg goes through so many changes in a fortnight that any info about it from even a month ago is usually incorrect. I guess I could poke around and find out more but eh.

[Qyot27]

Well, going by some short tests I did, any colorspace conversions would produce a differing md5sum on the files. At least, from how I understand it.

AviSynth script containing ConvertToRGB32()
RGBA-mode HuffYUV file -> RGBA-mode FFV1 file -> RGBA-mode HuffYUV file

(actual commands:
ffmpeg -i testscript.avs -vcodec huffyuv huffyuv-control.avi
ffmpeg -i huffyuv-control.avi -vcodec ffv1 ffv1.avi
ffmpeg -i ffv1.avi -vcodec huffyuv huffyuv-final.avi)

md5sums on original and final HuffYUV files match, and the filesizes were the same. I would take this to mean that FFV1 or ffmpeg (I used ffmpeg-r22714) didn't do any internal conversion. But to double-check that the assumption was correct, I additionally did:

AviSynth script containing ConvertToRGB32()
RGBA-mode HuffYUV file -> YV12-mode FFV1 file -> RGBA-mode FFV1 file -> RGBA-mode HuffYUV file

(actual commands:
ffmpeg -i testscript.avs -vcodec huffyuv huffyuv-control.avi
ffmpeg -i huffyuv-control.avi -vcodec ffv1 -pix_fmt yuv420p ffv1-yv12.avi
ffmpeg -i ffv1-yv12 -vcodec ffv1 -pix_fmt bgra ffv1-bgra.avi
ffmpeg -i ffv1-bgra.avi -vcodec huffyuv huffyuv-final.avi)

In order to make sure a colorspace conversion happened. The original and final HuffYUV files' md5sums did not match, and the filesize was different.

[Mister Hatt]

Which version of ffmpeg? Did it uses astrange's updated FFV1 stuff? Is it from the general svn, ffmpeg-mt git, or a non-recent build? Stuff changes often there, and I DID get that info about colourspace conversion only a few days ago from the main FFV1 maintainer.

[Qyot27]

It's a vanilla build that came from the general svn (svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk), and I built it the next day. r22714 is logged as having been committed on 2010-03-28 at 21:34:33 -0400, the build is Mar 29th at 10:53:49.

C:\dap\BT>svn log -r 22714 svn://svn.ffmpeg.org/ffmpeg/trunk
------------------------------------------------------------------------
r22714 | darkshikari | 2010-03-28 21:34:33 -0400 (Sun, 28 Mar 2010) | 4 lines

Update x264 presets in line with latest x264 changes.

Patch by Lou Logan.

------------------------------------------------------------------------

C:\dap\BT>ffmpeg
FFmpeg version SVN-r22714, Copyright (c) 2000-2010 the FFmpeg developers
built on Mar 29 2010 10:53:49 with gcc 4.4.3 (x86.generic.Komisar)
configuration: --prefix=/home/Stephen/ffms2_build --enable-gpl --enable-version3 --enable-postproc --enable-memalign-hack --enable-pthreads --enable-libxvid --disable-encoder=mpeg4 --enable-avisynth --extra-cflags='-I/home/Stephen/ffms2_build/include -march=pentium3' --extra-ldflags=-L/home/Stephen/ffms2_build/lib
libavutil 50.13. 0 / 50.13. 0
libavcodec 52.61. 0 / 52.61. 0
libavformat 52.58. 0 / 52.58. 0
libavdevice 52. 2. 0 / 52. 2. 0
libswscale 0.10. 0 / 0.10. 0
libpostproc 51. 2. 0 / 51. 2. 0
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...

Use -h to get full help or, even better, run 'man ffmpeg'

C:\dap\BT>

I can't see anything in the git commit logs about FFV1-related stuff, though (at least, not since 2009). I couldn't really see how to navigate around the ffmpeg-mt gitweb log easily, but as my setup is too old to make using ffmpeg-mt worthwhile I only looked at it yesterday or the day before, and not for that long.



The only log entry I could find from the last few days referring to YV12 (or more precisely, 4:2:0) stuff was this one, committed a couple days after the build I was using. But it seems to be relevant only to ffserver.

------------------------------------------------------------------------
r22751 | rbultje | 2010-03-31 17:02:34 -0400 (Wed, 31 Mar 2010) | 9 lines

Fix FFM-based streaming from ffmpeg to ffserver. The basic problem is that
we'd memset() the codec context to zero, thereby setting audio input to U8
and video to YUV420P. For most video encoders, that actually works, but for
most audio codecs, it doesn't. This patch changes defaults to those set by
avcodec_context_get_defaults() and have ffmpeg figure out the optimal encoding
format itself if not set explicitely (as it does for the non-ffserver-cases
also).

[Mister Hatt]

Just clarified with a few ffmpeg developers. It seems that it will only be a lossless encode to RGBA in FFV1 if your source is a 32bit RGB format, that is, RGB32 and BGR32, and any other plane order, as long as your libswscale is recent, otherwise only RGB32 will work. All other formats (including RGB24) will be converted to YV12 first for no apparent reason that anyone can tell.

[15:27:18] <Hatt> hey astrange, any idea why FFV1 kills the alpha channel in anything I throw at it and encode as RGBA?
[02:21:29] <astrange> Hatt: ffv1 doesn't have alpha encoding, only the official huffyuv does
[02:22:57] <Hatt> and where did the whole "it converts to YV12 internally" thing come from, I remember everyone talking about that a while ago
[02:25:17] <astrange> if you don't use the right rgb pixel format (rgb32) as input it converts to yv12 instead of rgb32 for no real good reason
[02:26:32] <Hatt> and then converts back to RGBA for output?
[02:28:32] <Hatt> also, for RGB pixel format, you mean just being RGB32, or does the planar order make a difference? (BGRA vs RGBA)
[02:33:56] <astrange> it uses rgb32 but ignores the content of alpha
[02:34:14] <astrange> i mean the ffmpeg pixel format named "rgb32"
[02:41:50] <Hatt> wait, so, the encoder needs RGB32 to encode without converting to YV12 first, BGR32 will still convert to YV12?
[02:43:28] <pengvado> if you give it RGB32 it'll work, and if you give it any other RGB format it'll fatal error, and if you tell ffmpeg to encode RGB32 and the input was some other format, it'll convert
[02:44:11] <pengvado> ffmpeg will convert, that is. FFV1 doesn't.
[02:44:25] <Hatt> so if I tell ffmpeg to encode RGB32 and I feed it BGR32 it will convert and not just reorder?
[02:44:44] <pengvado> converting RGB32 to BGR32 is a reorder
[02:46:56] <pengvado> there may be some cases where libswscale is stupid, but rgb<->bgr isn't one of them

[Qyot27]

They didn't say anything about other formats, though, save other RGB formats. RGB24 sure, because FFV1 doesn't seem to support that by input (and I did see that firsthand in the tests; I got around it by explicitly giving HuffYUV RGB32 via AviSynth instead of RGB24, and giving the Huffy to FFV1, or giving RGB32 from AviSynth directly to FFV1), but there should be no reason YUV 4:2:2 or YUV 4:4:4 or so on shouldn't work as expected (granted the ordering stuff and what all is correct; I was having all sorts of trouble sorting through yuv422p and yuvj422p and yuyv422p, etc.). You just have to know what you're feeding the darn thing before you do it, but that should be the case anyway.

The most I got out of that is that FFmpeg simply defaults to YV12 when it doesn't know what colorspace you're giving it, or if the format you're encoding to doesn't support the colorspace you're giving it (if it doesn't actually error out, anyway).

[Mister Hatt]

FFV1 only supports RGBA as input. ffmpeg itself will convert other planar RGB32 formats to RGB, but anything else from YUV to RGB24 will be converted to YV12 first. I didn't paste the entire log but that was the conclusion. The problem with the conversion is that it is not lossless. best to stick to the same colourspace whenever possible, with the same coefficients.