In about 2-5 minutes, video freezes

[GoogleCodeExporter]

Reported by Valery <sentromed@mail.ru> on Dec 9, 2009.

I got the latest source code and I found another issue, that seems is more 
critical.
In about 2-5 minutes of playing, the picture freezes. I dig a little and found 
out that the recv on publisher's socket stoped getting data.

To reproduce it faster I do minor changes to inclease bitrate.
- I changed width and height for video to 320x240
- added the code to 'private function publish'
        ns.publish(name, record ? 'record' : null);

        var camera:Camera = Camera.getCamera();
        camera.setMode(wVideo, hVideo, 30);
        camera.setQuality(0, 100);

        local.attachCamera(camera);
        ns.attachCamera(camera);

In about 30 seconds, it stops working.

Thanks,
Valery.

Original issue reported on code.google.com by voiprese...@gmail.com on 3 Feb 2011 at 7:23

[GoogleCodeExporter]

More on Dec 10, 2009

Hi again,

If that helps you.

I added some output to rtmp.py at line 92.
  print("%.2f recv %d %d" % (time.time(), self.bytesWritten,self.bytesRead))

Connect, Publish (no play).
Last output was:
1260466911.62 recv 3396 2750043

2.6Mb - some migic value.

Valery.

Original comment by voiprese...@gmail.com on 3 Feb 2011 at 7:25

[GoogleCodeExporter]

Also reported by Stefan Bunse <sb@datenwust.net> on Apr 8, 2010

Hi!
I'm just trying / testing rtmplite for a videochat application!

Thanks a lot for this great piece of software (and for writing it in
my favourite scripting language python ;) )!!

After massive headaches trying to understand and use red5 a friend of
mine sent me a link to rtmplite and after reading your code and
comments things got much clearer in my head and i began to understand
rtmp much better!
Thanks a lot for that.

But I also found a problem with live video publishing: After some
minutes video hangs and on the receiving / playing side i only see a
still image until i reconnect and restart the publisher, but then
playback continues, so i'm quite sure the problem lies on the
publishing side.

This happens with the 4.0 release as well as with the current svn
trunk using unmodified server and testclient.

Running everything locally on windows 7 the freeze happens quite fast
(after about a minute, but did not measure it exactly), running the
server on a remote linux host it lasts some time longer (about 3-4
minutes) until video freezes.

Do you know this problem and / or have an idea, what's the cause for
this? I suspect an issue with some multitask, perhaps a queue running
full or empty, but i never used multitask before and this is just a
guess into the blue...

I would be glad if you have some tips on how to debug and hopefully
fix this problem.

Thanks in advance and best regards
Stefan
---
Hi Stefan,

Thanks for your encouraging comments :)

There is a debug/trace command line option, -d, I think, which you can
enable to see if there was any exception or warning message.

Another issue could be the bandwidth of the stream, that Python's
multitask is not able to handle the load... if you have access to Flex
you can try reducing the bandwidth of the Camera object
(Camera.setQuality()).

Another option is to try out with/without video, and with/without
audio, enabled. Also if you can print any warning events on the
NetStream object (Flex/ActionScript), that can give more information.

I have been using it in videocity project for some testing but haven't
run across this issue. But I do most of my testing on Mac.

Good luck and lemme know how it goes!

---

sorry i didn't write for such a long time, but I was really busy the last 
weeks, not at least working on rtmplite for the project i'm currently involved 
in.

i did not yet have the time to produce a cleaned up version with the updates 
and fixes i made in the meantime, but i wanted to let you know about two bugs 
that took me lots of time to find and fix.

the first is about sending acknowledgement messages to a video (media) 
publishing client.

I'll attach my current rtmp.py and comment on the two most important bugfixes 
for now. i promise i'm going to clean up everything and send you the complete 
modified sources, but for now it's a mix-up of business logic, modified logging 
strategy and no more compatible with your testClient, so i don't want to send 
it out like it is at the moment...

the following line numbers refer to the modified version of rtmp.py i attached.

In lines 708-712 i check if an acknowledgement message is needed and sent it if 
so. the corresponding instance variables are initialized in lines 555-556 and 
updated in line 595-597 if the client sends a window acknowledgement message. 
This fixes the problem of the client suddenly stopping to send any more video 
data after a while i told you about in my last mail.

the other bug that nearly drove me crazy is about relaying video data. if 
rtmplite relays data between streams with different controlstream ids, the 
lastReceivedHeaders of the Protocol instance receiving the video from the 
publishing client got modified by the Stream.send() method, so only the first 
message got relayed correctly, all following messages received by the 
publishing client got assigned the wrong controlstream id because of the wrong 
id saved in lastReceivedHeaders in combination with the rtmp header 
"compression". The fix is to copy the message header in Stream.send() before 
setting the controlstream id of the receiving Stream instance (see line 1016).

these two are the only real bugs i remember to have fixed for now, all other 
changes are more of a cosmetic nature, a changed multi-instance handling and 
changed logging and config system.

for now that's it, i'm going to have a glass of wine now after uncounted hours 
searching for the controlstream id bug ;)

kind regards
stefan

Original comment by voiprese...@gmail.com on 4 Feb 2011 at 6:44

Attachments:

• rtmp.py

[GoogleCodeExporter]

Reviewed and applied the changes sent by Stefan Bunse in r38, version 7.0. This 
fixes the problem about video freeze after some time.

Original comment by voiprese...@gmail.com on 4 Feb 2011 at 11:01

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by voiprese...@gmail.com on 4 Feb 2011 at 11:36

• Changed state: Fixed