1 person found this helpful
audio should be higher priority than a .send(), but video is the lowest priority of all. because of that, i wouldn't expect the audio to freeze.
depending on the characteristics of the network path between the two clients, if the network buffers and never loses data, the path will appear to RTMFP as having a very high latency but not remarkable bandwidth. the data of the .send() could all be in the network (because it fits) ahead of the audio and video.
there are other potential explanations. it would be interesting to know if the behavior is the same if, instead of doing one send() of a 512KB object, if you did 8 sends of 64KB objects, or even more sends of smaller objects.
Even with the smallest files the whole thing freezes up until the file is pushed through. I did experience something interesting the other day, a 6mb file was accidentally sent through instead of a 6 kb file, anyway the result was 15 minutes later i heard some audio, and also saw the video from just after it froze on me. It seemed like flash was trying to fast forward the video to catch it up, about 2 minutes of 15 minute old video. The sound also was there, and in sync with the audio.
Is there any way to get the file through, where the network won't buffer it all and freeze everything?
i found a few interesting things. if at the subscribing end i set a buffer time of non-zero ("buffered mode"), then i see video and audio freeze until the large file is completely received. however, if i set the buffer time to zero ("live unbuffered" mode) and send a large file, then only the video freezes (until the very end -- i'll get to that in a second). in both cases with a packet sniffer i was able to see the audio packets going from the publisher to the subscriber (even if the subscriber wasn't playing them back).
i believe that in "buffered mode" the receiving end was trying to maintain audio and video sync, but the video was delayed so it halted everything. in "live unbuffered" mode, it played the audio as soon as it arrived (which was immediately) even though there was no video to play (since it was queued up behind the file transfer).
i believe this behavior is approximately correct given the priorities of the video, audio, and data.
the one behavior i observed which is not correct (and we'll investigate more) was that *after* the file was completely sent, both audio and video *stopped* being sent by the publisher for a few seconds. this was with a 6MB file. i suspect this delay may be related to clearing out the video backlog, but more investigation is needed to determine the real cause.
remember that the semantics of NetStream.send() is of placing a method call *in the timeline* synchronized with audio and video. if it takes a significant amount of time (seconds or minutes) to send the data to the receiving end, then the timing model is already broken. i don't believe NetStream.send() was originally intended for large bulk data transfers, and so it's not a surprise that it doesn't behave ideally for this use case. at the very least, NetStream.send() must be higher priority than video so that it can be used for signaling and have it have a chance of getting through when the channel is constrained (since video can so easily use so much bandwidth, while it's hard to use a lot of bandwidth on audio).
i can think of two things to try:
1) stop sending video while the file is transferring (perhaps have the receiver send a message back indicating that it's fully received to re-enable the video).
2) try sending the file over a separate NetStream than the one you're using for audio and video (that is, publish a second NetStream whose sole purpose is for data transfer).
let us know if one or both of those make a difference.
note that for thing-to-try #2, using a separate NetStream won't keep the video from freezing (since the.send() data is still higher priority than video), but it *might* affect the audio freezing even in buffered mode, and might also affect the few-seconds-freeze of audio and video in unbuffered live mode.
i highly recommend doing #1, though.
another thing to try (with Flash Player 10.1 beta) would be to set NetStream.videoReliable to false at the publisher. that might help with the backlog.
I'll give it a try. For flash player 10.1, is there a debug player for that available yet? I guess what i'm trying to do is reproduce a simple chat application, that has a way to push a file from one person to the other, kinda like windows live, or google talk. (Really helpful for the workplace when your throwing jars and wars around) It seems like they push there files through p2p, maybe not their messages though. What I'd like to ultimately do is show a progress bar on both ends showing how much has been sent/recieved of the file. And keep that slower than the audio/video.