On Sat, Sep 29, 2012 at 7:43 AM, Markus Kienast <[email protected]> wrote: > Hi Dan, > > we are having crazy problems with the Multi Consumer. > > We created a little playout system using the MLT Ruby bindings based > on the Playlist object and we are facing problems with seeking in the > playlist as soon as we switch to the Multi Consumer.
Some defaults in the multi consumer are setup for the use case of rendering projects. There are properties like terminate_on_pause, buffer, prefill, real_time, and mlt_profile on both the multi consumer and its children that may need to be set for various use cases. And even then I am not sure how robust it is for many use cases as it generally is not used much by myself or the open source projects I support. > I have used your playlist.rb example code to reproduce the problem > with the least amount of code possible. > > Here is the link to the code we used for testing: > https://gist.github.com/3804203 > I have also included the log of my interaction with MLT and the > multi.yaml we used. > > Seeking works nice and easy with no delay with the decklink consumer. > > As soon as we switch to Multi, seeking does freak out on us. > > In my example, when I seek the first time things freeze on decklink. > consumer.position stays close to where it was seeking from (can not > tell, if it stays exactly there or not). > pls.position seems to have jumped to the point I want to seek to plus > 28 frames and freezes there. Eventhough speed is 1 and is_stopped is > false. > Stuff stays there for a while. > Most of the time the beginning of the sequence I was seeking to can be > seen on the output already. Could be that this is not the actual frame > I jumped to, but one in the range of it plus 28 frames, I can not > tell. > After at least 90 seconds, everything seems to continue normally. > The positions reflect the change and video playback continues. > > On the second seek I was seeking backwards. > both, pls.position and consumer.position seem to be moving on as > nothing happened. But the picture freezes. > After a while things go back to normal again and pls.position and > consumer.position as well as the multi output have jumped to the > position I wanted to seek to. > > Very weird behavior. > > Can you tell me, where that is coming from or how to fix it? > Are forgetting any important config options on the two decklinks in multi? > Do we need to set anything on the multi consumer itself, like the > ("rescale", "none") thing? > > Please advise, > > Markus > Sorry, but I am not available to help you with this now or in the near future. All I can suggest is the hints I have provided about those properties and to study them and the code some more. http://mltframework.org/doxygen/properties.html Something not listed there or on the multi consumer documentation (but is in the avformat consumer doc) is terminate_on_pause. This is set to 1 (true) by default. It means just like it sounds. As soon as you pause the producer, the consumer will automatically go into the stopped state. Avformat consumer uses this to know when to stop encoding for files. Decklink consumer ignores it. But you should definitely set that to zero on the mutli consumer in your case. Then, for seeking behavior and delay, take into consideration that each consumer has buffers including multi, but is it needed everywhere? Maybe you can set the decklink consumers to the least amount of buffering (0 or 1 or 2?) and leave the multi at its default of 25 frames. -- +-DRD-+ ------------------------------------------------------------------------------ How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Mlt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mlt-devel
