Stream reencoding...

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Atmapuri - 24 Feb 2008 09:08 GMT

Hi!

Is there some software to use for reencoding the Live
stream from a publishing point and push it back to another
publishing point?

Thanks!
Atmapuri

Reply to this Message

Neil Smith [MVP Digital Media] - 24 Feb 2008 18:56 GMT

>Is there some software to use for reencoding the Live
>stream from a publishing point and push it back to another
>publishing point?

You forgot to say why you want to do this or even what you want to
transcode to, so that doesn't help us much to help you.

The server itself doesn't do specific transcoding - though it can drop
frames and streams. I'd consider making an MBR with multiple stream
bitrates, then arrange to use lpp:// protocol to reference the first
publishing point containing the MBR content.

On the second publishing point, set a stream limit just above the
specific bitrate you want to send.

HTH
Cheers - Neil
------------------------------------------------
Digital Media MVP : 2004-2008
http://mvp.support.microsoft.com/mvpfaqs

Reply to this Message

Atmapuri - 25 Feb 2008 06:49 GMT

Hi!

I would like to save bandwidth. Upload 1Mbps stream
and reencode 2 or 3 MBR streams at different bitrates and
push them to their own publishing points. Like this:

Point1: 1Mbps
Pont2: 750, 500Kbps
Point3: 350, 200Kbps
Point4: 105Kbps.

I find it "shocking" that windows media server 2008
still does not support that <g> The latest 8 core servers
are made for something like that.

I event went to to WM SDK and try to find out how
to reencode a stream comming from an URL, but it appears
I would have to rip up the floor and redo all the plumming <g>

Thanks!
Atmapuri

>>Is there some software to use for reencoding the Live
>>stream from a publishing point and push it back to another
[quoted text clipped - 16 lines]
> Digital Media MVP : 2004-2008
> http://mvp.support.microsoft.com/mvpfaqs

Reply to this Message

TotalStream.net - 25 Feb 2008 16:30 GMT

Why have 4 publishing points? Do you really want to put 4 URLS on
your website?

Why not simply encode it using a multi-bit rate encoder?

> Hi!
>
[quoted text clipped - 27 lines]
> > The server itself doesn't do specific transcoding - though it can drop
> > frames and streams. I'd consider making an MBR with multiple stream

> > bitrates, then arrange to use lpp:// protocol to reference the first
> > publishing point containing the MBR content.
[quoted text clipped - 9 lines]
>
> - Show quoted text -

Reply to this Message

Atmapuri - 25 Feb 2008 18:39 GMT

Hi!

>Why have 4 publishing points? Do you really want to put 4 URLS on
>your website?

You can always present one link as the main one.

And its not just 4 URL's, It is 6, because you can use
WMContentBitrate for the MBR's to break it down further, for
those that like the content and want to fine tune for better quality.

The ability to adjust specifically to customers bandwidth is very
much appreciated. Most streaming companies also advice against
using MBR streams, because the automatic switching by the WMP
is not that automatic. Many times the stream gets to be played at
a lower quality as it should, or the switching and detection time is
excessively long.

>Why not simply encode it using a multi-bit rate encoder?

Because live MBR upload takes 3MBps and single stream upload
takes 1Mbps. I can get three times better stream quality, if I could
encode multiple MBR live streams on the server itself.

Thanks!
Atmapuri

On Feb 24, 10:49 pm, "Atmapuri" <janez.makov...@usa.net> wrote:

> Hi!
>
[quoted text clipped - 33 lines]
> > The server itself doesn't do specific transcoding - though it can drop
> > frames and streams. I'd consider making an MBR with multiple stream

> > bitrates, then arrange to use lpp:// protocol to reference the first
> > publishing point containing the MBR content.
[quoted text clipped - 9 lines]
>
> - Show quoted text -

Reply to this Message

Neil Smith [MVP Digital Media] - 25 Feb 2008 19:06 GMT

>The ability to adjust specifically to customers bandwidth is very
>much appreciated. Most streaming companies also advice against
>using MBR streams, because the automatic switching by the WMP
>is not that automatic. Many times the stream gets to be played at
>a lower quality as it should, or the switching and detection time is
>excessively long.

I've never heard that and frankly no reputable / knowledgeable
streaming company would recommend that bad advice, since it would
impact their ability to manage the streaming automatically.

>>Why not simply encode it using a multi-bit rate encoder?
>
>Because live MBR upload takes 3MBps and single stream upload
>takes 1Mbps. I can get three times better stream quality, if I could

I don't follow - you intend to upload 1MBps stream content and have it
transcoded *up* to 3Mbps ? What will that achieve ? The quality will
at best be slightly worse due to losses in the transcode step, and
will just increase the bitrate not provide any better quality.

>encode multiple MBR live streams on the server itself.

You can't (or shouldn't) though. The server is specifically set up to
shovel bits from disk to network interface as fast as possible.

It's not designed to be an encoder, which has very different hardware
requirements regardless of number of cores (most encoders use between
1-4 cores max).

Your server would spend all it's time in CPU bound operations
attempting realtime transcoding for each stream request, rather than
efficiently transferring pre-encoded bits out to the internet.

That's what MBR is desgned for. If users players always get the lowest
bitrate (which I doubt) what do you propose instead - that you offer
then alternate download links ?

If so, you might as well be using a web server to delivery the content
instead of the built in content negotiation. How would a user know
which stream to pick ? Think about your grandma here....

The reason some users have got the worst stream is (1) their bandwidth
really isn't enough to keep up with the delivery bitrate (and they may
*not know* what they have in order to select the best bitrate, hence
it's automatic), or (2) they have the player configured manually to a
lower bitrate or (3) it's not reporting it's available bitrate because
of Privacy selections, or it's a Mac media player, or it's a Pocket PC
(neither of which report their available bitrate to the media server)

HTH
Cheers - Neil
------------------------------------------------
Digital Media MVP : 2004-2008
http://mvp.support.microsoft.com/mvpfaqs

Reply to this Message

Atmapuri - 25 Feb 2008 19:32 GMT

Hi!

<I've never heard that and frankly no reputable / knowledgeable
<streaming company would recommend that bad advice, since it would
<impact their ability to manage the streaming automatically.

You have to become a customer first <G> And not of one, but many
companies.

> I don't follow - you intend to upload 1MBps stream content and have it
> transcoded *up* to 3Mbps ? What will that achieve ? The quality will
> at best be slightly worse due to losses in the transcode step, and
> will just increase the bitrate not provide any better quality.

:) You know very well what I meant. If you upstream 1Mbps,

and create MBR on the server you get: 1Mbps, 800Kbps, 600Kbs
etc... And the sum of that MBR would be 1+0.8+0.6+0.4+0.2+0.1 = 3.1Mbps
if you would want to push it to server from the encoder.

The desire is to push only 1Mbps and create the rest on the server.

> Your server would spend all it's time in CPU bound operations
> attempting realtime transcoding for each stream request, rather than
> efficiently transferring pre-encoded bits out to the internet.

That was true 8 years ago. That thinking is outdated.

Currently I am running 4 encoders encoding 2-3 MBR per stream at
2Mbps and down on the 8 core machine no problem 24/7. I would
need only quorter of that for the Live stream. Also, I have a fully
dedicated server for each Live streaming.

> That's what MBR is desgned for. If users players always get the lowest
> bitrate (which I doubt) what do you propose instead - that you offer
> then alternate download links ?

You can find alternate links on most sites, if you browse around.

Besides, that was not the issue here at all. The desire is to reduce the
upload
bandwidth requirement and encoder PC requirement and yet provide
multiple MBR streams at high bitrates. High speed encoding computer
and high speed uplink bandwidth are expensive and hard to find. The
server you only buy once.

> If so, you might as well be using a web server to delivery the content
> instead of the built in content negotiation. How would a user know
> which stream to pick ? Think about your grandma here....

She can always select the default link, which covers most users :)
(But you have a point that the default link must be obvious).

Thanks!
Atmapuri

Reply to this Message