Frozen when rendering a clip in a playlist in a playlist

[LeifAndersen]

Frozen when rendering a clip in a playlist in a playlist

[LeifAndersen]

Also, when I manually modify the playlist0 file to have the same start and end times as playlist1:

  <playlist id="playlist0" title="Anonymous Submission">
    <entry producer="playlist1" in="0" out="5001"/>
  </playlist>

The video plays. Which makes me wonder why the xml generator didn't put that there in the first place.

[LeifAndersen]

I should also mention that I am explicitly setting the "out" property to 5001 on the playlists. But they seem to be discarded by the XML generator.

[ddennedy]

I highly doubt anyone will help you with this, and I do not have time to investigate it as a bug any time soon. I suggest you tinker around to figure it yourself and strongly consider not trying to nest playlists. Most tested/used cases of nesting things includes usage of the tractor element. Good luck.

[LeifAndersen]

Sigh, well thanks for the honest answer. I'll see if I can get it to work nesting with tractors. Thanks.

[LeifAndersen]

Also, interesting, you get this same issue when you put a tractor in a playlist:

...
  <tractor id="tractor0" in="" out="">
    <track producer="producer0"/>
  </tractor>
  <playlist id="playlist0" title="Anonymous Submission">
    <entry producer="tractor0" in="" out=""/>
  </playlist>
...

[LeifAndersen]

Hmm...ya, pretty sure at this point that this is a bug. This issue even persists when I use mlt_playlist_append_io.

@ddennedy Do you know where the code for the XML renderer is?

[ddennedy]

In general, I recommend people to stick to composition patterns that one can observe in the XML outputs from melt -consumer xml, Shotcut, and Kdenlive. SImply reading the documentation and trying things can lead to a lot of frustration. However, in this case, it does seem one ought to be able to use any producer as a playlist entry including a playlist. One could test this theory by making a short program or script. To answer your question see src/modules/xml/producer_xml.c

[LeifAndersen]

In general, I recommend people to stick to composition patterns that one can observe in the XML outputs from melt -consumer xml, Shotcut, and Kdenlive

Oh interesting, doesn't that mean everything needs to fall into just one tractor with flat playlists?

(I say that because as far as I can tell, you only really offset a clip in a track is to make it a playlist and insert a blank. Let me know if that is not correct.)

SImply reading the documentation and trying things can lead to a lot of frustration

Ya, I noticed. ;) If you have a better way though I'd love to hear about it. Thank you for all of the help you've given me so far though.

However, in this case, it does seem one ought to be able to use any producer as a playlist entry including a playlist

Yup. The idea being that abstraction is nice. Namely, my motivation for playing with these bindings is because I am working on a Racket based DSL for building videos, and I'm currently playing with using libmlt as a backend. If you are interested in checking it out sometime, the repo is at:

https://github.com/Leifandersen/video

One could test this theory by making a short program or script

Yup, done that. ;) That's how I generated the XML file.

To answer your question see src/modules/xml/producer_xml.c

Cool, thanks. Ya, this looks like a this is a bug in the xml generator. I'll play with a bit and submit a PR.

Thanks again, you're fantastic. :)

[ddennedy]

Oh interesting, doesn't that mean everything needs to fall into just one tractor with flat playlists?

Not necessarily. Shotcut lets you make clip, playlist, or multitrack projects by simply not using the respective features/panels. In a Shotcut multitrack timeline project, when you make a transition you can see an example of a nested tractor (a tractor implies a multitrack - not simply a wrapper for any producer). Also, if you use both playlist and timeline, you will see an orphan playlist. Compositions can have multiple top-level, unreferenced producers, but the xml producer returns the last-most, top-level producer to consume by default. Surely there are other composition patterns that will work but may only be discovered through heavy experimentation alone or experimentation combined with code analysis.