Streaming video out from PSP over USB

Bytrix · Post by **Bytrix** » Wed Jan 17, 2007 11:11 pm

Someone over on the maxconsole forums brought up an idea that sounds interesting (and so simple I'm sure someone has tried it before):

Basically some way of transmitting video data between PSP and PC (or hardware device), format doesn't matter, probably a raw dump of the framebuffer per frame. Using a reciever on the PC the data will be converted to screen format and displayed on a monitor.

I'm just asking if anyone has heard of this method before, or you programmers with more experience using the USB transfer if this is remotely possible?

I'm going to take a stab at it tomorrow anyway, I'm not expecting full video, if I even manage to transfer over one whole frame I'll be happy:

http://forums.maxconsole.net/showthread ... post374575

juanmiguelrr · Post by **juanmiguelrr** » Fri Jan 26, 2007 7:28 am

Hi Bytrix!

I've thinking about that you say for a long time and I thougt it was possible without problems BUT... I'll tell you some of my experiences trying it.

- First of all, I made some tests with the sample code "echo" that came with psplink2.0 (tools directory) and I was really excited when I realize that you can access data sent by PSP from PC in 127.0.0.1 port 1004 (with echo.prx) thanks to usbhost_fs.

- I thought all my problems where solved and I created a windows app that could get all that data from the psp (only empty bytes for testing not image)

- Next step, I captured a RAW frame with a sample code "screenshot" to the memory stick and I was able to translate it to TGA or BMP in the windows app. I was near...

- BUT when I test the bandwidth between my app and usbhosts all my dreams where broken... :(

- Look at this numbers:

1303664 bytes/sec = 1.251 MBytes/sec

This is the bandwidth between pc and psp via usb (usbhostfs)

Each frame in raw data from psp is 391680 bytes so we need to have 25fps... 9792000 bytes/sec = 9.338 MBytes/sec

So I'm at this point... do you think is possible to have a real usb 2.0 transfer???

Thank you!

Post by **TyRaNiD** » Fri Jan 26, 2007 7:54 am

The asynchronous USB stuff was designed for low bandwidth low latency stuff, not high bandwidth bulk transfers. I.e it was for shells, debuggers remote joystick stuff etc. If you want higher transfer rates in the order of 8 to 10 MB/s then you need a means of transferring it over the usbhostfs protocol, of course you could ask that USB2 is 480Mbit/s well tbh that is mostly bullshit, at best case you have 80MB/s to play with, then you have protocol overhead, bus contention, HDD speed, and the limitation of PCI itself (which lets face it is in most cases still a 33Mhz bus) so you end up with considerably less than that. Of course if you want to prove me wrong by writing a USb driver which transfers to a PC anywhere close to the 80MB/s then go right ahead :)

digihoe · Post by **digihoe** » Fri Jan 26, 2007 8:30 am

TyRaNiD, I'm having a hard time figuring out what you really mean with your reply...

Do you mean that USB with 8-10MB/s is possible with a driver rewrite?

Or do you mean that it's not possible too forece these speeds from the USB?

Other thought...
I have seen that UltraII MS can write upto 8-9MB/s depending on size, is it possible to use a big enough circular buffer on the MS and just read from this when the PSP is in USB mode A and in this way incressing the read speed?

Best regards!

Post by **TyRaNiD** » Fri Jan 26, 2007 3:16 pm

Okay perhaps it was slightly cryptic. As long as you are using usb2 (and there is no weird hardware issues) then you can use the normal filesystem access to write data to the PC at 8-10MB/s that is the performance of bulk writes, of course if you try and write in 1byte units you will get significantly lower performance than that.

There are also extra tricks to improve performance. For example make sure all your buffers are 64byte aligned as then usbhostfs doesn't have to do an internal copy and make your buffers multiples of 64KB as much as possible as that is the maximum transfer unit for a single usbhostfs command.

There is also the undocumented pure bulk mode which doesn't wait for the response from the PC so in theory can improve performance somewhat.

Ostehovel · Post by **Ostehovel** » Fri Jan 26, 2007 11:09 pm

If this app is realy going to life it will be easy to capture 25 FPS videos realtime over USB cable..
And maybe to an addition to the program... maybe you can make that you can control your PSP from the PC to?

juanmiguelrr · Post by **juanmiguelrr** » Sat Jan 27, 2007 12:13 am

Hi all,

Thanks for all your information but I think that I cant go so far with my knwolegde yet.
Tyranid, I don't understand so much what you say with the aligned 64 bytes. Which bandwidth are you speaking about doing that?

Another question... this undocumented pure bulk mode... where should be implemented? libusb? usbhost in both sides (pc & psp)?

Thank you so much!

Post by **TyRaNiD** » Sat Jan 27, 2007 3:03 am

Internally usbhostfs needs data to be aligned to 64byte addresses as it is dmaed to the usb controller chip. Now when something isn't 64byte aligned usbhostfs copies it into a local aligned buffer and transmits that, if you pass 64byte aligned stuff into the code then it doesn't need to do any memory copies and thus works faster.

As for 64KByte stuff, usbhostfs only has a limited amount of ram available for copying, plus it is synchronous, as the usb bus cannot be directly shared other things waiting to send data are queued, in order to balance out the availability of the asynchronous layer which is used for psplink shell etc. and the bulk transfer of files I chose to window up the transfer into at most 64KB blocks so that using a round robin priority system bulk transfers wouldn't lock up the bus.

And the undocumented bulk mode, well in a nut shell you call sceIoOpen with a special flag (1<<24 if I recall) which marks a single file descriptor for use in bulk transfer mode then you call the special usbBulkWrite function exported by usbhostfs to actual do the writes, this still writes to a file although in theory you could get it to write to the socket with abit of modification. All that is doing is working like async transfers (i.e. doesn't care if the data ever reached its destination) but with the block size of normal transfers (i.e. 64k as opposed to 512 bytes for async).

juanmiguelrr · Post by **juanmiguelrr** » Sat Jan 27, 2007 6:12 am

Thank u TyRaNiD, I think i'll investigate in this way. It is complicated for me now, but it's not impossible dedicating time to it. I'll try.

Thanks again. We should get alive this post, it's very interesting...

ahman · Post by **ahman** » Sat Jan 27, 2007 4:22 pm

This is an interesting topic. With a bit of smart compression and/or sending only the changes between screens, your bandwidth requirement will be greatly reduced. However, you shouldn't use those standard compression library, such as zlib which will only slow down your system tremendously. IMO, 1MByte/sec (8Mbit/sec) should be sufficient.

Post by **TyRaNiD** » Sat Jan 27, 2007 8:57 pm

Well this has been discussed before, the question really comes down to do we have free cpu time to actually do much in the way of compression. Certainly if you could get the ME to do the lifting you could get full frame compression and perhaps almost full frame rate, but then you would loose the ME. If you did it on the main cpu then any decent compression for images is going to take an amount of time which will impact your frame rate (remember it is potentially 60fps). And as for doing image changes, well that is going to work for certain things such as say a shell, maybe the vsh, maybe some games but in the general case it is going to fail unless you do something very complex mapping pixel movement etc al la mpeg style video.

Still my idea would be this, do the block removal just to hope that in most cases you can save some transmission time. Split the frame into blocks and checksum each one using perhaps crc32 or similar. If your blocks were say 32x16 then that gives you 255 blocks on screen which means we only need to store 255*4 bytes for our block map which is around 1k of memory (as opposed to storing the entire screen in one go). Also by chunking we could easily do some dirty compression schemes, say convert 32 to 16bit color, vertival and/or horizontal reduction shit like that, even perhaps even some variant of JPEG compression :)

Tinnus · Post by **Tinnus** » Sun Jan 28, 2007 6:58 am

Reducing color depth is a good one for quick speed gain. (a la VNC)

Interlacing could be a possibility too.

Post by **TyRaNiD** » Fri Feb 16, 2007 12:24 pm

In update I have managed to get this to work pretty reasonably, there are some issues with it but nothing totally awful, I get a pretty good framerate considering I am doing raw data transfers (with 32 to 16 colour conversion to reduce bandwidth somewhat). Nice to play ridge racer psp on my 19" monitor with an xbox gamepad ;)

Whether I'll release I dont know yet, will have to see :)

reefbarman · Post by **reefbarman** » Fri Feb 16, 2007 1:23 pm

a homebrew that could stream this over usb would rock the scene totally i believe, i think if you can tyranid release a stable version it would be pretty significant

Bytrix · Post by **Bytrix** » Fri Feb 16, 2007 9:46 pm

Sounds cool. I managed to get a decent speed in my own homebrew, but couldn't figure out how to do it with a plugin for OE. I look forward to seeing this working :)

digihoe · Post by **digihoe** » Sat Feb 17, 2007 10:50 am

Bytrix wrote:Sounds cool. I managed to get a decent speed in my own homebrew, but couldn't figure out how to do it with a plugin for OE. I look forward to seeing this working :)

What kind of framerate/speed did you get?

Best regards!

Post by **TyRaNiD** » Tue Feb 20, 2007 2:30 pm

Yawn, okay so i've put my code into subversion. It is a touch on the buggy side sometimes ;) Rough figures based on my PC, USB 2, 1.4 Athlon etc etc. is around 15fps 32bit colour full frame, 20-30fps 16bit colour (or 32bit reduced to 16) full frame. Good enough to play ridge racer with ;)

Code can at run time enable 32->16bit compression, quarter resolution etc. View full screen, take screenshots, run as a OE plugin, that kinda thing. Give it a try :P

reefbarman · Post by **reefbarman** » Tue Feb 20, 2007 4:31 pm

where can i find it, i had a look but i couldnt find it, what did you call it?

sounds really good cant wait to give it a try

Post by **TyRaNiD** » Tue Feb 20, 2007 11:43 pm

Come now, surely the fun is in working out where I put it ;)

digihoe · Post by **digihoe** » Wed Feb 21, 2007 12:42 am

Haha... In the subversion, I guess that means the CVS, i.e you need to compile it yourself...

Best regards!

Bytrix · Post by **Bytrix** » Wed Feb 21, 2007 1:04 am

We don't use CVS here, we use SVN instead (SubVersion):

It did confuse me a bit when I looked at the changelog and saw the only recent modifications were on remotejoy...

http://svn.ps2dev.org/filedetails.php?r ... =2186&sc=1

Post by **TyRaNiD** » Wed Feb 21, 2007 3:12 am

See that wasn't hard now was it :)

reefbarman · Post by **reefbarman** » Wed Feb 21, 2007 11:14 am

i did see that but i wans't to sure now to get it going i have to compile the entire remotejoy? and it compiles the pc side software required as well??

zhangaihe · Post by **zhangaihe** » Thu Jul 05, 2007 9:05 pm

first,sorry my poor english,i am from china
I make a experience,making use of psplink and remotejoy, and under game state,can transfer video to pc ,30fps,but my problem is :it cann't transfer video under play video.i am studing the psplink soure code.
regarg to all of you.
[email protected]

psychospacefish · Post by **psychospacefish** » Thu Sep 27, 2007 4:33 pm

Does anyone know if 32bpp to 24bpp is possible? What would be the best way to go about removing the alpha channel from the image?

forums.ps2dev.org

Streaming video out from PSP over USB

Streaming video out from PSP over USB

PSP2TFT :)

PSP2TFT or something...

i can transfer video to pc via usb under 30fps