changing rtsp buffer size in quicktime?
I am currently playing around with a network camera and am getting the rtsp video stream into jitter ok, however the streaming buffer is so large there is ~ 3-4 second delay. Looking at the stream in VLC (the QT alternative) is much better since there is a way to adjust the buffer setting (set to 50ms and seems to be quite lovely)…however no option in quicktime, and can’t see any path in jit.qt.movie to adjust the setting if it was possible. Anybody run into this and try to change the buffer setting? On a mac, btw, 10.6.6.
I’ve run into exactly the same problem: the video quality is fine, but I have a 2 sec delay using jit.qt.movie with read rtsp://etc. As described above, the problem is not the stream itself, as I can play it back almost in realtime with VLC.
I have also scrutinized the options I find in the standalone QT player (maybe the settings tweaked there are system-wide, so also apply to Max), but no results so far. I run this on Win7 Ultimate and pro, different machines make no difference (3GHz quad and six-cores), the network is a gigabit.
Thanks in advance!
same problem here!
anyone has something?
I was pointed to the solution in a different thread, but I think double-posting makes sense here (the threads speaking about this are often 5 or 6 yrs old…)
So, here is it:
- There is absolutely no way to change buffer-size or whatever for the jit.qt.movie object.
- If you need to stream real-time, use jit.netSend/Receive, it works like a charm, latency is something like 25ms (In the world of audio this is not real-time, of course, but the human eye is ridiculously inefficient)
- Caveats: if you need to set a different port than the default one, you have to do this in the netSend object itself, like this:
----------begin_max5_patcher---------- 553.3ocyVF0aaBCDG+YpT+NXwyYHe1g.rm59bLUM4.tTWA1LriV5p128YLAF KDTnL1xd.r3r8w+6246f2t+NO+8pibsO5inOi77dyZwyYqwhWmAO+R1wzBl1 sP+TUYIWZ72bZRC+nwMQot2VEyj9rPl+kZdpo08.MI.uAQH6bCac2wAXzica 5IkzHYkbmy9TsfUz6OQlynZ+KeHNt2p7PoPVvMNcACciV7cma.HHLIDhiFrE 0AS2dvNq+396ZFsCalMDJ4ZMKmOFB4bSAyvkou1OW6Kz7ZEukD99+JluDnZI TjCW6fl6P7B3Txk4DYAbBVLmLp77B9znPXOHMGZb5Nd7olAgbBbkiFqUTI4e y99Fm7+ZI2TqPg3oC38LY9rh3PhK+SWZcRB4+g7+SEJqqlFG14Y1VIygKI3f vl9GtNGg32EWL0BcJqvMENH4R3htdsUH2txEZaeUBLmxk3ab4Rs06bTpRJs5 mmgtdiyMmtlACfjX2.krzJH.iWuyDzUmduHLARtIPykYnGpT0FTz1nPzChJa vSBfcV.D.XXoeH5DGiZOR8GvQf92qUTqX7KDxQ+GiKjZl3L5pUGpS6PP22MP CBqLt1HjLiPIGtJxuupmEYYb2BvclJEYUJaM5Ikfdb5j9rEm6THBtp5n2D0c NTtr3Z9Wj2m3.ZXS29HZaMb+CqHRudBO91jvA5bT2nf3ej7NOWNg5.5BS4vV W+lsz9GFI6FC1geBPmuyhB -----------end_max5_patcher-----------
(I initially tried to bang it into the NetSend object, don’t do this, it will not work and the error message you get is a bit misleading)
I have not set the IP of the sending computer in the listening patch, making it listen to "any" (default option) was fine for me.
When you have started to make it work, you will see that it is a VERY forgiving and easy way to send video around the network.
(No, I do not know how to stream audio, sorry).
Streaming audio is done by using the jit.catch~ and jit.release~, use this two objects in combination whit jit.net.send/receive.
Let me get it straight, netSend object is good to send matrices over the network, but what if I need to get a stream from an IP camera? I tried with the patch posted by transponderfish but with no result. Have you guys managed to get the video stream without long latency?
I have the same problem.
The IP cam works fine in a browser.
I have a 3-4 seconds latency in Jitter (quality is very good, 30ips).
Any clue ?
y r a.
I ended up using a third party object, jit.ffdec:
Scroll down to the "receiving video" section. It works with minimal latency (< 50ms), but is a bit buggy (lots of crashes when quitting or changing parameters/closing the stream once a stream is open). There also seems to be some occasional buffering/processing issues where frames would come in out of order and cause a visual mess (the QT stream always appeared OK when this happened, so assumed there was some issue with the external). The buffering/processing issue seemed party related to CPU load in max, so created a standalone that just captured the stream via jit.ffdec, then re-streamed to another standalone via jit.send/recv where most of the post-stream image processing is taking place (latency on this step was < 1ms). It's been working for several months in an installation, but would still love to find another alternative, or have someone look at the jit.ffdec source code and see what the issues might be?
Hope this helps some!
Thanks for your answer.
The download is no longer available and I can’t find a way to contact them.
Can you share this object ?
y r a.
See if this works for you.
edit: maybe not…file is too big!
edit #2: actually download is available…it’s included in the oggZmax-v0.6-i386.zip file towards the top of the page.
Have you tried to download the file ? I have a 404 error.
Can you just send the object ? I think I don’t need the whole oggZmax package, do I ?
As I said…it’s too large to post so I’ll need an email address.
Robin Gareus sent me new download links.
He told me the old ones will be fixed soon.
Thanks for your help.
Forums > Jitter