What are reasons for NetStream.Buffer.Empty?

[Wim Deblauwe]

I have a red5 application that converts a live stream to a flash
stream. However, sometimes, the streaming video is just a still image.
I have no idea why this sometimes happens, but if it does happen, I
get this:

[trace] 7/2/2010 13:45:06.351 [DEBUG] VideoPlayer (#1) onNetStatus:
'NetStream.Buffer.Full'
[trace] 7/2/2010 13:45:06.351 [DEBUG] VideoPlayer (#1) onNetStatus:
'NetStream.Buffer.Empty'

The buffer gives an Empty status and not a full status. Who is sending
out those events? Can I do something about it? I have no idea where to
start debugging this problem, so any help is highly appriciated.

regards,

Wim

[Rob Schoenaker]

Wim,

NetStream events are client side (info) events. There can be a number of
reasons for this happening, even local PC issues (CPU limitation).

Mos probably, there is an issue with either bandwidth or timestamps of the
video frames. Bandwidth can be monitored with tools like WireShark.
The audio/video frame timestamp requires insight into the sent packages.

These are just some pointers to a possible solution.

HTH,

/Rob

[Wim Deblauwe]

Hi Rob,

thanks for the quick response. I will do a google search on how to use wireshark for the bandwidth. Can you elaborate on the timestamps? We are only doing video, not audio. 

regards,

Wim

2010/7/5 Rob Schoenaker <r...@schoenaker.eu>

[Wim Deblauwe]

Hi,

it seems indeed that the timestamps are behaving wrongly, this is some output from my application:

2010-07-05 12:38:12,963 [ProcessorService-1] TRACE RTSPProcessor [fca7c6f4596f7cb84922f74bcaae0a7f_232_202_512] Writing event to output stream: Video - ts: 280 length: 263
2010-07-05 12:38:13,015 [ProcessorService-1] TRACE RTSPProcessor [fca7c6f4596f7cb84922f74bcaae0a7f_232_202_512] Writing event to output stream: Video - ts: 320 length: 328
2010-07-05 12:38:13,017 [ProcessorService-1] TRACE RTSPProcessor [fca7c6f4596f7cb84922f74bcaae0a7f_232_202_512] Writing event to output stream: Video - ts: 360 length: 464
2010-07-05 12:38:13,069 [ProcessorService-1] TRACE RTSPProcessor [fca7c6f4596f7cb84922f74bcaae0a7f_232_202_512] Writing event to output stream: Video - ts: 580721980 length: 590
2010-07-05 12:38:13,069 [ProcessorService-1] DEBUG RTSPProcessor [fca7c6f4596f7cb84922f74bcaae0a7f_232_202_512] Reached FPS or max awake time
2010-07-05 12:38:13,069 [ProcessorService-1] DEBUG RTSPProcessor Sent frames: 11  -  FPS: 10
2010-07-05 12:38:13,069 [ProcessorService-1] DEBUG RTSPProcessor Awake for 421.299554 ms 
2010-07-05 12:38:13,121 [ProcessorService-1] TRACE RTSPProcessor [fca7c6f4596f7cb84922f74bcaae0a7f_232_202_512] Writing event to output stream: Video - ts: 580722020 length: 1773

Notice how the timestamp jumps from 360 to 580721980. Would you (or someone else) have a clue why there is such a jump in the timestamp?

regards,

Wim

2010/7/5 Wim Deblauwe <wim.de...@gmail.com>

[Rob Schoenaker]

Wim,

 

Which version are you using? IIRC, there were some timestamp issues in the past...

Also, keep in mind that timestamps are stored in an awkward manner in flash, 3 bytes and then 1one byte for msb (most significant). I am not sure what the RTSPProcessor is, but I assume it is something you did yourself?

 

I am on holidayleave from tonight onward so maybe someone on the list can give you an additional hand with this.

[Wim Deblauwe]

I tried with the latest version that their hudson is building (http://build.xuggle.com/job/red5_jdk6_stable/387/) and the issue is still present. RTSPProcessor is something the red5 guys created for my company, see http://imux.svn.sourceforge.net/viewvc/imux/trunk/imux-server/src/main/java/net/sourceforge/imux/process/RTSPProcessor.java?revision=3&view=markup

Do you have a reference on how the bytes are stored?

[Rob Schoenaker]

Wim,

 

I do not have time to check the code fully today (after holiday is OK)

the bytes are stored as mentioned in this document:http://www.adobe.com/devnet/flv/pdf/video_file_format_spec_v9.pdf

See 'FLV tags'

For now: good night and good luck :-)

[Wim Deblauwe]

After some more investigation, it might be in the Xuggle code. I
posted to their mailinglist: http://groups.google.com/group/xuggler-users/browse_thread/thread/1d75caed2b96fd1a

On Jul 5, 9:17 pm, "Rob Schoenaker" <r...@schoenaker.eu> wrote:
> Wim,
>
> I do not have time to check the code fully today (after holiday is OK)
> the bytes are stored as mentioned in this document:http://www.adobe.com/devnet/flv/pdf/video_file_format_spec_v9.pdf
> See 'FLV tags'
> For now: good night and good luck :-)
>
> /Rob
>
>
>
>   ----- Original Message -----
>   From: Wim Deblauwe
>   To: red5in...@googlegroups.com
>   Sent: Monday, July 05, 2010 9:11 PM
>   Subject: Re: [Red5] What are reasons for NetStream.Buffer.Empty?
>

>   I tried with the latest version that their hudson is building (http://build.xuggle.com/job/red5_jdk6_stable/387/) and the issue is still present. RTSPProcessor is something the red5 guys created for my company, seehttp://imux.svn.sourceforge.net/viewvc/imux/trunk/imux-server/src/mai...

>
>   Do you have a reference on how the bytes are stored?
>
>   regards,
>
>   Wim
>
>   2010/7/5 Rob Schoenaker <r...@schoenaker.eu>
>
>     Wim,
>
>     Which version are you using? IIRC, there were some timestamp issues in the past...
>     Also, keep in mind that timestamps are stored in an awkward manner in flash, 3 bytes and then 1one byte for msb (most significant). I am not sure what the RTSPProcessor is, but I assume it is something you did yourself?
>
>     I am on holidayleave from tonight onward so maybe someone on the list can give you an additional hand with this.
>
>     HTH,
>
>     /Rob
>       ----- Original Message -----
>       From: Wim Deblauwe
>       To: red5in...@googlegroups.com
>       Sent: Monday, July 05, 2010 12:53 PM
>       Subject: Re: [Red5] What are reasons for NetStream.Buffer.Empty?
>
>       Hi,
>
>       it seems indeed that the timestamps are behaving wrongly, this is some output from my application:
>
> 2010-07-05 12:38:12,963 [ProcessorService-1] TRACE RTSPProcessor [fca7c6f4596f7cb84922f74bcaae0a7f_232_202_512] Writing event to output stream: Video - ts: 280 length: 263
> 2010-07-05 12:38:13,015 [ProcessorService-1] TRACE RTSPProcessor [fca7c6f4596f7cb84922f74bcaae0a7f_232_202_512] Writing event to output stream: Video - ts: 320 length: 328
> 2010-07-05 12:38:13,017 [ProcessorService-1] TRACE RTSPProcessor [fca7c6f4596f7cb84922f74bcaae0a7f_232_202_512] Writing event to output stream: Video - ts: 360 length: 464
> 2010-07-05 12:38:13,069 [ProcessorService-1] TRACE RTSPProcessor [fca7c6f4596f7cb84922f74bcaae0a7f_232_202_512] Writing event to output stream: Video - ts: 580721980 length: 590
> 2010-07-05 12:38:13,069 [ProcessorService-1] DEBUG RTSPProcessor [fca7c6f4596f7cb84922f74bcaae0a7f_232_202_512] Reached FPS or max awake time
> 2010-07-05 12:38:13,069 [ProcessorService-1] DEBUG RTSPProcessor Sent frames: 11  -  FPS: 10
> 2010-07-05 12:38:13,069 [ProcessorService-1] DEBUG RTSPProcessor Awake for 421.299554 ms

> 2010-07-05 12:38:13,121 [ProcessorService-1] TRACE RTSPProcessor [fca7c6f4596f7cb84922f74bcaae0a7f_232_202_512] Writing event to output stream: Video - ts: 580722020 length: 1773Notice how the timestamp jumps from 360 to 580721980. Would you (or someone else) have a clue why there is such a jump in the timestamp?regards,Wim
>
>       2010/7/5 Wim Deblauwe <wim.debla...@gmail.com>

>
>         Hi Rob,
>
>         thanks for the quick response. I will do a google search on how to use wireshark for the bandwidth. Can you elaborate on the timestamps? We are only doing video, not audio.
>
>         regards,
>
>         Wim
>
>         2010/7/5 Rob Schoenaker <r...@schoenaker.eu>
>
>           Wim,
>
>           NetStream events are client side (info) events. There can be a number of reasons for this happening, even local PC issues (CPU limitation).
>
>           Mos probably, there is an issue with either bandwidth or timestamps of the video frames. Bandwidth can be monitored with  tools like WireShark.
>           The audio/video frame timestamp requires insight into the sent packages.
>
>           These are just some pointers to a possible solution.
>
>           HTH,
>
>           /Rob

>           ----- Original Message ----- From: "Wim Deblauwe" <wim.debla...@gmail.com>

[Rob Schoenaker]

Wim,

Got back from holiday and I noticed you had not nailed this issue yet.
Some more pointers that could be useful:

I have done some FFMpeg with C# and I have come across similar problems with
DTS and PTS. These two value are basically the timestamp that represents the
time of display (DisplayTimeStamp) and presentation (PresentationTimeStamp).
There is some confusion about these two. My custom C# code does not use
these value to determine the actual timestamp, since some container formats
handle them incorrectly.

IOW: do not use the timestamps IN the stream, but instead use the duration
of each frame to determine the timestamp for the video.

Note that this only occurs with VOD streams (from a file). I have had good
luck with relying on the duration only (and the DTS/PTS from the first
frame)

Hope this helps!

/Rob

----- Original Message -----
From: "Wim Deblauwe" <wim.de...@gmail.com>
To: "red5" <red5in...@googlegroups.com>

[Wim Deblauwe]

Thanks for that Rob, I am going on holiday today. If I have some time I will try that still today, otherwise it will be after my holiday. I hope I get get the duration of the frame somewhere.

regards,

Wim

2010/7/19 Rob Schoenaker <r...@schoenaker.eu>