[Red5] Major Red5 bug

[Jeremy Morton]

Andy Shaules wrote:
> Ok,
> Your code wont work for a few reasons. And yes It is irritating that you
> slam red5 and file a critical jira ticket without looking at your own
> code, but I still am immensly interested in timing.

I did not 'slam' Red5.  Claiming it has a bug is not the same thing. 
Please give me one example of where I 'slammed' Red5, or kindly don't 
accuse me of it.

> So to repeat: Your code wont work for a few reasons.....
> 1.
> You force a timestamp increment set to 10 frames per second regardless
> of data.
 >
> 'timestampCount+=  this.tsInterval;'

Yes, I do, because things don't work if I don't do that.  Some weird 
Xuggler/ffmpeg bug (I'm pretty sure it's not my incoming data).  It's 
not ideal, but I don't think it causes significant problems.

> 2.
> You dont even look at the timestamp of ANY of the packets but the first one

Why would I need to?

> 3.
> You do not handle the timestamp data that would be present when Xuggler
> and ffMpeg fail to decode a frame. Whether or not you decode it, it is
> still a frame with a stamp. you discard it and use its timestamp for the
> following successful decode.

That's true, and the odd frame will be dropped.  In time, this will mean 
that the buffer drops to zero.  By 'time', I'm talking hours.  This is a 
very minor problem for my purposes, because these streams are only 
really intended to be viewed for 5-10 minutes.

> Also...
> As far as testing, you havent even set up a stream listener to log the
> timestamps in the rtmp.

I don't really understand what you mean here, or how setting up such a 
stream listener would help in the slightest.

> I think that maybe xuggler is cofiguring the output to have AUDIO flag
> in the header.

According to the Xuggler code in Red5Handler.java's appendFLVHeader():
       byte audioVideoFlag = 0;
       if (mStreamInfo.hasAudio())
         audioVideoFlag |= 0x04;
       if (mStreamInfo.hasVideo())
         audioVideoFlag |= 0x01;
       in.put(audioVideoFlag);

My mStreamInfo has hasAudio() set to false, hasVideo() set to true.  So 
it looks like Xuggler is not doing that.

> Conclusion:
> So here is what happens in my opinion.....
> You load 4 seconds of data in the buffer but it reallity, _you have no
> idea how much data you send_ because _you always increment the timestamp
> by a full frame unit._

I disagree.  The fact that 4 seconds of buffer have built up implies 
that I have sent exactly 40 frames of video data, because I increment 
the timestamp by 100ms per frame.

Best regards,
Jeremy Morton (Jez)