Re: [Mlt-devel] melted playlist with live capture and video files mix not working

[Dan D. <da...@de...>]

On Tue, Sep 27, 2011 at 10:41 PM, Dan Dennedy <da...@de...> wrote:
> On Mon, Sep 26, 2011 at 12:59 PM, Raymond Doran
> <ra...@th...> wrote:
>>
>> On Sep 26, 2011, at 2:52 PM, Dan Dennedy wrote:
>>
>>> On Mon, Sep 26, 2011 at 11:48 AM, Raymond Doran
>>> <ra...@th...> wrote:
>>>> All,
>>>>
>>>> I can get live capture to play through melted ( Thank you Dan Dennedy!) but when I try to append another video clip to the playlist with the APND command it will not play.  If i load the clip with the LOAD command it plays the clip, but I can never play capture again.  I get INVALID on the output.  I try to CLEAR and load it still will not play the capture again until I shutdown melted and restart it.
>>>>
>>>> One thing I noticed the last time is that when I load a capture xml it immediately starts playing through the output and the USTA U0 command says that U0 is stopped with the track info from the capture xml.
>>>>
>>>
>>> What is your version of MLT? If it ends with an odd version, then what
>>> is the checkout date? Reason I ask is because I recently changed the
>>> decklink producer from starting on creation to starting on first frame
>>> request. So, it sounds like the older version.
>>
>> I just ran the build-melted.sh this morning.  melt -version says 0.7.5
>>
>>>
>>>> I have attached the xml I am using as well.
>>>>
>>>> 1.  capture.mlt - xml generated from "melt -profile dv_pal decklink -consumer xml:/microplayer/mlt/capture.mlt"
>>>> 2.  capture.mlt  - modified version of capture.mlt
>>>>
>>>> Any ideas.
>>>
>>> You are not doing anything wrong. This is just not a typical use case
>>> for which melted is used and tested. Melted has been around for a long
>>> time and mainly used for SDI playout of files and not capture to SDL
>>> or IP. So there is a bug, and I am busy with other things at the
>>> moment. I will at least let you know within a few days if I reproduce
>>> it, but I cannot necessarily debug it at this time.
>>>
>>
>> Oh, I did not want to heart that... That means they will want me to write code to interface with the card.  ugh.  Please let me know if you get a chance to look at it or maybe even an idea of where in the code it might be so I  can look at it.
>>
>> Raymoind
>
> I just ran a test, and that quickly "jogged" my brain. The problem is
> that each instance of the decklink producer in a melted playlist is an
> additional instance. When the first instance is created, it opens the
> hardware driver and resources. The resources remain opened even beyond
> the out point because you could use that service again by reference or
> simply by seeking. Therefore, when the second producer instance is
> created, it fails to open the driver because it is already open! This
> XML demonstrates how a composition can reuse a producer and workaround
> this problem:
>
> <mlt profile="dv_ntsc">
>  <producer id="producer0">
>    <property name="mlt_service">decklink</property>
>  </producer>
>  <producer id="producer1">
>    <property name="mlt_service">noise</property>
>  </producer>
>  <playlist id="playlist0">
>    <entry producer="producer0" in="0" out="99"/>
>    <entry producer="producer1" in="0" out="99"/>
>    <entry producer="producer0" in="0" out="99"/>
>  </playlist>
>  <tractor>
>    <track producer="playlist0"/>
>  </tractor>
> </mlt>
>
> If you think about this behavior in a general abstract sense, you can
> see how a very large composition can exhaust resources like file
> handles. There are solutions to this problem within mlt_playlist
> (autoclose=1) and usage of mlt_cache within avformat producer to flush
> and reinstantiate on-demand. However, those do not work here
> (autoclose always only closes producers before previous leaving
> previous open for as-run logging). And, of course, doing it all in XML
> does not help you utilize a melted playlist. Maybe because the
> decklink producer is not seekable, as a solution we can have it detect
> when it has reached the out point and close the driver. However, each
> producer is created when loading the composition or added to the
> melted playlist, and currently the decklink driver is opened upon
> creation. (Producer are supposed to validate their input.)
>
> So, yeah, a bit needs to be restructured in producer_decklink.cpp to
> support this. Probably the best thing is remove the mlt_producer_s
> from the DeckLinkProducer class so you can destroy decklink within
> producer_decklink_init() after validating it and re-create it on the
> first call to get_frame(). Then, at the bottom of get_frame() add
> something like:
>
> if ( mlt_producer_position( producer ) >= mlt_producer_get_out( producer ) )
> {
>    delete decklink;
>    producer->child = NULL;
> }

OK, I have this change basically working but only under specific
conditions. First, you have to create your decklink.mlt xml file with
a specific length or out point. Secondly, when your melted playlist
gets to that playlist entry, it must play through to the end so that
the producer sees it is at the end and closes itself. That means
manual, ad hoc loading the decklink.mlt to play for a while then
playing something else does not quite work right. Likewise, you have
to always let the decklink.mlt play through to its end. Lastly, the
cut from a clip to the decklink producer is not perfectly smooth
because the decklink is re-opened on the first frame requested from
it, and there is a little pre-buffering (adjustable through prefill
property).

-- 
+-DRD-+