08:00 | fredy | left the channel | |
08:00 | intrac | left the channel | |
08:00 | dos | left the channel | |
08:00 | se6astian | left the channel | |
08:00 | fredy | joined the channel | |
08:01 | intrac | joined the channel | |
08:02 | dos | joined the channel | |
08:02 | se6astian | joined the channel | |
08:05 | paulk | Bertl: sure :) it's an ongoing project and will probably take a while to get a prototype but will get there hopefully!
| |
08:09 | paulk | vup: rk3399 is 1080p@30, allwinner v3 is 1080p@60
| |
08:09 | paulk | but newer generations do around 4k@30
| |
08:10 | paulk | RK3588 does h.264/h.265 8k@30
| |
08:10 | paulk | it's a dedicated hw block
| |
08:10 | paulk | rockchip uses the verisilicon hantro family
| |
08:11 | paulk | for allwinner it's less clear, could be some imgtech derivative
| |
09:09 | se6astian | hi paulk, very interesting project, is your focus on higher performance than raspberry pi + hq camera or do you just enjoy working on it yourself
| |
09:10 | se6astian | there is the effort to squeeze out the max possible performance from the pi and use it as cinema camera
| |
09:10 | se6astian | https://forums.raspberrypi.com/viewtopic.php?t=296776&sid=d4197f8a2e8ab8ebe6792ddc497b2ad6&start=150
| |
09:10 | se6astian | but the hardware is of course rather limited
| |
09:10 | se6astian | but very affordable in return
| |
09:20 | paulk | se6astian: yeah it's a rather similar goal, I would just like to avoid the raspberrypi because it's not all that free software friendly
| |
09:21 | se6astian | Right
| |
09:21 | paulk | ideally I'd like to find a better sensor (at least global shutter)
| |
14:18 | davidak[m] | <paulk> "RK3588 does h.264/h.265 8k@30" <- paulk: do these encoders support ALL-I (frames) 4:2:2? that is the next best thing when ProRes 4:2:2 is not available in the camera. when it has clean feed out HDMI you can use an external recorder that support ProRes (i think all do)
| |
14:18 | davidak[m] | not sure if that makes sense with affordable sensors
| |
14:20 | paulk | davidak[m]: pretty sure you can get all-I (it's really up to the driver, also there's no firmware intermediate to prevent that)
| |
14:20 | paulk | I haven't checked 4:2:2 but that feels plausible
| |
14:20 | paulk | who knows, maybe even 4:4:4 :)
| |
14:21 | davidak[m] | sounds very good
| |
14:21 | paulk | yeah basically the gap is closing
| |
14:22 | paulk | i.e. it becomes viable for more serious things than your average user's 30fps 1080p at 4:2:0
| |
14:23 | paulk | about hdmi: "TMDS Scrambler to enable support for 2160p@60 Hz with RGB/YCbCr4:4:4 or YCbCr4:2:2"
| |
14:23 | paulk | that's for rk3588
| |
14:23 | paulk | (HDMI 2.0)
| |
14:24 | paulk | RK3399 is only YUV420 though
| |
14:26 | paulk | but well, my use case for now is to have something somewhat comparable to my Canon EOS 80D, which does 1080p 4:2:0 H.264 I/P
| |
14:26 | paulk | so nothing too fancy, but newer platforms like rk3588 do bring it further
| |
14:27 | davidak[m] | would magic latern help?
| |
14:28 | paulk | on the 80D side probably (support is early work in progress)
| |
14:28 | davidak[m] | ok
| |
14:28 | paulk | for supporting SoCs with Linux probably not
| |
14:28 | paulk | AFAIK magic lantern is very canon-centric
| |
14:28 | davidak[m] | yes
| |
14:31 | paulk | for now my production ambition is more short videos for the web (youtube channel) so I don't really need to be able to produce a high-quality DCP or such
| |
14:45 | anuejn | paulk: sounds interesting :)
| |
14:46 | anuejn | maybe one could also do something like log encoding the images with a shader before encoding them
| |
14:46 | anuejn | that could also help quality-wise
| |
14:47 | anuejn | ef lenses sound a bit to long for these tiny sensors?
| |
14:48 | anuejn | also maybe something like encoding all r, g, and b sensels seperately could be interesting
| |
14:48 | anuejn | (idk if it helps quality-wise)
| |
14:49 | paulk | anuejn: the ISP hardware typically also has gamma LUTs
| |
14:49 | paulk | although if the sensor is only linear, it might help with compression but won't really give a better dynamic range
| |
14:50 | paulk | ah yes for the EF lens that's my worry
| |
14:50 | paulk | I've made a few tries with C-mount cameras that have small sensors
| |
14:50 | paulk | and it's difficult to get focus
| |
14:50 | paulk | that's why I'm interested in large sensors too :)
| |
16:16 | anuejn | sounds interesting
| |
16:17 | anuejn | but for driving the af in a meaningful way you would also need some information
| |
16:17 | anuejn | an i fear that the rpi camera sensor does not have phase detection pixels :(
| |
20:01 | vup | I mean you don't need phase detection if you have the magic of AI :P
| |
20:08 | aombk | joined the channel | |
20:08 | aombk2 | left the channel | |
20:25 | paulk | anuejn: yeah the isp gives sharpness information stats
| |
20:25 | paulk | but probably not phase detection indeed
| |
20:35 | anuejn | paulk: but contrast based af sucks since you dont know in which direction to drive ;P
| |
20:35 | anuejn | especially for video
| |
21:14 | vup | af for video in general usually sucks :P
| |
21:28 | paulk | yes yes
| |
21:29 | paulk | what I have in mind about it is more to draw the indication on-screen and have remote focus pulling
| |
21:30 | paulk | hopefully the lens protocol can allow reliably driving the focus coil without an external stepper
| |
21:31 | paulk | actually one the most recent canon lens I have it seems that the ring is not mechanically driving focus when in manual mode but behaves like a rotary encoder fed to the canon chip as input
| |
21:32 | paulk | which then drives the focus coil accordingly
| |
21:32 | paulk | or maybe it doesn't even go out of the lens at all
| |
21:33 | paulk | anyway not really counting on af
| |
21:34 | anuejn | yeah that would be very interesting
| |
21:34 | anuejn | how well remote focus pulling with ef lenses feels
| |
21:34 | anuejn | since they cant be actuated in an absolute manner
| |
21:39 | paulk | yeah, but at least it would allow controlling the step sensitivity
| |
21:39 | paulk | feels like it could be tweaked to be usable
| |
21:40 | paulk | I'm more worried about roundtrip time from moving the rotary encoder to getting the updated sharpness feedback on-screen
| |
21:40 | paulk | especially if doing remote as in actually wireless
| |
21:41 | paulk | but definitely worth a try
| |
23:45 | Spirit532 | left the channel | |
23:45 | Spirit532 | joined the channel | |
23:48 | aombk | left the channel | |
23:52 | aombk | joined the channel |