[PLUG-AV] Fwd: Re: Dumping to screen gets slower, and slower

[Euan de Kock]

I am thinking how to route the A/V on the looped file playback.

The dvsource commands do not have a dvsink-command equivalent, so we are
limited to a file or device (firewire or v4l) as a source.

However, it is possible to specify /dev/stdin as our file, so...

while true
 do
  cat flowers.dv
 done | gst-launch -q fdsrc ! dvdemux name=dmx dmx.audio ! queue !
alsasink dmx.video ! queue ! fdsink | dvsource-file -h localhost -p
1234 /dev/stdin

Will stream a dv format video "flowers.dv" continuously through the
gstreamer system, demuxing the audio and video into separate streams. 

The audio gets sent out to the alsa device, while the video stream gets
sent into our dvsource-filename command.

I have run this for half an hour and have not seen any out of sync
errors so it looks feasible. (I am running on a 6-core AMD Phenom
system, so YMMV)

Note we do not attempt to loop from the dvsource-filename as we are
using stdin as the source which is non-rewindable.

The audio out can be sent into our mixer, and looped back into our alsa
input which we are already capturing as our normal microphone sources.

As an extra aside, we can easily extend the command above to loop over
several videos eg replace the single line "cat flowers.dv" with several
cat commands

cat flowers.dv
cat trees.dv
cat penguins.dv

while "gst-launch videotestsrc ! ximagesink" will generate a funky 70's
style test pattern.

We really do need to invest some time to get gstreamer loaded. (The
good, the bad and the ugly). We can then also look at embedding the plug
logo over our stream using a similar method.

As regards the delays we are seeing, I'd suggest we try a few of the
following:

Different playback clients - gstreamer, vlc, etc.
Faster client machine
Multicasting the stream (Client has to run at the stream speed or skip
frames)

I think the multicasting is something we are going to end up needing as
we get more attached devices all wanting to monitor the stream, multiple
streams don't only cost in bandwidth, they also consume CPU/RAM etc and
with a multicast stream everyone sees the same thing at the same time.

With gstreamer, we can also implement a time overlay on the video stream
as per your other request, but the command line gets a bit more complex
as we need to decode the video to a raw format to add any overlays and
then recode back to dv format (This will also apply to our logo
embedding).

Regards,

Euan.


On Thu, 2011-09-15 at 11:49 +0800, James Bromberger wrote:

> Response from Ben (dvswitch-devel), FYI.
> 
> -------- Original Message -------- 
>                           Subject: 
> Re: Dumping to screen gets slower,
> and slower
>                              Date: 
> Thu, 15 Sep 2011 04:46:11 +0100
>                              From: 
> Ben Hutchings <ben at decadent.org.uk>
>                          Reply-To: 
> dvswitch development discussions
> <dvswitch-devel at lists.alioth.debian.org>
>                                To: 
> dvswitch-devel at lists.alioth.debian.org
> 
> 
> 
> On Thu, 2011-09-15 at 11:17 +0800, James Bromberger wrote:
> > Hello all,
> > 
> > 
> > I was using dvsink-command -h $host -p $port -- mplayer - the other
> > night during a PLUG presentation (www.plug.org.au) in order to show
> > the video stream to the room we were recording in. It started off that
> > the delay between what we were mixing on dvswitch and what we were
> > seeing from this dvsink command was around .2 of a second. As the hour
> > progressed, this became further and further lagged, to a few seconds.
> > 
> > Anyone got any better solutions or fixes for this? Would it be the
> > speed of the host showing the video that could be an issue. or do
> > others see this.  Is mplayer recommended over VLC (or something else)
> > to render the video?
> 
> I've not seen this, but I think it could happen if the audio clock runs
> slow on the playback machine (say, 47.9 kHz when it should be 48 kHz) or
> fast on the audio source, or both.  If you disabled audio playback
> completely then it could happen if the system clock runs slow on the
> playback machine.
> 
> > If I have a video file (with audio) and I want to route the audio out
> > to a mixing desk and send the video to the dvswitch app - would you
> > recommend a gstreamer command line or something else?
> 
> Sorry, I haven't done much with gstreamer yet.
> 
> Note that by default dvsource-alsa delays audio by 0.2 seconds to match
> the typical processing delay in a video camera.  In this case there
> wouldn't be any such processing delay for the video, so you would need
> to override the audio delay to keep them in synch.
> 
> > When playing out a dvsource-file, is it feasible to get a verbose
> > option to tell you how many seconds through and how many seconds
> > remain on a file being sent to the dvswitch console?
> 
> No, it's not.  It probably wouldn't be that hard for you to add.
> 
> > That way, when plaing an into video, I can see when I have 1 second
> > left of intro and can then switch to the live camera(s) before the
> > file ends (and in combination with audio routing above, can have intro
> > music keep being heard as I bring in room audio and room video).
> > Alternatively, is this meta data available to overlay (or beside) a
> > video source window in DVswitch?
> 
> The network protocol doesn't provide any such metadata.
> 
> > When a source disconnects, can we remove the slot it occupies in the
> > gallery? 
> 
> Currently, no, it's assumed that you'll try to reconnect the source.  I
> realise this assumption is wrong when you use a non-looping file source!
> 
> Ben.
> 
> -- 
> Ben Hutchings
> All extremists should be taken out and shot.
> 
> _______________________________________________
> AV mailing list
> AV at plug.org.au
> http://lists.plug.org.au/mailman/listinfo/av


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plug.org.au/pipermail/av/attachments/20110915/2e430d64/attachment.html>