On Sep 29, 2012 10:51 AM, "Markus Kienast" <email@example.com> wrote:
> Short, simple one:
> Why actually is it possible to have two consumers in "melt" without
> the use of "multi"? Is it using "multi" internally, or is there
> another way to hook up more than one consumer to the same producer?
melt uses multi consumer, also so does shotcut for sdi/hdmi preview, without all the problems you mention - but perhaps improved? Can you test shotcut's usage of multi consumer to see how it compares? If ok then you can learn from it's source - I will show you where.
> On Sat, Sep 29, 2012 at 6:55 PM, Dan Dennedy <firstname.lastname@example.org> wrote:
> > On Sat, Sep 29, 2012 at 7:43 AM, Markus Kienast <email@example.com> 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-+