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