On Fri, Apr 19, 2013 at 8:09 PM, Dan Dennedy <d...@dennedy.org> wrote:
>
> Does it? MLT is not really intended to be used for capturing an IP
> stream and then relaying it.
>
>
Maybe I am assuming some functionality that isn't there, but since there
was, I believe I read, a wrapper around ffmpeg functionality, that so long
as the functionality existed in ffmpeg it could conceivably be used like
this.
>
> It depends; that's hard to answer, but doubtful that a novice can do it.
>
>
Ok gives me something to go off of, means I probably couldn't get it done
to quickly at least, which gives me a near term plan for this software.
> > Are producers following a defined API that might be documented somewhere
> > outside of code, or are they all hardcoded into the framework and not
> > following an API?
>
> The API is documented under API Reference in the Documentation section
> of the web site or just look at the source code of existing producers.
>
>
Thank you, I was looking at the code of the Decklink producer, will add in
the doxygen documentation as well, may clear up some questions I had.
> > I think I would rather switch my software to using mlt-framework as a
> > backend since it handles what I want and would be much more flexible,
> but I
> > would certainly have to be able to add in support for the ATEM hardware
> > encoders we are using in order to do this. Part of the issue however
> may be
>
> Often hardware encoders output an IP stream. Software does not need to
> specifically handle an ATEM hardware encoder unless perhaps it is PCI
> card-based encoder.
>
Correct, or rather in this case it is an IP stream from a USB device via
Blackmagic's proprietary server software, which is what the hold up on
Linux is I believe.
>
> > that there doesn't seem to be any support for them on Linux, only OS
> X(Where
> > I am developing for) and Windows.
> >
> > Alternatively, is it possible to route a MPEG-TS encapsulated stream with
> > h.264 and aac into the mlt since I already have that code written in
> python
>
> Yes, figure out how to play your stream with ffplay or avplay and then
> trying giving the same URL to melt. Is it simply TS/UDP?
>
>
Yes it is. The only thing that has caused me to have a hang up thus far,
and it could be my lack of knowledge on socket programming, is that in
python for some reason I haven't been able to create an identical socket to
the same destination, and I need to be able to send command strings through
the same socket, as well as send a string to actually identify the socket
as a receiver for data and have the data streamed over the socket.
Currently I am simply filtering out known strings to the console for
feedback, and writing everything else to disk and feeding that to ffmpeg
with a -re flag.
Reading that statement I realize it may not be clear so let me try to
explain the process for getting data from the encoder(Obviously simplified
slightly):
1. Create Socket to Server/Driver software
2. Send command strings to set up the encoder to the appropriate settings
and to start the encoder
3. Ideally create a new socket to receive data on, but right now I am using
the same socket
4. Send a command string on this new socket telling it that we are a
receiver for the data, at which point it will begin streaming the data over
the socket to us
5. Use the first socket to send command strings to stop or otherwise modify
the encoder as needed.
So really I should be using two different sockets. But I haven't been able
to get two identical sockets created in Python for some reason, I am new to
socket programming though so I don't count out my inexperience on this
topic as the reason, in fact it almost certainly is the reason:) But even
using two sockets, I have to send a command string before the data will be
sent to the receiving socket, and it has to be sent out via the receiving
socket, which has proven difficult to manage so that I could feed the
output in realtime to ffplay/vlc/whatever. On the other hand if I use the
same socket and simply filter the data coming in, it seems to work well
enough, and I have the data to do whatever I need to with.
> > and just use mlt for consumers (Network stream and disk in my case)?
> Then a
>
> Do you realize the avormat consumer that does this needs to do
> encoding (unless you are writing uncompressed to disk, which is
> technically not encoding)?
>
Was not aware of that. So there is no way to tell the avformat consumer to
copy the existing encoding? (ie. ffmpeg's -c:v or -vcodec copy filters?)
>
> It will help if you explain at a higher level what you want to do
> instead of perhaps what you think you want to do. :-) Does your ATEM
> have HDMI and SDI outputs?
>
In this case no. There are two pieces of hardware that qualify for what I
am doing, the Blackmagic Design h.264 Pro Recorder (Which is what I have)
and the ATEM TV Studio (Which I do not have but does act as a video mixer
as well with HDMI and SDI output). The h.264 Pro Recorder that I have is
merely an encoder, it does not have any video outputs whatsoever. What I
am trying to do is to take the network stream that is put out by the server
software installed as part of the 'driver' for this, and do two things to
it.
One is to write a copy to disk, as-is at least while it is being written,
but then ideally to be re-encapsulated into a .mp4 container upon
completion of the writing. This does require some re-ordering of how the
AAC data is muxed according to what little I know of it, as I do need to
pass a specific flag to ffmpeg to do the conversion(-absf adtstoasc) but
that is the extent of it, otherwise I end up with a nice clean .mp4 that
can be played anywhere I have thus far tested(Though I am primarily
concerned with VLC for this purpose).
The second step is to take the stream and stream it out to a Wowza server
online via rtsp live. I do this for bandwidth reasons, I have two other
campuses and we are looking to grow farther looking to connect to this
stream, and I don't have the bandwidth at our broadcasting campus to
maintain multiple copies of the stream. So they connect to the Wowza
server to watch the stream, and I can record on the Wowza server for yet
another copy of the file and a backup. And in the hopefully not to distant
future we will be moving to online streaming to the public as well, but
getting the rest of these goals complete needs to happen first.
The third goal is to provide a confidence monitor via dual 8" monitors I
have rackmounted above the two mac minis (redundancy of recordings and
stream, this is essentially a mission critical thing for us, it has to work
every time:) this is being used on. For right now I am just outputting the
entire desktop via HDMI, but the future goal is to utilize a BMD
mini-monitor or Decklink to output direct to SDI and use the desktop for
control only, thus an interest in the decklink capabilities of the
mlt-framework.
The fourth goal would be to do a basic cut on a keyframe edit to be able to
trim a file without reencoding for delivery to these campuses as well in as
time efficient manner as possible. They usually only want the 'message'
portion of the file which is about 30mins of a 1hr or more file. And
because of time crunches the smaller I make it the better, and re-encoding
it is out of the question, thus the using a hardware encoder for realtime
encoding in this case.
In the distant future the ability to use our Decklink capture cards and do
realtime encoding on the computer would be nice as well, but it is not
highest on my priority list at this time. But this is another reason the
decklink producer ability of the mlt-framework was interesting to me.
So for the most part what I would need I believe:
1. An ability to utilize avformat to restream the output to a network
destination without re-encoding
2. An ability to write the stream to disk without re-encoding(This can be
outside of mlt honestly, especially if I don't treat the ATEM as a mlt
producer)
3. An ability to take the stream and output to a confidence monitor window
on OS X, sdl consumer seems like it should work for this, audio is not an
absolute necessity at this time though would be nice in the future
What I would be looking for in the future:
4. The ability to take a file (producer) and re-encapsulate it with minimal
if any encoding to a .mp4 container
5. The ability to provide a confidence monitor via a BMD device over SDI
6. The ability to do an edit without re-encoding by splicing on a keyframe
(Perfect edits not needed for this particular task just something close)
7. The possible ability to use a standard decklink as a producer and
provide realtime encoding on the computer via mlt before sending the output
to the above destinations.
Thank you very much for your time!
Seablade
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
