I think this would be a good optimization.
QImage::Format_RGBA8888 is not available in Qt 4.8. So we would need some
pre-processor conditionals to use either the previous way or the new way
depending on version.
Are you sure that line order is the same between Qt and MLT image formats? For
some reason I was thinking that line 0 is the bottom for MLT and the top for
Qt. If that is the case, the new method can not be used for services that need
to draw on the image because, for example, text would be written upside down.
It may not matter for some services like your transition that don't have any
directional component. Maybe the difference could be compensated by applying a
transform to the painter. Could you check this out and report back?
The documentation it a little confusing. It states: "The order of the colors is
the same on any architecture if read as bytes 0xRR,0xGG,0xBB,0xAA.". I think
what they are trying to say is that the color order will be the same on any
architecture if you look at the bytes, but if you look at each pixel as an int,
the order will appear differently depending on the endianess of the system. So
I think this will work for us on big or little endian systems since. If we find
that it does not work on big-endian systems, we can just put a check in place
and either convert the easy way or the hard (current) way.
~Brian
From: Jean-Baptiste Mardelle <j...@kdenlive.org>
To: mlt-devel@lists.sourceforge.net
Sent: Saturday, July 16, 2016 8:56 AM
Subject: [Mlt-devel] Optimizing Qt functions
Hi,
Following my tests with the qtblend transitions, I realized that the QImage
format Format_RGBA8888 allows for a much simpler conversion between MLT and
QImage, avoiding the need to copy data. We can in fact simply create a
QImage directly from MLT's image buffer (with format=mlt_image_rgb24a):
QImage img( *image, *width, *height, QImage::Format_RGBA8888 );
We can then use a QPainter to draw directly on the buffer.
So for instance, in filter_audiowaveform we currently do (line 214):
QImage qimg( *width, *height, QImage::Format_ARGB32 );
copy_mlt_to_qimage_rgba( *image, &qimg );
draw_waveforms( filter, frame, &qimg, audio, channels, samples );
copy_qimage_to_mlt_rgba( &qimg, *image );
This can be replaced by:
QImage qimg( *image, *width, *height, QImage::Format_RGBA8888 );
draw_waveforms( filter, frame, &qimg, audio, channels, samples );
In my tests, this results in a 8% speedup when rendering a simple video
with the audiowaveform filter.
My only concern is that in the doc (
http://doc.qt.io/qt-5/qimage.html#Format-enum ) it says thatÂ
QImage::Format_RGBA8888 behaves differently on big endian systems, and I am
not sure if this would affect us...
Can anyone with a better understanding or a big endian system tell me if
this works on such systems ?
Seems like something we might want to use in our Qt producers/filters, what
do you think?
regards,
jb
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
