• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

Dashcam -- Joying Intel

Search This thread

doitright

Senior Member
Oct 31, 2014
1,512
861
Ok, so people have found that standard USB cameras don't work on these units. The only known working camera is actually a fully self-contained recording device, that really only uses the USB wire for power and a few pointless controls.

https://www.carjoying.com/car-acces...-for-joying-new-android-system-head-unit.html

Really, if you're going to make the camera self contained, then what the heck is the point of bothering with the hookup with the head unit to begin with? Makes no sense.

Now the reason they did this is quite obvious... in their OLDER head units, they used the complete piece of trash ROCKCHIP 3188 SoC. I'm referring, of course, to MTC units. Those units would be *completely crippled* if you tried to record video on them, since they had neither video encoder nor even video decoder hardware blocks, which means that the video processing would be done entirely on the CPU! So they sold a camera that would mask this problem by recording the video itself!

The Intel SoC's have a video CODEC, so obviously the right way to do this now is to actually record the video on the head unit, using standard file formats.

I initially theorized that they had crippled either the kernel or the camera HAL.
So last night I watched the kernel log while plugging a PROPER USB camera in, and found something very interesting;
1) The kernel detected the camera, and properly associated it with the UVC video driver!
2) It was assigned a devfs entry of /dev/video5 --- 5? FIVE?

That's interesting. Why 5? Because there are already entries of /dev/video0 through /dev/video4.

Wonder what those extra inputs correspond to? Typically, when you plug in a device like a camera, the devfs entry is created dynamically. Yes, in this case, it was! But it was created at 5 (the 6th video device). Very likely, the HAL is hardcoded to use specific inputs from 0-4. I'm not aware of any Android mechanism for manually selecting the device. So blank screen on "DVR"? Because its trying to pull video from a video device that has no video INPUT.

It is certainly worth some investigation. I wonder what those inputs correspond to. Don't suppose that they could actually have video feeds from things like BACKUP camera and VIDEO IN, that feed Android, could they? Note that some video devices can create multiple devfs entries that correspond to different modes of operation, which could explain why there are so many.

It is also possible that the FYT5009 SoM has video input option that may not even be hooked up. Depends on how the MCU board is wired up.

I also note that in the configuration options for backup camera, there is an option for it to use a USB camera.

EDIT:
Checked into the camera HAL, it has hardcoded values for /dev/video0 through /dev/video3. What this means, is that there is currently no way in hell that Android can access /dev/video5, which is where an external USB camera is attached.

THIS IS SOMETHING WE CAN WORK WITH!!!!

AOSP USB Camera HAL:
https://android.googlesource.com/platform/hardware/libhardware/+/master/modules/usbcamera


Found something more...
There is an executable at /sbin/camcap
What it is, is a butchered build of ffmpeg :p
Which, of course, is licensed as GPL/LGPL.
So... intentionally and knowingly violating GPL, else why would they be hiding the identity of the program!
 
Last edited:

doitright

Senior Member
Oct 31, 2014
1,512
861
Good news, everyone!

I have successfully captured a video from a generic uvcvideo USB camera! And even better, over a test with a duration of about 2 minutes of HD MJPEG at whatever maximum frame rate it was able to deliver, the CPU utilization never exceeded 2% of *one* core.

Now truth is that I completely bypassed Android for this test, and ran ffmpeg directly with /dev/video5. Now this actually is a great option for running dashcam, since it is low overhead, greater running stability (no worry about Android coming around and killing the process!), and very effective.

I will begin working on a utility for managing it.
I would like to be able to capture the camera's audio stream as well, mux multiple cameras into a single video file, time based auto splitting, and a subtitle track containing a coordinate / speed readout from GPS. Ffmpeg should be able to handle all of it, except interfacing with the GPS, I will need something else to come up with the data stream for that.
 

KamaL

Senior Member
Oct 2, 2006
771
68
500px.com
Good news, everyone!

I have successfully captured a video from a generic uvcvideo USB camera! And even better, over a test with a duration of about 2 minutes of HD MJPEG at whatever maximum frame rate it was able to deliver, the CPU utilization never exceeded 2% of *one* core.

Now truth is that I completely bypassed Android for this test, and ran ffmpeg directly with /dev/video5. Now this actually is a great option for running dashcam, since it is low overhead, greater running stability (no worry about Android coming around and killing the process!), and very effective.

I will begin working on a utility for managing it.
I would like to be able to capture the camera's audio stream as well, mux multiple cameras into a single video file, time based auto splitting, and a subtitle track containing a coordinate / speed readout from GPS. Ffmpeg should be able to handle all of it, except interfacing with the GPS, I will need something else to come up with the data stream for that.

Well, that's worth being an app on Play store. Keep up the gr8 work!
 

doitright

Senior Member
Oct 31, 2014
1,512
861
Well, that was a sort of a compliment, but I'm not surprised of your reply...

One of the great strengths of Android is that you don't need to mess around with the "manufacturer's only authorized software source" -- as in apple. Reality is that play store is only there for people who don't have the faintest idea about how powerful their devices actually are. Apple's store is there to restrict their users' freedom.
 

doitright

Senior Member
Oct 31, 2014
1,512
861
So I've been playing with ffmpeg, and have figured out how to use it to capture any number of v4l2 video streams into a single mkv file, with unequal video configurations, and automatic time-based file splitting.

Its pretty cool what you can do.
For instance, BETTER camera does mjpeg at high resolution (say 800x600, or even higher), 30 fps. Crappy camera only does raw 320x240 at 5 fps. I can simultaneously shove BOTH of their streams into a single mkv file **WITHOUT TRANSCODING THE STREAMS***.

This makes sense because (1) you might have a bunch of leftover cameras that you want to use, (2) you probably want to go with a higher quality on the front than the back -- backwards cameras are a lot less interesting (though still useful enough to make sense to record).

In any case, this is going to be pretty nice.

I wonder if our head units have one USB port with a hub chip? Or if they have two genuine USB ports? Easy enough to find out, I just haven't bothered to look yet.

One "issue" I'm having with the CHEAP USB cameras I'm playing around with, is that I can't select framerate or quality. It would be nice to be able to tell the camera to increase the compression ratio and drop the framerate down to, say 5 fps.... since it would make the storage requirements significantly lower. Of course, I could turn on transcoding, but couldn't use the hardware codec with ffmpeg, which means it would be on the CPU. I wonder if the cameras support it? Or if its a limitation of uvcvideo (the driver)?
 
  • Like
Reactions: KamaL

KamaL

Senior Member
Oct 2, 2006
771
68
500px.com
Now that @doitright is banned, is there anyone capable of continuing his work with this issue?

I'd love to use my USB camera for DVR.

I contacted Joying with this regard, and they weren't helpful at all. They keep claiming on their USB camera is supported. True nonsense.
 

KamaL

Senior Member
Oct 2, 2006
771
68
500px.com
Weird, he was a helpful user, giving us full bluetooth and all. Seems counterproductive to ban a good resource, oh well....
Yep, I know. I'm trying to contact him through the official Joying forums, he was active there too, but no traces of him yet. I'm sure he could have found a solution for this issue.
I have my USB dvr cam installed in the car, waiting for a fix.
 

typos1

Senior Member
Apr 3, 2007
9,440
1,716
UK
Weird, he was a helpful user, giving us full bluetooth and all. Seems counterproductive to ban a good resource, oh well....

Yep, I know. I'm trying to contact him through the official Joying forums, he was active there too, but no traces of him yet. I'm sure he could have found a solution for this issue.
I have my USB dvr cam installed in the car, waiting for a fix.

Not weird at all if he broke forum rules (which he must have to be suspended).

Unless you think that if someone is helpful then theyre allowed to break the rules ?
 

Top Liked Posts

  • There are no posts matching your filters.
  • 3
    Ok, so people have found that standard USB cameras don't work on these units. The only known working camera is actually a fully self-contained recording device, that really only uses the USB wire for power and a few pointless controls.

    https://www.carjoying.com/car-acces...-for-joying-new-android-system-head-unit.html

    Really, if you're going to make the camera self contained, then what the heck is the point of bothering with the hookup with the head unit to begin with? Makes no sense.

    Now the reason they did this is quite obvious... in their OLDER head units, they used the complete piece of trash ROCKCHIP 3188 SoC. I'm referring, of course, to MTC units. Those units would be *completely crippled* if you tried to record video on them, since they had neither video encoder nor even video decoder hardware blocks, which means that the video processing would be done entirely on the CPU! So they sold a camera that would mask this problem by recording the video itself!

    The Intel SoC's have a video CODEC, so obviously the right way to do this now is to actually record the video on the head unit, using standard file formats.

    I initially theorized that they had crippled either the kernel or the camera HAL.
    So last night I watched the kernel log while plugging a PROPER USB camera in, and found something very interesting;
    1) The kernel detected the camera, and properly associated it with the UVC video driver!
    2) It was assigned a devfs entry of /dev/video5 --- 5? FIVE?

    That's interesting. Why 5? Because there are already entries of /dev/video0 through /dev/video4.

    Wonder what those extra inputs correspond to? Typically, when you plug in a device like a camera, the devfs entry is created dynamically. Yes, in this case, it was! But it was created at 5 (the 6th video device). Very likely, the HAL is hardcoded to use specific inputs from 0-4. I'm not aware of any Android mechanism for manually selecting the device. So blank screen on "DVR"? Because its trying to pull video from a video device that has no video INPUT.

    It is certainly worth some investigation. I wonder what those inputs correspond to. Don't suppose that they could actually have video feeds from things like BACKUP camera and VIDEO IN, that feed Android, could they? Note that some video devices can create multiple devfs entries that correspond to different modes of operation, which could explain why there are so many.

    It is also possible that the FYT5009 SoM has video input option that may not even be hooked up. Depends on how the MCU board is wired up.

    I also note that in the configuration options for backup camera, there is an option for it to use a USB camera.

    EDIT:
    Checked into the camera HAL, it has hardcoded values for /dev/video0 through /dev/video3. What this means, is that there is currently no way in hell that Android can access /dev/video5, which is where an external USB camera is attached.

    THIS IS SOMETHING WE CAN WORK WITH!!!!

    AOSP USB Camera HAL:
    https://android.googlesource.com/platform/hardware/libhardware/+/master/modules/usbcamera


    Found something more...
    There is an executable at /sbin/camcap
    What it is, is a butchered build of ffmpeg :p
    Which, of course, is licensed as GPL/LGPL.
    So... intentionally and knowingly violating GPL, else why would they be hiding the identity of the program!
    3
    Good news, everyone!

    I have successfully captured a video from a generic uvcvideo USB camera! And even better, over a test with a duration of about 2 minutes of HD MJPEG at whatever maximum frame rate it was able to deliver, the CPU utilization never exceeded 2% of *one* core.

    Now truth is that I completely bypassed Android for this test, and ran ffmpeg directly with /dev/video5. Now this actually is a great option for running dashcam, since it is low overhead, greater running stability (no worry about Android coming around and killing the process!), and very effective.

    I will begin working on a utility for managing it.
    I would like to be able to capture the camera's audio stream as well, mux multiple cameras into a single video file, time based auto splitting, and a subtitle track containing a coordinate / speed readout from GPS. Ffmpeg should be able to handle all of it, except interfacing with the GPS, I will need something else to come up with the data stream for that.
    2
    Great news everyone, we have a working solution for running any USB cam on the joying intel units!
    I'll let you guess who is working on it. check the progress on github:

    https://github.com/lbdroid/FFMpeg-DashCam

    It's working pretty well for me!!
    2
    Hey everyone...I know this thread is a little old, but wanted to contribute/give back.

    Here is a no-name clone of the same Joying cam that they sell for $46USD on Ebay for $13USD. I can confirm that it does indeed work!
    https://www.ebay.com/itm/FB44-Ultra...195806?hash=item23bc12ac9e:g:GsgAAOSw9J9c0ZPB
    1
    Here is the video from the DDVR-CAM2 on mine.
    https://youtu.be/3JY6CF82r7o