On Tue, Sep 9, 2014 at 1:48 AM, Keith Johnson <ke...@xentrik.tv> wrote:
>
> Keith, I am not quite sure how to answer this. I do not really
> understand what you need and are asking for. It does not sound like
> there are many MLT applications that are close to what you need. With
> Shotcut or melt, you can record (capture and encode) from HDMI, SDI,
> and V4L. If you use FireWire cams, MLT can receive the stream through
> libavdevice as long as there is no stream discontinuity, but it can
> only then decode it and then do something else with it like view or
> encode to file. In other words, it does not provide direct capture to
> file of FireWire data streams like dvgrab does.
>
> Thanks for your reply, Dan. It looks like the best approach might be to
> use dvgrab for the capturing side of things, then a mixture of custom and
> existing MLT tools to do the rest. It doesn't matter if it's a bit of a
> cobble-together at this stage. Can MLT handle HDV clips captured by dvgrab,
> then?
>
Unfortunately, this is actually one of the few formats that I have found to
be hit-or-miss for seeking within MLT. It is a rather passe format now, and
it is very difficult to make format-specific improvements let alone seek
and sync improvements as that requires heavy regression testing. On the
other hand, I seem to recall I found that some HDV files I was testing
against had some data loss or corruption contributing to my problem. For
your app, it sounds like you just need non-seeking playback for live
preview followed by seeking-based processing during post. In that case, you
can transmux or transcode the HDV in post if needed.
> Essentially, the most important thing I want to do is to be able to create
> an app that play two files simultaneously in sync (while they are still
> being captured by dvgrab or whatever), and log points where we want to
> switch from one source to the other. That logged information can then be
> used to create a compiled video using existing tools.
>
Frame accurate sync between sources is not something MLT provides today.
Presumably, this is based upon a timecode (starting value or track)
embedded in the source. However, if all you need is to play - without
seeking - from 2 growing files with sync accurate to within a 100 ms or so
based simply on task startup timing, then it will be sufficient.
In order to play multiple inputs with python (or other high level language)
and SDL within the same process, you must use the composite transition to
compose them into one output view. You can use a custom mlt_profile to
define a resolution and aspect ratio that best accommodates that. That will
be a little heavy due to the image processing involved. If you want to do
something that has lower CPU overhead, then you will need to use C/C++ to
receive the MLT consumer-frame-show event with the frame object, and then
get the image data as YUV or RGB to paint it in your app GUI. And to do
that drawing efficiently you may need to use OpenGL or combine buffers
similar to composite transition to feed into an overlay (e.g. XVideo) API.
IOW, there is little middle ground. Probably best to use composite and SDL
in short term.
MLT can switch between sources and clips. Shotcut shows this can be
> done by letting you add live sources to a playlist alongside clips.
> However, there is no MLT app I know of that shows more than one device
> source in a multiview while simultaneously capturing let alone
> switching between them. Developing something for this will take a lot
> of time if you do not already know MLT.
>
> As long as we have some kind of methodology that gets the job done in a
> fashion to start with we've got 5 years of this contract to tinker with it
> and get it right. We did something similar last year, but were simply
> recording to SD cards in the cameras and then clipping this material up
> with existing tools (KDenLive, mainly). What I'm trying to do is find tools
> like dvgrab and MLT that might help us streamline the process.
>
> With that said, here is a python script that comes with MLT that
> provides a very simple web service that switches between two sources,
> outputting to a third:
> https://github.com/mltframework/mlt/blob/master/src/swig/python/switcher.py
>
> You can execute this to see what it does without DeckLink devices:
> ./switcher.py color:blue noise: sdl
> Then "curl localhost:8888/switch" to trigger it. It does not actually
> do a simple switch; rather, a friend needed it to reduce input 1 size
> by 20% revealing input 2 in the background along the left and bottom
> edges, and then to return input 1 to full size on the next switch.
>
> Sounds interesting. I just need to look at examples like this to see what
> can be done.
>
>
> I am afraid I will not be able to help you much with the project as
> this is just a part time hobby, and I am already so busy with Shotcut.
>
> Understood. I'm happy to do the donkey work myself, and it's great that
> there are open-source projects around which I can study.
>
>
> Do you know about DVswitch? http://dvswitch.alioth.debian.org/wiki/
> Alas, that appears to be a SD only solution.
>
> Also, from this list:
> http://www.opensourcebroadcast.com/category/directory/video-post-production
> Snowmix and Open Playout are 2 gstreamer-based projects worth considering.
>
> Again, interesting. These are all tools which might prove useful. As I
> said, it doesn't matter if I have to cobble together several different
> tools at this stage. We can worry about something more refined and better
> integrated later.
>
> Regards,
>
> Keith
>
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel