Connection closed issue about v380

[prsyahmi]

@ihateadmins could provide wireshark data for connection sequence?

[sbcdave]

I'm having the same issue. Been trying everything I can think of. Camera was purchased on Amazon under manufacturer name Autens. It's the nicest of these bulb cams I have found and has 3 IR lights with real night vision, as well as better resolution than any others I have tried.

nmap shows only available port is 8800 and your software is the closest I have been to communicating with it, outside of my Android's V380 Pro app that can interact with it and see the video stream. I can netcat or telnet to its 8800, but it never replies, and like the other person here your software gets connection closed, although --discover somehow is able to see it with the correct ip, mac, and p2p ID.

My Wireshark dumps can see my phone connecting to it, but only shows Mac address of my phone and the camera, and doesn't show any TCP communication, and I never see anything like a handshake, port, or a URL. All the data in the packets seems like giberish to me as I have no idea how to decode it.

Any advice would be greatly appreciated.

[prsyahmi]

@sbcdave @ihateadmins I believe I found out the problems, I will begin fixing now.

Please test new version.

[sbcdave]

Thank you. Now if I run any of the connection commands without piping the output anywhere I get stoi 5 times instead of the failed connection message.

I tried piping the output to ffplay, ffmpeg, and the gstreamer server, without any luck yet. Probably just some mistakes I'm making though. I'll keep trying later today and let you know. Thanks

[prsyahmi]

@sbcdave ah yes, I made some mistake. You could connect with -id though instead of -addr

[sbcdave]

Ok thanks. For your information, your readme mistakenly says -ip where it should say -addr.

[prsyahmi]

Fixed, thanks! Does it connect to cam properly now?

[sbcdave]

I haven't figured out how to get video out of it yet, but it seems to be connecting now. I'm not familiar with ffplay and not very familiar with ffmpeg, and the example lines you give are throwing bash errors about ) for some reason, maybe my version of ffmpeg or I'm typing something wrong. I got the ffmpeg line to work, and didn't see anything in my browser (error message) with localhost:8090 If you have any advice or suggestions I can try them now, but I'm supposed to be working so I'll have to wait until tonight to really dig into it and try to figure it out on my own.

[prsyahmi]

@sbcdave Perhaps you got error like #4

Since I mainly use windows, the syntax might be different on linux
You could try:
./v380 -u username -p password -id 123456 | ffplay -vf 'setpts = N / (25 * TB)' -i -
or
./v380 -u username -p password -id 123456 | ffplay -i -

you could try vlc too
./v380 -u username -p password -id 123456 | vlc -

[sbcdave]

Looks like it might not be working. It seems to connect and open ffplay, but data rate shows as 0kbs. The vlc command runs and holds the terminal, but vlc never opens. I'm pretty unfamiliar above IP layer, but my research suggests this is a p2p camera that uses layer 2 (MAC to MAC, no IPs) for communication across my network. Do you think the camera may be bound to my smart phone's MAC, and I should reset the camera and then try from the computer? Ultimately I need the video stream fed to an end point so I can capture it with zoneminder (my home surveillance software). nmap suggests there is an IP layer connection available on 8800 with a sun web server running, but I haven't figured out anyway to get a response from the web server.

[sbcdave]

[sbcdave]

[sbcdave]

[prsyahmi]

@sbcdave I forgot to mention, with ffplay I always need to wait some minutes before ffplay window will appear. Maybe you can try to wait first a minute or two. Not sure why is this happen, it may be codec related. I have no knowledge how h264 packet works. Perhaps there is a corruption on packet header or something is just missing.

The camera may transmit video with variable framerate and the -vf 'setpts = N / (25 * TB)' will fix ffplay to 25fps, this can prevent image juddering due to seek head reach end of stream first before new stream comes available.

The camera is a server-client using TCP. The server on camera port 8800 is what v380 software communicate with. The camera should not bound to phone, at least for my camera - since I can connect to it multiple times and multiple devices.

[prsyahmi]

the -probesize 32 may help.

./v380 -u username -p password -id 12345678 | ffplay -vcodec h264 -probesize 32 -formatprobesize 0 -avioflags direct -flags low_delay -i -

[sbcdave]

No luck yet. I let ffplay run for an hour periodically hitting enter at the terminal and it would just create a new line that also showed all zeros.

The other bulb cameras I have seen are all lower resolution than this one, I started looking through your code and wonder if the video encoding stuff you're using is designed for a lower resolution?

[sbcdave]

Another thought, this camera advertised having better security. I wonder if it's an https connection and maybe your code is only designed for http?

[sbcdave]

I just confirmed I was able to view another bulb camera's rtsp stream with ffplay, and tried using the same ffplay settings while piping your v380 output to ffplay, but same thing happens, it never seems to get the video stream

[prsyahmi]

@sbcdave if you run without piping, does it output garbage to console?

[sbcdave]

So I'm off work now and digging in. I added a bunch of debug print statements to your code and I can see that it's stuck in the recv loop and generally has an unknown type (no type case matching, I added a default case that prints unknown), but it occasionally receives type 0x16, which your comments call audio, but don't do anything with. Any ideas?

[sbcdave]

Ha, I just missed your comment as I was commenting. No, it holds the Shell and doesn't output anything. I had to print to stderr to get any output out of it

[sbcdave]

I wonder if it's working fine and I just need to redirect stderr to ffplay. I'm not sure how I can do that though. I'll meet around with it.

[prsyahmi]

No output on console without piping might suggest it is not working. Can you check if the resp->version > 2

[sbcdave]

Yeah version is 3

[sbcdave]

[sbcdave]

[prsyahmi]

It looks like to me you may have received some frame packet, maybe try output it to file instead to check if it really working:
./v380 -u -p -id xxx > file.h264

What type are you receiving?

default:
    fprintf(stderr, "Unknown type %d\n", type);

[sbcdave]

It starts with 13 loops that get type 52, then it alternates between x16 and 53. I tried passing the unknowns and x16 all to ffplay and it just showed a bunch of errors. Maybe I should try to only pass the type 53. I'll try that now

[sbcdave]

Got it :) I had to let 52 and 53 use the same code from your x01. Thanks a million. Any ideas for audio?

[prsyahmi]

@sbcdave nice! I didn't find type 52/53 on the official v380 app though, maybe packet is corrupted. I have some changes that I will push later, maybe you can give that a try.

The audio code is there but requires muxing (combine video+audio together). I have looked into matroska, but seems complicated at that time. Maybe I will take a look at it again later.

You can try to output just the audio, comment out the video part and let it play with ffplay.

[sbcdave]

Cool thanks. Right now I'm struggling to get ffmpeg http steam working and keep getting an error about requiring audio. Looks like I should be able to bipass it with proper ffserver setup, but I'll have to dig into that tomorrow. Thanks again for the troubleshooting help :)

[sbcdave]

[ihateadmins]

sry that i didn't upload my wireshark trace, i have completely forgot this thread. But ye after i downloaded the recent version everything works perfectly fine. Thanks a lot!!!

[sbcdave]

I got around the audio and got it setup as an rtsp stream with ffserver now. I'm having some blur issues that are probably related to fps, but all is totally unrelated to this issue now :) Thanks again for all the help. I'm digging into trying to get the audio data parsed through an aac codec (assuming v380 bulb cam is sending aac encoded audio with type x16). If I have any luck I'll let you know. At the moment my next attempt is going to be to have your code output the video to one file and the audio to another file, but I still need to figure out how to do something like tail on both files at the same time and feed them both into ffmpeg as the video and audio inputs.

[user201534]

I have "SDETER 1080p 720P IP camera" from https://www.aliexpress.com/item/4000012251071.html.
The camera works fine with V380 Pro mobile application, but haven't been able to get it working with this v380 project.
I am getting the following: types 0x1 (video) and 0x16 (audio). There are also a lot of 0x1f commands that are currently not parsed. The issue is similar to what sbcdave was having. ffplay/ffmpeg is not playing the stream no matter what I have tried. If the output of v380 is redirected to the file, I can see it is outputting something. However, haven't been able to play the output file with ffmpeg or vlc.

I have tried the following without things:
-tried all the ffmpeg and ffplay commands mentioned here
-printing the cur frame. It seems do the following sequence 0,0,0,0,1,2,3,...N,0,0,0,1,2,3,....N, where N is between 7 and 14.
-added handling for 52 and 53 types sbcdave did
-port scan reports the following ports open: 8800 and 9800
-the login seems to work, returning the version 3.

I think the problem is related 0x1f commands, not sure what to do with those. Also noticed the android app "V380_v5.4.apk" from https://github.com/brusdev/V380-SDK is not able to show the video from this camera. Perhaps there is a difference between V380 and "V380 PRO" models?

Any help is highly appreciated! Thanks.

[sbcdave]

Irs been a while since I've looked at the code or thought about this, but I was never able to get the audio working, and what did eventually work for me was to have this code output only the "correct" "type", where "correct" was which ever type had only video data. So first modify the code to build you a list of types, and let it run for a minute or so to make sure you know all the types you might want to try. Then with the list of types try sending one at a time as the only output of the code, with a catch all that does nothing with the other types. Cycle through all types one by one to see if you get one that works. Good luck

[prsyahmi]

@user201534 is it possible that your camera uses x265 ?

[sbcdave]

Mine's x264 if you were asking me. Sorry I just saw this.

Aside from getting the audio working, I still have a lot of the screen all grey very often and only temporary (few seconds) instances where I can see the entire window