H.264

[gusmanb]

I've been thinking a bit about the H.264 interface.

I'm not an expert in H.264 but I have used it a bit with streaming cameras, these used RTP encapsulation to send the frames, and a tipical packet size was 1024.

The OUT report of this interface is 1024 bytes length, which fits with these packet size, so may be worth it to try to send RTP encapsulated H264 data, it may accept it.

When I get some spare time I will create a WinUSB driver and installer and try to feed the device with RTP packets and see what happens.

If someone has any other thoughs all are welcome.

[mungewell]

Great thought....

Is it possible to have a little script which connects to a streaming source, and just throws packets into the USB endpoint?

[gusmanb]

First I would like to contact the people what I worked on that project as they have more knowledge on RTP packaging, I have no idea on how to make the RTP packets as I only manipulated them to feed a video player on web, I hope they can help me a bit on this.

Maybe looking at VLC streaming server can help, will check it this week as I know VLC or GStreamer can be used for this. Once we got the stream correctly encoded and encapsulated is just a matter to send the packets as-is.

[Entropy512]

I'm guessing based on some of this discussion that you seem to have made most of your discoveries using the morpheus bridge source code along with some trial and error to see what various commands do?

Have you done any USB traffic sniffing using something like USBProxy - https://github.com/dominicgs/USBProxy - If not I can try to get that set up later. It should be much easier to figure out what the PSVR wants to see by looking at a traffic capture, the H.264 headers should be recognizable making it easy to recognize the encapsulation. This assumes that USBProxy doesn't degrade performance to the point where things just crap out

[gusmanb]

@Entropy512 Do you have a PS4, the PS VR and a board with OTG? If yes then that would give us a lot of info, not just on this interface but also with all the missing bits of protocol on the rest of the reports.

I didn't knew about USBProxy, I was asking in other issue if someone kew about a cheap USB analyzer, and this can be what I need. Do you know if this will work with a Raspberry Zero? I don't have one but are extremely cheap, so if this work I will buy one for sure.

Please, test if this works and share your results. I think at least for commands will work, they're reporting speeds about 15 reports per second, for real time video this is insufficient, but we don't need a working stream, just the first packets to the interface. A big problem I can see is the sensor report, it updates a thousand times per second with two sensor reports inside to achieve the 2Khz sensor frequency required for the fusion algorithms, so that will saturate the device. But, if the tests are done with the headset off that report is not sent, so may be it will work for some things and not for others.

[Entropy512]

I have a PS4 and PSVR.

I don't believe the Pi family of devices has USB Gadget support - the MicroUSB port is only for power I'm fairly certain. Most USBProxy development appears to be done on the BeagleBone Black which I do have (although I'm not quite sure exactly where it is right now) - I'm going to attempt to get it set up sometime in the next few days.

[gusmanb]

The Zero module does have OTG and is used precisely to create gadgets.

[Entropy512]

That might work - both gadget and host, although USBProxy would obviously need some massaging to work with the Zero. I'm at least going to focus on the BBBlack initially as it has an Ethernet interface that is not hung off of the USB controller, which would help for getting the captured data off the device. It also happens to be what the USBProxy guys are developing against. :) Well, there's also the fact that I don't have a Zero but I have a Black. :)

[gusmanb]

Perfect :)