06:06 <chewitt> vkoskiv: the kernel patches are likely required to make the rpi-ffmpeg branch work

06:07 <chewitt> I wouldn't be surprised if there are sub-optimal things in the memcp paths

06:08 <chewitt> the code hasn't really been touched beyond basic "make it compile again" fixups since early 2020

06:09 <chewitt> the kernel has likely moved onwards in places causing a little code drift

06:10 <chewitt> conformance tests flag a few things

06:10 <chewitt> (hence it's all still in staging)

06:13 <chewitt> vp9 should work as long as it's 8-bit content

06:14 <chewitt> the challenges that I see are that lots of vp9 is 10-bit which results in board lock-up

06:15 <chewitt> or it's in 59.94 which results in "Fatal Error, invalid HDMI vclk freq 593406" and nothing plays

06:15 <chewitt> more info: https://github.com/chewitt/linux/issues/3

19:07 <lvrp16> f_: both the codec hw ip is completely proprietary to Amlogic.

19:07 <lvrp16> that might make it pretty difficult to RE.

19:08 <f_> too bad..but I wasn't going to reverse-engineer vdec

19:18 <f_> That might make it difficult to RE though, indeed

21:21 <cyrozap> IIRC the AMRISC registers and memory are visible to the host, so reverse engineering the ISA should be fairly straightforward. Even with purely static analysis of the firmware binaries I was able to identify possible jump instructions. So, really it's just a matter of time and energy that needs to be spent to RE that ISA--it didn't look like anything really exotic, and a 5- or 6-bit opcode space in

21:21 <cyrozap> 28-bit instruction words means there aren't too many instructions to RE in the first place.

21:24 <cyrozap> My guess is that AMRISC is just your basic textbook MIPS-like 32-bit RISC CPU, and once the ISA is RE'd it should be straightforward to RE the video decoder hardware.

22:08 <f_> still reverse-engineering vdec?