On Sat, May 14, 2011 at 8:33 PM, Dan Dennedy <d...@dennedy.org> wrote: > On Fri, May 13, 2011 at 8:17 AM, stefan <ste...@webformat.at> wrote: >> hi there, >> i am currently trying to capture the stream from the Linux Wochen Linz >> with melt and pipe it out through our Decklink sdi card.. >> >> unfortunatly melt is not very good at capturing network streams, > > This is a known current limitation particularly when you need both > audio and video. A company recently contracted me to address this > shortcoming - well, at least to about the same capability of > libavformat/ffplay. That should be ready in about a month.
looking forward to that! but i have to tell that capturing the stream worked quite well on day2 and day3. might be that we had network issues. > >> whenever there is a lag on the network it just outputs white and > > A recent change in avformat makes mid-stream errors repeat the last > successfully decoded image instead of sending white. > >> doesn't try to reconnect. > > hmm, I will have to keep this in mind when working on it. I am not > certain it is something entirely under my control with libavformat. > >> if it connects it works pretty well as long as the stream is not >> interrupted.. > > The reason it does kind of work today is because of libavformat, but > the bad part is that mlt basically opens the stream twice: once for > video and another for audio. This is why it fails with pipe inputs, in > particular, and does not have good sync with some protocols. This is > the problem that I am attempting to address. that explains why icecast saw two connections for each melt client > > Can you test and comment on how well ffplay handles the stream interruptions? liwoli is over now, but we will do more streaming and testing the within the next weeks > >> what i've tried now is start a virtual xserver with xvfb >> Xvfb :1 -screen 0 640x480x24 -fbdir /var/tmp/ >> >> start vlc within the virtual screen >> DISPLAY=:1.0 vlc --no-x11-shm --vout x11 --aout jack --volume 1024 >> --fullscreen -R http://87.106.167.44:443/stream.ogg >> >> and then grab the virtual screen with melt and output it to the decklink >> card: >> /usr/bin/melt -profile dv_pal x11grab::1.0+0,0?width:640\&height:480 >> -consumer decklink: >> >> >> this works perfect for the video, vlc's .R option makes sure the >> player reconnects when it got disconnected. >> >> the only problem i have now is that i can't find a way to get the >> audio working in melt. >> i've tried every possible combination, the alsa and the jack options, >> but it seems that melt doesn't allow for jack audio input. routing the > > libavdevice supports alsa or jack, and that should work as long as you > do not try to use it on the same producer as x11grab. IOW, make audio > input a separate producer and on a separate track as seen in FAQ. > However, my version of ffmpeg is not currently built with jack support > to test that right now. Alternatively, you can use the mlt jackrack > filter. It can be tricky in that you need some non-bogus audio source > because filters can not modify a frame with no audio such as that > created with x11grab! > > melt -verbose -profile dv_pal alsa:default -attach jackrack > in_1=Qtractor:Master/out_1 in_2=Qtractor:Master/out_2 out_1=null > out_2=null -track x11grab:?width:640\&height:480 -consumer decklink > > In that example, I used alsa:default to generate audio from a muted > input line, but you could also use a long silent wav file. Notice that > I am connecting Mlt's JACK output ports to a dummy JACK client to > prevent any of its audio sources from going into the output (e.g. if I > used a random video or audio clip as the base audio signal). The > decklink consumer must have 48 KHz audio, so you must run jackd at > 48000! i will try that asap. i had jack running with 44 KHz, maybe that was the problem. i might also have attached the jackrack filter to the wrong track. thank you for the tips! > > -- > +-DRD-+ > ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Mlt-devel mailing list Mlt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mlt-devel
