Thanks very much for that information. I appreciate it.
Would it be correct to assume that the decoder outperforms VLC?
Is SSL an option between the hardware encoder/decoder pairs? Or have you associated the stream with something like JWPlayer on an SSL encrypted webpage?
I'm assuming there is no provision for adaptive streaming. It would be nice if the encoder could, at least, simultaneously output various bitrates for use by a player that supported adaptive streaming (JW).
Yes, Multicast (224.0.0.0 - 239.255.255.255) is typically only routable on a LAN. My application includes both LAN and Internet, which is why I asked.
Lastly, your impressive latency numbers suggested regional backbones. It would be interesting to see how that number changes NY-LA.
Thanks again.
--- In Avid-L2@yahoogroups.com, Ryan Johnson <phinalcut@...> wrote:
>
> Regarding the Teradek:
>
> VLC has it's own buffer settings that need to be adjusted to keep latency
> as low as possible ("Network Caching"). Depending upon the bitrate you're
> of the stream, you can only set this so low before the image breaks up.
> I've been testing with a ~2012 Mac Book Pro (2.6GHz i7), and a ~4Mb/s 720p
> stream averages about 33% CPU utilization.
>
> According to the manual, the encoder does support multicasting, but to my
> knowledge that's only useful if you're streaming on a private LAN that
> supports it. In my case, the stream has to travel over the public internet.
> On it's own, the encoder can support multiple simultaneous streams, but I'm
> not sure where that tops out. I only have the resources to test one at a
> time. (The default "Maximum Client Connections" is set to 10.)
>
> My only complaints so far: The built in web GUI is a bit sluggish, and
> seemed to lock up often when SSL was enabled (I am waiting to hear back
> from Teradek support on this.) With the web GUI locked up, there's no means
> of regaining control without power cycling the unit. This can be
> problematic if you don't have physical access to the hardware. Also,
> there's no telnet or ssh access as an alternative.
>
> Also, so far I have only tested using two local ISPs (separate networks,
> but geographically close.) I'll be testing a stream from LA to NY, where
> network latency averages 80ms. I'll report back later this week.
>
> -Ryan
>
>
> On Wed, May 29, 2013 at 7:02 AM, Edit B <bouke@...> wrote:
>
> > **
> >
> >
> > Nope, just indicating that any half decent encoder should have the option
> > to do both, as that is about the easiest part of the whole machine.
> >
> >
> > Bouke
> >
> > VideoToolShed
> > van Oldenbarneveltstraat 33
> > 6512 AS NIJMEGEN, the Netherlands
> > +31 24 3553311
> > ----- Original Message -----
> > From: blafarm
> > To: Avid-L2@yahoogroups.com
> > Sent: Wednesday, May 29, 2013 2:35 AM
> > Subject: [Avid-L2] Re: Semi OT: Screen sharing with clients
> >
> > Do you use Teradek too?
> >
> > --- In Avid-L2@yahoogroups.com, "Edit B" <bouke@> wrote:
> > >
> > > Biggest difference between multi and single is the behaviour of a reset.
> > > A single stream will require no restart of the stream at the viewers
> > site (and side for that matter).
> > > So in case of any trouble, it's way more user friendly if the end user
> > does not have to refresh their browser / restart the stream.
> > > For the encoder it does not really make a difference, the difficult part
> > there is how to encode, not the push or pull.
> > >
> > > Bouke
> > >
> > > VideoToolShed
> > > van Oldenbarneveltstraat 33
> > > 6512 AS NIJMEGEN, the Netherlands
> > > +31 24 3553311
> > > ----- Original Message -----
> > > From: blafarm
> > > To: Avid-L2@yahoogroups.com
> > > Sent: Tuesday, May 28, 2013 7:25 PM
> > > Subject: [Avid-L2] Re: Semi OT: Screen sharing with clients
> > >
> > >
> > >
> > > > Right now, I'm trying out an encoder/decoder pair from Teradek (the
> > 105,> 305 "Cube" series.)
> > >
> > > 250ms latency is impressive -- especially without using leased lines.
> > > And $3,000 is a very reasonable price considering the alternatives --
> > especially if you can effectively cut that price in half by just purchasing
> > the encoder.
> > >
> > > Out of curiosity, what don't you like about it?
> > >
> > > How dependent is smooth VLC performance on the host computing platform?
> > >
> > > Lastly, is multicast capability built-in to the encoder (allowing for
> > multiple VLC or decoder clients)?
> > >
> > > Thanks
> > >
> > > --- In Avid-L2@yahoogroups.com, Ryan Johnson <phinalcut@> wrote:
> > > >
> > > > I've been trying out lots of solutions for this application... It
> > seems the
> > > > real problem is latency. Video streams can look great when buffering
> > is an
> > > > option, but if real-time- or close to real-time- delivery is
> > important, it
> > > > becomes a real challenge.
> > > >
> > > > In our case, the editors and clients require as close to real-time
> > > > performance as possible, so any latency above 1/2 second is considered
> > > > unusable. Typically, the remote clients will speak to the editor by
> > > > telephone while watching video/audio streamed separately from the
> > output of
> > > > Avid or FCP.
> > > >
> > > > iChat (now "Messages") can be made to work using any DV device and an
> > old
> > > > computer. This solution works fairly well... Latency is generally
> > below 1/4
> > > > second, and it's certainly cheap to implement. However, video
> > resolution is
> > > > limited to 640 x 480 (at best) and the stream bandwidth is capped at 2
> > > > Mb/s. Also, the codec in use is best suited for static 'talking-head'
> > style
> > > > imagery, so if you're footage is handheld with lots of random motion,
> > the
> > > > image falls apart pretty quickly.
> > > >
> > > > Right now, I'm trying out an encoder/decoder pair from Teradek (the
> > 105,
> > > > 305 "Cube" series.) These boxes will stream 1080p23.98 at up to
> > 10Mb/s. You
> > > > can stream from one box to another, or stream directly to VLC player
> > using
> > > > RTSP.
> > > >
> > > > So far, the performance on these is pretty impressive. For whatever
> > reason,
> > > > 720p59.94 yields lower latency than 1080p, so I am cross-converting the
> > > > output of the Avid to suit. The stream bandwidth is capped at 4 Mb/s,
> > and
> > > > still looks good. There are a handful of encoder settings that can be
> > > > tweaked depending upon your application to get even lower latency, but
> > I am
> > > > getting about 1/4 second from our local ISP to another remote network.
> > > >
> > > > Of course, the encoder/decoder pair runs about $3K, so it's not the
> > > > cheapest solution out there.
> > > >
> > > > I'm pretty sure if somebody had the time, a equivalent solution (or
> > > > better?) could be built using a reasonably fast Linux box running
> > ffmpeg
> > > > and x264. Anybody?
> > > >
> > > >
> > > > -Ryan
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, May 28, 2013 at 1:43 AM, Christopher Pitbladdo <
> > > > avid@> wrote:
> > > >
> > > > > **
> > > > >
> > > > >
> > > > > No problem with the audio, as I recall (I only used it a handful of
> > times,
> > > > > due to the overall lag).
> > > > >
> > > > > ***
> > > > > Christopher Pitbladdo
> > > > > Digital Buddy
> > > > > 496 Ferry Road
> > > > > Edinburgh
> > > > > EH5 2DL
> > > > > Tel: 0131 552 553 0
> > > > > Mob: 07590 570 683
> > > > > www.digitalbuddy.co.uk
> > > > >
> > > > > Credit list available at www.digitalbuddy.co.uk/creditlist.pdf
> > > > >
> > > > > On 28 May 2013, at 00:04, "Tony Breuer" <tonybreuer@> wrote:
> > > > >
> > > > > > Thanks, Christopher. I forgot about sling box. The audio stayed in
> > sync
> > > > > though, right?
> > > > > >
> > > > > > --- In Avid-L2@yahoogroups.com, Christopher Pitbladdo <avid@>
> > wrote:
> > > > > > >
> > > > > > > I hooked a SlingBox up to my Avid output for the same reason...
> > In
> > > > > reality, the lag was a bit of an issue, typically they were around
> > five
> > > > > seconds behind me.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ***
> > > > > > > Christopher Pitbladdo
> > > > > > > Digital Buddy
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > [Non-text portions of this message have been removed]
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > [Non-text portions of this message have been removed]
> > > >
> > >
> > >
> > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>
Reply via web post | Reply to sender | Reply to group | Start a New Topic | Messages in this topic (29) |
No comments:
Post a Comment