2

I'm trying to stream video from endoscope camera YPC99 on linux PC using the WiFi connection. From what I have found so far the camera is using IP 192.168.1.1. It supports RTSP protocol on port 7070 (the only one opened port). The DESCRIBE reports that the stream should be JPEG video (RTP/AVP 26)

DESCRIBE rtsp://192.168.1.1:7070/webcam RTSP/1.0
CSec: 2

RTSP/1.0 200 OK
Content-Base: rtsp://192.168.1.1:7070/webcam/
Content-Type: application/sdp
Content-Length: 122

v=0
o=- 1 1 IN IP4 127.0.0.1
s=Test
a=type:broadcast
t=0 0
c=IN IP4 0.0.0.0
m=video 0 RTP/AVP 26
a=control:track0

VLC is showing black screen. ffmpeg also can't detect the correct codec to be used:

$ ffmpeg -i rtsp://192.168.1.1:7070/webcam  -vcodec copy /tmp/abc.mp4
ffmpeg version n4.2.2 Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 9.3.0 (Arch Linux 9.3.0-1)
  configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-fontconfig --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libdav1d --enable-libdrm --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libiec61883 --enable-libjack --enable-libmfx --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-nvdec --enable-nvenc --enable-omx --enable-shared --enable-version3
  libavutil      56. 31.100 / 56. 31.100
  libavcodec     58. 54.100 / 58. 54.100
  libavformat    58. 29.100 / 58. 29.100
  libavdevice    58.  8.100 / 58.  8.100
  libavfilter     7. 57.100 /  7. 57.100
  libswscale      5.  5.100 /  5.  5.100
  libswresample   3.  5.100 /  3.  5.100
  libpostproc    55.  5.100 / 55.  5.100
[mjpeg @ 0x55ef344d0900] dqt: 0 quant value
    Last message repeated 58 times
[rtsp @ 0x55ef344ccfc0] decoding for stream 0 failed
[rtsp @ 0x55ef344ccfc0] Could not find codec parameters for stream 0 (Video: mjpeg, none(bt470bg/unknown/unknown)): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Input #0, rtsp, from 'rtsp://192.168.1.1:7070/webcam':
  Metadata:
    title           : Test
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: mjpeg, none(bt470bg/unknown/unknown), 90k tbr, 90k tbn, 90k tbc
[mp4 @ 0x55ef344fcc40] dimensions not set
Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
    Last message repeated 1 times

I have a wireshark dump of some seconds of streaming (while was trying to play it with VLC). From what I have read each frame should start with FFD8 and should end with FFD9. There is no single package containing FFD8 but there are many containing FFD9, so I can't find out the beginning of the frame to see if some headers there could help me.

There is andorid and iPhone apps to watch the stream from the camera. The app is called YCamera. I have downloaded the andorid app (https://apkpure.com/ycamera/cn.com.buildwin.YCamera) and have de-compile it. In the resources directory there are the following libs:

  • libijkffmpeg.so
  • libijkplayer.so
  • libijksdl.so

It seems that libijkffmpeg.so is the one processing the stream (the string bt470bg is found only inside it). According my research (for this one I'm not sure if I'm looking where I should) it's part of ijkplayer player that should be based on ffmpeg but strangely ffmpeg can't recognize the stream.

I know that my question is too open but any suggestions how can I keep progressing?

The final goal is to be able to make this stream public. For this purpose it will be best if ffmpeg or vlc can recognize the stream.

Improve this question
1
  • Just to add some confusion to the fire. I also have one of these YPC99 and mine doesn't respond to rtsp access: erik@Barnard inskam % ffmpeg -i rtsp://192.168.1.1:7070/webcam -vcodec copy /tmp/abc.mp4 ffmpeg version 4.3.2 Copyright (c) 2000-2021 the FFmpeg developers built with Apple clang version 12.0.0 (clang-1200.0.32.29) configuration: --prefix=/usr/local/Cellar/ffmpeg/4.3.2 --enable-shared --enable-pthreads --enable-version3 --enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libbluray --enable-libdav1d --enab
    – ErikAndren
    Mar 24, 2021 at 18:18

4 Answers 4

Reset to default
1

Ok, I've started to look into this one by connecting to the PCB's RX/TX.

Baudrate is 921600 (8N1) and I get this output:

system version:84.12.5.4.87
param: clock=1615037753
param: tz=-3600
usb host begin 
USBHALHost init  begin 
musb change to bdevice after usbc reset 
set_network_ap,enter
usb connect 0x10
----------------maclib task 

 mark ip 1

 ip_table.ip_range[0] = 0x1

 mark ip 1

 ip_table.ip_range[0] = 0x1
usb device connect 
[bool USBHostCam::connect():105]Trying to connect Cam device
vid:0x5004,pid:0x4979
find mjpeg format index 1
find mjpeg frame 640*360 index 1
find mjpeg frame 640*480 index 2
find mjpeg frame 1280*720 index 3
altsetting 1 max_packet_size 4608
altsetting 2 max_packet_size 3072
altsetting 3 max_packet_size 1024
altsetting 4 max_packet_size 512
fifo_count is 26
get_cur 0
01 00 01 01 80 96 98 00 00 00 00 00 00 00 00 00 00 00 00 8c 0a 00 00 06 00 00 
fifo_count is 26
set intf format 1, frame 1
set intf altsetting 1
1 min
2 min
3 min
....
N min
N+1 min

I can power it using the VCC (3.3V). Still haven't found out what firmware they are using and how to gain access. I thought I'd post my findings here. Will update when I know more.

G=TXd, Y=RXd, R=VCC(3.3V), B=GND

Improve this answer
4
  • I've been able to replicate this but so far I have not been able to make it react to incoming serial
    – ErikAndren
    Mar 25, 2021 at 19:53
  • Some progress (?) By holding enter while booting you can enter a "boot >" prompt. Some rudimentary commands are supported: 'c' - checksum type addr len - CRC 1, SHA1 2, MD5 3 CRC_DMA 4 - Calculate Checksum from 'addr' with 'len' Command handler do not well, ret = -1 'g' - Usage: go type addr - Auto 1, Custom 2 - start application at 'addr' with different type Command handler do not well, ret = -1
    – ErikAndren
    Mar 25, 2021 at 20:13
  • I've poked the i2c bus and there is a device at address 0x60. I've been unable to identify it nor read it out
    – ErikAndren
    Mar 27, 2021 at 20:14
  • Ah! That's good to know. I'm gonna try some of that myself.
    – Jimmy Westberg
    Mar 31, 2021 at 15:30
0

https://hackaday.io/project/19680/logs

I know it has been 10 months, but if you are interested in an answer to your question, the same module and protocol are used in cheap wifi drones. There are a few nuggets in there. One thing I noticed as I look through the wireshark log of the app I was sniffing, each time one of these packets was sent, a new port was assigned to client and server.

 OPTIONS rtsp://192.168.1.1:7070/webcam RTSP/1.0
 CSeq: 1
 User-Agent: Lavf56.40.101

 RTSP/1.0 200 OK
 CSeq: 1
 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

 DESCRIBE rtsp://192.168.1.1:7070/webcam RTSP/1.0
 Accept: application/sdp
 CSeq: 2
 User-Agent: Lavf56.40.101

 RTSP/1.0 200 OK
 CSeq: 2
 Content-Base: rtsp://192.168.1.1:7070/webcam/
 Content-Type: application/sdp
 Content-Length: 122

 v=0
 o=- 1 1 IN IP4 127.0.0.1
 s=Test
 a=type:broadcast
 t=0 0
 c=IN IP4 0.0.0.0
 m=video 0 RTP/AVP 26
 a=control:track0
 SETUP rtsp://192.168.1.1:7070/webcam/track0 RTSP/1.0
 Transport: RTP/AVP/UDP;unicast;client_port=8974-8975
 CSeq: 3
 User-Agent: Lavf56.40.101

 RTSP/1.0 200 OK
 CSeq: 3
 Transport: RTP/AVP;unicast;client_port=8974-8975;server_port=52844-52845
 Session: AEAFB0B1B2B3B4B5B6B7B8B9BABBBC

 PLAY rtsp://192.168.1.1:7070/webcam/ RTSP/1.0
 Range: npt=0.000-
 CSeq: 4
 User-Agent: Lavf56.40.101
 Session: AEAFB0B1B2B3B4B5B6B7B8B9BABBBC

 RTSP/1.0 200 OK
 CSeq: 4
 Session: AEAFB0B1B2B3B4B5B6B7B8B9BABBBC
Improve this answer
0

This seems to be a problem plaguing the internet. FFMpeg and all its derivatives I have tried (VideoLan, GStreamer...) cannot decode properly the MJPeg format used by this type of cameras (used in many types of drones, the I-Spy Mini tank, and the Endoscope Camera YPC99 you are mentioning). The android software provided for all these products is based on the IjkPlayer open source (which is mainly a ffmpeg specific build), but all the Windows versions I have tried failed to do the job. (I have posted my view in the https://trac.ffmpeg.org/ticket/8211)

The solution may be in the calculation of the buffer size [¿?] That is the ONLY difference in the whole process. Comparing one by one the analysis sequence of IjkPlayer on Android (FFmpeg: ff3.3--bw0.8.0--20180323--001-1-geb1575fefe) and FFPLAY on Windows (version 4.3.2-2021-02-27-full_build-www.gyan.dev) they are EXACTLY the same except when arriving at the stage of decoding the JFIF markers (specially the DA marker [Start of Scan]): IJKMEDIA [IjkPlayer] marker=da avail_size_in_buf=37009 component: 0 component: 1 component: 2 marker parser used 36932 bytes (295454 bits)

ffplay -loglevel debug -i rtsp://192.168.1.1:7070/webcam [mjpeg @ 05ff6740] marker=da avail_size_in_buf=17132 component: 0 component: 1 component: 2 mjpeg_decode_dc: bad vlc: 0:0 (05b1e6a8) error dc error y=1 x=0 marker parser used 196 bytes (1568 bits)

As you can see the avail_size_in_buf reserved is consistently more or less half of the required (for all the frames) so the marker=da is just partially processed resulting in the final error Apparently, this has nothing to do with the available memory as that other lines are more or less equal in both systems: [udp @ 05af7080] end receive buffer size reported is 65536 [udp @ 05b0cdc0] No default whitelist set [udp @ 05b0cdc0] 'circular_buffer_size' option was set but it is not supported on this build (pthread support is required) [udp @ 05b0cdc0] end receive buffer size reported is 65536 [rtsp @ 05af50a0] setting jitter buffer size to 500 However, unfortunately I have not found out how to change that behaviour on the Windows implementation, and the error persists. I am still waiting for some suggestions and will keep researching any possible solutions around this problem. Hope that you are luckier than me!

Improve this answer
2
  • I have made an update to trac.ffmpeg.org/ticket/8211
    – HappyCow
    Mar 21, 2021 at 21:58
  • ,,,tracking the behaviour of the the Ijkplayer Android version and the FFPlayer Windows version. The findings are summarized there. My final request was about if it were possible to get a "replica" build of the Android ffmpeg lib in Windows (the compilation directives are listed there) to further analyze those differences. If any expert in this group can indicate me how to get (or make) such binary version I would really appreciate.
    – HappyCow
    Mar 21, 2021 at 22:02
0

Problem SOLVED!

It required a minor patch in ffmpeg because the mjpeg format used by this type of cameras is not fully compliant with the standard FF DD [Restart interval] JPEG marker.

It was solved by "cehoyos". See details at https://trac.ffmpeg.org/ticket/8211

This solution applies to the cameras used in some wifi-rc-tanks, a few cheap drones and [I assume] to the YPC99 and other cameras using the rtsp://192.168.1.1:7070/webcam url (and playable by the IjkPlayer libs in android). Feel free to test it and report your findings.

Happy engineering!

Improve this answer
1
  • This still needs the connection to be based on the camera/YPC99 access point? I'm hoping to have it connect to my network instead, to be able to have it monitor my 3D printers nozzles.
    – Jimmy Westberg
    Apr 1, 2021 at 9:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.