<wens>
i guess the next thing to figure out is to install linux in the onboard emmc, instead of an sd card
<LongChair>
stdint: regarding P010 format, everywhere i looked i found out that it was more or less the same as P016 in terms of memory layout, which was 2 bytes per compononent in terms of memory usage
<LongChair>
and i have the feeling that it's not the way it's used by rk decoder
<stdint>
the decoder don't support P016 only P010
<LongChair>
yes
<LongChair>
it's more about how to interpret the P010 format that is in the buffer
<stdint>
similar to P016 but no empty part in memory
<LongChair>
for a 4K image (3840 x 2160) coming out of a 10 bits , i'm getting a buffer size of 18 911 232
<LongChair>
bytes
<LongChair>
image also reports a stride of 4864 bytes
<stdint>
align with 255
<LongChair>
so 3840 /8 *10 would be 4800
<LongChair>
ok aligned with 256 it will be 4864 which corresponds to Y
<LongChair>
so I have 2160 lines with 4864 bytes for Y
<LongChair>
then what about UV, is that then 2160 /2 * 4864 bytes for UV ?
<LongChair>
because I don't see how it comes to 18 911 232 bytes
<stdint>
the size is correct
<stdint>
you don't need care about that
<stdint>
also the extra space is allocated at the same time to store the mv data
<stdint>
which is appended to the end of the yuv data for a frame
<LongChair>
so the format is 2160 lines with 4864 bytes for Y and then 2160 /2 * 4864 for UV ?
<LongChair>
The fact that the pixels are packed (not aligned on 2 bytes) is going to make it tricky
<LongChair>
it's almost not usable for anything else in terms of format
<LongChair>
see what i mean ?
wzyy2 has joined #linux-rockchip
fischerm has quit [Ping timeout: 245 seconds]
<stdint>
no
<stdint>
this format have been accepted in ffmpeg
<LongChair>
yes P010 has been accepted there, but it's not the same
<LongChair>
in ffmpeg P010 is not packed
<LongChair>
it uses 2 bytes to store the 10 bits in memory
<LongChair>
so the memory storage is the same as P016, but they just use 10 bits amongst the 16 bits in memory
<LongChair>
I checked that with the people that made the P010 format in ffmpeg
<LongChair>
well P010 & P016 have same memory footprint
<LongChair>
just that the data in there is not used the same
<LongChair>
i have seen that 2 bytes alignement also in microsoft description
<LongChair>
so it looks like eveyone uses it the same way
<stdint>
Two 4:2:0 formats are defined, with the FOURCC codes P016 and P010. They share the same memory layout, but P016 uses 16 bits per channel and P010 uses 10 bits per channel.
<stdint>
you had better read it carefully
<LongChair>
yes "They share the same memory layout"
<LongChair>
which is exactly my point
<stdint>
plus 6-bit zeroes in the LSBs P016
<stdint>
without -> P010
<LongChair>
No
<LongChair>
P010 and P016 have same memory layout that is 2 bytes per component
<LongChair>
then P016 uses the 16 bits, P010 uses only 10 bits in those 16 bits, but the 6 remaining bits are set to 0
<LongChair>
but the memory layou is the same
<LongChair>
and it's not the same memory layout as the P010 layout coming from mpp
<LongChair>
for a 3840x2160 image, stride would be 3840 x 2bpp = 7680 bytes
<LongChair>
"The 16-bit representations described here use little-endian WORD values for each channel. The 10-bit formats also use 16 bits for each channel, with the lowest 6 bits set to zero, as shown in the following diagram."
<LongChair>
@stdint : So my point is that the MPP P010 memory layout is not the standard one, which makes it not usable by any other app .. including ffmpeg
<stdint>
LongChair, at lease it works for gstreamer
<LongChair>
yeah .. that's is not very helpful for me :)
<LongChair>
it also makes the decoder output not usable by anything using opengl easilly
<LongChair>
i mean the 10 bit stuff
<LongChair>
because the 8 bit NV12 stuff is standard
<LongChair>
@stdint : is the way the 10 bits is stored in memory a hardware constraint ? or is it just a wrong implementation of P010 ?
<stdint>
it is a hardware implementation
wzyy2 has quit [Read error: No route to host]
wzyy2 has joined #linux-rockchip
<LongChair>
@stdint : so means there is no chance that this can change right ?
<stdint>
yes
<stdint>
it is a good format which save a lots of memory space
<stdint>
I though it is the P010, now it is a new format
<LongChair>
yeah :)
<stdint>
I have to do more extra job to make it work
akaizen has joined #linux-rockchip
<stdint>
I mean those kernel RFC patch
<stdint>
and I have no idea about the its pixel name
<LongChair>
i dunno, maybe something like P010_PACKED or something like that
<LongChair>
also is there any way to have mpp notify which format is really supported ? I mean i know now that there is HEVC /AVC & VP8, but if it depends on the chip, and considerign that mpp could be used on several chips, it would be nice to know
<stdint>
LongChair, yes, but I don't plan to do that
<LongChair>
and i have no idea what makes the difference on wether it is supported or not
<stdint>
LongChair, that list is designed for the future chip than rk3288
<stdint>
there is not a support list exists for different chips
<LongChair>
so in the future, any chip will support all these ?
<stdint>
rk3399
<LongChair>
so rk 3399 supports it all ?
<stdint>
yes
<stdint>
also rk3328
ssvb has quit [Remote host closed the connection]
wzyy2 has quit [Remote host closed the connection]
wzyy2 has joined #linux-rockchip
<wzyy2>
beeno, I have checked the tearing problem before. It's caused by modesetting.
<wzyy2>
Unlike armsoc DDX, modesetting DDX only use one buffer.
<wzyy2>
I plan to restart rga support in modesetting, it might help to improve graphics performance.
wens_ has joined #linux-rockchip
zoobab_ has joined #linux-rockchip
diego71_ has joined #linux-rockchip
mfischer_ has joined #linux-rockchip
cnxsoft has quit [Quit: cnxsoft]
cnxsoft has joined #linux-rockchip
fischerm has quit [*.net *.split]
ayaka has quit [*.net *.split]
zoobab has quit [*.net *.split]
wens has quit [*.net *.split]
diego71 has quit [*.net *.split]
dlezcano has quit [*.net *.split]
dlezcano has joined #linux-rockchip
cnxsoft has quit [Client Quit]
cnxsoft has joined #linux-rockchip
cnxsoft has quit [Client Quit]
cnxsoft has joined #linux-rockchip
nighty has quit [Quit: Disappears in a puff of smoke]
ayaka has joined #linux-rockchip
<LongWork>
@stdint : could RK3299 support VP9 ?
<LongWork>
err 3288 sorry
<LongWork>
i know it is not there yet, but is it capable ?
<stdint>
LongWork, not
ssvb has joined #linux-rockchip
nighty has joined #linux-rockchip
wzyy2 has quit [Read error: Connection reset by peer]
wens_ is now known as wens
<alex_>
Hey guys, managed to semi brick my C201 (disabled dev mode while trying to do a chromeos recovery, so can't boot from usb/sdcard, chromeos wont boot), chromeos recovery fails http://bit.ly/2kS8wmD Any thoughts on how to unbrick it except doing a "external" firmware flash
afaerber has quit [Quit: Leaving]
paulk-collins has joined #linux-rockchip
cnxsoft has quit [Quit: cnxsoft]
afaerber has joined #linux-rockchip
tor has joined #linux-rockchip
paulk-collins has quit [Quit: Leaving]
JohnDoe_71Rus has joined #linux-rockchip
muvlon has joined #linux-rockchip
paulk-collins has joined #linux-rockchip
descend has quit [Remote host closed the connection]
steev has quit [Remote host closed the connection]
narmstrong has quit [Remote host closed the connection]
bamvor has quit [Remote host closed the connection]
sjg1_ has quit [Remote host closed the connection]
lvrp16 has quit [Write error: Broken pipe]
arnd has quit [Remote host closed the connection]
vagrantc has joined #linux-rockchip
steev has joined #linux-rockchip
arnd has joined #linux-rockchip
descend has joined #linux-rockchip
narmstrong has joined #linux-rockchip
bamvor has joined #linux-rockchip
sjg1_ has joined #linux-rockchip
lvrp16 has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
<amstan>
alex_: hey, you probably want to get rid of libreboot perhaps?
<amstan>
alex_: you shouldn't need that, the default coreboot it comes with should work just fine
<amstan>
and it's already open source
vagrantc has joined #linux-rockchip
mrueg has quit [Remote host closed the connection]
mrueg has joined #linux-rockchip
jwerner has joined #linux-rockchip
<alex_>
managed to save it by running chromeos recovery and then powering off after some tim (as suggested by libreboot mailing list), and then enabling crossystem dev_boot_usb=1