ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | Wiki at | Logs at | ML at
vagrantc has quit [Quit: leaving]
LongWork has joined #linux-rockchip
LongChair has quit [Ping timeout: 240 seconds]
LongChair1 is now known as LongChair
nighty has joined #linux-rockchip
cnxsoft has joined #linux-rockchip
<wens> phh: -rc7 works on my c201
tizbac has quit [Ping timeout: 245 seconds]
tizbac has joined #linux-rockchip
<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
fischerm has joined #linux-rockchip
<LongChair> > P010 is the 10-bit variant of NV12 (planar luma, packed chroma), using two
<LongChair> > bytes per component to store 10-bit data plus 6-bit zeroes in the LSBs.
<LongChair> so one Y is 2 bytes storage
<LongChair> the remaining 6 bits are set to zero, they are not used to the 6 first bits of next pixel
<LongChair> which is my point
<LongChair> i tried the buffers that i'm getting out of the decoder with ffmpeg P010 format, but lib swscale will crash on it because of this
<LongChair> it's expecting a bigger buffer there as it's expecting 2 bytes per component instead of 10
<LongChair> bits
<LongChair> see ? :)
<LongChair> the swcale lib in ffmpeg will crash in those conversion functions :
<LongChair> because they expect 2 bytes per pixel
<LongChair> @stdint : thoughts ? :)
<stdint> it is not correct then
<LongChair> what is not correct N
<stdint> plus 6-bit zeroes in the LSBs
<stdint> it is P016 not P010
<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> may i ask why ? :)
Omegamoon has joined #linux-rockchip
<LongChair> the function is already existing there : , it just returns invalid values
<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 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
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria]
Omegamoon has left #linux-rockchip [#linux-rockchip]
tor has quit [Quit: Leaving]
afaerber has quit [Quit: Leaving]
nighty has quit [Quit: Disappears in a puff of smoke]