Difference between revisions of "Talk:Str"
| (4 intermediate revisions by 3 users not shown) | |||
| Line 4: | Line 4: | ||
Another issue we are having with the streamer is that when we enable audio and multicast then the stream works with the first client that connects but then when the second client connects there is a librtsp: buffer overflow in rtsp_get error displayed and both clients drop the stream. | Another issue we are having with the streamer is that when we enable audio and multicast then the stream works with the first client that connects but then when the second client connects there is a librtsp: buffer overflow in rtsp_get error displayed and both clients drop the stream. | ||
--Garth McDonald | --Garth McDonald | ||
| + | |||
| + | |||
| + | Thank you for testing and bug-report. They are several different issues with the streamer, Landy will look on. Have you tried the last streamer from CVS? I am interested, for how long have you recorded video+audio with camogm2 ? It would be interesting to make an overnight test. | ||
| + | |||
| + | It would be interesting to try also str with audio in VLC, could you please ? --[[User:Polto|Alexandre.Poltorak]] 20:45, 5 June 2009 (CDT) | ||
| + | |||
| + | I guess I didn't mean to start a discussion about camogm2 here but as you asked we tried to record with camogm2 for a long period of time and discovered that it does not respond after awhile while recording with audio. We did not even get a long enough recording to attempt a overnight recording. camogm does record overnight and camogm2 records as long as audio is not enabled. Is there any particular reason camogm2 becomes non responsive while recording with audio? Is it a driver issue? | ||
| + | |||
| + | Back to the streamer - yesterday we did more testing and we updated to the latest CVS and still had the same issues with audio syncing with mplayer. We then tried VLC and there is no issue with syncing audio in vlc. That leaves us with the following questions: | ||
| + | |||
| + | 1 - Is the audio and video streams from the camera not in sync or is the client compensating by dropping frames? | ||
| + | |||
| + | 2 - How do we verify that we are not loosing frames at the cost of having audio? | ||
| + | |||
| + | 3 - Why does the streamer fail when you are in multicast mode with audio enabled and the second client connects? | ||
| + | |||
| + | --Garth McDonald 9, June 2009 | ||
| + | |||
| + | ''2 - How do we verify that we are not loosing frames at the cost of having audio?'' | ||
| + | |||
| + | You can using '''rtptools''' for it(look http://www.cs.columbia.edu/irt/software/rtptools/). You can dumping headers RTP stream and look at sequences of packets. | ||
| + | |||
| + | ''3 - Why does the streamer fail when you are in multicast mode with audio enabled and the second client connects?'' | ||
| + | |||
| + | Do You start client on same PC or on different? Can You try next: configure streamer for multicast stream, next start first client like | ||
| + | |||
| + | mplayer rtsp://camera_ip:554 | ||
| + | |||
| + | but starting next clients via | ||
| + | |||
| + | mplayer sdp://camera.sdp | ||
| + | |||
| + | where camera.sdp - SDP file, generated by str for first client?(You can look at it for SDP file ''mplayer -msglevel all=9 rtsp://camera_ip:554'') | ||
| + | |||
| + | --[[User:Landy|Andrey Latin]] , 18 June 2009 | ||
Latest revision as of 19:52, 17 June 2009
Currently one of the problems we are having with the streamer is with the audio syncing. We are using a plantronics usb audi device that is unmarked other than the brand. When we use camogm2 and write to a sata device then we don't have any syncing issue with the audio and video and playback is great. But when we use the streamer and enable audio the audio and video are fine at the begining but then they slowly begin to go out of sync. So far we have tried to use the -autosync parameter with mplayer and the -framedrop parameter but neither seem to help with the issue but mplayer does show that the audio and video are out of sync.
Another issue we are having with the streamer is that when we enable audio and multicast then the stream works with the first client that connects but then when the second client connects there is a librtsp: buffer overflow in rtsp_get error displayed and both clients drop the stream. --Garth McDonald
Thank you for testing and bug-report. They are several different issues with the streamer, Landy will look on. Have you tried the last streamer from CVS? I am interested, for how long have you recorded video+audio with camogm2 ? It would be interesting to make an overnight test.
It would be interesting to try also str with audio in VLC, could you please ? --Alexandre.Poltorak 20:45, 5 June 2009 (CDT)
I guess I didn't mean to start a discussion about camogm2 here but as you asked we tried to record with camogm2 for a long period of time and discovered that it does not respond after awhile while recording with audio. We did not even get a long enough recording to attempt a overnight recording. camogm does record overnight and camogm2 records as long as audio is not enabled. Is there any particular reason camogm2 becomes non responsive while recording with audio? Is it a driver issue?
Back to the streamer - yesterday we did more testing and we updated to the latest CVS and still had the same issues with audio syncing with mplayer. We then tried VLC and there is no issue with syncing audio in vlc. That leaves us with the following questions:
1 - Is the audio and video streams from the camera not in sync or is the client compensating by dropping frames?
2 - How do we verify that we are not loosing frames at the cost of having audio?
3 - Why does the streamer fail when you are in multicast mode with audio enabled and the second client connects?
--Garth McDonald 9, June 2009
2 - How do we verify that we are not loosing frames at the cost of having audio?
You can using rtptools for it(look http://www.cs.columbia.edu/irt/software/rtptools/). You can dumping headers RTP stream and look at sequences of packets.
3 - Why does the streamer fail when you are in multicast mode with audio enabled and the second client connects?
Do You start client on same PC or on different? Can You try next: configure streamer for multicast stream, next start first client like
mplayer rtsp://camera_ip:554
but starting next clients via
mplayer sdp://camera.sdp
where camera.sdp - SDP file, generated by str for first client?(You can look at it for SDP file mplayer -msglevel all=9 rtsp://camera_ip:554)
--Andrey Latin , 18 June 2009
