problems with RTSP client for PTZ Optics HD Box camera #400
Comments
MartinPulec
changed the title
DNM refers to CESNETGH-400
show only in fullhelp \+ added the fullhelp option \+ pretty-print the output (use colors) refers to GH-400
If no port is included in the URI, use 554 (default RTSP). refer to GH-400
|
Hi, I've looked into it and make some observations and changes.
Except that, I've also made couple of further improvements:
The changes are already included in the continuous build. Please let us know if it works now with the proposed RTSP port syntax. |
|
The changes in the continuous build are a big improvement, thank you ! Unfortunately I still can't get rtsp working from this device, but that seems to be more a problem with the device itself. I am going to poke at it more and try to see what's going on. Just out of interest: is there a verbose switch I can use for UG to see more complete logging? |
|
So I just tried a passthrough from the camera device with ffmpeg to the MediaMTX/Simple RTMP server with similar results. UG Command Line: Output: FFMPEG command (stream copy):
VLC is able to open the stream, so it appears that everything is working, however UG is not picking it up. Adding a slash gives me a slightly different output that's more in line with what attempting a direct connection to the camera device gives: The RTSP server is outputting only this: Obviously even If I could get it working this way, it's not a practical solution as the ffmpeg binary and rtsp server introduces a horrendous latency, but I figured I would try it out to provide more information. For completeness sake here is the command I used to launch the mediaserver container:
|
Sure, Anyways, related to this, I've just added a verbose logging of the options that are being set to see, what exactly does the
Thanks, I'll try tomorrow to see if I am able to reproduce.
I am not expert on RTSP URI syntax but it may be possible, that the slash isn't allowed there. I hope that I'll be able to give you more info if I am able to to reproduce with FFmpeg. At least I've just noticed a potential problem in the output: even when user:pass is not provided in URI, which I suppose is not correct. |
|
Great - Here is the output from the new continuous build with the command |
|
Great, thanks for the UltraGrid output. I think that I can see the current problem now. In your SDP, there is: So the video is MJPEG and audio AAC (not sure if in stream container, like MPEG PES). The current implementation of RTSP client in UltraGrid has currently quite limited set of supported codecs. I think that we can add JPEG with not so much effort. I'll see what about AAC (if it is also important for you), I don't have currently how to test (eg. if I get FFmpeg to produce one). |
|
Great! Audio isn't strictly speaking necessary for my purposes but I suppose it would be nice-to-have. |
|
Just gave it a try on the recently published 1.9.5, same behavior; |
|
Tested again on this morning's continuous build - curl error gone, now the error message says "no usable video stream" as per log below; |
|
Another update: I was able to get into the device settings and configure it to output an H.264 stream, which DOES work fine via RTSP. However JPEG does not work, nor does H.265. |
|
Thanks for the update, I can confirm that for video only H.264 is currently supported for RTSP. I believe that I'll be able to add JPEG soon (H.265 could be also possible later). |
JPEG done, it should be already included in the continuous builds. It won't be, however, ported to UltraGrid 1.9.X but to next major version. I'd be glad if you could test - it should decode the JPEG formats specified in RFC 2435, but the format allows also custom types. |
|
Hi Martin, My apologies for not getting back within a reasonable time on this. I had to adjust my attention to other tasks for a while. I have just tested the hardware in question with MJPEG compression and I can confirm it's working fine in the continuous build. The first test segfaulted after a small amount of time, but that might have been because I was using -VV, or possibly down to a poor stream from the device - which is not something we can control. A subsequent test ran for much longer and seemed both lower latency, and more stable than ingesting H264 from the device. Thank you very much for your attention on this! |
Well, this should not happen. Actually especially when using
Also not a thing that should not happen. If you could provide more information to debug (stacktrace, console output) it will be great. |
Apologies to resurrect this old discussion, but I seem to be having some issues here - FFPLAY works fine;
However UltraGrid is giving me some error message:
I did a few searches and found this extremely old StackOverflow post;
https://stackoverflow.com/questions/18525980/rtsp-client-sending-delimited-data-before-session-has-been-completely-set-up
The RTSP server device is a PTZ Optics HD Box camera (PoE) - it might just be that it's putting out a bad stream.
My apologies in advance if this is a poor question, and I have missed something simple.
Originally posted by @Allethrium in #178 (comment)
The text was updated successfully, but these errors were encountered: