-
Notifications
You must be signed in to change notification settings - Fork 1
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
problem with MBP85C camera #1
Comments
This was explicitly removed in the firmware
Work around is currently downgrade firmware, and use your router to block ota.hubble.in resolving so the camera cant update |
I managed to get RTSP without downgrading the firmware if anyone is still interested. |
Thanks for that! Struggeling to get working at the min ps shows
Netstat shows
but ffplay rtsp://user:pass@ip:6668/blinkhd Just seems to hang Any suggestions? |
Command was wrong ffmpeg -rtsp_transport tcp rtsp://user:pass@ip:6668/blinkhd is the correct command |
Did you get video out okay with your command? Just interested to know if it worked for you. To be honest I found the h264 a bit rough with my camera (quite a lot of bad mpeg packets), I had some horrors like re-encoding it which helped or even worse twice re-encoded with different encoders to fix up. ffmpeg -rtsp_transport tcp -i 'rtsp://user:pass@cam.lan:6668/blinkhd' -listen 1 -ar 44100 -vcodec libx264 -bsf:v h264_mp4toannexb -preset ultrafast -tune zerolatency -r 24 -async 1 -acodec libmp3lame -b:a 128k -method HEAD -f mpegts http://:55555 or #!/bin/bash ffmpeg -rtsp_transport tcp -i 'rtsp://user:pass@cam.lan:6668/blinkhd' -listen 1 -ar 44100 -vcodec libx264 -bsf:v h264_mp4toannexb -preset ultrafast -tune zerolatency -r 24 -async 1 -acodec sleep 10 cvlc 'http://localhost:55554' :network-caching=1000 --sout "#transcode{acodec=mp3,ab=128}:standard{access=http,mux=ts,dst=:55555}" --sout-keep Maybe worth nothing to you..just thought I'd mention. |
thanks. very strange, but for me it doesn't work... I only see this in netstat: I don't have also this: If I use this command: it open port 6668, but when I try to connect using vlc, it doesn't works and webcam close connection... VLC media player 3.0.18 Vetinari (revision 3.0.18-0-ge9eceaed4d) do you used user and password used in hubble app? I can use dot in username? |
Manually it should be: telnet cam.lan mkfifo /tmp/recorder/backpipe They need to be in a pipe to perform bi-directional comms between the two nc's I just wrapped this in a loop so it doesn't stop after the first connection disconnects |
all seems to works fine on webcam cli, but I'm not able to connect? which credentials are you using? I tried app credentials and root...but don't help... |
This exact command to test, it has nothing to do with the apps credentials. Try a telnet to |
when I start VLC comand, net process dead on webcam and I receive closed connection result on my client: telnet 192.168.4.20 6668 the same with vlc client: vlc 'rtsp://user:pass@192.168.4.20:6668/blinkhd' :network-caching=1000 :rtsp-tcp the same happen using ffmpeg client: ffmpeg -rtsp_transport tcp -i 'rtsp://user:pass@192.168.4.20:6668/blinkhd' -listen 1 -ar 44100 -vcodec libx264 -bsf:v h264_mp4toannexb -preset ultrafast -tune zerolatency -r 24 -async 1 -acodec libmp3lame -b:a 128k -method HEAD -f mpegts http://:55555 where I have to put script to open RTSP flow every day? |
To be honest I didn't alter the camera in any way, which I was actually quite happy about. My Camera would always reboot about 3:00PM, I'd just cron this script a few times over the hour after that, to hack the service back in place:
I guess you could add a to the bottom of /mnt/skyeye/msloader_go.sh before the exit 0 But I haven't tried this, I haven't got the camera anymore to test this, and don't blame me if it doesn't work or stops the camera booting! I don't even know if this partition is R/W by default. If I was going down this road I'd probably put this is in a script somewhere (e.g. /mnt/skyeye/bin/rtsphack), test on the cli to see if okay and call this backgrounded from this file msloader_go.sh (i.e. When I bought this device for quite a lot of money and my partner wouldn't have been happy if I bricked it, so I liked the ability to just apply the hack with no permanent changes to the camera, a reboot would fix anything. |
Hi, #mkfifo /tmp/recorder/backpipe mkfifo: /tmp/recorder/backpipe: File exists #nc 127.0.0.1 6667 0</tmp/recorder/backpipe #ps | grp nc ->no any process active with nc command... if i use this comand: nc 127.0.0.1 6667 0</tmp/recorder/backpipe | nc -l -p 6668 1>/tmp/recorder/backpipe I only see this process/port opened: 1161 root 820 nc -l -p 6668 this process don't opened any port on 6668... |
The command It needs to be in a pipeline: i.e. nc is outputing video via the pipe to the nc -l, but the backpipe is taking the output from the server to complete the TCP connection for the server and this goes back into the connecting nc. This is just a port forward hack, there maybe another way of doing this (better) on Linux but the CLI isn't very rich on the camera but there maybe another way. All this is doing is taking port inbound 6668 TCP and port forwarding to port 6667 on loopback 127.0.0.1. Running this, Is the build in process listening on 6667 on the loopback interface, I can't remember even the process name. |
ok, thanks. when I launch nc, I see it on webcam: tcp 127.0.0.1:6667 0.0.0.0:* LISTEN 815/msloader and only one nc -l -p 6668 process... but when I launch vlc command, ports remain opened but I see nc process died...I don't understand why?! |
If you kill all nc's and rerun the pipeline command what does |
only one process: 1258 root nc -l -p 6668 |
Same, quality seems poor but it does work. ffplay complains quite a lot about it but it does display |
I found the image quality itself okay e.g. resolution and update rate (equal to the app if not better when viewed via VLC), but just the dodgy h264 encode. If this is fixed up by re-encoding it mostly stable. |
do you have problem of nc process died when you launch vlc command...?! |
If you leave the command in a shell in the foreground you'll see when the first nc dies when you connect. |
I see first nc died, but died also second nc how may nc process I have to see? |
1 similar comment
I see first nc died, but died also second nc how may nc process I have to see? |
That is expected, the nc's should die after a single connection is connected then terminated. This will only allow one connection at a time also. You can keep it running by putting this in a loop (still a single connection though), to restart the listener, after each connection closes: As I say this is a grotty hack to get some rtsp out of this and a further grotty hack to get port redirection to work with it's limited CLI toolset. |
Or even for debug stick and echo in the loop and see if it's constantly restarting, or (as it should be) just on a reconnection:
|
Ok, shell script modified and launched. when I call one time VLC, I see one restarting messages in webcam console… |
If from another machine you telnet cam.lan 6668 There should be no restarting message until you quit this telnet session. |
Hi,
what means? |
I'm not sure why this might be, and working for others, maybe your camera is a bit different. |
You tested it on MBP86C? Which traffic I have to capture? |
Mine was an MBP667. Not sure what other @exussum12 has as this works for him too. tcpdump -i intetfacename port 6668 -w /tmp/rtsp.cap , where interfacename is the ethernet interface use to connect to the camera. And load and decode the RTSP (if it gets that far) in wireshark. |
I have Motorola MBP853 and its working fine |
|
Sadly I just don't see any RTSP traffic from the camera at all. I don't really see why as the ports from msloader look open and should port forward through the named pipe and the standard pipe to the nc process. Sadly I'm at a bit of a loss. |
I think it's a trivial problem...I must have done something wrong! :-) I will summarize the following key elements: tcp 0 0 127.0.0.1:6667 0.0.0.0:* LISTEN 5126 root 820 S nc -l -p 6668 then I send this command in webcam cli: now what I have to check again? |
if I open VLC happen:
what am I doing wrong? |
I guess to check the FIFO needs to be in place:
And you had a missing '<' in the above command line but that maybe was just formatting in the forum chat... |
great job: now it works!!!!!!!!!! thanks very muche for your help!!!!! |
That's good news! |
I tried to use this bash script:
What I have to change on script? |
The script was a quick knocked together thing as demo. It assumes that if port 23 telnet is still open the camera hasn't rebooted. So multiple runs won't restart the streaming piece as I personally never saw it die. I guess the first step would be to telnet into the camera and see if the nc's are still running from ps. |
Thanks for suggestions! I go to do some test! do you know right image snapshot URL? http://192.168.4.20/cgi/jpg/image.cgi Seems don’t working… |
I think this was disabled with a previous firmware update due to security concerns, I don't know this one sadly. |
For me could be interesting recover snapshot feature…I don’t know from where I have to start…?! |
HI,
all worked fine for me in last 6 months, but from about 1 month these links:
http://192.168.1.107/-wvhttp-01-/video.cgi
http://192.168.1.107/cgi/jpg/image.cgi
don't work for my MBP85C webcam.
can you help me?
The text was updated successfully, but these errors were encountered: