Re: [Mlt-devel] melted playlist with live capture and video files mix not working
Brought to you by:
ddennedy,
lilo_booter
From: Dan D. <da...@de...> - 2011-09-29 21:09:07
|
On Wed, Sep 28, 2011 at 9:19 AM, Dan Dennedy <da...@de...> wrote: > On Wed, Sep 28, 2011 at 5:02 AM, Raymond Doran > <ra...@th...> wrote: >> Thanks Dan, I will check this out when I get to my server. Is the change in git? >> > > No, it needs a little more work and testing. I want to make sure you > understand the conditions. I tested some more yesterday with Kdenlive and some other utility I am working on, and I think it works good. So, I checked it in, and you can give it a try. >> On Sep 28, 2011, at 2:06 AM, Dan Dennedy <da...@de...> wrote: >> >>> 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-+ >>> >>> >> > > > > -- > +-DRD-+ > -- +-DRD-+ |