Related
I want to run each of the 3 plugs from a component video cable to a separate ADC, How many samples per second do I need, and what bit resolution should I use. after it is converted to digital I want to send the binary data to an RF transmitter, send it to a receiver, the binary data received then needs to go to a DAC. Any information and/or part #'s would be great.
--
Gregory J. Gauvin
ratlink
ratdock
What kind of video are you digitizing?
For "full" resolution, you typically need to capture at least 8 bits on each channel for each pixel. 10- or 14-bit converters are generally preferred. "Analog" (SD) TV was roughly 640x480 and 30 frames a second, so that would be 9.2 M samples/s. NTSC was broadcast on a 6 MHz bandwidth; Nyquist sampling would be 12 MHz for that signal.
There are plenty of digitization cards out there, depending on the platform you are looking for. The better ones used to include a MPEG engine; that may have become less of a requirement with today's higher-speed PCI bus choices and computational power. The MythTV site may have some recommendations still up for analog capture cards.
Here's a reference on digital video that you might find helpful.
If I want to output video from a component video cable from a ps3, at the maximum resolution, I'm guessing 1080x1920 at 60 or 120 Hz, that the ps3 can support over the component video cable. What bit resolution adc should I use and at how many sample per second.
--
Gregory J. Gauvin
ratlink
ratdock
Pixels/frame * frames/sec = pixels/sec
You need at least one sample per pixel, especially if you aren't phase-locked to the pixel clock.
I suspect you're going to find out that the data rates are far beyond what you want to deal with over anything but a processor-direct interface.
Posted from my SGS4G, thanks to Team Acid development
Is the signal coming off the component video cable analog or digital.
--
Gregory J. Gauvin
ratlink
ratdock
http://en.wikipedia.org/wiki/Component_video
ratdock said:
Is the signal coming off the component video cable analog or digital.
--
Gregory J. Gauvin
ratlink
ratdock
Click to expand...
Click to collapse
Component is analog, HDMI is digital.
Please don't ask for Moonlight help on Nvidia's forums! It's not their responsibility to support this app. Ask on this forum, another non-Nvidia forum, by email, etc
What happened to Limelight?/Why did you change your name?
On April 21, 2015, we received a Cease and Desist letter from Limelight Networks, Inc. They also do streaming services and were concerned about confusion between this project and their company trademarks. To comply with the terms of their C&D, we've decided to rename our project to Moonlight.
Quick Links
Main website: https://moonlight-stream.org
Help: https://github.com/moonlight-stream/moonlight-docs/wiki/Setup-Guide
Discord: https://moonlight-stream.org/discord
PC GitHub project: https://github.com/moonlight-stream/moonlight-qt
iOS GitHub project: https://github.com/moonlight-stream/moonlight-ios
Android GitHub project: https://github.com/moonlight-stream/moonlight-android
Android GitHub releases page (APKs): https://github.com/moonlight-stream/moonlight-android/releases
Embedded port (for Raspberry Pi and other embedded devices): https://github.com/irtimmer/limelight-embedded
GearVR port (for GearVR devices): http://sideloadvr.com/detail.php?id=14
iOS version
The iOS port of Moonlight is now on the App Store: https://itunes.apple.com/us/app/moonlight-game-streaming/id1000551566
Windows, Mac, and Linux port
PC port binaries: https://github.com/moonlight-stream/moonlight-qt/releases
PC port source: https://github.com/moonlight-stream/moonlight-qt
Moonlight for Chrome OS
Download the latest version from the Chrome Web Store.
General Streaming Latency Information
The latency of streaming is dependent on the device you're streaming to and the network you're streaming over. Different devices have different H.264 hardware decoding latency. After streaming, a toast will show up with latency numbers. It will show the total client latency and the portion of the total client latency spent waiting for the hardware decoder. Note that the total client latency does NOT include network latency, so the real latency is higher than the number you see. The total client latency is a measure of the time that the first packet in a frame is received to the time that the frame is released for rendering on screen.
Anecdotal Hardware Decoder Latency Numbers
These are some latency numbers (from memory) I've seen on my test devices as of Moonlight Android 4.0.1. I'll try to keep updating this as I test.
Tier 1 devices:
Tegra 4 - Nvidia Shield - 5 ms - 1080p60 supported
Intel Atom/Bay Trail/Moorefield - Nexus Player - 8 ms - 1080p60 supported (may need a USB OTG Ethernet adapter for consistent performance)
Razer Forge TV - 10 ms - 1080p60 supported - H.265 supported
Tegra X1 - SHIELD Android TV - 10 ms - 4K60 supported - H.265 supported in hardware but needs changes in Moonlight to work well
Tegra K1 - Nexus 9 - 15 ms - 1080p60 supported
Tegra 3 - OUYA and Nexus 7 (2012) - 17 ms - 1080p60 supported
Tier 2 devices:
Broadcom VideoCore IV - Fire TV Stick - 20 ms - 720p60/1080p30 supported
Exynos 7420 - Galaxy S6 - 20 ms - 1080p60/4K30 supported - H.265 supported
Snapdragon S4 Pro (rebranded 600) - Nexus 7 (2013) - 20 ms - 720p60/1080p30 supported
Snapdragon 801 - HTC One M8 GPE - 20 ms - 1080p60 supported
Snapdragon 800 - Nexus 5 - 20 ms - 1080p60 supported
Snapdragon 600 - Fire TV (2014) - 30 ms - 720p60/1080p30 supported
Tier 3 devices:
MediaTek devices - Fire TV (2015) - 55 ms - 1080p60 supported - H.265 supported
Adding games/apps that aren't automatically found
You can stream any almost any game or app by adding the EXE file to GFE manually (if it's not found by the automatic app scan). Open GeForce Experience, click the Preferences tab, click GameStream on the sidebar, then click the add (+) button on the right. Browse to the app or file you want to add and click OK. You can rename the app using the edit button on the right (near the add button).
Using Moonlight as a remote desktop solution
You can stream the entire Windows desktop via Moonlight. Follow step 2 from this guide
Streaming over the Internet
Install the Moonlight Internet Streaming Helper on your host gaming PC to enable streaming over the Internet. If your router supports UPnP, you won't need to make any manual changes.
If the above tool isn't able to enable Internet streaming automatically or your router doesn't support it, forward these ports manually:
TCP 47984, 47989, 48010
UDP 47998, 47999, 48000, 48010
General requirements for current APK:
SoC capable of decoding H.264 High Profile in hardware (Snapdragon, Exynos, Tegra 3 or higher, Rockchip, and more)
Android 4.1 or higher
GeForce Experience with a GTX 600/700/800/900 GPU or GTX 600M/700M/800M (GT-series not supported)
Xbox, PS3 (with SixAxis app), Moga (B/HID mode), Shield, or Ouya controller (other controllers may work too in HID mode)
Mid to high-end wireless router (preferably dual-band 802.11n or better)
Good wireless connection to your Android device
Troubleshooting tips:
1. Make sure GeForce Experience is open, up-to-date, and that you've scanned for games.
2. Make sure your device is on the same network as your computer for initial pairing.
3. Try disabling any firewall software running on your machine.
4. Try rebooting your machine. Sometimes the streaming software gets into a messed up state where it won't work normally until the machine is rebooted.
5. Make sure your Android device has a strong wireless connection (and your PC too, if it's connected wirelessly).
6. For Internet streaming, make sure to install Moonlight Internet Streaming Helper on your host gaming PC, then run the Moonlight Internet Streaming Tester that it installs to troubleshoot further.
7. To check if GFE is working properly, try navigating to the following URLs on your GFE PC:
http://127.0.0.1:47989/serverinfo?uniqueid=1234
https://127.0.0.1:47984/serverinfo?uniqueid=1234
For those with latency issues, please see this post.
Device-related issues
Depending on the wireless chipset on your phone/tablet, you may have a bad streaming experience if Bluetooth is active while streaming. Unfortunately, there's nothing we can do about this. If you experience significant connection degradation with a Bluetooth controller connected, you could try connecting the controller to your PC (see the section above), a USB Ethernet adapter, or controller that connects directly to your Android device (assuming your Android device supports USB OTG)
Older Changes:
Update 12 - March 13, 2014:
Significant video quality improvements. Lower video latency. New UI that makes it easier to choose the best streaming settings. Transient messages are displayed while streaming if network or device problems are detected.
Update 11:
Tegra hardware decoding latency bug is fixed. Hardware decoding is now used by default on Tegra and Rockchip devices. Performance is vastly improved on Tegra devices (1080p60 decodes in real-time, even on Tegra 3). The parser bug causing additional artifacts and image corruption is (finally) fixed.
Update 10:
Added options to force either hardware or software decoding. Reduce audio decoding CPU usage. Fix image quality and performance regressions from update 9.
Update 9:
Reduced CPU usage of video decoding. Added options to choose target resolution (720p or 1080p) and FPS (30 or 60).
Update 8:
Added a checkbox to choose image quality vs performance (only for CPU decoding). Optimize CPU decoding further. The frame rate is now playable on the Ouya with its Tegra 3..
Update 7:
Connectivity issues should be resolved now. Update to the latest APK if you were experiencing connection failures with the last couple of releases.
Update 6:
There's now GUI feedback when connecting. The whitelist for hardware decoding (that only included Qualcomm decoders) has now been replaced with a blacklist (currently containing TI and Nvidia decoders). The Exynos decoder in Exynos 5 Octa has been confirmed to work.
Update 5:
The app will now request a new reference frame if packet loss occurs on the video stream. This means that the stream will recover from blockiness and artifacting that occur when video packets get lost. CPU decoding for non-Snapdragon devices is a bit better. Fixed back button on Shield.
Update 4:
Added multithreaded CPU H264 decoding support for non-Snapdragon devices with ffmpeg. Both landscape orientations now work. This grows the APK significantly so don't be alarmed when this download is larger than previous builds.
Tegra 4 is now very smooth in the games I've tested. Tegra 3 works significantly better than before, but still not perfect (and won't likely ever be as smooth as Snapdragon or Tegra 4).
For Qualcomm devices, a dual-core SoC (even as old as Cortex-A8 stuff) is sufficient due to the hardware decoder. For other devices, CPU decoding will now be used. These devices will need more CPU horsepower (a quad-core Tegra 3 is almost enough).
Look forward to keyboard support and a better GUI coming in the next several days.
Update 3:
Frame pacing improvements for Snapdragon and Tegra devices, although Tegra still has more latency than Snapdragon devices. If you have issues with blockiness or discoloration in the video stream, make sure that you have a good wireless connection. Moonlight doesn't currently deal with packet loss as well as the Shield streaming app.
Update 2:
PS3, Xbox, Shield, and Moga Pro controllers are working with the latest APK.
Update:
Audio is now working. Video is working pretty well on Snapdragon devices (with some lag on Tegra devices). I've attached the current APK here for those that want to test. Due to the framework we're using for video decoding, this app requires Android 4.1 or higher. This is still in alpha so expect bugs.
Original post:
Here is a demo of a WIP app that uses the same Shield streaming technology to stream to any Android device. Controller and mouse input works. Keyboard input isn't implemented yet. Video support works (minus some artifacts at rare points and minor frame pacing issues). Audio doesn't work yet (not sure what format it is).
We've had success with very low H264 decoding latency on Snapdragon S4 Pro/600 devices (like the 2013 Nexus 7 and HTC One), but the Tegra 3/4 decoder has a high latency per frame (~1 second) that makes streaming more laggy on devices like the Ouya, 2012 Nexus 7, and even the Shield itself.
The next big step to a release-ready app is audio support (and the obligatory code cleanup). I'd be happy to respond to any questions about the way the app or the GFE streaming protocol works. If there's significant interest in this, I'll try to put more time into finishing it ASAP.
Demo video (a bit old now):
http://www.youtube.com/watch?v=0VOti83qZRU
Downloads:
I'd recommend downloading the app from the Play Store. Updates are automatically applied through the Play Store when they are released. Crash reports also get to us automatically if you use the Play Store version and click the Report button if Moonlight crashes.
Google Play Link
Sometimes APKs are more convenient for sideloading and other things, so they will continue to be posted.
You can find the latest APKs on the GitHub page here: https://github.com/moonlight-stream/moonlight-android/releases
cgutman said:
Here is a demo of a WIP app that uses the same Shield streaming technology to stream to any Android device. Controller and mouse input works. Keyboard input isn't implemented yet. Video support works (minus some artifacts at rare points and minor frame pacing issues). Audio doesn't work yet (not sure what format it is).
We've had success with very low H264 decoding latency on Snapdragon S4 Pro/600 devices (like the 2013 Nexus 7 and HTC One), but the Tegra 3/4 decoder has a high latency per frame (~1 second) that makes streaming more laggy on devices like the Ouya, 2012 Nexus 7, and even the Shield itself.
The next big step to a release-ready app is audio support (and the obligatory code cleanup). I'd be happy to respond to any questions about the way the app or the GFE streaming protocol works. If there's significant interest in this, I'll try to put more time into finishing it ASAP.
http://www.youtube.com/watch?v=0VOti83qZRU
Click to expand...
Click to collapse
sounds very promising you should post this info over the nexus 7 forum HTC and Samsung forums you will get more interest there
I will be happy to try it on my note 3 if you get audio working
very interesting work however I think you might find this
http://forum.xda-developers.com/showthread.php?t=2506438
a better alternative to work on, maybe if you find a way to get splashtop THD algorithm for streaming, which is leaps and bounds ahead of nvidia's solution. A plus point of this is you can stream anything, your not restricted to just steam and big picture mode.
Really cool!
Tested on Asus TF300 its lagging a lot but i really like what you are doing!
Keep up the good job!
Some questions:
Why no pair button? I had to discover the pair url and do it by hand.
Also why the mac is not read from the android system? Had to change it before compile.
You forgotten to put the link for the code... cant post because new user
danielb7390 said:
Really cool!
Tested on Asus TF300 its lagging a lot but i really like what you are doing!
Keep up the good job!
Some questions:
Why no pair button? I had to discover the pair url and do it by hand.
Also why the mac is not read from the android system? Had to change it before compile.
You forgotten to put the link for the code... cant post because new user
Click to expand...
Click to collapse
The pairing should take place on the first connection. When we get the /pair URL, it should prompt for pairing on the PC. The MAC wasn't read simply because this was some proof of concept code written in a hurry. I'll be fixing that (and other things) shortly.
There's also no UI feedback yet as to what's going on (since we've mostly been debugging it with ADB over the network). I might add some toasts for now to indicate what's going on. In general, it needs cleanup in the UI area along with some code cleanup of some of the early stuff we wrote. There's code in there for mDNS discovery (like the Shield's app uses) which does work but we lack the UI to display the results. We'll also eventually have a proper game selection UI (since we also know how the Shield's app requests game thumbnails), so games can be launched without using Big Picture.
The code link wasn't posted originally because it's a very early proof of concept, but since you asked: https://github.com/cgutman/limelight
EDIT: You were right about the pairing bug. I forgot that we checked if it was paired before attempting to connect. I've added a pairing button and fixed the hardcoded MAC address.
Nice!
"early proof of concept" that works!
I will be following the updates!
Stoped working!
Don't know what happened i cant pair...also tried the same way i did yesterday ( manually through firefox) and it doesn't accept!!!
Really don't know whats going on here!!
danielb7390 said:
Don't know what happened i cant pair...also tried the same way i did yesterday ( manually through firefox) and it doesn't accept!!!
Really don't know whats going on here!!
Click to expand...
Click to collapse
Try pairing using the button. It's possible that the MAC address that you specified manually isn't the same one that the code selects now.
Got it working
Got it working after a pc reboot... stupid windows as always!
Anyways i believe theres a problem in your connection layout i can't click the pair button until i resize "mDNSResultView" because its on top of the buttons or its something else!
Also it's supposed to be working the DNS find? No pc's come up on the list.
I get 1s lag is this normal or i have some problem on my end?
danielb7390 said:
Got it working after a pc reboot... stupid windows as always!
Anyways i believe theres a problem in your connection layout i can't click the pair button until i resize "mDNSResultView" because its on top of the buttons or its something else!
Also it's supposed to be working the DNS find? No pc's come up on the list.
I get 1s lag is this normal or i have some problem on my end?
Click to expand...
Click to collapse
The connection layout problem was some code that someone accidentally committed because they didn't diff what they were committing. They've been publicly shamed
The layout is fixed now so the pairing button should work again.
The H264 stream that is being fed to the decoders currently isn't 100% perfect. There are a few issues we're still trying to work out. The Snapdragon decoder seems to be the most lenient and fast. The Tegra decoder seems to be fairly lenient as well, but does have the 1 second lag which is common to both Tegra 3 and Tegra 4 devices. I'm not sure if the decoder is just too slow for real-time decoding or if we're doing something wrong, but I suspect the latter since I think Shield itself uses the hardware H264 decoder when streaming the normal way. Both of these decoders handle our H264 stream better than TI's hardware decoder and Google's software decoder which both crash immediately with "Decoder Failed -2". I'm working on fixing the H264 stream issues in the "av" branch.
If you need me to test something just say!
The stream is a standard rtsp stream or has something special?
The sound doesn't work why? Can't find the proper decoder?
danielb7390 said:
If you need me to test something just say!
The stream is a standard rtsp stream or has something special?
The sound doesn't work why? Can't find the proper decoder?
Click to expand...
Click to collapse
It's an RTP stream but it seems to have some proprietary 56-byte header between the RTP header and the media payload. It also sends both audio and video on the same RTP stream with the same packet type, so we need to find and remove the audio to parse it separately. I'm working on getting video decoding working 100% on all devices to see if I can root out the bad data causing the software decoder to fail (which might be the audio). I had originally assumed the audio was AAC since we were looking at an H264 stream and the two formats are commonly bundled together, but it appears the audio is something else. At this point, our best guess for the audio format is Opus.
I guess you already tried to open the stream with some player? Or capture the data and try to play it with vlc for example?
Probably saying garbage but whatever!
I just bought an xperia z ultra, I would like to try this out how do I go about it.
You need a pc that meets the requirements for shield streaming
and compile the source code using android SDK.
I don't know if i cant provide a apk.
Can this thread be moved? It's not relevant to the Shield.
Audio is here with the latest code! Turns out that audio was coming in over UDP port 48000. I wrote a JNI binding for the Opus reference decoder and fed the data to the AudioTrack class.
danielb7390 said:
You need a pc that meets the requirements for shield streaming
and compile the source code using android SDK.
I don't know if i cant provide a apk.
Click to expand...
Click to collapse
I've attached an APK that you can use for testing to this post.
nielo360 said:
I just bought an xperia z ultra, I would like to try this out how do I go about it.
Click to expand...
Click to collapse
It should work fine with the attached APK since that phone has a Snapdragon 800 which plays nice with our H264 stream.
LVNeptune8 said:
Can this thread be moved? It's not relevant to the Shield.
Click to expand...
Click to collapse
Sure, ideas for the new location?
Audio its working!
Video still has delay seems little bit better but still needs some work
The middle controller button the "xbox home" button doesn't work at least for me! Its needed to open the steam overlay.
danielb7390 said:
Audio its working!
Video still has delay seems little bit better but still needs some work
The middle controller button the "xbox home" button doesn't work at least for me! Its needed to open the steam overlay.
Click to expand...
Click to collapse
The xbox home button unfortunately sends key events like the Android home button which makes it problematic to intercept. Instead, I've made it so Back+Start will open the steam overlay.
The video delay issue is possibly an issue with Tegra's decoder or how we're interfacing with it. The problem with Google's software decoder and TI's hardware decoder is that the stream that we're getting is H264 high profile, while Android only requires implementing H264 baseline profile. Qualcomm's hardware decoder does high profile perfectly well. Tegra 3 and 4 also support high profile hardware decoding but they seem to decode very slowly, particularly when a large portion of the screen changes. The current plan is to look into software decoding of the H264 stream for devices that have problematic decoders, while letting the Qualcomm devices decode in hardware.
There's an updated APK attached to this post.
Where can I send you a donation?
I have an nVidia SHIELD and Nexus 7, but the only thing I don't like on the shield is the screen size so I'd LOVE to be able to play on my Nexus 7 with a 360 controller, etc so this project looks fantastic!
EDIT: Also, I'm just wondering, but how does this compare to Splashtop THD? Is it using the same NVENC and RTP methods for encoding and sending data? I am thinking about purchasing an ASUS TF701T tablet but one of the main (?) purposes would be remote streaming some games from my desktop. It's confusing that you say that Tegra chips are slower because isn't Splashtop THD (made for Tegra) extremely low latency?
Hey there!
I am looking to start an open-source, non-profit project geared towards creating a handheld gaming/PDA device powered by the Raspberry Pi Compute Module. This device should be able to run emulators and games with input from an onboard controller, and should be customizable with different button configurations and different chassis with different screen sizes, battery capacities, and extended functionality. I am hoping that throughout this project I will be able to expand my knowledge of how electronics wor.
The main purpose of the project is to go over the basic design principles of a handheld device, along with engineering that goes into it. This includes PCB design, power management, engineering of components, etc.
As a basic idea, I am looking to design a base model with the following configuration:
- 3.2" or larger LCD
- Built-in speakers & headphone output
- HDMI and/or Composite Output
- 4000 to 6000 MaH Rechargeable Battery (Li-Ion/Li-Po)
- Ethernet connectivity and/or 802.11n Wireless
- Multiple controller inputs (for if it is connected to a TV for those looking to play multiplayer)
- (eventually) a Dock for hooking it up to a TV.
Obviously, I would like to keep everything absolutely open source. This includes the schematics, any customized source code for user interfaces, parts lists, etc. I am hoping to create a guide as to how the device was designed. This will go over the use of a PMIC, designing connectors for modular buttons and screens, placement of internal components, avoiding noise from power sources and signals, etc.
So far I've only realistically researched power management for the unit. The reason behind this is because overall, we only have to provide proper power outputs for the Raspberry Pi Compute module while still having features that would be required in a handheld device. Below, I will be compiling a list of components along with a list of their features that I believe is beneficial to the device.
This list will be updated as I continue to do more research.
Power Management: Texas Instruments TPS65800 PMIC (Single unit cost: $12 & $5.78 for 1Ku)
- 6x LDOs adjustable between 1.25V and 3.3V
- 2x Buck regulators fixed at 3.3V (one will be used to power VBAT, other to power 3V3)
- I2C interface (will allow for voltage adjustments and battery level indication)
- 3 GPIO ports (not sure what we'd use 'em for, but they're there!)
- Li-Ion and Li-Po charging up to 1.5A
Any help, ideas, or suggestions would be greatly appreciated. I'd like to note that I am fairly new to electronics design and am hoping this project will help to further my knowledge in the field.
So you want someone else to design and build it so you can collect money from a kick start for yourself?
5ft24 said:
So you want someone else to design and build it so you can collect money from a kick start for yourself?
Click to expand...
Click to collapse
Quite the contrary! I was looking for help in learning how to design such a device, not for someone to design it for me. If I did get a Kickstarter going eventually, I'd personally rather have the proceeds go to the Raspberry Pi Foundation so that others can learn how to do this themselves. As I stated, everything (including parts lists, schematics, etc) would be completely open source.
As a sidenote, I think a device like this would be very interesting for kids learning how to design their own games.
Great idea, I'd love a device like this running a well integrated retropie(Raspbian) operating system ! Unfortunately I can't help you with this stuff, but I'll spread the word
I have recently replaced my head unit
Everything works on my unit, but the USB camera refuses to work with any of the available dash camera apps
I have installed a basic USB camera app and I can see the input from the camera, so it seems the other apps, simply don't recognize it
I had the camera installed on another MTCD unit and it was working perfectly well
I suspect there is some configuration that is telling android to use a different input, so I have manager to get to the hidden menu and there is a field for DVR, and changed it from the default (0) to 1, then to 2 then to 3, all to no avail
This unit is an Android 6 unit with a quad core with 2GB Ram
See below some of the device details :
HMI: TSJK_010.2017.04.15.10.51
MCU: TS907.170330
MEDIA: CZJv1.0.1_170411_1815
BTV: BT.17.04.07.1755(17:04:20:21:30:45)
Any help will be appreciated
Follow this: Car Settings>Setting Logo>Set Password:3368>DVR type>USB DVR.
https://www.photobox.co.uk/my/photo/full?photo_id=9775466627
I think this is what you need to do if you have joying.
Unfortunately there is no option to put "USB", the only options are numeric, starting from 0
I already tried 0, 1 , 2 and 3, but no joy
The unit looks very much like joying , but it isn't
I have asked the seller and they sell a compatible usb camera, but it has its own sd memory card to record.
What's the point of having a camera connected to an android unit, it is has its own local storage? You may instead have bought a separate dashboard camera
Anyway thanks for the suggestion
usd dash cam ?
I have heard this first time.
javiermi said:
...What's the point of having a camera connected to an android unit, it is has its own local storage? You may instead have bought a separate dashboard camera
Click to expand...
Click to collapse
1. HD+ video recording is a very CPU consuming task, one would not want to have his/her HU stalled. So let the daschcam use its dedicated CPU and local storage SD to do the task.
2. The point of having a camera connected is (as implemented by Joying) being able to output video on HU display, both live and stored on cam's SD - very handy; connected Joying cam (which does not have own battery) also takes time from HU to stamp video. Other brands are even able to take GPS coordinates from HU.
javiermi said:
What's the point of having a camera connected to an android unit, it is has its own local storage? You may instead have bought a separate dashboard camera
Click to expand...
Click to collapse
Because you do not know how usb works.
HD-video is not only CPU intensive, like ste2002 already mentioned, but it can flood your USB channel if you use raw video and encode it on your android unit.
USB-2, as on ALL android units is "half-duplex", meaning that only one device can use it at a certain time and only in one direction (like a walkie-talkie: only one can speak and you press the button and say "over" (as handshake in digitial language) to let the other speak). If you have 2 devices with your dashcam recording, and the 2nd one polls the usb hub, your video stream is interrupted and thereby immediately corrupt. Or the unit needs to send "something" to the dashcam, it will also interrupt and corrupt the video stream.
The option of encoding it on the dashcam and send the video over USB to the unit is better but not fault-tolerant.
encoding it on the dashcam and saving it over usb directly to your unit, might work but could still run in above mentioned problems.
encoding it on the dashcam, save it on the dashcam (internal "mini"-storage), and then copy the complete video over usb to the unit might work well. These dashcams might even be for sale, but I expect they are quite expensive, whereas a local sd-card in the dashcam is dead-simple and dead-cheap.
Once USB-3 gets to these android units, being full-duplex and having much higher speed and bandwidth, it might be useful to do it over USB (making sure all devices are USB-3 or that you have a real switching USB-3 hub), but only if the CPU can handle the HD raw video and encode it: A PX3 can't, a PX5 can't, a Sofia 3GR can't. Wait for much faster units (specification wise both the PX5 and Sofia 3GR should, but both fail on it).
That is why you should ALWAYS let the dashcam do both the video encoding and the storing of the media files, and NEVER over the usb.
Edit: With the Joying, and a lot of others, you can view back the movies, or get an online view where a MJPEG stream is displayed on the unit.
surfer63 said:
Because you do not know how usb works.
HD-video is not only CPU intensive, like ste2002 already mentioned, but it can flood your USB channel if you use raw video and encode it on your android unit.
USB-2, as on ALL android units is "half-duplex", meaning that only one device can use it at a certain time and only in one direction (like a walkie-talkie: only one can speak and you press the button and say "over" (as handshake in digitial language) to let the other speak). If you have 2 devices with your dashcam recording, and the 2nd one polls the usb hub, your video stream is interrupted and thereby immediately corrupt. Or the unit needs to send "something" to the dashcam, it will also interrupt and corrupt the video stream.
The option of encoding it on the dashcam and send the video over USB to the unit is better but not fault-tolerant.
encoding it on the dashcam and saving it over usb directly to your unit, might work but could still run in above mentioned problems.
encoding it on the dashcam, save it on the dashcam (internal "mini"-storage), and then copy the complete video over usb to the unit might work well. These dashcams might even be for sale, but I expect they are quite expensive, whereas a local sd-card in the dashcam is dead-simple and dead-cheap.
Once USB-3 gets to these android units, being full-duplex and having much higher speed and bandwidth, it might be useful to do it over USB (making sure all devices are USB-3 or that you have a real switching USB-3 hub), but only if the CPU can handle the HD raw video and encode it: A PX3 can't, a PX5 can't, a Sofia 3GR can't. Wait for much faster units (specification wise both the PX5 and Sofia 3GR should, but both fail on it).
That is why you should ALWAYS let the dashcam do both the video encoding and the storing of the media files, and NEVER over the usb.
Edit: With the Joying, and a lot of others, you can view back the movies, or get an online view where a MJPEG stream is displayed on the unit.
Click to expand...
Click to collapse
Surfer63,
Thanks for this post, it's one of the more informative ones I've found when searching for answers about making USB cameras work with these Chinese head units. I'm replying because while I'm far from an expert, my experience does not seem to follow some of what your wrote. In my case, I have an ISUDAR brand PX3, 2GB ram using a 7.1.2 "GS" ROM and have successfully used a UVC compliant 1080p USB Camera (Logitech C922x Pro Stream Webcam) and was able to record no problem using the factory supplied app labelled "DVR". The camera has no built in storage, and the only storage option the DVR app allows requires the file to be written to an attached USB stick (my unit has no SD card slot). Both the camera and USB stick are plugged into ports labelled USB 2.0. Overall this seems like good news as it's more successful than most have found.
For me, however it's still not success and I hoped you could shed more light here. My main goal is not a DVR, but to use the camera to record videos by other apps, such as Torque or TrackAddict. These apps support USB cameras and work fine with my Logitech and OTG adapter on my phone, however on the head unit it only partially works. When opening both Torque or TrackAddict the video displays properly in preview, but once Record is selected it either appears to work but does not actually capture video (Torque) or immediately gives an error "recording failed to start" (TrackAddict). When attempting playback from Torque you hear the audio, but the screen is a static mess of the actual image and various green hues and lines.
From this almost successful experience I am trying to determine what is likely not right, and if/how to check and correct. A few thoughts:
1) I know little about the Android inner workings, but reading some android camera API developer info I'm wondering if the ROM has the MediaRecorder aspect "hardwired" to only the DVR app. In my simple view this could explain why video preview works in other apps but recording does not.
2) In Torque you can select which camera to use, since the unit has no built in camera Back 0 doesn't exist and is not in list, Front 0 doesn't either but is in list (shows nothing). Front 1 shows the USB camera and selecting this makes preview work in the app. Interestingly the list also shows the USB camera by name, but when selected crashes the app. Is the head unit seeing the USB camera, assigning it to Front 1 in the background, and also forcing some record settings to USB stick and DVR app? If I could stop the head unit from automatically assigning the USB camera to Front 1, perhaps selecting it by name in Torque would allow it to function properly and record? I have not found any option in the Factory Settings menu to affect this yet.
Anyway, given I feel a bit closer to success than many on here I was hoping for some guidance on what to chase and how. Your insight would be much appreciated.
I'm struggling with similar issues with Eonon 2170 Android 8:
built in DVR app seems to work when it works, though, often stops recording (red light on USB cam goes off)
Torque's plugin just crashes... even though it's supposed to support USB cam
got somewhere with Dash Cam Travel – from Tomas Valek, dev promised to look into this
and, getting results from USB Camera - Connect EasyCap USB WebCam ShenYao China
abbots said:
I'm struggling with similar issues with Eonon 2170 Android 8:
built in DVR app seems to work when it works, though, often stops recording (red light on USB cam goes off)
Torque's plugin just crashes... even though it's supposed to support USB cam
got somewhere with Dash Cam Travel – from Tomas Valek, dev promised to look into this
and, getting results from USB Camera - Connect EasyCap USB WebCam ShenYao China
Click to expand...
Click to collapse
I just updated from a KitKat unit (4.4.4) where the dash cam apps all worked with the USB camera just fine. I have a Allwinner T8 unit and the USB dash cam is not seen using the apps I have.
The apps that I got from the play store now uses my backup camera for the forward camera, but the supplied Dash Cam App works fine selecting the USB camera.
Trying to figure why the USB selection on the apps refuse to select USB while it always selects the backup cam (video source)
I have even disabled the backup and those apps will not work at all.. I will try the Dash Cam travel to see.
I can't help much with the main question(s) being discussed here but I have one of those standalone USB powered dash cams in my vehicle. It's just a totally generic Chinese eBay one.
It records directly to an SD card on the camera itself and broadcasts a wifi signal so that I can manage/view the feed on a (very unstable) app on my iPhone. The app is called "WCVR-PWD".
I've always wondered if there's a way to just view it directly on the Joying itself an sounds like some of you guys are doing that. All I'd be interested in is a totally live feed to adjust the camera as necessary.
What app/mod/function do I need to do to the Joying to do that?
As most? the head units have multiple inputs:
rear camera video in
video/audio in
USB
any experts care to comment on suitability or pros and cons of using composite video output camera versus USB camera?
Would composite output video camera be a superior choice?
javiermi said:
I have recently replaced my head unit
Everything works on my unit, but the USB camera refuses to work with any of the available dash camera apps
I have installed a basic USB camera app and I can see the input from the camera, so it seems the other apps, simply don't recognize it
I had the camera installed on another MTCD unit and it was working perfectly well
I suspect there is some configuration that is telling android to use a different input, so I have manager to get to the hidden menu and there is a field for DVR, and changed it from the default (0) to 1, then to 2 then to 3, all to no avail
This unit is an Android 6 unit with a quad core with 2GB Ram
See below some of the device details :
HMI: TSJK_010.2017.04.15.10.51
MCU: TS907.170330
MEDIA: CZJv1.0.1_170411_1815
BTV: BT.17.04.07.1755(17:04:20:21:30:45)
Any help will be appreciated
Click to expand...
Click to collapse
How did u solve it then .?
conclusion for dvr with SDCard?
Hi
This is a good summary and helpful since a lot of info on google seems outdated.
I have a new Joying 8 Core intel unit (Nov 2019).
I want to buy a small non-Joying DVR camera, record to sdcard in cam, and use the head unit to review video from cam and manipulate the files as required (ex. send an important video or image).
Will the Joying do this for any cheap DVR camera?
Do I just need to use a different DVR app on the head unit?
Thanks!
surfer63 said:
Because you do not know how usb works.
HD-video is not only CPU intensive, like ste2002 already mentioned, but it can flood your USB channel if you use raw video and encode it on your android unit.
USB-2, as on ALL android units is "half-duplex", meaning that only one device can use it at a certain time and only in one direction (like a walkie-talkie: only one can speak and you press the button and say "over" (as handshake in digitial language) to let the other speak). If you have 2 devices with your dashcam recording, and the 2nd one polls the usb hub, your video stream is interrupted and thereby immediately corrupt. Or the unit needs to send "something" to the dashcam, it will also interrupt and corrupt the video stream.
The option of encoding it on the dashcam and send the video over USB to the unit is better but not fault-tolerant.
encoding it on the dashcam and saving it over usb directly to your unit, might work but could still run in above mentioned problems.
encoding it on the dashcam, save it on the dashcam (internal "mini"-storage), and then copy the complete video over usb to the unit might work well. These dashcams might even be for sale, but I expect they are quite expensive, whereas a local sd-card in the dashcam is dead-simple and dead-cheap.
Once USB-3 gets to these android units, being full-duplex and having much higher speed and bandwidth, it might be useful to do it over USB (making sure all devices are USB-3 or that you have a real switching USB-3 hub), but only if the CPU can handle the HD raw video and encode it: A PX3 can't, a PX5 can't, a Sofia 3GR can't. Wait for much faster units (specification wise both the PX5 and Sofia 3GR should, but both fail on it).
That is why you should ALWAYS let the dashcam do both the video encoding and the storing of the media files, and NEVER over the usb.
Edit: With the Joying, and a lot of others, you can view back the movies, or get an online view where a MJPEG stream is displayed on the unit.
Click to expand...
Click to collapse
samster125 said:
I want to buy a small non-Joying DVR camera, record to sdcard in cam, and use the head unit to review video from cam and manipulate the files as required (ex. send an important video or image).
Will the Joying do this for any cheap DVR camera?
Do I just need to use a different DVR app on the head unit?
Click to expand...
Click to collapse
I do not know if the joying will do this for "any" DVR camera. That is an extremely wide area.
90% of the Chinese dashcams are the same and have more or less the same app. I did not hear yet about issues.
Some dashcams come with internal GPS location logging, some not.
Some apps allow you to view the videos over usb, some/most allow you to copy the videos over usb to your local unit drive.
I use my dashcam as well for Mapillary recording. That results in big amounts of data and I simply take the sd-card out of the camera and do it on my laptop. I have two SD-cards which I simply exchange. A 16-32 Gb-sdcard costs something between 6-12 euros (in the Netherlands). Note that any class 4 or better will do. You don't need extremely fast cards.
What I have also noticed in the past (with 2 dashcams, so statistically perhaps completely unreliable) is that most cheap dashcams simply stop in the middle of a recording when being switched off: no battery whatsoever to nicely finish the recording and nicely unmount the sd-card. This leads to lots of minor corruptions. So when I switch SD-cards, I always do a "checkdisk" on the SD-cards and I always have to repair errors. Be aware of that.
GPS for USB Dash Cam
ste2002 said:
1. HD+ video recording is a very CPU consuming task, one would not want to have his/her HU stalled. So let the daschcam use its dedicated CPU and local storage SD to do the task.
2. The point of having a camera connected is (as implemented by Joying) being able to output video on HU display, both live and stored on cam's SD - very handy; connected Joying cam (which does not have own battery) also takes time from HU to stamp video. Other brands are even able to take GPS coordinates from HU.
Click to expand...
Click to collapse
I recently got an ATOTO A6 Pro and have been frustrated trying to embed GPS in the dash cam files. You mention that, "Other brands are even able to take GPS coordinates from HU." Which brands would that be? ATOTO has not been able to help. They just say it is impossible.
I have an Xtrons PX6 Android 9 headunit with cheap usb dash cam. The cam itself has micro SD card inserted and usb plugs into my usb on the headunit for viewing.
I have bought 3 of these cameras 2 to use in different vehicles and 2nd new Xtrons cam to go with the PX6. All of these cameras generally have pre-installed APK on the camera to install on the headunit.
You'll also find that these cameras have GPS and eDog built in aswell as ADAS. I purchased 2 of these cheap Chinese units from eBay for about £15 each and they work perfectly.
The advantage of having the camera record is that if the headunit goes down you still have the camera covering your ass if theirs a problem.
Sent from my VOG-L29 using Tapatalk
Sorry to hijack this thread.
Does anyone know what might be the problem when GPS signals lost immediately right after an usb camera plugged in?
The signals came back once the camera were unplugged. (the camera functioning fine, apart from not detecting gps as they're all lost)
Would it be a fault of the camera or the head unit itself?
USB thumbdrive works fine though, no issues.
Tbizzness said:
I have an Xtrons PX6 Android 9 headunit with cheap usb dash cam. The cam itself has micro SD card inserted and usb plugs into my usb on the headunit for viewing.
I have bought 3 of these cameras 2 to use in different vehicles and 2nd new Xtrons cam to go with the PX6. All of these cameras generally have pre-installed APK on the camera to install on the headunit.
You'll also find that these cameras have GPS and eDog built in aswell as ADAS. I purchased 2 of these cheap Chinese units from eBay for about £15 each and they work perfectly.
The advantage of having the camera record is that if the headunit goes down you still have the camera covering your ass if theirs a problem.
Sent from my VOG-L29 using Tapatalk
Click to expand...
Click to collapse
I have this usb dash cam,but i can't download the update to have adas and other fatures.i can't communicate with the seller because the store is closed.my cam is the U3 Mini Full HD 1080P Car DVR Camera ADAS ...can you help me with the apk file pls?
Hello everyone
Because I came in looking for a solution to a problem with a camera for my car that has a "head unit", I come to ask my question. The "head unit" is isudar px3 with Android 7.1.2. I bought a forward camera that works well on a cell phone with android 7 (and with OTG adapter) without problems and on the date of its correct recording. When trying to put it in the car through one of the USB ports (there are 2 - one that I will say is normal and the other prepared for 3G/WIFI) and after installing the .apk that comes with the camera, it tells me that there is no card and that there is a problem with the USB, as if it did not exist.
already tried several .apk but none can connect with the camera.
During the time that it is connected, the card in the usb case records image and sound although it does not show anything on the car's media player screen, but these recordings show a much earlier date that has nothing to do with the moment in which it is recorded. That date will be that of the camera itself a few years ago. If the date was correct, it would still leave the camera in its place and for the least. But as it does not, its validity in case of an accident will be very weak, obviously, and so it is not working. Having asked the question, I ask for the opinion of someone who has had the same problem and has solved it. Thanks in advance.
Hello world,
So I have several books that I am currently trying to rotate through, since looking at one aspect of any device for too long bores me, and so one of these books is a CompTIA A+ guide. I can get you the author if you'd like, but my question is what would these devices look like inside of an Android device, of course there are many makes and models but just looking to make some friends, and discuss tech. Please, if there are errors DRAW THEM TO MY ATTENTION!
- A BUS is the way by which data is transferred internally. What is the common standard used today? PCI. What is the communication bandwidth of these connectors?
- A central processor, is where data – in the form of machine code is broken down into binary. The processor takes data, in the form of binary streams, performs math, and sends these bit streams to the “addressed?” peripheral or memory devices. Is it fair to say that all other devices other than the cpu are peripherals?
- A Northbridge is the responsible for the flow of data from the CPU and storage component – ie RAM. What is northbridge?
- All external communications occur through the Southbridge.
V/R
Cryptologic Tech 3
I dislike, very much subnetting.