Firmware Uploads, Still no access to video stream...

[evorta]

Hi BigBoss,

I am running Mac OS, El Captain + Parallels installed Linux 14.04 + Full USB 3.0 Support (tested independently on another 3.0 hard disk device).

parallels@ubuntu:~$ cat /proc/version Linux version 3.17.3-031703-generic (apw@gomeisa) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201411141335 SMP Fri Nov 14 18:36:40 UTC 2014

I have all the code working. I have been able to successfully upload the firmware:

parallels@ubuntu:~/ps4eye/python$ ./ps4eye_init.py PS4 camera already initialized

parallels@ubuntu:~/ps4eye/python$ lsusb Bus 001 Device 003: ID 203a:fffa

Bus 001 Device 002: ID 203a:fffa

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 003: ID 05a9:058a OmniVision Technologies, Inc. Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

I can even get the light (red light) on the ps4eye to turn on via the other code:

sudo ./ps4eye_cmd.py startup.bin PS4 camera commands done device 0: endpoint 0 : 81 detaching kernel driver... aborting camera read attaching kernel driver...

So I can talk to it. I can even see the option for /dev/video0 when I run Cheese on ubuntu (webcam viewer) I can see the video resolutions of the device - all correctly... But when I click on the PS4Eye to stream I get a blank screen... If I restart and enable the internal HD video camera on the mac - that works fine.

Any ideas to what could be wrong ?

I really appreciate any help even if you can offer some pointers It'd be a big help.

Thank you for all your work it's great, I also emailed the author of the ROS extension as maybe he has seen this issue.

Also in El Captain if I JUST connect the ps4eye to the mac local machine (not the visualised machine). I can see in "Photo Booth & VLC" a second video option USB Camera-OV580 but no video comes out, no errors, just no video...

I'm so close to getting this going, really don't want to give up as it'd be great to have all this running.

I was thinking of the next step being just cutting the wires shorter and re-soldering as maybe it's a cable length / quality of connection issue....

kind regards, eVorta

[bigboss-ps3dev]

Sorry but i don't know what can be happen on linux. Try to use a mode with low resolution and low framerate, perhaps your linux/parallel can't work directly at high framerates/resolutions.

About osx you can use my code to play with your camera, but you must understand that osx does not understand ps4eye camera frames with default system driver because does not understand the format. You can do with my code or make your system driver.

Check this to understand format http://bigboss-eyetoy.blogspot.com.es/2015/02/reversing-playstation-4-camera.html you will understand why osx don't understand frames by default.

[evorta]

Hi,

Thanks for getting back to me. I found the problem being poor connections in the cable hack. I used your source to see that most frames were being dumped. I am going to try and rebuild it and build a simple extension to push out a /dev/videoX device with a pre-configured framer rate and resolution.

I see what you mean by the frames too now, even if they did get through they aren't in a format that are understood.

Thanks again for your input, will link back/credit you and your source if I get anywhere with it.

[dreiundzwanzig23]

Hi evorta, I get exactly the same problem on Ubuntu 15.10 and 14.04 LTS with 4.2 kernel on a laptop and desktop. I can see and init the cam but get no frames from it, only a black box with the right resolution. After resoldering the cable 3 times I give up. It would be very nice if you can give any hints if you solve the problem. Best 23

[evorta]

Hey,

1). If you use this python script: https://github.com/ps4eye/ps4eye/tree/master/python. Can you initialise the camera, e.g. it changes to a initialised video device? Then most importantly if you run the

./ps4eye_cmd.py startup.bin 0

The 0 is the /dev/video device - so if you have a internal video device it may be ./ps4eye_cmd.py startup.bin 1

Do you see the light on the front turn on after the command has run? if so it's probably the same issue I had. I got the code running (https://github.com/ps4eye/ps4eye/tree/master/record) and if I dropped the frame rate to 8 frames per second, I can get 2 1280X800 views.

2). I suggest just using the code BigBoss made as it works perfectly I did some changes so I didn't have to use any frameworks so it's just pure c++, libusb and opencv to show frames, If you'd like a copy it runs on OS X, I'll have it running on ubuntu today so I'll try and ask BigBoss to add it to this repo or create an off shoot for ya.

Regards,

[evorta]

Also to run at full frame rate I ordered a real usb connector that i'll solder it all properly to. I'll report back on speeds once it's done.

[dreiundzwanzig23]

Hi, yes I can use the python script ./ps4eye_init.py from ps4eye/python to successfully init the camera. When executing ./ps4eye_cmd.py startup.bin 1 (on my laptop device 0 is the internal camera) a lot of stuff is printed to the command line and the red led turns on. In this script is a commented opencv2 capturing part, when using it, again the captured frame is initialized and a black box is visible, but not more, no video stream. I guess the connection is established but unable to get the frames. I have not tried to use the stuff in the record folder yet, I will test it next, thanks for your hint. It would be very nice if you can share the pure c++ code, because I have no mac available to test BigBoss's code. Regards, 23

[stbnps]

Hi! I may be able to shed some light on the matter.

I have the same problem that you are reporting on linux (tested on all versions of ubuntu equal above 14.04).

I've managed to build and run the library in both linux (only a couple of things needed to be changed) and windows (using a fork of libusb with isochronous support).

I know the connection is working because Windows has a propietary driver for the ov580 and I'm able to see the frames with the windows 10 camera app (though frames aren't being decoded correctly).

From what I've seen so far, what happens is that the image processor sends empty isochronous packets (only sends the header). According to the UVC specification this may be the result of a buffer underrun (Table 4-85). Most importantly, this happens both when running the c++ code in linux or when using Windows' 10 camera app inside VirtualBox (frames are empty on windows too in this case). This makes me think it may be an issue with linux's xHCI driver.

On the other hand I've been able to grab frames on windows with the c++ code. Hovever it's not completely working yet. There are some issues like the camera not working at 1280×800p@60fps (but working fine at the rest of modes: 1280×800p @ lower fps, and lower resolution @ all supported framerates). Other problem I'm facing is that the images are too dark and I haven't been able to control the gain or exposure yet.

Maybe we could help eachother!

[bigboss-ps3dev]

It would good to see windows code. Is the ov580 native driver incorporated on w10? I would like to investigate a little on it. Are you loading firmware with my code or are you using python loader?

i only asure full perfomance on osx, i did a multicam extension but this code is not released. Buffers with greater size are needed

I am reversing some ps4 parts of the original driver but progress wil be slow

[stbnps]

Hi!

I've just created a repository and uploaded the code I'm running (which is almost the same as yours).

I've also added a traffic dump I captured using wireshark.

In answering to your questions, I don't use the python code at all. I upload the firmware and grab the frames with the same app (on the first run, it uploads the firmware; and on the second run it streams video).

I also believe once the firmware has been uploaded, windows realizes it is a camera processor and loads the native video driver (usbvideo.sys). From that moment it is the user application's duty to recover and display frames; the default camera app fails to figure out the data format, but the stream happens anyway and glitchy images can be seen.

[stbnps]

By the way, it is working on Windows 10! :smile:

The dark images were because the camera didn't have automatic exposure switched on, and the exposure value was too low. This makes me wonder... How were you be able to get your images? You don't seem to be setting auto exposure on anywhere.

[bigboss-ps3dev]

Cool, glad to see w10 working code, commit your changes please. What are you using to compile in w10?. I have a vm with w10 on osx and i would like to test on it. Don't forget to include license files.

[stbnps]

Hi! I used Visual Studio 2015. Bear in mind that you need to link the project to a specific version of libusb (check the README on my repository).

[bigboss-ps3dev]

Nice i will test it, and i will try to incorporate your changes

[bigboss-ps3dev]

i compiled your code in w10 but i received error 87. Are you compiling 32 or 64 bit code?

I got this executing. Same problem reported from other user: Found PlayStation Camera 1 libusb: error [windows_transfer_callback] detected I/O error 87: [87] El parßmetro no es correcto.

[stbnps]

Hi!

I compiled it to 32 bits. Your program is printing a 1. That means the init method is working, then the error pops up. I'm guessing that you get that error when starting the isochronous transfers.

Did any of you try to run it outside a virtual machine? (I already said that it doesnt work when running it on a windows vm inside a linux host)

Did you use the correct version of libusb? (Not the official one, but the one with isochronous support)

Did you set the ov580's composite parent device to use libusbK as driver? (Use zadig to do it)

I recall having the error you describe, but I dont know how it solved it. It may be any of the things I just told you. Again, the most likely scenario is that your isochronous transfers aren't starting.

If you can't solve the error, let me now and I'll try to reproduce it.

[bigboss-ps3dev]

I am using vbox w10 vm in osx. I attach device to vm after check and load firmware on osx. Could you share exe with static libs and without forcing firmware loading (you are forcing load firmware always, i check fisrt and if it is loaded i don't reload it) to discard compiling issues? I believe that it can be vbox issue.

[chrisheaththomas]

Same error 87 for me running Win 10, libusbK 3.0.7, VS 2013, libusb iso fork https://github.com/dmitrykos/libusb/tree/windows_iso

[stbnps]

I've been extremely busy lately, let's see if I manage to do it this weekend. Sorry for the delay.

[bigboss-ps3dev]

Cool i had been working and i have new firmware to test. Also i discovered that Sony support 4 types of cmos sensors i have ready settings for them i will share infoabout it soon

• KINKO 1G4P
• OV9713 1G4P (it's the one that i have in my devices)
• OV9714 1G4P
• other one named 5P

[jdavidberger]

I've been hacking up one of the newer PS4 eye models. It enumerates just fine but the video isn't great; seems like its dropping most of the data frames. Any idea what the current draw requirements for the camera are?

I have some testing tools coming in next week to look more into it, but was curious if this was a known thing.

[jdavidberger]

Current draw requirements on the camera are 250-300ma as far as I can tell -- and that is running off the PS4 itself -- that wasn't the issue.

LPM is the issue on linux. It basically tries to sleep during streaming, which doesn't go super well. You can disable LPM starting with kernel ~4.6; I tested it under 4.8. Do this by running:

sudo su
cd /sys
find | grep usb3_lpm_permit | xargs -I {} bash -c "echo 0 > {}"

After that the camera works with this repo; and somewhat with normal UVC stuff -- although the frames are oddly sized in normal UVC viewers; which is to be expected.

[l33tl4bs]

Give this guy a medal!!! @jdavidberger

Fixes the black screen when trying to access the uvc stream (e.g. guvcview). All working fine after disabling LPM on Ubuntu 16.04.1 with kernel 4.13.0-43-generic. Also, if you try to access the feed programatically and get errors of this type: "Error: pack %d status %d" - also fixes these!

[thomask77]

[..]

sudo su
cd /sys
find | grep usb3_lpm_permit | xargs -I {} bash -c "echo 0 > {}"

[..]

Is there a way to do this in an udev rule?