When recording buffered video packets are appended to the end of the .flv file.

[naicuoctavian]

When trying to record audio+video over a slow connection, FlashPlayer will buffer the video and send only the audio to the server.

What happens is that the .flv file will get written before the buffered video data will reach the server, thus the video data will be most probably writtenat the end of the video file resulting in .flv files in which the audio streams fine but the video data is all at the end and plays all at once in a "fast-forward like" way.

No video data across the .flv file also means no keyframes which means no way to seek to that area of the video.

I have reproduced this with Red5 0.8 RC1 and NetLimiter.

For FMS 3 there is a workaround for this issue.
IFMS 3.5 will have this issue fixed from the start.
Wowza waits longer for the packets and rearrages them, thus does not have this issue.

[aclarke]

Hi. As part of an effort to clean up our bug database we're resolving issues that haven't been commented on for a while as incomplete, and asking the filer to please reverify the bug in the current tip of tree. Sorry about that, but we need your help.

To reopen, make sure the bug is still happening, and then please upload as much information to help us. In fact, the best thing you can do is:
1) give steps to reproduce
2) give log files/data that shows problem
3) write a JUnit test that reproduces the issue
4) submit a patch

bugs that do all 4 will get attention the fastest.

Thanks,

- Art

[aclarke]

Naicu claims on the Red5 list that this is still a problem. I'm re-opening but for RC3;

I'm also assigning to me until it has more information in it that makes it easier for Paul to debug or until someone (hint) volunteers a patch.

[ir73]

I have a sample application which produces that bug in latest trunk. Please launch Streamer.swf and stream with audio for 5 seconds. Then check "streams" folder in oflaDemo webabb, and play "camera_test2.flv" file in VLC video player. You will notice that the sound is lagging which is a bug. However, if you play that file via Adobe Media Player, it will pay as expected, but watch how fast seconds are running on the counter. So this is a buggy video, recorded as invalid flv file by Red5.

I use red5 installed on localhost so there's nothing like slow connection. This bug does not depend on the connection speed.

I think this is a critical (or even blocker) issue because it makes using red5 impossible for recording files.

[ir73]

I have found that a bug that is described in my last comment occurs in revision 3671, but it was not present in rev 3670. The problem is in ClientBroadcastStream.java class. Commit log is "Patch for client broadcast stream for relative timestamping across all packets."

 http://code.google.com/p/red5/source/browse/java/server/trunk/src/org/red5/server/stream/ClientBroadcastStream.java?spec=svn3671&r=3671

[mondain]

I'll look into this for 0.9 release

[mondain]

I cannot reproduce the issue locally using the attached swf's. I do however believe there is an issue with the FLVWriter when encountering a slow broadcast connection. I have a strategy to combat this and will add some buffering to resolve this issue.

[mondain]

This should no-longer occur as of revision 4018. This revision contains a queue in which items to be written are queued up to a threshold (default 33) and are then sorted by timestamp and sent to the writer. If you still experience an issue with recordings, you may simply increase the threshold via Spring.