[FFmpeg-devel] [PATCH 2/5] libavformat/avisynth: enable additional pix_fmts

Stephen Hutchinson qyot27 at gmail.com
Mon Mar 25 03:13:11 EET 2019


On 3/24/2019 7:07 PM, Carl Eugen Hoyos wrote:
> 2019-03-24 21:25 GMT+01:00, Stephen Hutchinson <qyot27 at gmail.com>:
>> These pix_fmts have been added to FFmpeg in the 31 months since
>> commit 92916e8542e425ca20daddb490261a5818643206 added support for
>> the larger number of pix_fmts that AviSynth+ can use. They were
>> present in AviSynth+ even then, just not in libavutil.
>> +    /* Single precision floating point Planar RGB (AviSynth+) */
>> +    case AVS_CS_RGBPS:
>> +        st->codecpar->format = AV_PIX_FMT_GBRPF32;
>> +    /* Single precision floating point Planar RGB with Alpha (AviSynth+) */
>> +    case AVS_CS_RGBAPS:
>> +        st->codecpar->format = AV_PIX_FMT_GBRAPF32;
> Were you able to test these two in any way?
> Is there absolutely no danger that they mean something
> completely different in avisynth?
There shouldn't be any danger whatsoever.  AviSynth+ supports 32bpp 
video only as being floating point¹,
and the plane order is exactly the same as the other RGB(A)P formats 
libavformat already support in
AviSynth scripts².

AviSynth+-side, they can be tested with relatively simple scripts that 
generate content in these pix_fmts.
Planar RGB Float:
Version().ConvertToPlanarRGB().ConvertBits(32) # ConvertToFloat() is an 
older, more specific alternative to the ConvertBits call
or
BlankClip(pixel_type="RGBPS")


Planar RGBA Float:
Version().ConvertToPlanarRGB().ConvertBits(32).AddAlphaPlane()
or
BlankClip(pixel_type="RGBAPS")

I also tested with real video input. I don't have any natively-float 
RGB(A) samples,
so I used the above conversion functions on a standard 8bpp 4:2:0 input, and
verified that the script is detected as gbr(a)pf32 in FFmpeg, and the actual
output was correct when previewed with a build of mpv linked against the 
patched
libavformat (and it also detected the video as gbr(a)pf32).  I wasn't 
able to preview
either of those formats in ffplay, but I think that may simply be a 
problem with the
way I built SDL2, unless SDL2 itself doesn't support floating-point 
RGB(A); the
Y32/GRAYF32 test worked in ffplay.

¹http://avisynth.nl/index.php/Avisynthplus_color_formats (see footnote 
2, linked from the Bit Depth column in the table)

²http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/avisynth.c;h=250a489321edc6b150e079d2c960c47be48f6b37;hb=c3b517dac2bbd3007c5ac8fc61efe87661dda5c0#l100,
the formats themselves defined in avisynth_c.h (using the 
AVS_GENERIC_RGBP and AVS_GENERIC_RGBAP values):
http://git.videolan.org/?p=ffmpeg.git;a=blob;f=compat/avisynth/avisynth_c.h;h=605b92ae62f94e374242dc90f1e4f2ea1f7ac864;hb=c3b517dac2bbd3007c5ac8fc61efe87661dda5c0#l186
http://git.videolan.org/?p=ffmpeg.git;a=blob;f=compat/avisynth/avisynth_c.h;h=605b92ae62f94e374242dc90f1e4f2ea1f7ac864;hb=c3b517dac2bbd3007c5ac8fc61efe87661dda5c0#l194



More information about the ffmpeg-devel mailing list