How to burn a Qt type to video?

[Megubit]

Hello,

I'm using the library for a simple project in Qt and I'm wondering it's possible to burn a QML type (for example a Rectangle) to the video.

Using this simple example:

// Create a reader for a video
openshot::FFmpegReader r("MyAwesomeVideo.webm");
r.Open(); // Open the target reader
// Create a writer (which will create a WebM video)
openshot::FFmpegWriter w("/home/jonathan/NewVideo.webm");
// Set options
// Sample Rate: 44100, Channels: 2, Bitrate: 128000
w.SetAudioOptions(true, "libvorbis", 44100, 2, openshot::ChannelLayout::LAYOUT_STEREO, 128000);
// FPS: 24, Size: 720x480, Pixel Ratio: 1/1, Bitrate: 300000
w.SetVideoOptions(true, "libvpx", openshot::Fraction(24,1), 720, 480, openshot::Fraction(1,1), false, false, 300000);
// Open the writer
w.Open();
// Write all frames from the reader
w.WriteFrame(&r, 1, r.info.video_length);
// Close the reader & writer
w.Close();
r.Close();

If I understand right, I can use the WriteFrame() function to write a openshot::Frame and add a QImage to it.
In theory that should work, but I'm stuck at the part of creating a QImage of a Rectangle.

Maybe I have the wrong way of thoughts about how to accomplish this, or if it's even possible to do it this way, but I decided to ask if anyone has some kind of hints of how to do it.

I'm sure I need a custom component so it can be displayed to the user and referenced to the writer, I just can't think of one that would accomplish this, maybe a subclass of QQuickPaintedItem would suffice or a QPixmap Class?

[Megubit]

Got an answer for the QML type, using grabToImage seems to work just fine as it creates a QImage.

Now just to get it into the video, Timeline and Clip should be the right way for it, I guess.

[Megubit]

Timeline and Clip was indeed the answer :)

[ferdnyc]

@Megued

That's actually an interesting problem. As heavily as it uses Qt, the libopenshot API is very Qt-unfriendly. Mostly that's because its feature are primarily targeted to OpenShot's needs, so it tends to fill those but can be lacking in areas beyond that.

But maybe it doesn't have to be. There's no reason there couldn't be a reader that's a better Qt citizen, like a QImageReader. (Only downside: confusion with the existing QtImageReader, where Qt is only an implementation detail in that it happens to use QImage to load image file formats from disk.)

My thinking is, QImageReader would have APIs to directly interact with its internal QImage buffer, rather than focusing on image files being loaded from disk. You could create it by passing in an existing QImage, or any Qt type that's castable to a QImage, or have it create a new QImage instance, then get access to it and modify it using QPainter... things like that.

No reason it needs to be limited to QImage, either. Support for QPixmap seems like a logical next step, and maybe some other API sugar. (Like, the reader itself could be a QPaintDevice, that's the first thing that comes to mind and seems like it might be handy.)

In fact maybe it should just be a QtReader. Hmm.

Reopening for an idea possibly worth exploring. Thanks!

(Oh, and glad you solved your thing, too. 😉)

[Megubit]

QImageReader does indeed sound interesting, especially if it would have access to QImage buffer. But at the moment don't have the time to check it out.
What I did for the current solution is save images with QML Item grabToImage and store them in a temp folder for later use with QtImageReader. Bit of a workaround but it works 😅

[ferdnyc]

What I did for the current solution is save images with QML Item grabToImage and store them in a temp folder for later use with QtImageReader. Bit of a workaround but it works

That's OK, you wanna talk roundabout? Here's how OpenShot thumbnails media files: It calls openshot.Frame.Thumbnail() (the Python binding for openshot::Frame::Thumbnail) with a filesystem path for libopenshot to write the thumbnail to, then generates a URL corresponding to that file's location and passes it over to the JavaScript timeline implementation, which then sets that URL as the source location of an <IMG> which will end up being retrieved from OpenShot's internal HTTP server. 😁

[ferdnyc]

Sorry, dumb fingers.