Sure the 3rd option is much simpler, and since MLT doesn't currently
support > 8bit buffers it won't make much difference in the result.
A simple patch is in my github's fork:
https://github.com/j-b-m/mlt/commit/d8c723130e34da7680b50b47bc31a927ef6414cd
It supports both missing formats from the bugreport
https://bugs.kde.org/show_bug.cgi?id=391963
However more pixel formats will probably require the same adjustments in
the future.
There are some areas where 10-bit video can be used through
mlt_image_yuv422p16, primarily only for input and output via decklink
and avformat. With some work, it can be added into movit integration for
16-bit float processing. However, the change mentioned above will work
until that is done.
I made some nit comments on the commit, but in general, I think this is
an OK solution.
As a more general solution, in the future, I think we could add a final
"else" statement that queries the AVPixFmtDescriptor and tries to make
an automatic determination. Something like:
... Existing code...
else {
AVPixFmtDescriptor* desc = av_pix_fmt_desc_get(
codec_context->pix_fmt );
if( desc->flags & AV_PIX_FMT_FLAG_ALPHA ) {
*format = mlt_image_rgb24a;
} else if( av_get_bits_per_pixel( desc ) > 24 ) {
*format = mlt_image_yuv422p16;
} else if( desc->flags & AV_PIX_FMT_FLAG_RGB ) {
*format = mlt_image_rgb24;
} else {
*format = mlt_image_yuv422;
}
I'm not volunteering to do this myself, but if anyone is interested, it
might be a nice general solution.
~Brian
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
