Well, I've been doing my reading up, and it looks like I can do all the
post-processing we need to do with Melt. A command line tool which can be
scripted like this is exactly what we need to clip up and assemble the videos
for our clients, and we only need to add authoring tools like DVD-author (which
we're already using with the manually created clips).
I've tested capturing two HDV streams at the same time with dvgrab and it's
fine - left cameras running for 20 hours and no glitches. Only thing I'm stuck
on is creating a composite video file with 1/2 resolution side-by-side view of
the two files. I've looked at the composite transition in MLT, but it doesn't
seem to work the way I thought it would, even wth the examples given, so I must
be missing something. Seems to produce full-frame video regardless of settings.
Maybe I'll just develop a simple transition plugin in C to do this. Affine
seems to be another option, but there is no documentation of parameters for
this and many of the other plugins, although some deep study of the C source in
conjunction with implementation in kdenlive might help here.
On a more general note, it would be great if one of the higher-level edit
packages (kdenlive or shotcut) could export an .XML MLT file for a transition
from the timeline. This would mean effects and transition could be put together
and tested in a practical UI and the resulting XML used with a script. Maybe
they can already do this - I can see I'll have to do some more digging around,
but thanks again for a great set of tools, and I hope I might be able to
contribute with some ideas and plugins of my own.
Keith
_____
From: Dan Dennedy [mailto:d...@dennedy.org]
To: Keith Johnson [mailto:ke...@xentrik.tv]
Cc: mlt-devel [mailto:mlt-devel@lists.sourceforge.net]
Sent: Tue, 09 Sep 2014 18:05:32 +0000
Subject: Re: [Mlt-devel] Help for Newbie, please!
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
------------------------------------------------------------------------------
Slashdot TV. Video for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
