As you may know there is a undocumented (without sources) api hooking loader. Beside the ilegal use of this tool, there might be a legal use as well.
I wondered if it is possible to hook the api call(s) responsible for checking wether a video is loaded from ms or disc0.
If hooked successfully there migth be a chance to increase the resolution as well as a change to the AVC codec. Sony already promotes the AVC ms solution for Firmware version 2.0. Can we do that for 1.50?
Any comments will be appreciated :-)
api hook
Hooking and analysing the running system is a complicated issue, with many different alternatives.
One way is to hook all the calls of a program/game to the system, and provide loging (as "hooking loader" does). This is useful if you don't know what the program is doing. Legal for educational uses, but unfortunately more often used for "cracking".
This doesn't help understanding what is going on inside the system (ie. between the time the game calls a system API and when it returns).
Fortunately with the Kernel memory access, you can patch any function you want (including those in the bowels of the system). Patch it to jump to your code before and after it does the real work. Your patch can log what is going on, or muck around with the parameters.
This is often done driven by your own test program (ie. you already know what system calls are being called, you are trying to find out what the system is doing under the covers).
----
re: improving video playing
It gets more complicated -- many of the standalone feature (like movie playing, or photo viewing) are done in the "VSH" modules. They are not loaded like normal games. Other similar fake loading tricks are possible.
The video/audio codec libraries can be loaded by your program, but the interface hasn't been worked out (yet?)
That's my advice where to start: write a stand alone program that loads and plays a video (using the "sce*codec" and "sceMpeg*" system libraries). Take a gander at the VSH "msvideo_plugin.prx".
------
Bottom line: it depends on your approach. Adding new features to the core operating system can be a lot of reverse engineering work, hooking tricks, and may not be possible afterall (without reflashing -- because the way the system restarts between programs)
The other approach is to find an open-source player that does what you want, and port it directly [requires much less reverse engineering, but won't exploit the hardware as well]
BTW: CLIE owners have a similar tradeoff (using the built-in but format limited movie/audio player which is optimized to the hardware, or a 3rd party player like TCMP which is more general but less optimized)
One way is to hook all the calls of a program/game to the system, and provide loging (as "hooking loader" does). This is useful if you don't know what the program is doing. Legal for educational uses, but unfortunately more often used for "cracking".
This doesn't help understanding what is going on inside the system (ie. between the time the game calls a system API and when it returns).
Fortunately with the Kernel memory access, you can patch any function you want (including those in the bowels of the system). Patch it to jump to your code before and after it does the real work. Your patch can log what is going on, or muck around with the parameters.
This is often done driven by your own test program (ie. you already know what system calls are being called, you are trying to find out what the system is doing under the covers).
----
re: improving video playing
It gets more complicated -- many of the standalone feature (like movie playing, or photo viewing) are done in the "VSH" modules. They are not loaded like normal games. Other similar fake loading tricks are possible.
The video/audio codec libraries can be loaded by your program, but the interface hasn't been worked out (yet?)
That's my advice where to start: write a stand alone program that loads and plays a video (using the "sce*codec" and "sceMpeg*" system libraries). Take a gander at the VSH "msvideo_plugin.prx".
------
Bottom line: it depends on your approach. Adding new features to the core operating system can be a lot of reverse engineering work, hooking tricks, and may not be possible afterall (without reflashing -- because the way the system restarts between programs)
The other approach is to find an open-source player that does what you want, and port it directly [requires much less reverse engineering, but won't exploit the hardware as well]
BTW: CLIE owners have a similar tradeoff (using the built-in but format limited movie/audio player which is optimized to the hardware, or a 3rd party player like TCMP which is more general but less optimized)