Nabble - Red5 - English

SoundMixer.computeSpectrum rtmp livestream

2009-11-27T08:27:27Z

Hello,

I'm new to this list and want to thank all developers of red5 for the
great software.
I'm devloping my first project with flex and red5 at the moment and try
to use SoundMixer.computeSpectrum on a rtmp live stream. When I check
the byteArray which is filled by computeSpectrum, it only contains zero
values.
If I use computeSpectrum with a rtmp file-stream, stored in the
"streams" directory of the red5-server, everything works perfect. The
only thing I change is the name of the stream in the
netstream.play()-method.
Does anybody have an idea why computeSpectrum is not working with the
live stream?

Thank you,
John

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

Scope problem

2009-11-27T08:18:11Z

Hi,
i'm having some problems with scope's.
In the server side i create a new scope like "Paul Gregoire's Blog" and then joined the clients.

In my case i make join(client,"myapp/room/n")

In my logs the join returns true, and when i get the scope by resolveScope(appScope,"room/n"), all works fine. Then i get connections or clients from this scope but i get nothing.

Someone know's what's happen's?

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

red5 0.9.0rc1 .deb installation file

2009-11-27T06:31:16Z

Is a .deb file available for this, i see people talking about it on list , but can't find it via the red5 pages or svn.

is it even released, Sure i can use the zip, but my build process currently uses .deb's!! :-(

hope you can point in the right direction.

Cheers,
tox

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

How to catch events like one video is over and another is started?

2009-11-27T04:42:06Z

Hello every1!
How to catch events like one video is over and another is started on the serverside? I mean, i need to redefine some Shared Object value and let my flash player to know, that new video is started. How i can done this? In FMS it was pretty easy to done, but i am not very familiar with Java :(

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

Video/Audio Subscribe

2009-11-27T02:32:21Z

Hello Users,

I have been using Red5 since v6. I am gr8ful to its developers. Recently am doing some new experiments.

In a scenario, there three clients and a server. All connected via red5 server. Server wants to apply video download/play restriction on some clients (may be on demand from client).

Some examples are, apply watermark on all video being streamed or allow video to be played at certain speed only. Is it possible? How?

Thanking You all!!

unequal delay on audio and video

2009-11-27T01:24:35Z

That's not that different from what I do:
In Xuggle I have a timebase for the audio stream of 1/90000; the dts start at zero (of course) and are incremented by 90000*(576/22050), which is the correct frame duration in ticks of timebase, for every packet. Let's leave audio alone; with this configuration audio dies after a while (8 minutes with a buffer of one second on the player); that is, something is still streaming, but I can't hear anything.
If that dts interval is correct I don't know what else I am doing wrong.

-----Messaggio originale-----
Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Andy Shaules
Inviato: venerdì 27 novembre 2009 8.54
A: red5@...
Oggetto: Re: [Red5] R: R: R: unequal delay on audio and video

//Assume you have a class field name 'lastTimecode' of type double.

//read the header.
MP3Header header=new MP3Header(hdr);

//get the span
double timeSpan=header.frameDuration();

//set the timestamp at last audioFrame start + last audioFrame duration.
audio.setTimestamp((int) lastTimecode);

//Adjust to end of frame for next one.
lastTimecode+=timeSpan;

Thats it. There is no mystery about it. This will stream for hours and hours
and be in sync.

Stamp the latest video frame you get with the latest audio timestamp you
have.

----- Original Message -----
From: Daniele Bettella
To: red5@...
Sent: Thursday, November 26, 2009 11:23 PM
Subject: [Red5] R: R: R: unequal delay on audio and video

I've checked a thing, but I'm not sure it makes sense..
Let's say I stream audio only with timestamps calculated from mp3header.
I then check the application log (which takes the time of every post) and I
get something like this:
- at log time zero I send rtmp packet with timestamp zero (just
shifted the times)
- at log time 19578 (that is, 19.5 seconds after the first packet)
I send packet with timestamp 20000
- at log time 79125 I send timestamp 80000
- at log time 158483 I send timestamp 160000 (the audio probably
already died by now)

Is this a good way of telling whether timestamps are correct or not?

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di
Andy Shaules
Inviato: giovedì 26 novembre 2009 8.22
A: red5@...
Oggetto: Re: [Red5] R: R: unequal delay on audio and video

10000 samples/ second * 100 bits/ sample = 1000000 bits /second

1000000 bits/second * 1 byte / 8 bits = 125000 bytes per second

But forget all of that!

If you count the frame durations calculated by the mp3 header then you
should be fine. If its not fine, then you are doing something else not
right.

Here is my situation. I get 3 mp3 frames for every one h264 frame, yet I can
still take the calculated values from the mp3 header add all of them up, and
my stream will still be synchronized after 24 hours.

Something you are doing is not right. Yes the duration will calculate to a
double precision value and the timestamp will take an integer, but if you
keep the double precision around for the whole process, you will be good to
go.

If fact, if your client is running windows, windows will adjust the system
clock to fill those micro gaps, just as FLV video framerate is determined by
the audio sample counts.

----- Original Message -----
From: Daniele Bettella
To: red5@...
Sent: Wednesday, November 25, 2009 10:58 PM
Subject: [Red5] R: R: unequal delay on audio and video

I thank you very much for helping me; let's see if I had this right:
Let's say I have 100 byte per packet, at 100 bit per sample, with a sample
rate of 10000 samples per second; this means I have 8 samples per packet and
so 8/10000 seconds per packet. and this is my timestamp interval.
Is this correct?

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di
Andy Shaules
Inviato: mercoledì 25 novembre 2009 18.57
A: red5@...
Oggetto: Re: [Red5] R: unequal delay on audio and video

wrong,

audio duration is an equation without guesses. that is your only error.

You have sample rate, you have bits per sample, you have bits per second.
You can take that info and calulate to the 100 nano-second accuracy if you
need too.

Now, caviot! FLV frame rate is determined by audio sample count per frame,
not time of frame.

If you count duration correctly you will not have lag problems.

I do it with both mp3 and aac based on number of bytes in the buffer and
sample rate/bits per sample. Works perfect every time.

----- Original Message -----
From: Daniele Bettella
To: red5@...
Sent: Wednesday, November 25, 2009 1:06 AM
Subject: [Red5] R: unequal delay on audio and video

I need help on understanding how this works..
In the current solution I set the interval between audio timestamps by
guess,
It is 2080 on a stream timebase of 1/90000.
This way audio and video are in sync, at least for a while; there are some
other problems, but with this not being a correct solution I don't bother.

So what if I calculate the audio frame duration? It comes out at 26ish
msecs; I set the timestamp interval based on the stream timebase. The logs
say my audio rtmp packets are correctly spaced at 26 msecs, but the end
result is audio and video not in sync and lagging.
With my guess of 2080 the rtmp audio packets are every 23 msecs, but this
doesn't make much sense.

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di
Daniele Bettella
Inviato: martedì 24 novembre 2009 18.11
A: red5@...
Oggetto: [Red5] R: R: unequal delay on audio and video

Cancel the previous message, I forgot to enable the interleaving of packets.
Apparently I still need to understand how to correlate the stream timebase
and the audio frame duration.

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di
Daniele Bettella
Inviato: martedì 24 novembre 2009 17.58
A: red5@...
Oggetto: [Red5] R: unequal delay on audio and video

Ok, I was able to calculate my timestamps based on the code in the mp3
header; it all works fine for the first minutes, but after a while I begin
to notice a little delay on audio. I think this could be because the frame
duration is calculated as
576 / (getSampleRate() * 0.001)
Inevitably this is not an integer, but the set dts requires one.
So whatever I do (and based on the stream timebase, which is 1/90000) I'll
need to transform a double into a long and hence introduce error.
And my audio will not be in sync.

I suppose there's a solution to this, but what is it?

Daniele

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di
Andy Shaules
Inviato: lunedì 23 novembre 2009 17.14
A: red5@...
Oggetto: Re: [Red5] unequal delay on audio and video

You should base your timestamps on the mp3 frame durations, not guesses.

Look at the MP3Header class in the red5.io.mp3 package. Use the class to
determine each duration.
----- Original Message -----
From: Daniele Bettella
To: red5@...
Sent: Monday, November 23, 2009 3:05 AM
Subject: [Red5] unequal delay on audio and video

I'm using Xuggle to publish an H264/mp3 live stream on red5. Audio and video
are already encoded when they get to xuggle, so I do no transcoding, I just
pass the packets on to red5.
Now, if I stream video only I have a small delay, around 0.3 secs, I don't
know where it comes from, but it's either in xuggle/red5 or the player
(which has a buffer of zero, btw). I could live with this delay (well, sort
of), problem is, when I stream audio too this has a delay of little less
than one second, resulting in audio and video not in sync.
So came the idea to force interleaving of packets (that is, using
container.writePacket(packet, true)). This meant adjusting dsts by hand,
since my packets had no timestamps to start with. This brought two problems:

1) I know how to adjust timestamps on video packets (since I have one
frame per packet), but I had to guess on audio packets;
2) My best guess resulted in audio and video in sync (at least for the
first minutes), but with a delay of one second which grew when insufficient
bandwidths came out (streaming locally). Which is no good at all.

What I'd really like would be to minimize and balance the delays when non
interleaving packets in xuggle, because that's the way I have had the best
results.

Also to note: if I stream video only at 15fps instead of 30fps the delay
grows from .3 to .8 seconds (which, as a side effect, make audio and video
in sync if I add it).

I'd really love to figure out where these delays come out from.
Thanks in advance.

Daniele

P.S.
I'm sending this on osflash for now, since my membership on the official
group is pending

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

Re: R: R: R: unequal delay on audio and video

2009-11-26T23:53:30Z

//Assume you have a class field name 'lastTimecode' of type double.

//read the header.
MP3Header header=new MP3Header(hdr);

//get the span
double timeSpan=header.frameDuration();

//set the timestamp at last audioFrame start + last audioFrame duration.
audio.setTimestamp((int) lastTimecode);

//Adjust to end of frame for next one.
lastTimecode+=timeSpan;

Thats it. There is no mystery about it. This will stream for hours and hours
and be in sync.

Stamp the latest video frame you get with the latest audio timestamp you
have.

----- Original Message -----
From: Daniele Bettella
To: red5@...
Sent: Thursday, November 26, 2009 11:23 PM
Subject: [Red5] R: R: R: unequal delay on audio and video

I've checked a thing, but I'm not sure it makes sense..
Let's say I stream audio only with timestamps calculated from mp3header.
I then check the application log (which takes the time of every post) and I
get something like this:
- at log time zero I send rtmp packet with timestamp zero (just
shifted the times)
- at log time 19578 (that is, 19.5 seconds after the first packet)
I send packet with timestamp 20000
- at log time 79125 I send timestamp 80000
- at log time 158483 I send timestamp 160000 (the audio probably
already died by now)

Is this a good way of telling whether timestamps are correct or not?

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di
Andy Shaules
Inviato: giovedì 26 novembre 2009 8.22
A: red5@...
Oggetto: Re: [Red5] R: R: unequal delay on audio and video

10000 samples/ second * 100 bits/ sample = 1000000 bits /second

1000000 bits/second * 1 byte / 8 bits = 125000 bytes per second

But forget all of that!

If you count the frame durations calculated by the mp3 header then you
should be fine. If its not fine, then you are doing something else not
right.

Here is my situation. I get 3 mp3 frames for every one h264 frame, yet I can
still take the calculated values from the mp3 header add all of them up, and
my stream will still be synchronized after 24 hours.

Something you are doing is not right. Yes the duration will calculate to a
double precision value and the timestamp will take an integer, but if you
keep the double precision around for the whole process, you will be good to
go.

If fact, if your client is running windows, windows will adjust the system
clock to fill those micro gaps, just as FLV video framerate is determined by
the audio sample counts.

----- Original Message -----
From: Daniele Bettella
To: red5@...
Sent: Wednesday, November 25, 2009 10:58 PM
Subject: [Red5] R: R: unequal delay on audio and video

I thank you very much for helping me; let's see if I had this right:
Let's say I have 100 byte per packet, at 100 bit per sample, with a sample
rate of 10000 samples per second; this means I have 8 samples per packet and
so 8/10000 seconds per packet. and this is my timestamp interval.
Is this correct?

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di
Andy Shaules
Inviato: mercoledì 25 novembre 2009 18.57
A: red5@...
Oggetto: Re: [Red5] R: unequal delay on audio and video

wrong,

audio duration is an equation without guesses. that is your only error.

You have sample rate, you have bits per sample, you have bits per second.
You can take that info and calulate to the 100 nano-second accuracy if you
need too.

Now, caviot! FLV frame rate is determined by audio sample count per frame,
not time of frame.

If you count duration correctly you will not have lag problems.

I do it with both mp3 and aac based on number of bytes in the buffer and
sample rate/bits per sample. Works perfect every time.

----- Original Message -----
From: Daniele Bettella
To: red5@...
Sent: Wednesday, November 25, 2009 1:06 AM
Subject: [Red5] R: unequal delay on audio and video

I need help on understanding how this works..
In the current solution I set the interval between audio timestamps by
guess,
It is 2080 on a stream timebase of 1/90000.
This way audio and video are in sync, at least for a while; there are some
other problems, but with this not being a correct solution I don't bother.

So what if I calculate the audio frame duration? It comes out at 26ish
msecs; I set the timestamp interval based on the stream timebase. The logs
say my audio rtmp packets are correctly spaced at 26 msecs, but the end
result is audio and video not in sync and lagging.
With my guess of 2080 the rtmp audio packets are every 23 msecs, but this
doesn't make much sense.

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di
Daniele Bettella
Inviato: martedì 24 novembre 2009 18.11
A: red5@...
Oggetto: [Red5] R: R: unequal delay on audio and video

Cancel the previous message, I forgot to enable the interleaving of packets.
Apparently I still need to understand how to correlate the stream timebase
and the audio frame duration.

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di
Daniele Bettella
Inviato: martedì 24 novembre 2009 17.58
A: red5@...
Oggetto: [Red5] R: unequal delay on audio and video

Ok, I was able to calculate my timestamps based on the code in the mp3
header; it all works fine for the first minutes, but after a while I begin
to notice a little delay on audio. I think this could be because the frame
duration is calculated as
576 / (getSampleRate() * 0.001)
Inevitably this is not an integer, but the set dts requires one.
So whatever I do (and based on the stream timebase, which is 1/90000) I'll
need to transform a double into a long and hence introduce error.
And my audio will not be in sync.

I suppose there's a solution to this, but what is it?

Daniele

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di
Andy Shaules
Inviato: lunedì 23 novembre 2009 17.14
A: red5@...
Oggetto: Re: [Red5] unequal delay on audio and video

You should base your timestamps on the mp3 frame durations, not guesses.

Look at the MP3Header class in the red5.io.mp3 package. Use the class to
determine each duration.
----- Original Message -----
From: Daniele Bettella
To: red5@...
Sent: Monday, November 23, 2009 3:05 AM
Subject: [Red5] unequal delay on audio and video

I'm using Xuggle to publish an H264/mp3 live stream on red5. Audio and video
are already encoded when they get to xuggle, so I do no transcoding, I just
pass the packets on to red5.
Now, if I stream video only I have a small delay, around 0.3 secs, I don't
know where it comes from, but it's either in xuggle/red5 or the player
(which has a buffer of zero, btw). I could live with this delay (well, sort
of), problem is, when I stream audio too this has a delay of little less
than one second, resulting in audio and video not in sync.
So came the idea to force interleaving of packets (that is, using
container.writePacket(packet, true)). This meant adjusting dsts by hand,
since my packets had no timestamps to start with. This brought two problems:

1) I know how to adjust timestamps on video packets (since I have one
frame per packet), but I had to guess on audio packets;
2) My best guess resulted in audio and video in sync (at least for the
first minutes), but with a delay of one second which grew when insufficient
bandwidths came out (streaming locally). Which is no good at all.

What I'd really like would be to minimize and balance the delays when non
interleaving packets in xuggle, because that's the way I have had the best
results.

Also to note: if I stream video only at 15fps instead of 30fps the delay
grows from .3 to .8 seconds (which, as a side effect, make audio and video
in sync if I add it).

I'd really love to figure out where these delays come out from.
Thanks in advance.

Daniele

P.S.
I'm sending this on osflash for now, since my membership on the official
group is pending

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

R: R: R: unequal delay on audio and video

2009-11-26T23:23:14Z

I’ve checked a thing, but I’m not sure it makes sense..

Let’s say I stream audio only with timestamps calculated from mp3header.

I then check the application log (which takes the time of every post) and I get something like this:

- at log time zero I send rtmp packet with timestamp zero (just shifted the times)

- at log time 19578 (that is, 19.5 seconds after the first packet) I send packet with timestamp 20000

- at log time 79125 I send timestamp 80000

- at log time 158483 I send timestamp 160000 (the audio probably already died by now)

Is this a good way of telling whether timestamps are correct or not?

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Andy Shaules
Inviato: giovedì 26 novembre 2009 8.22
A: red5@...
Oggetto: Re: [Red5] R: R: unequal delay on audio and video

10000 samples/ second * 100 bits/ sample = 1000000 bits /second

1000000 bits/second * 1 byte / 8 bits = 125000 bytes per second

But forget all of that!

If you count the frame durations calculated by the mp3 header then you should be fine. If its not fine, then you are doing something else not right.

Here is my situation. I get 3 mp3 frames for every one h264 frame, yet I can still take the calculated values from the mp3 header add all of them up, and my stream will still be synchronized after 24 hours.

Something you are doing is not right. Yes the duration will calculate to a double precision value and the timestamp will take an integer, but if you keep the double precision around for the whole process, you will be good to go.

If fact, if your client is running windows, windows will adjust the system clock to fill those micro gaps, just as FLV video framerate is determined by the audio sample counts.

----- Original Message -----

From: daniele.bettella@...

To: red5@...

Sent: Wednesday, November 25, 2009 10:58 PM

Subject: [Red5] R: R: unequal delay on audio and video

I thank you very much for helping me; let’s see if I had this right:

Let’s say I have 100 byte per packet, at 100 bit per sample, with a sample rate of 10000 samples per second; this means I have 8 samples per packet and so 8/10000 seconds per packet… and this is my timestamp interval.

Is this correct?

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Andy Shaules
Inviato: mercoledì 25 novembre 2009 18.57
A: red5@...
Oggetto: Re: [Red5] R: unequal delay on audio and video

wrong,

audio duration is an equation without guesses. that is your only error.

You have sample rate, you have bits per sample, you have bits per second. You can take that info and calulate to the 100 nano-second accuracy if you need too.

Now, caviot! FLV frame rate is determined by audio sample count per frame, not time of frame.

If you count duration correctly you will not have lag problems.

I do it with both mp3 and aac based on number of bytes in the buffer and sample rate/bits per sample. Works perfect every time.
----- Original Message -----

From: daniele.bettella@...

To: red5@...

Sent: Wednesday, November 25, 2009 1:06 AM

Subject: [Red5] R: unequal delay on audio and video

I need help on understanding how this works..

In the current solution I set the interval between audio timestamps by guess,

It is 2080 on a stream timebase of 1/90000.

This way audio and video are in sync, at least for a while; there are some other problems, but with this not being a correct solution I don’t bother.

So what if I calculate the audio frame duration? It comes out at 26ish msecs; I set the timestamp interval based on the stream timebase. The logs say my audio rtmp packets are correctly spaced at 26 msecs, but the end result is audio and video not in sync and lagging.

With my guess of 2080 the rtmp audio packets are every 23 msecs, but this doesn’t make much sense…

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Daniele Bettella
Inviato: martedì 24 novembre 2009 18.11
A: red5@...
Oggetto: [Red5] R: R: unequal delay on audio and video

Cancel the previous message, I forgot to enable the interleaving of packets…

Apparently I still need to understand how to correlate the stream timebase and the audio frame duration…

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Daniele Bettella
Inviato: martedì 24 novembre 2009 17.58
A: red5@...
Oggetto: [Red5] R: unequal delay on audio and video
Ok, I was able to calculate my timestamps based on the code in the mp3 header; it all works fine for the first minutes, but after a while I begin to notice a little delay on audio. I think this could be because the frame duration is calculated as 
576 / (getSampleRate() * 0.001)
Inevitably this is not an integer, but the set dts requires one.
So whatever I do (and based on the stream timebase, which is 1/90000) I’ll need to transform a double into a long and hence introduce error…
And my audio will not be in sync.
 
I suppose there’s a solution to this, but what is it?
 
Daniele
Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Andy Shaules
Inviato: lunedì 23 novembre 2009 17.14
A: red5@...
Oggetto: Re: [Red5] unequal delay on audio and video

You should base your timestamps on the mp3 frame durations, not guesses.

Look at the MP3Header class in the red5.io.mp3 package. Use the class to determine each duration.

----- Original Message -----

From: daniele.bettella@...

To: red5@...

Sent: Monday, November 23, 2009 3:05 AM

Subject: [Red5] unequal delay on audio and video

I’m using Xuggle to publish an H264/mp3 live stream on red5. Audio and video are already encoded when they get to xuggle, so I do no transcoding, I just pass the packets on to red5.

Now, if I stream video only I have a small delay, around 0.3 secs, I don’t know where it comes from, but it’s either in xuggle/red5 or the player (which has a buffer of zero, btw). I could live with this delay (well, sort of), problem is, when I stream audio too this has a delay of little less than one second, resulting in audio and video not in sync.

So came the idea to force interleaving of packets (that is, using container.writePacket(packet, true)). This meant adjusting dsts by hand, since my packets had no timestamps to start with. This brought two problems:

1) I know how to adjust timestamps on video packets (since I have one frame per packet), but I had to guess on audio packets;

2) My best guess resulted in audio and video in sync (at least for the first minutes), but with a delay of one second which grew when insufficient bandwidths came out (streaming locally). Which is no good at all.

What I’d really like would be to minimize and balance the delays when non interleaving packets in xuggle, because that’s the way I have had the best results.

Also to note: if I stream video only at 15fps instead of 30fps the delay grows from .3 to .8 seconds (which, as a side effect, make audio and video in sync if I add it).

I’d really love to figure out where these delays come out from.

Thanks in advance.

Daniele

P.S.

I’m sending this on osflash for now, since my membership on the official group is pending

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

R: Frequent freezes/jerky on .9.0 RC2 (main trunk)

2009-11-26T23:10:46Z

Hi, I've been using steamStream for a while, but I have heavily modified it for my needs. I have that message sometimes, but rarely.
I probably won't be the best at helping though..
What happens if you don't set timestamps, of if you change timebases?

-----Messaggio originale-----
Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Jonathan Hawkes
Inviato: giovedì 26 novembre 2009 20.56
A: red5@...
Oggetto: [Red5] Frequent freezes/jerky on .9.0 RC2 (main trunk)

I am using steamStream (http://www.red5wiki.com/wiki/SteamStream) in
production. I only modified it to pull from HTTP instead of RTSP. It has
worked well for the most part. I started using it with the main trunk of
Red5 before any of the .9.0 release candidates. (So I don't know if that
was technically .8.0 or what.)

However, ever since the merge with the xuggle_timestamp_fixes branch,
video has been choppy and frequently freezes on the client side. (The
stream continues to broadcast, and a page refresh temporarily "fixes" it.)

I don't really know if this is a bug in Red5 or in steamStream.
SteamStream sets the timestamp for each packet and auto increments each
timestamp. I've been seeing at lot of the below errors (which weren't
there before), and I figure that they are probably related. Any thoughts
on how to fix or should I revert to 0.8.0?

2009-11-26 11:16:55,775 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259415775) to stream time (369600)
2009-11-26 11:16:55,775 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259415775) to stream time (368000)
2009-11-26 11:16:57,497 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259417497) to stream time (371200)
2009-11-26 11:16:57,498 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259417498) to stream time (369600)
2009-11-26 11:17:24,033 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259444033) to stream time (396800)
2009-11-26 11:17:24,033 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259444033) to stream time (395200)
2009-11-26 11:17:25,493 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259445493) to stream time (398400)
2009-11-26 11:17:25,494 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259445494) to stream time (396800)
2009-11-26 11:17:27,146 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259447146) to stream time (400000)
2009-11-26 11:17:27,146 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259447146) to stream time (398400)
2009-11-26 11:17:28,762 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259448762) to stream time (401600)
2009-11-26 11:17:28,762 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259448762) to stream time (400000)
2009-11-26 11:17:30,435 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259450435) to stream time (403200)
2009-11-26 11:17:30,436 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259450436) to stream time (401600)
2009-11-26 11:17:32,397 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259452397) to stream time (404800)
2009-11-26 11:17:32,398 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259452398) to stream time (403200)
2009-11-26 11:17:33,739 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259453739) to stream time (406400)
2009-11-26 11:17:33,740 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259453740) to stream time (404800)
2009-11-26 11:17:35,756 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259455756) to stream time (408000)
2009-11-26 11:17:35,756 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259455756) to stream time (406400)
2009-11-26 11:17:37,216 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259457216) to stream time (409600)
2009-11-26 11:17:37,216 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259457216) to stream time (408000)
2009-11-26 11:17:39,146 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259459146) to stream time (411200)
2009-11-26 11:17:39,147 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259459147) to stream time (409600)
2009-11-26 11:17:40,706 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259460706) to stream time (412800)
2009-11-26 11:17:40,706 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259460706) to stream time (411200)
2009-11-26 11:17:42,582 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259462582) to stream time (414400)
2009-11-26 11:17:42,582 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259462582) to stream time (412800)

Thanks in advance,
Jonathan Hawkes

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

JNDI in red5

2009-11-26T14:41:21Z

Hey,

I'm new to Java and I can't get connection pooling to work, What I did was to followed this tutorial but it says I have to put the context/resource inside the server.xml file inside the tomcat conf folder, however I'm using the standalone version of red5 and it doesn't have a server.xml file, I tried to create the file but it didn't work.

This is the error message I'm receiving:

2009-11-26 23:33:13,327 [main] WARN o.a.c.core.NamingContextListener - Failed to register in JMX: javax.naming.NamingException: Could not create resource factory instance [Root exception is java.lang.ClassNotFoundException: org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory]
2009-11-26 23:33:13,478 [Launcher:/lobby] ERROR org.red5.core.Application - JNDIException: Could not create resource factory instance

MP3's with iTunes album artwork do not play in Red5

2009-11-26T13:35:22Z

I have just had a customer point out to me that when they upload certain mp3's, the server does not stream them. He sent me the mp3's and after trial and error I realised it was the iTunes album artwork that was causing the problem.

I'm actually using oflaDemo to stream the mp3's - why do they not work with iTunes album artwork? How can I solve this problem? Has anyone ever experienced anything like this?

Frequent freezes/jerky on .9.0 RC2 (main trunk)

2009-11-26T11:56:01Z

I am using steamStream (http://www.red5wiki.com/wiki/SteamStream) in
production. I only modified it to pull from HTTP instead of RTSP. It has
worked well for the most part. I started using it with the main trunk of
Red5 before any of the .9.0 release candidates. (So I don't know if that
was technically .8.0 or what.)

However, ever since the merge with the xuggle_timestamp_fixes branch,
video has been choppy and frequently freezes on the client side. (The
stream continues to broadcast, and a page refresh temporarily "fixes" it.)

I don't really know if this is a bug in Red5 or in steamStream.
SteamStream sets the timestamp for each packet and auto increments each
timestamp. I've been seeing at lot of the below errors (which weren't
there before), and I figure that they are probably related. Any thoughts
on how to fix or should I revert to 0.8.0?

2009-11-26 11:16:55,775 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259415775) to stream time (369600)
2009-11-26 11:16:55,775 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259415775) to stream time (368000)
2009-11-26 11:16:57,497 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259417497) to stream time (371200)
2009-11-26 11:16:57,498 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259417498) to stream time (369600)
2009-11-26 11:17:24,033 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259444033) to stream time (396800)
2009-11-26 11:17:24,033 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259444033) to stream time (395200)
2009-11-26 11:17:25,493 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259445493) to stream time (398400)
2009-11-26 11:17:25,494 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259445494) to stream time (396800)
2009-11-26 11:17:27,146 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259447146) to stream time (400000)
2009-11-26 11:17:27,146 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259447146) to stream time (398400)
2009-11-26 11:17:28,762 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259448762) to stream time (401600)
2009-11-26 11:17:28,762 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259448762) to stream time (400000)
2009-11-26 11:17:30,435 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259450435) to stream time (403200)
2009-11-26 11:17:30,436 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259450436) to stream time (401600)
2009-11-26 11:17:32,397 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259452397) to stream time (404800)
2009-11-26 11:17:32,398 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259452398) to stream time (403200)
2009-11-26 11:17:33,739 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259453739) to stream time (406400)
2009-11-26 11:17:33,740 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259453740) to stream time (404800)
2009-11-26 11:17:35,756 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259455756) to stream time (408000)
2009-11-26 11:17:35,756 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259455756) to stream time (406400)
2009-11-26 11:17:37,216 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259457216) to stream time (409600)
2009-11-26 11:17:37,216 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259457216) to stream time (408000)
2009-11-26 11:17:39,146 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259459146) to stream time (411200)
2009-11-26 11:17:39,147 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259459147) to stream time (409600)
2009-11-26 11:17:40,706 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259460706) to stream time (412800)
2009-11-26 11:17:40,706 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259460706) to stream time (411200)
2009-11-26 11:17:42,582 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259462582) to stream time (414400)
2009-11-26 11:17:42,582 [Thread-20] INFO
o.r.s.n.r.codec.RTMPProtocolEncoder - Resetting clock time
(1259259462582) to stream time (412800)

Thanks in advance,
Jonathan Hawkes

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

R: R: R: R: unequal delay on audio and video

2009-11-26T08:00:24Z

I’m sorry, I meant the timestamps are spaced by 26 mseconds, not 23.

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Daniele Bettella
Inviato: giovedì 26 novembre 2009 15.36
A: red5@...
Oggetto: [Red5] R: R: R: unequal delay on audio and video

Let me see if I understood this..

The mp3 header says a frame duration is:

576/(22050*0.001)

You talked about sample count, in fact my coder says I have by default 576 samples per frame and I suppose that’s where the 576 on the mp3header comes out.

If I take that value of frame duration I have timestamps spaced by 23 mseconds, that don’t look right because:

1) Audio won’t be in sync with video (then maybe is video that has wrong timestamps?

2) If I send audio only with those timestamps it goes on for a bit (two or three minutes) and then dies.

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Andy Shaules
Inviato: giovedì 26 novembre 2009 8.22
A: red5@...
Oggetto: Re: [Red5] R: R: unequal delay on audio and video

10000 samples/ second * 100 bits/ sample = 1000000 bits /second

1000000 bits/second * 1 byte / 8 bits = 125000 bytes per second

But forget all of that!

If you count the frame durations calculated by the mp3 header then you should be fine. If its not fine, then you are doing something else not right.

If fact, if your client is running windows, windows will adjust the system clock to fill those micro gaps, just as FLV video framerate is determined by the audio sample counts.

----- Original Message -----

From: daniele.bettella@...

To: red5@...

Sent: Wednesday, November 25, 2009 10:58 PM

Subject: [Red5] R: R: unequal delay on audio and video

I thank you very much for helping me; let’s see if I had this right:

Let’s say I have 100 byte per packet, at 100 bit per sample, with a sample rate of 10000 samples per second; this means I have 8 samples per packet and so 8/10000 seconds per packet… and this is my timestamp interval.

Is this correct?

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Andy Shaules
Inviato: mercoledì 25 novembre 2009 18.57
A: red5@...
Oggetto: Re: [Red5] R: unequal delay on audio and video

wrong,

audio duration is an equation without guesses. that is your only error.

You have sample rate, you have bits per sample, you have bits per second. You can take that info and calulate to the 100 nano-second accuracy if you need too.

Now, caviot! FLV frame rate is determined by audio sample count per frame, not time of frame.

If you count duration correctly you will not have lag problems.

I do it with both mp3 and aac based on number of bytes in the buffer and sample rate/bits per sample. Works perfect every time.
----- Original Message -----

From: daniele.bettella@...

To: red5@...

Sent: Wednesday, November 25, 2009 1:06 AM

Subject: [Red5] R: unequal delay on audio and video

I need help on understanding how this works..

In the current solution I set the interval between audio timestamps by guess,

It is 2080 on a stream timebase of 1/90000.

This way audio and video are in sync, at least for a while; there are some other problems, but with this not being a correct solution I don’t bother.

So what if I calculate the audio frame duration? It comes out at 26ish msecs; I set the timestamp interval based on the stream timebase. The logs say my audio rtmp packets are correctly spaced at 26 msecs, but the end result is audio and video not in sync and lagging.

With my guess of 2080 the rtmp audio packets are every 23 msecs, but this doesn’t make much sense…

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Daniele Bettella
Inviato: martedì 24 novembre 2009 18.11
A: red5@...
Oggetto: [Red5] R: R: unequal delay on audio and video

Cancel the previous message, I forgot to enable the interleaving of packets…

Apparently I still need to understand how to correlate the stream timebase and the audio frame duration…

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Daniele Bettella
Inviato: martedì 24 novembre 2009 17.58
A: red5@...
Oggetto: [Red5] R: unequal delay on audio and video
Ok, I was able to calculate my timestamps based on the code in the mp3 header; it all works fine for the first minutes, but after a while I begin to notice a little delay on audio. I think this could be because the frame duration is calculated as 
576 / (getSampleRate() * 0.001)
Inevitably this is not an integer, but the set dts requires one.
So whatever I do (and based on the stream timebase, which is 1/90000) I’ll need to transform a double into a long and hence introduce error…
And my audio will not be in sync.
 
I suppose there’s a solution to this, but what is it?
 
Daniele
Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Andy Shaules
Inviato: lunedì 23 novembre 2009 17.14
A: red5@...
Oggetto: Re: [Red5] unequal delay on audio and video

You should base your timestamps on the mp3 frame durations, not guesses.

Look at the MP3Header class in the red5.io.mp3 package. Use the class to determine each duration.

----- Original Message -----

From: daniele.bettella@...

To: red5@...

Sent: Monday, November 23, 2009 3:05 AM

Subject: [Red5] unequal delay on audio and video

I’m using Xuggle to publish an H264/mp3 live stream on red5. Audio and video are already encoded when they get to xuggle, so I do no transcoding, I just pass the packets on to red5.

Now, if I stream video only I have a small delay, around 0.3 secs, I don’t know where it comes from, but it’s either in xuggle/red5 or the player (which has a buffer of zero, btw). I could live with this delay (well, sort of), problem is, when I stream audio too this has a delay of little less than one second, resulting in audio and video not in sync.

So came the idea to force interleaving of packets (that is, using container.writePacket(packet, true)). This meant adjusting dsts by hand, since my packets had no timestamps to start with. This brought two problems:

1) I know how to adjust timestamps on video packets (since I have one frame per packet), but I had to guess on audio packets;

2) My best guess resulted in audio and video in sync (at least for the first minutes), but with a delay of one second which grew when insufficient bandwidths came out (streaming locally). Which is no good at all.

What I’d really like would be to minimize and balance the delays when non interleaving packets in xuggle, because that’s the way I have had the best results.

Also to note: if I stream video only at 15fps instead of 30fps the delay grows from .3 to .8 seconds (which, as a side effect, make audio and video in sync if I add it).

I’d really love to figure out where these delays come out from.

Thanks in advance.

Daniele

P.S.

I’m sending this on osflash for now, since my membership on the official group is pending

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

R: R: R: unequal delay on audio and video

2009-11-26T06:36:17Z

Let me see if I understood this..

The mp3 header says a frame duration is:

576/(22050*0.001)

You talked about sample count, in fact my coder says I have by default 576 samples per frame and I suppose that’s where the 576 on the mp3header comes out.

If I take that value of frame duration I have timestamps spaced by 23 mseconds, that don’t look right because:

1) Audio won’t be in sync with video (then maybe is video that has wrong timestamps?

2) If I send audio only with those timestamps it goes on for a bit (two or three minutes) and then dies.

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Andy Shaules
Inviato: giovedì 26 novembre 2009 8.22
A: red5@...
Oggetto: Re: [Red5] R: R: unequal delay on audio and video

10000 samples/ second * 100 bits/ sample = 1000000 bits /second

1000000 bits/second * 1 byte / 8 bits = 125000 bytes per second

But forget all of that!

If you count the frame durations calculated by the mp3 header then you should be fine. If its not fine, then you are doing something else not right.

If fact, if your client is running windows, windows will adjust the system clock to fill those micro gaps, just as FLV video framerate is determined by the audio sample counts.

----- Original Message -----

From: daniele.bettella@...

To: red5@...

Sent: Wednesday, November 25, 2009 10:58 PM

Subject: [Red5] R: R: unequal delay on audio and video

I thank you very much for helping me; let’s see if I had this right:

Let’s say I have 100 byte per packet, at 100 bit per sample, with a sample rate of 10000 samples per second; this means I have 8 samples per packet and so 8/10000 seconds per packet… and this is my timestamp interval.

Is this correct?

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Andy Shaules
Inviato: mercoledì 25 novembre 2009 18.57
A: red5@...
Oggetto: Re: [Red5] R: unequal delay on audio and video

wrong,

audio duration is an equation without guesses. that is your only error.

You have sample rate, you have bits per sample, you have bits per second. You can take that info and calulate to the 100 nano-second accuracy if you need too.

Now, caviot! FLV frame rate is determined by audio sample count per frame, not time of frame.

If you count duration correctly you will not have lag problems.

I do it with both mp3 and aac based on number of bytes in the buffer and sample rate/bits per sample. Works perfect every time.
----- Original Message -----

From: daniele.bettella@...

To: red5@...

Sent: Wednesday, November 25, 2009 1:06 AM

Subject: [Red5] R: unequal delay on audio and video

I need help on understanding how this works..

In the current solution I set the interval between audio timestamps by guess,

It is 2080 on a stream timebase of 1/90000.

This way audio and video are in sync, at least for a while; there are some other problems, but with this not being a correct solution I don’t bother.

So what if I calculate the audio frame duration? It comes out at 26ish msecs; I set the timestamp interval based on the stream timebase. The logs say my audio rtmp packets are correctly spaced at 26 msecs, but the end result is audio and video not in sync and lagging.

With my guess of 2080 the rtmp audio packets are every 23 msecs, but this doesn’t make much sense…

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Daniele Bettella
Inviato: martedì 24 novembre 2009 18.11
A: red5@...
Oggetto: [Red5] R: R: unequal delay on audio and video

Cancel the previous message, I forgot to enable the interleaving of packets…

Apparently I still need to understand how to correlate the stream timebase and the audio frame duration…

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Daniele Bettella
Inviato: martedì 24 novembre 2009 17.58
A: red5@...
Oggetto: [Red5] R: unequal delay on audio and video
Ok, I was able to calculate my timestamps based on the code in the mp3 header; it all works fine for the first minutes, but after a while I begin to notice a little delay on audio. I think this could be because the frame duration is calculated as 
576 / (getSampleRate() * 0.001)
Inevitably this is not an integer, but the set dts requires one.
So whatever I do (and based on the stream timebase, which is 1/90000) I’ll need to transform a double into a long and hence introduce error…
And my audio will not be in sync.
 
I suppose there’s a solution to this, but what is it?
 
Daniele
Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Andy Shaules
Inviato: lunedì 23 novembre 2009 17.14
A: red5@...
Oggetto: Re: [Red5] unequal delay on audio and video

You should base your timestamps on the mp3 frame durations, not guesses.

Look at the MP3Header class in the red5.io.mp3 package. Use the class to determine each duration.

----- Original Message -----

From: daniele.bettella@...

To: red5@...

Sent: Monday, November 23, 2009 3:05 AM

Subject: [Red5] unequal delay on audio and video

I’m using Xuggle to publish an H264/mp3 live stream on red5. Audio and video are already encoded when they get to xuggle, so I do no transcoding, I just pass the packets on to red5.

Now, if I stream video only I have a small delay, around 0.3 secs, I don’t know where it comes from, but it’s either in xuggle/red5 or the player (which has a buffer of zero, btw). I could live with this delay (well, sort of), problem is, when I stream audio too this has a delay of little less than one second, resulting in audio and video not in sync.

So came the idea to force interleaving of packets (that is, using container.writePacket(packet, true)). This meant adjusting dsts by hand, since my packets had no timestamps to start with. This brought two problems:

1) I know how to adjust timestamps on video packets (since I have one frame per packet), but I had to guess on audio packets;

2) My best guess resulted in audio and video in sync (at least for the first minutes), but with a delay of one second which grew when insufficient bandwidths came out (streaming locally). Which is no good at all.

What I’d really like would be to minimize and balance the delays when non interleaving packets in xuggle, because that’s the way I have had the best results.

Also to note: if I stream video only at 15fps instead of 30fps the delay grows from .3 to .8 seconds (which, as a side effect, make audio and video in sync if I add it).

I’d really love to figure out where these delays come out from.

Thanks in advance.

Daniele

P.S.

I’m sending this on osflash for now, since my membership on the official group is pending

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

R: R: R: unequal delay on audio and video

2009-11-26T00:28:47Z

I’m using a modified version of steamStream, which does no transcoding and processes audio and video on different threads

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Andy Shaules
Inviato: giovedì 26 novembre 2009 8.32
A: red5@...
Oggetto: Re: [Red5] R: R: unequal delay on audio and video

what is the broadcasting source program?

Using xuggler but how?

----- Original Message -----

From: bowljoman@...

To: red5@...

Sent: Wednesday, November 25, 2009 11:21 PM

Subject: Re: [Red5] R: R: unequal delay on audio and video

10000 samples/ second * 100 bits/ sample = 1000000 bits /second

1000000 bits/second * 1 byte / 8 bits = 125000 bytes per second

But forget all of that!

If you count the frame durations calculated by the mp3 header then you should be fine. If its not fine, then you are doing something else not right.

Here is my situation. I get 3 mp3 frames for every one h264 frame, yet I can still take the calculated values from the mp3 header add all of them up, and my stream will still be synchronized after 24 hours.

Something you are doing is not right. Yes the duration will calculate to a double precision value and the timestamp will take an integer, but if you keep the double precision around for the whole process, you will be good to go.

If fact, if your client is running windows, windows will adjust the system clock to fill those micro gaps, just as FLV video framerate is determined by the audio sample counts.
----- Original Message -----

From: daniele.bettella@...

To: red5@...

Sent: Wednesday, November 25, 2009 10:58 PM

Subject: [Red5] R: R: unequal delay on audio and video

I thank you very much for helping me; let’s see if I had this right:

Let’s say I have 100 byte per packet, at 100 bit per sample, with a sample rate of 10000 samples per second; this means I have 8 samples per packet and so 8/10000 seconds per packet… and this is my timestamp interval.

Is this correct?

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Andy Shaules
Inviato: mercoledì 25 novembre 2009 18.57
A: red5@...
Oggetto: Re: [Red5] R: unequal delay on audio and video

wrong,

audio duration is an equation without guesses. that is your only error.

You have sample rate, you have bits per sample, you have bits per second. You can take that info and calulate to the 100 nano-second accuracy if you need too.

Now, caviot! FLV frame rate is determined by audio sample count per frame, not time of frame.

If you count duration correctly you will not have lag problems.

I do it with both mp3 and aac based on number of bytes in the buffer and sample rate/bits per sample. Works perfect every time.
----- Original Message -----

From: daniele.bettella@...

To: red5@...

Sent: Wednesday, November 25, 2009 1:06 AM

Subject: [Red5] R: unequal delay on audio and video

I need help on understanding how this works..

In the current solution I set the interval between audio timestamps by guess,

It is 2080 on a stream timebase of 1/90000.

This way audio and video are in sync, at least for a while; there are some other problems, but with this not being a correct solution I don’t bother.

So what if I calculate the audio frame duration? It comes out at 26ish msecs; I set the timestamp interval based on the stream timebase. The logs say my audio rtmp packets are correctly spaced at 26 msecs, but the end result is audio and video not in sync and lagging.

With my guess of 2080 the rtmp audio packets are every 23 msecs, but this doesn’t make much sense…

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Daniele Bettella
Inviato: martedì 24 novembre 2009 18.11
A: red5@...
Oggetto: [Red5] R: R: unequal delay on audio and video

Cancel the previous message, I forgot to enable the interleaving of packets…

Apparently I still need to understand how to correlate the stream timebase and the audio frame duration…

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Daniele Bettella
Inviato: martedì 24 novembre 2009 17.58
A: red5@...
Oggetto: [Red5] R: unequal delay on audio and video
Ok, I was able to calculate my timestamps based on the code in the mp3 header; it all works fine for the first minutes, but after a while I begin to notice a little delay on audio. I think this could be because the frame duration is calculated as 
576 / (getSampleRate() * 0.001)
Inevitably this is not an integer, but the set dts requires one.
So whatever I do (and based on the stream timebase, which is 1/90000) I’ll need to transform a double into a long and hence introduce error…
And my audio will not be in sync.
 
I suppose there’s a solution to this, but what is it?
 
Daniele
Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Andy Shaules
Inviato: lunedì 23 novembre 2009 17.14
A: red5@...
Oggetto: Re: [Red5] unequal delay on audio and video

You should base your timestamps on the mp3 frame durations, not guesses.

Look at the MP3Header class in the red5.io.mp3 package. Use the class to determine each duration.

----- Original Message -----

From: daniele.bettella@...

To: red5@...

Sent: Monday, November 23, 2009 3:05 AM

Subject: [Red5] unequal delay on audio and video

I’m using Xuggle to publish an H264/mp3 live stream on red5. Audio and video are already encoded when they get to xuggle, so I do no transcoding, I just pass the packets on to red5.

Now, if I stream video only I have a small delay, around 0.3 secs, I don’t know where it comes from, but it’s either in xuggle/red5 or the player (which has a buffer of zero, btw). I could live with this delay (well, sort of), problem is, when I stream audio too this has a delay of little less than one second, resulting in audio and video not in sync.

So came the idea to force interleaving of packets (that is, using container.writePacket(packet, true)). This meant adjusting dsts by hand, since my packets had no timestamps to start with. This brought two problems:

1) I know how to adjust timestamps on video packets (since I have one frame per packet), but I had to guess on audio packets;

2) My best guess resulted in audio and video in sync (at least for the first minutes), but with a delay of one second which grew when insufficient bandwidths came out (streaming locally). Which is no good at all.

What I’d really like would be to minimize and balance the delays when non interleaving packets in xuggle, because that’s the way I have had the best results.

Also to note: if I stream video only at 15fps instead of 30fps the delay grows from .3 to .8 seconds (which, as a side effect, make audio and video in sync if I add it).

I’d really love to figure out where these delays come out from.

Thanks in advance.

Daniele

P.S.

I’m sending this on osflash for now, since my membership on the official group is pending

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

Re: R: R: unequal delay on audio and video

2009-11-25T23:32:03Z

what is the broadcasting source program?

Using xuggler but how?

----- Original Message -----

From: bowljoman@...

To: red5@...

Sent: Wednesday, November 25, 2009 11:21 PM

Subject: Re: [Red5] R: R: unequal delay on audio and video

10000 samples/ second * 100 bits/ sample = 1000000 bits /second

1000000 bits/second * 1 byte / 8 bits = 125000 bytes per second

But forget all of that!

If you count the frame durations calculated by the mp3 header then you should be fine. If its not fine, then you are doing something else not right.

Here is my situation. I get 3 mp3 frames for every one h264 frame, yet I can still take the calculated values from the mp3 header add all of them up, and my stream will still be synchronized after 24 hours.

Something you are doing is not right. Yes the duration will calculate to a double precision value and the timestamp will take an integer, but if you keep the double precision around for the whole process, you will be good to go.

If fact, if your client is running windows, windows will adjust the system clock to fill those micro gaps, just as FLV video framerate is determined by the audio sample counts.
----- Original Message -----

From: daniele.bettella@...

To: red5@...

Sent: Wednesday, November 25, 2009 10:58 PM

Subject: [Red5] R: R: unequal delay on audio and video
I thank you very much for helping me; lets see if I had this right:

Lets say I have 100 byte per packet, at 100 bit per sample, with a sample rate of 10000 samples per second; this means I have 8 samples per packet and so 8/10000 seconds per packet and this is my timestamp interval.

Is this correct?

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Andy Shaules
Inviato: mercoledì 25 novembre 2009 18.57
A: red5@...
Oggetto: Re: [Red5] R: unequal delay on audio and video

wrong,

audio duration is an equation without guesses. that is your only error.

You have sample rate, you have bits per sample, you have bits per second. You can take that info and calulate to the 100 nano-second accuracy if you need too.

Now, caviot! FLV frame rate is determined by audio sample count per frame, not time of frame.

If you count duration correctly you will not have lag problems.

I do it with both mp3 and aac based on number of bytes in the buffer and sample rate/bits per sample. Works perfect every time.
----- Original Message -----

From: daniele.bettella@...

To: red5@...

Sent: Wednesday, November 25, 2009 1:06 AM

Subject: [Red5] R: unequal delay on audio and video

I need help on understanding how this works..

In the current solution I set the interval between audio timestamps by guess,

It is 2080 on a stream timebase of 1/90000.

This way audio and video are in sync, at least for a while; there are some other problems, but with this not being a correct solution I dont bother.

So what if I calculate the audio frame duration? It comes out at 26ish msecs; I set the timestamp interval based on the stream timebase. The logs say my audio rtmp packets are correctly spaced at 26 msecs, but the end result is audio and video not in sync and lagging.

With my guess of 2080 the rtmp audio packets are every 23 msecs, but this doesnt make much sense

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Daniele Bettella
Inviato: martedì 24 novembre 2009 18.11
A: red5@...
Oggetto: [Red5] R: R: unequal delay on audio and video

Cancel the previous message, I forgot to enable the interleaving of packets

Apparently I still need to understand how to correlate the stream timebase and the audio frame duration

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Daniele Bettella
Inviato: martedì 24 novembre 2009 17.58
A: red5@...
Oggetto: [Red5] R: unequal delay on audio and video
Ok, I was able to calculate my timestamps based on the code in the mp3 header; it all works fine for the first minutes, but after a while I begin to notice a little delay on audio. I think this could be because the frame duration is calculated as 
576 / (getSampleRate() * 0.001)
Inevitably this is not an integer, but the set dts requires one.
So whatever I do (and based on the stream timebase, which is 1/90000) Ill need to transform a double into a long and hence introduce error
And my audio will not be in sync.
 
I suppose theres a solution to this, but what is it?
 
Daniele
Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Andy Shaules
Inviato: lunedì 23 novembre 2009 17.14
A: red5@...
Oggetto: Re: [Red5] unequal delay on audio and video

You should base your timestamps on the mp3 frame durations, not guesses.

Look at the MP3Header class in the red5.io.mp3 package. Use the class to determine each duration.

----- Original Message -----

From: daniele.bettella@...

To: red5@...

Sent: Monday, November 23, 2009 3:05 AM

Subject: [Red5] unequal delay on audio and video

Im using Xuggle to publish an H264/mp3 live stream on red5. Audio and video are already encoded when they get to xuggle, so I do no transcoding, I just pass the packets on to red5.

Now, if I stream video only I have a small delay, around 0.3 secs, I dont know where it comes from, but its either in xuggle/red5 or the player (which has a buffer of zero, btw). I could live with this delay (well, sort of), problem is, when I stream audio too this has a delay of little less than one second, resulting in audio and video not in sync.

So came the idea to force interleaving of packets (that is, using container.writePacket(packet, true)). This meant adjusting dsts by hand, since my packets had no timestamps to start with. This brought two problems:

1) I know how to adjust timestamps on video packets (since I have one frame per packet), but I had to guess on audio packets;

2) My best guess resulted in audio and video in sync (at least for the first minutes), but with a delay of one second which grew when insufficient bandwidths came out (streaming locally). Which is no good at all.

What Id really like would be to minimize and balance the delays when non interleaving packets in xuggle, because thats the way I have had the best results.

Also to note: if I stream video only at 15fps instead of 30fps the delay grows from .3 to .8 seconds (which, as a side effect, make audio and video in sync if I add it).

Id really love to figure out where these delays come out from.

Thanks in advance.

Daniele

P.S.

Im sending this on osflash for now, since my membership on the official group is pending

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

Re: R: R: unequal delay on audio and video

2009-11-25T23:21:59Z

10000 samples/ second * 100 bits/ sample = 1000000 bits /second

1000000 bits/second * 1 byte / 8 bits = 125000 bytes per second

But forget all of that!

If you count the frame durations calculated by the mp3 header then you should be fine. If its not fine, then you are doing something else not right.

If fact, if your client is running windows, windows will adjust the system clock to fill those micro gaps, just as FLV video framerate is determined by the audio sample counts.

----- Original Message -----

From: daniele.bettella@...

To: red5@...

Sent: Wednesday, November 25, 2009 10:58 PM

Subject: [Red5] R: R: unequal delay on audio and video
I thank you very much for helping me; lets see if I had this right:

Lets say I have 100 byte per packet, at 100 bit per sample, with a sample rate of 10000 samples per second; this means I have 8 samples per packet and so 8/10000 seconds per packet and this is my timestamp interval.

Is this correct?

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Andy Shaules
Inviato: mercoledì 25 novembre 2009 18.57
A: red5@...
Oggetto: Re: [Red5] R: unequal delay on audio and video

wrong,

audio duration is an equation without guesses. that is your only error.

You have sample rate, you have bits per sample, you have bits per second. You can take that info and calulate to the 100 nano-second accuracy if you need too.

Now, caviot! FLV frame rate is determined by audio sample count per frame, not time of frame.

If you count duration correctly you will not have lag problems.

I do it with both mp3 and aac based on number of bytes in the buffer and sample rate/bits per sample. Works perfect every time.
----- Original Message -----

From: daniele.bettella@...

To: red5@...

Sent: Wednesday, November 25, 2009 1:06 AM

Subject: [Red5] R: unequal delay on audio and video

I need help on understanding how this works..

In the current solution I set the interval between audio timestamps by guess,

It is 2080 on a stream timebase of 1/90000.

This way audio and video are in sync, at least for a while; there are some other problems, but with this not being a correct solution I dont bother.

So what if I calculate the audio frame duration? It comes out at 26ish msecs; I set the timestamp interval based on the stream timebase. The logs say my audio rtmp packets are correctly spaced at 26 msecs, but the end result is audio and video not in sync and lagging.

With my guess of 2080 the rtmp audio packets are every 23 msecs, but this doesnt make much sense

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Daniele Bettella
Inviato: martedì 24 novembre 2009 18.11
A: red5@...
Oggetto: [Red5] R: R: unequal delay on audio and video

Cancel the previous message, I forgot to enable the interleaving of packets

Apparently I still need to understand how to correlate the stream timebase and the audio frame duration

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Daniele Bettella
Inviato: martedì 24 novembre 2009 17.58
A: red5@...
Oggetto: [Red5] R: unequal delay on audio and video
Ok, I was able to calculate my timestamps based on the code in the mp3 header; it all works fine for the first minutes, but after a while I begin to notice a little delay on audio. I think this could be because the frame duration is calculated as 
576 / (getSampleRate() * 0.001)
Inevitably this is not an integer, but the set dts requires one.
So whatever I do (and based on the stream timebase, which is 1/90000) Ill need to transform a double into a long and hence introduce error
And my audio will not be in sync.
 
I suppose theres a solution to this, but what is it?
 
Daniele
Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Andy Shaules
Inviato: lunedì 23 novembre 2009 17.14
A: red5@...
Oggetto: Re: [Red5] unequal delay on audio and video

You should base your timestamps on the mp3 frame durations, not guesses.

Look at the MP3Header class in the red5.io.mp3 package. Use the class to determine each duration.

----- Original Message -----

From: daniele.bettella@...

To: red5@...

Sent: Monday, November 23, 2009 3:05 AM

Subject: [Red5] unequal delay on audio and video

Im using Xuggle to publish an H264/mp3 live stream on red5. Audio and video are already encoded when they get to xuggle, so I do no transcoding, I just pass the packets on to red5.

Now, if I stream video only I have a small delay, around 0.3 secs, I dont know where it comes from, but its either in xuggle/red5 or the player (which has a buffer of zero, btw). I could live with this delay (well, sort of), problem is, when I stream audio too this has a delay of little less than one second, resulting in audio and video not in sync.

So came the idea to force interleaving of packets (that is, using container.writePacket(packet, true)). This meant adjusting dsts by hand, since my packets had no timestamps to start with. This brought two problems:

1) I know how to adjust timestamps on video packets (since I have one frame per packet), but I had to guess on audio packets;

2) My best guess resulted in audio and video in sync (at least for the first minutes), but with a delay of one second which grew when insufficient bandwidths came out (streaming locally). Which is no good at all.

What Id really like would be to minimize and balance the delays when non interleaving packets in xuggle, because thats the way I have had the best results.

Also to note: if I stream video only at 15fps instead of 30fps the delay grows from .3 to .8 seconds (which, as a side effect, make audio and video in sync if I add it).

Id really love to figure out where these delays come out from.

Thanks in advance.

Daniele

P.S.

Im sending this on osflash for now, since my membership on the official group is pending

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

R: R: unequal delay on audio and video

2009-11-25T22:58:09Z

I thank you very much for helping me; let’s see if I had this right:

Let’s say I have 100 byte per packet, at 100 bit per sample, with a sample rate of 10000 samples per second; this means I have 8 samples per packet and so 8/10000 seconds per packet… and this is my timestamp interval.

Is this correct?

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Andy Shaules
Inviato: mercoledì 25 novembre 2009 18.57
A: red5@...
Oggetto: Re: [Red5] R: unequal delay on audio and video

wrong,

audio duration is an equation without guesses. that is your only error.

You have sample rate, you have bits per sample, you have bits per second. You can take that info and calulate to the 100 nano-second accuracy if you need too.

Now, caviot! FLV frame rate is determined by audio sample count per frame, not time of frame.

If you count duration correctly you will not have lag problems.

I do it with both mp3 and aac based on number of bytes in the buffer and sample rate/bits per sample. Works perfect every time.

----- Original Message -----

From: daniele.bettella@...

To: red5@...

Sent: Wednesday, November 25, 2009 1:06 AM

Subject: [Red5] R: unequal delay on audio and video

I need help on understanding how this works..

In the current solution I set the interval between audio timestamps by guess,

It is 2080 on a stream timebase of 1/90000.

This way audio and video are in sync, at least for a while; there are some other problems, but with this not being a correct solution I don’t bother.

So what if I calculate the audio frame duration? It comes out at 26ish msecs; I set the timestamp interval based on the stream timebase. The logs say my audio rtmp packets are correctly spaced at 26 msecs, but the end result is audio and video not in sync and lagging.

With my guess of 2080 the rtmp audio packets are every 23 msecs, but this doesn’t make much sense…

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Daniele Bettella
Inviato: martedì 24 novembre 2009 18.11
A: red5@...
Oggetto: [Red5] R: R: unequal delay on audio and video

Cancel the previous message, I forgot to enable the interleaving of packets…

Apparently I still need to understand how to correlate the stream timebase and the audio frame duration…

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Daniele Bettella
Inviato: martedì 24 novembre 2009 17.58
A: red5@...
Oggetto: [Red5] R: unequal delay on audio and video
Ok, I was able to calculate my timestamps based on the code in the mp3 header; it all works fine for the first minutes, but after a while I begin to notice a little delay on audio. I think this could be because the frame duration is calculated as 
576 / (getSampleRate() * 0.001)
Inevitably this is not an integer, but the set dts requires one.
So whatever I do (and based on the stream timebase, which is 1/90000) I’ll need to transform a double into a long and hence introduce error…
And my audio will not be in sync.
 
I suppose there’s a solution to this, but what is it?
 
Daniele
Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Andy Shaules
Inviato: lunedì 23 novembre 2009 17.14
A: red5@...
Oggetto: Re: [Red5] unequal delay on audio and video

You should base your timestamps on the mp3 frame durations, not guesses.

Look at the MP3Header class in the red5.io.mp3 package. Use the class to determine each duration.

----- Original Message -----

From: daniele.bettella@...

To: red5@...

Sent: Monday, November 23, 2009 3:05 AM

Subject: [Red5] unequal delay on audio and video

I’m using Xuggle to publish an H264/mp3 live stream on red5. Audio and video are already encoded when they get to xuggle, so I do no transcoding, I just pass the packets on to red5.

Now, if I stream video only I have a small delay, around 0.3 secs, I don’t know where it comes from, but it’s either in xuggle/red5 or the player (which has a buffer of zero, btw). I could live with this delay (well, sort of), problem is, when I stream audio too this has a delay of little less than one second, resulting in audio and video not in sync.

So came the idea to force interleaving of packets (that is, using container.writePacket(packet, true)). This meant adjusting dsts by hand, since my packets had no timestamps to start with. This brought two problems:

1) I know how to adjust timestamps on video packets (since I have one frame per packet), but I had to guess on audio packets;

2) My best guess resulted in audio and video in sync (at least for the first minutes), but with a delay of one second which grew when insufficient bandwidths came out (streaming locally). Which is no good at all.

What I’d really like would be to minimize and balance the delays when non interleaving packets in xuggle, because that’s the way I have had the best results.

Also to note: if I stream video only at 15fps instead of 30fps the delay grows from .3 to .8 seconds (which, as a side effect, make audio and video in sync if I add it).

I’d really love to figure out where these delays come out from.

Thanks in advance.

Daniele

P.S.

I’m sending this on osflash for now, since my membership on the official group is pending

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

Re: xuggle - how to dynamically add/remove audio input in/froman outputStream

2009-11-25T18:20:12Z

Thanks for the clarification.

On Thu, Nov 26, 2009 at 1:43 AM, Andy Shaules <bowljoman@...> wrote:

IT doesnt.

You will have to learn that one and create it.

When you have a buffer of un compressed smaples, yes, smaples heheh. You must combine two or more of them to get your desired output.

While possible for sure, nobody said it would be easy.

You must clearly understand PCM audio samples and how to combine two of them.

16 bit audio sample is a value between 0 and 2^16, If you have two samples for the same point in time, you add them together with addition, and check for ceiling.

If a smaple starts on time .0001 and you have another sample that starts at .0100, you must line up sample by sample according to time offset and add their sample values.

Both very easy in combining and very difficult to do it right.

It is far from impossible and Im sure a rewarding experience once finished.

----- Original Message -----

From: jingwei.yang@...

To: red5@...

Sent: Tuesday, November 24, 2009 11:29 PM

Subject: [Red5] xuggle - how to dynamically add/remove audio input in/froman outputStream

Hi Guys,

I'm looking into a xuggle utility to combine multiple audio input streams into one OutputStream. I've checked AudioTranscoderDemo and found here's the line to link the streams:

Transcoder transcoder = new Transcoder(aStream,
outputStream, outputStreamInfo);

Then I checked the Transcoder class, but found it supports only one InputStream.

private final IBroadcastStream mInputStream;

How should Xuggle add inputs into the output and later remove from it? And once there're no inputs any more, stop the output?

Thanks and best regards,
-Jingwei

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

Re: screen share with Xuggler

2009-11-25T18:19:33Z

Thanks Richard.

On Wed, Nov 25, 2009 at 11:24 PM, Richard Alam <ritzalam@...> wrote:

Just go through the archive
(http://osflash.org/mailman/listinfo/red5_osflash.org) for Oct and Nov
then search for Desktop Sharing. There's several implementations of
what you want to accomplish.

And send your mail to http://groups.google.com/group/red5interest as
all the Red5 dev team has
moved there. Not sure if this list is still being monitored by them.

Richard

On Wed, Nov 25, 2009 at 4:05 AM, Jingwei Yang <jingwei.yang@...> wrote:
> Hi Guys,
>
> I believe this topic has been discussed many times in the forum. Is there a
> conclusion? As far as I understand, here's the whole process:
>
> 1. Client A captures his screen using applet (taking advantage of
> java.awt.Robot)
> 2. Xuggler encodes the serial screen shots into a video (within the applet)
> 3. Client A broadcasts the video via red5
> 4. Client B subscribes to the stream and watches the video
>
> But how does Client A broadcast the video? The Video info is still handled
> by the java applet. How does the applet inform red5? Any thoughts or advise
> are highly appreciated.
>
> Thanks and best regards,
> -Jingwei
>

> _______________________________________________
> Red5 mailing list
> Red5@...
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
>

--
---
BigBlueButton
http://www.bigbluebutton.org
http://code.google.com/p/bigbluebutton

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

Re: R: unequal delay on audio and video

2009-11-25T08:44:24Z

wrong,

audio duration is an equation without guesses. that is your only error.

You have sample rate, you have bits per sample, you have bits per second. You can take that info and calulate to the 100 nano-second accuracy if you need too.

Now, caviot! FLV frame rate is determined by audio sample count per frame, not time of frame.

If you count duration correctly you will not have lag problems.

I do it with both mp3 and aac based on number of bytes in the buffer and sample rate/bits per sample. Works perfect every time.

----- Original Message -----

From: daniele.bettella@...

To: red5@...

Sent: Wednesday, November 25, 2009 1:06 AM

Subject: [Red5] R: unequal delay on audio and video
I need help on understanding how this works..

In the current solution I set the interval between audio timestamps by guess,

It is 2080 on a stream timebase of 1/90000.

This way audio and video are in sync, at least for a while; there are some other problems, but with this not being a correct solution I dont bother.

So what if I calculate the audio frame duration? It comes out at 26ish msecs; I set the timestamp interval based on the stream timebase. The logs say my audio rtmp packets are correctly spaced at 26 msecs, but the end result is audio and video not in sync and lagging.

With my guess of 2080 the rtmp audio packets are every 23 msecs, but this doesnt make much sense

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Daniele Bettella
Inviato: martedì 24 novembre 2009 18.11
A: red5@...
Oggetto: [Red5] R: R: unequal delay on audio and video

Cancel the previous message, I forgot to enable the interleaving of packets

Apparently I still need to understand how to correlate the stream timebase and the audio frame duration

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Daniele Bettella
Inviato: martedì 24 novembre 2009 17.58
A: red5@...
Oggetto: [Red5] R: unequal delay on audio and video
Ok, I was able to calculate my timestamps based on the code in the mp3 header; it all works fine for the first minutes, but after a while I begin to notice a little delay on audio. I think this could be because the frame duration is calculated as 
576 / (getSampleRate() * 0.001)
Inevitably this is not an integer, but the set dts requires one.
So whatever I do (and based on the stream timebase, which is 1/90000) Ill need to transform a double into a long and hence introduce error
And my audio will not be in sync.
 
I suppose theres a solution to this, but what is it?
 
Daniele
Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Andy Shaules
Inviato: lunedì 23 novembre 2009 17.14
A: red5@...
Oggetto: Re: [Red5] unequal delay on audio and video

You should base your timestamps on the mp3 frame durations, not guesses.

Look at the MP3Header class in the red5.io.mp3 package. Use the class to determine each duration.

----- Original Message -----

From: daniele.bettella@...

To: red5@...

Sent: Monday, November 23, 2009 3:05 AM

Subject: [Red5] unequal delay on audio and video

Im using Xuggle to publish an H264/mp3 live stream on red5. Audio and video are already encoded when they get to xuggle, so I do no transcoding, I just pass the packets on to red5.

Now, if I stream video only I have a small delay, around 0.3 secs, I dont know where it comes from, but its either in xuggle/red5 or the player (which has a buffer of zero, btw). I could live with this delay (well, sort of), problem is, when I stream audio too this has a delay of little less than one second, resulting in audio and video not in sync.

So came the idea to force interleaving of packets (that is, using container.writePacket(packet, true)). This meant adjusting dsts by hand, since my packets had no timestamps to start with. This brought two problems:

1) I know how to adjust timestamps on video packets (since I have one frame per packet), but I had to guess on audio packets;

2) My best guess resulted in audio and video in sync (at least for the first minutes), but with a delay of one second which grew when insufficient bandwidths came out (streaming locally). Which is no good at all.

What Id really like would be to minimize and balance the delays when non interleaving packets in xuggle, because thats the way I have had the best results.

Also to note: if I stream video only at 15fps instead of 30fps the delay grows from .3 to .8 seconds (which, as a side effect, make audio and video in sync if I add it).

Id really love to figure out where these delays come out from.

Thanks in advance.

Daniele

P.S.

Im sending this on osflash for now, since my membership on the official group is pending

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

Re: xuggle - how to dynamically add/remove audio input in/froman outputStream

2009-11-25T08:31:56Z

IT doesnt.

You will have to learn that one and create it.

When you have a buffer of un compressed smaples, yes, smaples heheh. You must combine two or more of them to get your desired output.

While possible for sure, nobody said it would be easy.

You must clearly understand PCM audio samples and how to combine two of them.

16 bit audio sample is a value between 0 and 2^16, If you have two samples for the same point in time, you add them together with addition, and check for ceiling.

If a smaple starts on time .0001 and you have another sample that starts at .0100, you must line up sample by sample according to time offset and add their sample values.

Both very easy in combining and very difficult to do it right.

It is far from impossible and Im sure a rewarding experience once finished.

----- Original Message -----

From: jingwei.yang@...

To: red5@...

Sent: Tuesday, November 24, 2009 11:29 PM

Subject: [Red5] xuggle - how to dynamically add/remove audio input in/froman outputStream

Hi Guys,

I'm looking into a xuggle utility to combine multiple audio input streams into one OutputStream. I've checked AudioTranscoderDemo and found here's the line to link the streams:

Transcoder transcoder = new Transcoder(aStream,
outputStream, outputStreamInfo);

Then I checked the Transcoder class, but found it supports only one InputStream.

private final IBroadcastStream mInputStream;

How should Xuggle add inputs into the output and later remove from it? And once there're no inputs any more, stop the output?

Thanks and best regards,
-Jingwei

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

Re: screen share with Xuggler

2009-11-25T07:24:29Z

Just go through the archive
(http://osflash.org/mailman/listinfo/red5_osflash.org) for Oct and Nov
then search for Desktop Sharing. There's several implementations of
what you want to accomplish.

And send your mail to http://groups.google.com/group/red5interest as
all the Red5 dev team has
moved there. Not sure if this list is still being monitored by them.

Richard

On Wed, Nov 25, 2009 at 4:05 AM, Jingwei Yang <jingwei.yang@...> wrote:

> Hi Guys,
>
> I believe this topic has been discussed many times in the forum. Is there a
> conclusion? As far as I understand, here's the whole process:
>
> 1. Client A captures his screen using applet (taking advantage of
> java.awt.Robot)
> 2. Xuggler encodes the serial screen shots into a video (within the applet)
> 3. Client A broadcasts the video via red5
> 4. Client B subscribes to the stream and watches the video
>
> But how does Client A broadcast the video? The Video info is still handled
> by the java applet. How does the applet inform red5? Any thoughts or advise
> are highly appreciated.
>
> Thanks and best regards,
> -Jingwei
>
> _______________________________________________
> Red5 mailing list
> Red5@...
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
>

--
---
BigBlueButton
http://www.bigbluebutton.org
http://code.google.com/p/bigbluebutton

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

Re: Red5 0.9.0 RC3 - trunk Rev 3967

2009-11-25T01:57:32Z

It was just a matter of exporting the flash/trunk/deploy/* files from
the repository, putting them in a folder and editing the path to it at
build.xml:322.

Now, the 3967 build still has the severe seek problem :-(

Is the seeking problem in the bug ticket system?

ヨンニ　ベリィストロム wrote:

> I get the same:
>
> "BUILD FAILED
> /home/unigent/red5/0.9_3967/build.xml:226: The following error
> occurred while executing this line:
> /home/unigent/red5/0.9_3967/build.xml:321: /home/flash/trunk/deploy
> not found."
>
>
> And I tried it also as root. I think the path on line 322 is not
> correct, as Carlos suggests.
> I guess I'll temporarily create the /home/flash/ tree...
>
>
> J
>
> devon girard wrote:
>> have you tried
>> sudo ant
>>
>> from within the trunk directory?
>>
>> could be permissions...
>>

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

Re: Red5 0.9.0 RC3 - trunk Rev 3967

2009-11-25T01:23:24Z

I get the same:

"BUILD FAILED
/home/unigent/red5/0.9_3967/build.xml:226: The following error occurred
while executing this line:
/home/unigent/red5/0.9_3967/build.xml:321: /home/flash/trunk/deploy not
found."

And I tried it also as root. I think the path on line 322 is not
correct, as Carlos suggests.
I guess I'll temporarily create the /home/flash/ tree...

J

devon girard wrote:

> have you tried
>
> sudo ant
>
> from within the trunk directory?
>
> could be permissions...
>
> On Tue, Nov 24, 2009 at 7:06 PM, carlosl <carlosl@...
> <mailto:carlosl@...>> wrote:
>
> Hello Everybody,
>
> FYI.
> I updated my dev version with trunk revision 3967 few minuted ago.
> it failed
> compiling because of build.xml line 322 (../../flash/trunk/deploy).
>
> I tried several times with same results. I had to create the
> folder tree
> for /flash/trunk/deploy to compile sucessfully (BTW. My current trunk
> installation is at /opt/Red5-development/red5_server_trunk in case
> it is
> relevant)
>
> While it is not critical, just wanted to let you know.
>
> Regards,
>
> Carlos Lozano
> CAX IT Services
> Houston, TX
>
>
> _______________________________________________
> Red5 mailing list
> Red5@... <mailto:Red5@...>
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Red5 mailing list
> Red5@...
> http://osflash.org/mailman/listinfo/red5_osflash.org
>

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

Re: How to secure red5?

2009-11-25T01:19:48Z

Ok thanks , so the token exchange between server and client seems to be the
best solution ... but why red5 don't implement swf verification like FMS ?
In my opinion it's a very important feature !

I am going to explain you how i am going to do token exchange , you can tell
me if i am right :
On webserver :
When user loggued in my application with login and password and the
verification is ok, i insert a php authentification session in a mySql
database.

On my swf :
I get the php session generated by my php server, in my netconnection param
i put this phpsession and i send it to my java red5 server code, in my
server code i check if the phpsession is ok using mysql request.

But in this case user can loggued in to get a valid session and use it in
his own swf ...So i have to change the token everytime !

----- Original Message -----
From: "???????????" <jonny@...>
To: <red5@...>
Sent: Wednesday, November 25, 2009 9:44 AM
Subject: Re: [Red5] How to secure red5?

> I'm thinking of this same thing.
> A webserver generates tokens per client request - puts them along with the
> client IP in a local database table, then pass the token to the client,
> which has to use the token when connecting (and also has to connect from
> same ip). The Red5 app checks the database table upon client connection.
>
> I'm thinking of the greatest weakneses in such a setup.
>
>
> Naicu Octavian wrote:
>> FMS has swf verification which at least protects you from someone making
>> its own swf to call functions on your Red5 app!
>>
>> referer verification can be easily bypassed
>>
>> you can also use verification tokens which are generated on your
>> webserver send to the swf then to red5 then red5 verifies them against
>> the web server again
>>
>>
>> 2009/11/24 Yann JAMAR <yann.jamar@...
>> <mailto:yann.jamar@...>>
>>
>> Hi all,
>> Everything works fine in my videoconference application BUT now ,
>> i would like to secure all that.
>> So i have implement Stream playback security , Stream publishing
>> security,ISharedObjectSecurity describe here :
>> http://www.joachim-bauch.de/tutorials/red5/HOWTO-Security.txt
>> Now the problem is that i would like to secure invoke methods. At
>> this moment , if someone is allowed to connect to my red5
>> application (using login and password registered during
>> registration), decomple my swf and show my call methods ,he can
>> change arguments of the client side call methods and send bad data
>> to my server.
>> I was thinking about check referer of the client side application,
>> but the referer can be easily falsified ...
>> Any ideas?
>> Regards , Yann.
>>
>
>
> _______________________________________________
> Red5 mailing list
> Red5@...
> http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

R: unequal delay on audio and video

2009-11-25T01:06:37Z

I need help on understanding how this works..

In the current solution I set the interval between audio timestamps by guess,

It is 2080 on a stream timebase of 1/90000.

This way audio and video are in sync, at least for a while; there are some other problems, but with this not being a correct solution I don’t bother.

So what if I calculate the audio frame duration? It comes out at 26ish msecs; I set the timestamp interval based on the stream timebase. The logs say my audio rtmp packets are correctly spaced at 26 msecs, but the end result is audio and video not in sync and lagging.

With my guess of 2080 the rtmp audio packets are every 23 msecs, but this doesn’t make much sense…

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Daniele Bettella
Inviato: martedì 24 novembre 2009 18.11
A: red5@...
Oggetto: [Red5] R: R: unequal delay on audio and video

Cancel the previous message, I forgot to enable the interleaving of packets…

Apparently I still need to understand how to correlate the stream timebase and the audio frame duration…

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Daniele Bettella
Inviato: martedì 24 novembre 2009 17.58
A: red5@...
Oggetto: [Red5] R: unequal delay on audio and video

Ok, I was able to calculate my timestamps based on the code in the mp3 header; it all works fine for the first minutes, but after a while I begin to notice a little delay on audio. I think this could be because the frame duration is calculated as

576 / (getSampleRate() * 0.001)

Inevitably this is not an integer, but the set dts requires one.

So whatever I do (and based on the stream timebase, which is 1/90000) I’ll need to transform a double into a long and hence introduce error…

And my audio will not be in sync.

I suppose there’s a solution to this, but what is it?

Daniele

Da: red5-bounces@... [mailto:red5-bounces@...] Per conto di Andy Shaules
Inviato: lunedì 23 novembre 2009 17.14
A: red5@...
Oggetto: Re: [Red5] unequal delay on audio and video

You should base your timestamps on the mp3 frame durations, not guesses.

Look at the MP3Header class in the red5.io.mp3 package. Use the class to determine each duration.

----- Original Message -----

From: daniele.bettella@...

To: red5@...

Sent: Monday, November 23, 2009 3:05 AM

Subject: [Red5] unequal delay on audio and video

I’m using Xuggle to publish an H264/mp3 live stream on red5. Audio and video are already encoded when they get to xuggle, so I do no transcoding, I just pass the packets on to red5.

Now, if I stream video only I have a small delay, around 0.3 secs, I don’t know where it comes from, but it’s either in xuggle/red5 or the player (which has a buffer of zero, btw). I could live with this delay (well, sort of), problem is, when I stream audio too this has a delay of little less than one second, resulting in audio and video not in sync.

So came the idea to force interleaving of packets (that is, using container.writePacket(packet, true)). This meant adjusting dsts by hand, since my packets had no timestamps to start with. This brought two problems:

1) I know how to adjust timestamps on video packets (since I have one frame per packet), but I had to guess on audio packets;

2) My best guess resulted in audio and video in sync (at least for the first minutes), but with a delay of one second which grew when insufficient bandwidths came out (streaming locally). Which is no good at all.

What I’d really like would be to minimize and balance the delays when non interleaving packets in xuggle, because that’s the way I have had the best results.

Also to note: if I stream video only at 15fps instead of 30fps the delay grows from .3 to .8 seconds (which, as a side effect, make audio and video in sync if I add it).

I’d really love to figure out where these delays come out from.

Thanks in advance.

Daniele

P.S.

I’m sending this on osflash for now, since my membership on the official group is pending

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

screen share with Xuggler

2009-11-25T01:05:09Z

Hi Guys,

I believe this topic has been discussed many times in the forum. Is there a conclusion? As far as I understand, here's the whole process:

1. Client A captures his screen using applet (taking advantage of java.awt.Robot)
2. Xuggler encodes the serial screen shots into a video (within the applet)
3. Client A broadcasts the video via red5
4. Client B subscribes to the stream and watches the video

But how does Client A broadcast the video? The Video info is still handled by the java applet. How does the applet inform red5? Any thoughts or advise are highly appreciated.

Thanks and best regards,
-Jingwei

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

Re: Red5 0.9.0 RC3 - trunk Rev 3967

2009-11-25T01:04:12Z

have you tried

sudo ant

from within the trunk directory?

could be permissions...

On Tue, Nov 24, 2009 at 7:06 PM, carlosl <carlosl@...> wrote:

Hello Everybody,

FYI.
I updated my dev version with trunk revision 3967 few minuted ago. it failed
compiling because of build.xml line 322 (../../flash/trunk/deploy).

I tried several times with same results. I had to create the folder tree
for /flash/trunk/deploy to compile sucessfully (BTW. My current trunk
installation is at /opt/Red5-development/red5_server_trunk in case it is
relevant)

While it is not critical, just wanted to let you know.

Regards,

Carlos Lozano
CAX IT Services
Houston, TX

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

Re: How to secure red5?

2009-11-25T00:44:59Z

I'm thinking of this same thing.
A webserver generates tokens per client request - puts them along with
the client IP in a local database table, then pass the token to the
client, which has to use the token when connecting (and also has to
connect from same ip). The Red5 app checks the database table upon
client connection.

I'm thinking of the greatest weakneses in such a setup.

Naicu Octavian wrote:

> FMS has swf verification which at least protects you from someone
> making its own swf to call functions on your Red5 app!
>
> referer verification can be easily bypassed
>
> you can also use verification tokens which are generated on your
> webserver send to the swf then to red5 then red5 verifies them against
> the web server again
>
>
> 2009/11/24 Yann JAMAR <yann.jamar@... <mailto:yann.jamar@...>>
>
> Hi all,
> Everything works fine in my videoconference application BUT now ,
> i would like to secure all that.
> So i have implement Stream playback security , Stream publishing
> security,ISharedObjectSecurity describe here :
> http://www.joachim-bauch.de/tutorials/red5/HOWTO-Security.txt
>
> Now the problem is that i would like to secure invoke methods. At
> this moment , if someone is allowed to connect to my red5
> application (using login and password registered during
> registration), decomple my swf and show my call methods ,he can
> change arguments of the client side call methods and send bad data
> to my server.
>
> I was thinking about check referer of the client side application,
> but the referer can be easily falsified ...
>
> Any ideas?
>
> Regards , Yann.
>
>

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

Re: How to secure red5?

2009-11-25T00:22:21Z

FMS has swf verification which at least protects you from someone making its own swf to call functions on your Red5 app!

referer verification can be easily bypassed

you can also use verification tokens which are generated on your webserver send to the swf then to red5 then red5 verifies them against the web server again

2009/11/24 Yann JAMAR <yann.jamar@...>

Hi all,

Everything works fine in my videoconference application BUT now , i would like to secure all that.

So i have implement Stream playback security , Stream publishing security,ISharedObjectSecurity describe here :

http://www.joachim-bauch.de/tutorials/red5/HOWTO-Security.txt

Now the problem is that i would like to secure invoke methods. At this moment , if someone is allowed to connect to my red5 application (using login and password registered during registration), decomple my swf and show my call methods ,he can change arguments of the client side call methods and send bad data to my server.

I was thinking about check referer of the client side application, but the referer can be easily falsified ...

Any ideas?

Regards , Yann.

----- Original Message -----

From: setyr@...

To: red5@...

Sent: Tuesday, November 24, 2009 7:52 AM

Subject: Re: [Red5] Tv-like red5 application

And here is a third Tv-like demo using only red5 and php+ajax :

http://www.nielsenaa.com/TV/tv.php

----- Original Message -----

From: bowljoman@...

To: red5@...

Sent: Sunday, November 22, 2009 5:57 PM

Subject: Re: [Red5] Tv-like red5 application

Another method:

red5 .9 rc1

shoutcasth264 jar

nsvtools with x264 encoding- Use flask from nsvtools to convert your files to NSV format with h264 vid and aac audio.

from scvi.net get nsvscsrcGUI.exe and stream files from client-side playlist. You can add,remove,arrange the playlist while in action.

Have fun!

Andy

----- Original Message -----

From: imdogma@...

To: red5@...

Sent: Sunday, November 22, 2009 6:14 AM

Subject: Re: [Red5] Tv-like red5 application

Thanks, i will try!
22.11.09, 13:58, "Manuel Raña" <info@...>:
Hi, take a look at the second commented code block (2nd "if" ) from:
http://red5.googlecode.com/svn/java/example/trunk/oflaDemo/src/org/red5/demos/oflaDemo/Application.java

This creates a ServerStream which do what you want

2009/11/22 Tipugin Alexander <imdogma@...>

Hello friends! Can anybody suggest any tutorial, how to create a tv-like application (or any tutorial, there described how to work with prerecored video and playlists)? I mean, i need application, there videos are playing in playlist order, and then user connects to the stream, he starts watching video from the moment, which is currently on the server.
I've spended 3-4 days of searching, but haven't get any results :((( Please help mates!

p.s. sry for my poor english :(

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

--
Яндекс.Почта. Письма есть. Спама - нет. http://mail.yandex.ru/nospam/sign

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.425 / Virus Database: 270.14.76/2518 - Release Date: 11/21/09 19:41:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com
Version: 8.5.425 / Virus Database: 270.14.79/2522 - Release Date: 11/23/09 19:45:00

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

xuggle - how to dynamically add/remove audio input in/from an outputStream

2009-11-24T23:29:13Z

Hi Guys,

I'm looking into a xuggle utility to combine multiple audio input streams into one OutputStream. I've checked AudioTranscoderDemo and found here's the line to link the streams:

Transcoder transcoder = new Transcoder(aStream,
outputStream, outputStreamInfo);

Then I checked the Transcoder class, but found it supports only one InputStream.

private final IBroadcastStream mInputStream;

How should Xuggle add inputs into the output and later remove from it? And once there're no inputs any more, stop the output?

Thanks and best regards,
-Jingwei

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

Recording live audio stream problem

2009-11-24T21:28:47Z

Hi, I got some problem when recording live audio stream, below is my code, my problem is, if the live audio stream is not continuous(eg. has data in second 1-3, silence in secend 4-8, has data in second 9-10 etc.), when I play the recording file, it will skip from second 3 to second 9. but If I record with ClientBroadcastStream.saveAs method, it will play correctly. Pls help, Thx.

Ping

===========code in streamManager.java=======
public void recordShow(IConnection conn) {
System.out.println("Recording show for: {}"+conn.getScope().getContextPath());
String streamName = String.valueOf(System.currentTimeMillis());
try {

   ClientBroadcastStream stream = (ClientBroadcastStream) app.getBroadcastStream(conn.getScope(), "BartiAudioStream");
   FileOutputStream fos = new FileOutputStream("d://temp//testScreen1.flv");
   FLVWriter flvWriter = new FLVWriter(fos,false);
   if(flvWriter!=null)
      writerlist.put(roomName,flvWriter);
   flvWriter.writeHeader();

   // Save the stream to disk.
   //stream.saveAs(streamName, false);
   long now = System.currentTimeMillis();
   MyAudioStreamListener audioListener = new MyAudioStreamListener (flvWriter);
    stream.addStreamListener(audioListener);
    audioListener.setStartTimestamp(now);

} catch (Exception e) {
   e.printStackTrace();
   logger.error("Error while saving stream: {}", streamName);
}

public void stopRecordingShow(IConnection conn) {
System.out.println("Stop recording show for: {}"+ conn.getScope().getContextPath());
FLVWriter flvWriter = (FLVWriter)writerlist.get("roomName");
flvWriter.close();
}

===========code in MyAudioStreamListener.java ================
public class ScreenAudioStreamListener implements IStreamListener
{
final private Logger log = Red5LoggerFactory.getLogger(ScreenAudioStreamListener.class, "deskshare");
private long sTimeStamp = -1;
FLVWriter flvWriter;
private final static byte audioTagType = 0x08;

public ScreenAudioStreamListener(FLVWriter flvWriter){
this.flvWriter = flvWriter;
}
public void setStartTimestamp(long startTimestamp) {
   this.sTimeStamp = startTimestamp;
}
public void packetReceived(IBroadcastStream aStream, IStreamPacket aPacket) {

    if (sTimeStamp == -1) return;
   try
    {
      IoBuffer buf = aPacket.getData();
     //System.out.println(buf.toString());
      if (buf != null)
        buf.rewind();
      if ((buf == null) || (buf.remaining() == 0))
      {
        this.log.debug("skipping empty packet with no data");
        return;
      }
      if (aPacket instanceof AudioData)
      {
       ITag tag = new Tag();
        tag.setDataType(audioTagType);
        tag.setTimestamp(getTimeStamp());
        tag.setBodySize(buf.limit());
        tag.setBody(buf);
        synchronized(flvWriter)
        {
          flvWriter.writeTag(tag);
        }
      }
    }catch (IOException e) {
     e.printStackTrace();
}

}

private int getTimeStamp() {
long now = System.currentTimeMillis();
int ret = new Long(now - sTimeStamp).intValue();
    return ret;
}

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

0.8.0 seek problem

2009-11-24T20:16:15Z

(Sent this to the new list, however it doesn't seem to show up there, so
sending to the old list.)

I'm using the Linux red5 0.8.0 release, streaming vp6 flv using rmtp.

Using the Flex "VideoDisplay" client.

It behaves a bit strange. During playback, I do a seek - sometimes the
player seeks for a while (I'm using a pretty slow connection atm, the
seeking/buffering until playback resumes can take several seconds) and,
even if the playback (and obviously buffering) does not actually stop,
the stateChange comes back with a "VideoEvent.STOPPED", which means the
player thinks the video has stopped. The Flex component is designed so
that when VideoEvent.STOPPED is received, no further update events like
time etc are retrieved anymore.

I'm a bit confused now if this is a problem of the server (like Red5
incorrectly sends a stopped or similar event), or with the Flex
component (like it "times out", waiting, at some point).
I'm really confused why this stop event comes up at all, because the
playback resumes normally after the buffering completes - the video
playback continues but some of the describing data stops coming.

/J

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

Red5 0.9.0 RC3 - trunk Rev 3967

2009-11-24T19:06:27Z

Hello Everybody,

FYI.
I updated my dev version with trunk revision 3967 few minuted ago. it failed
compiling because of build.xml line 322 (../../flash/trunk/deploy).

I tried several times with same results. I had to create the folder tree
for /flash/trunk/deploy to compile sucessfully (BTW. My current trunk
installation is at /opt/Red5-development/red5_server_trunk in case it is
relevant)

While it is not critical, just wanted to let you know.

Regards,

Carlos Lozano
CAX IT Services
Houston, TX

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org