-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't play "some" RTSP streams #64
Comments
If you directly run command Also try without the |
Running the command
gives:
Running the command without
Running the command with only
I guess it is streaming with |
So from the fact that your manual ffprobe with udp also gives all empty values, and the one with tcp works, I think you suggestion that it may be due to use of udp seems correct. But how to fix it, I do not know. For me, when running omxplayer manually, I had the same issue, I had to use tcp for some cameras, which is why I was so happy to see this software did it automatically correct. |
I have tried the OS before that and while I was adding the URLs I selected to preview the feed before adding the cameras and I was able to see the preview correctly at the corner of the screen. However, after adding the camera it was not able to get the feed on the main screen. I will look into the code to find the argument, if it was that easy enough. I can probably change it. EDIT:
and at line 199:
any ideas? |
Reading the source in streaminfo, I see how to hack, but I also see it should have already tried tcp. |
Deleting |
It is weird that if you try manually with tcp it works, but the code seems primed to also try tcp first and only fallback to udp. Also your dump above actually claims it found Does it even populate the cache/streaminfo file? Can you show the content? |
I freshly ran Raspbian with a fresh install of camplayer. Here, I was using this free RTSP link rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov and some other local files and indeed it includes the info in the cache/streaminfo file.
However, it does not even create a cache/streaminfo file if I include all of my other camera feed URLs only in the config. It will only include data for other free test RTSP URLs or local files. I guess it is a problem with omxplayer as it can't play my links (no output) but can only play other links. I tried it separately using BTW: I tried the camera RTSP link with UDP and proved fruitless rtsp://192.168.1.13:10554/udp/av0_1 |
I highly doubt it is a problem with omxplayer. The cache/streaminfo content is generated with Both the log in your first post, and the fact cache/streaminfo stays blank, means The only weird thing is, when you did the manual I think it is something with the URL. Can you move the RTSP port to 554 so you can leave of the
To be honest, I am randomly trying a bit with above. But I do believe internally camplayer should be using the |
Oh, and also, delete the 2nd stream. Rather silly to offer the same quality stream twice:
|
I was using the demo config example and it had multiple streams of different qualities, so I thought I'll populate them with the only stream quality I need as camplayer shuffles between the views/windows and the streams. Surely, I'll remove all links except one per channel. Thanks. |
Having the same stream in there twice would cause it to ffprobe it twice, which I do not think is the cause of the problem, but it surely will not help either. Anyway, any luck with the suggestion to play with how to write the URL and its port number? |
From these:
I got this one working, only after changing
and outputs:
Notice the video bit rate is coming as N/A. Is that normal? Regarding the port number, I tried many different URLs and I searched the internet but I couldn't find any other than these:
and I couldn't find a way of predicting it. I can not find anything for the port 10554 for this camera. I believe it has a lower quality stream by the port 9000 and I notice that the Android app for the system uses it but I can't think a way of capturing it. I can use that URL if I find it, as my hardware setup doesn't call for more quality. Camera port settings below as well as its model number. |
I overlooked that /tcp/ in the URL, thanks. So from earlier report, this works: But this one did not work? How about these: And of course, this one also works: BTW: you once mentioned it worked in VLC. I trust you tried both udp and tcp and both 0_0 and 0_1 variants in VLC? BTW: since you do have a 2nd stream with different qualities, you could add back in that 2nd stream.
|
ffprobe:All of the possible trials, so far for
They all output:
And for
They all output:
Testing on VLC:from a Windows 10 machine: I also tried to run them on VLC Desktop from the same Raspbian (no HW acceleration here I believe) and they are all working. I just can't take a snapshot from VNC viewer but here is a photo of VLC running |
I'm still suspecting omxplayer as it recognises the stream metadata but does not play it on screen for some reason and wishes me a nice day. Running both:
give:
and
I tried all of the possible URLs I wrote in the previous post and it just does not want to play any of them. To roll things out, I tried many public free URLs and it plays most of them and other there were just connectivity problems and not problems with playback.
give:
and
respectively and plays them successfully on screen. |
So, it is working quite well from command line. But not at all from the program. Lets go deeper. In /usr/local/share/camplayer/camplayer/streaminfo.py
to
So add both prints and the |
Displays 4 blank streams and outputs:
|
So our replies crossed. But you told me the stream does not even show up in cache/streaminfo So that to me is a clear indicator it is not even reaching the omxplayer part. |
In your log, note that you see both tcp and udp ffprobe attempts printed, but never the result. However, I may see why now: the -rtsp-transport is placed behind the URL. That is absolutely not allowed when you add the |
I think like this:
|
That was certainly unexpected 😁. My mistake eventually, I will try not forget to quote reply the next time And yes, cache/streaminfo is not present after running, even after adding Possible scenarios:
|
I also added both prints.
|
So the tcp one is not showing any result, and then the udp one is timing out. How long do your manual ffprobe attempts take? And your VLC connection time? Changing timeout to 20 and also adding a print
|
Takes around 5 seconds to get the stream going on VLC. Increased timeout to 20 and
and cache
|
Ok, so the tcp stream was indeed timing out. Granted, the cache is mostly 0, and while you do not mention, yet I am assuming it is not actually playing. And still, the manual ffprobe did work, by your suggestion:
So lets try a bit more with the exact format. You already tried, but please try again:
Oh, and since your cache/streaminfo is now populated, but with incorrect data, you will have to delete it on each attemp. |
YAAAY!! After studying the omxplayer arguments closely from https://elinux.org/Omxplayer, I actually got omxplayer to work manually using:
I had to disable the audio stream by Not sure if I will be able to implement EDIT: I'm not able to implement that. I couldn't find a documentation regarding ffprobe arguments to omxplayer. Do you have one in hand? |
After I got omxplayer working using the av0_0 and av0_1 links, I think it doesn't help to use the av0_0 as it causes broken stream output in omxplayer because of limited bandwidth (as I saw from the output) but I will add it anyway to the config.
gives:
|
Ok. so why does it give proper output when run manually, and almost all 0 when running via camplayer? I do have a workaround suggestion for you though: |
Could be possible that the arguments sent by ffprobe is not what omxplayer expects? |
So any luck with faking the cache/streaminfo with the correct values, so it skips ffprobe and goes directly to camplayer? |
I also had the same issue with 10 secs drop signal. Has this been fix or is there plan on updating the repo to solve the omxplayer udp issue? |
Hi
I am using camplayer on raspbian lite. These are my configs:
and on starting camplayer I get:
I can get these streams working on VLC on a Windows machine.
No matter what, it tries every 10 seconds and then 'NO LINK'. My thinking is that it tries to start the stream using "RTSP over UDP" instead of "RTSP" as in the camplayer OS. I can see a hint of it in the second error line ('udp'). Could be it only an argument to the player?
The text was updated successfully, but these errors were encountered: