`_^gk`_^1wm`_^ has left #linux-rockchip [#linux-rockchip]
<stdint>
LongWork, I think that branch lacks of a patch to support 4K@60HZ
<stdint>
you have to force it into 4k@30HZ
geekerlw has joined #linux-rockchip
nighty has joined #linux-rockchip
geekerlw has quit [Quit: Page closed]
cosm has quit [Remote host closed the connection]
cosm has joined #linux-rockchip
muvlon has quit [Quit: Leaving]
cnxsoft has joined #linux-rockchip
Laibsch has quit [Read error: Connection reset by peer]
athidhep has quit [Quit: athidhep]
leah2 has joined #linux-rockchip
wzyy2 has joined #linux-rockchip
Laibsch has joined #linux-rockchip
wzyy2 has quit [Read error: Connection reset by peer]
muvlon has joined #linux-rockchip
czar_x has joined #linux-rockchip
tlwoerner has joined #linux-rockchip
czar_x has quit [Read error: Connection reset by peer]
czar_x has joined #linux-rockchip
tlwoerner_ has joined #linux-rockchip
czar_x has quit [Read error: Connection reset by peer]
tlwoerner has quit [Client Quit]
tlwoerner_ is now known as tlwoerner
Laibsch has quit [Read error: Connection reset by peer]
beeno has joined #linux-rockchip
lkcl has joined #linux-rockchip
Laibsch has joined #linux-rockchip
muvlon has quit [Ping timeout: 245 seconds]
muvlon has joined #linux-rockchip
holin has joined #linux-rockchip
ganbold has quit [Remote host closed the connection]
tlwoerner_ has joined #linux-rockchip
tlwoerner_ has joined #linux-rockchip
tlwoerner has quit [Ping timeout: 252 seconds]
tlwoerner_ has quit [Ping timeout: 260 seconds]
<beeno>
hi guys. Has anyone ever played a vp8 file?
ganbold has joined #linux-rockchip
tlwoerner_ has joined #linux-rockchip
<LongChair>
stdint: morning
<LongChair>
i have a small issue with mpp
<LongChair>
i have an async program that can close decoder & release frames separately
<LongChair>
when i deinit frames after decoder has been closed i'm getting "mpp_buffer: Assertion buffer->ref_count == 0 failed at deinit_buffer_no_lock:178"
<LongChair>
and i don't see a way to know if the mppframe buffer has still references
<LongChair>
is there a way to get that information ?
wadim_ has joined #linux-rockchip
Omegamoon has joined #linux-rockchip
<stdint>
LongChair, oh it looks that you don't Free all the buffer
<stdint>
every buffer get from mpp_buffer_get() should be release with mpp_buffer_put()
<LongChair>
i'm using only mpp_frame_get_buffer
<stdint>
how do you allocate the buffer for mpp?
<LongChair>
i don't do that myself, mpi is doing that
<LongChair>
i think it might come from the fact that i try to deinit the frame afetr decoder was closed
<LongChair>
then mpp displays that there is a remaining buffer (fd=39)
<LongChair>
then i deinit that frame
<LongChair>
then assertion
<stdint>
LongChair, you may share my your code
<LongChair>
yes i will push that in a moment and link it
paulk-collins has joined #linux-rockchip
<LongChair>
but should mpp_frame_deinit work ok after mpi has been closed ?
<beeno>
stdint: Do you know what type of file is required for OMX_RK_VIDEO_CodingVP8. What is the file extension in this case?
<stdint>
beeno, just vp8 video codec
<stdint>
you could use mp4 or mkv to contain this video codec format
<beeno>
ok but my file is in IVF format so I believed I should read that and parse the frame packets directly. Doesn't seem to work
<beeno>
does the vpu automatically decode the container?
<stdint>
no
<stdint>
vpu has nothing to do with container
<beeno>
yes, so for the ivf I read the frame headers and pass the packets to vpu. decode_sendstream swalows the packets but decode_getframe never returns anything useful
<beeno>
and decoder_err never changes
<beeno>
my method works perfectly fine for av_codec so I can't see why vpu doesn't want to accept those same packets
<holin>
is the rockchip kernel at https://github.com/rockchip-linux/kernel, branch 4.4 only for aarch64? Tried to compile for rk3288, but it was painful Werror after Werror and then some undefined symbols..
<beeno>
stdint: what values must I specify for Packet.dts, Packet.pts and Packet.nFlags if I just want to read all the frames one by one without any automatic sync or timing
<beeno>
As far as I'm aware, vp8 does not include any frame timings in the data
<stdint>
beeno, you could ignore those field
<beeno>
stdint: is the packet.capability field used by the vpu?
<stdint>
LongChair, mpp_frame_deinit may need to access the internal stack, then the answer is no
<stdint>
beeno, I don't know what you want to do
<stdint>
holin, don't use those default config
<beeno>
stdint: I'm setting packet->capability = packet->size before calling CodecContext->decode
<stdint>
beeno, may I look at your code?
<beeno>
you want me to paste here or send some other way?
<holin>
stdint, I got the config from chromeos 4.4, which does seem to be for aarch64 mainly
<stdint>
no
<holin>
is there a better defconfig for a starting point?
<stdint>
use linux defconfig
<holin>
you mean mainline?
<holin>
one thing that I hit was I needed to have ANDROID ION enabled in order to get rockchip framebuffer (console)
<holin>
i'd like to avoid android at this point
<stdint>
holin, no, there are three defconfig in that branch
<stdint>
for android, chromebook and linux
<holin>
ah, ok
<holin>
does compiler matter? I'm using the Linaro gcc 4.9 x86_64 arm-linux-gnueabihf cross compiler right now.
<stdint>
no
<holin>
since there's no SoC specific config, I'm guessing the deconfig would be arch/arm/configs/rockchip_linux_defconfig
<beeno>
stdint: if I call decode, it returns 0 but Packet.size does not change. Does that mean it did not accept the data?
<stdint>
beeno, if you don't give me the code, I have no idea at what you are doing
<stdint>
holin, yes and you need to adjust some opinions based on that for a platform
<holin>
stdint, in 3.14 there was an eDP drm module. Do you know if the analogix DP is the same thing in 4.4?
<stdint>
holin, it only support ION buffer in 3.14 I think
lkcl has quit [Ping timeout: 255 seconds]
nighty has quit [Quit: Disappears in a puff of smoke]
<holin>
stdint, thanks for the help, the 4.4 kernel compiled with the linux defconfig.
<holin>
however, it won't boot on the chromebook flip, but that seems to the way it is now with anything else than chromium 3.14
paulk-collins has quit [Quit: Leaving]
beeno has quit [Ping timeout: 260 seconds]
<LongWork>
stdint: is 4K modes any better in the miniarm branch ? and is vpu-service available there ?
<stdint>
LongWork, hard to say, there is just one more patch there
<stdint>
the display async patch
<LongWork>
you mentionned forcing displaymode to 4K30, you mean in X11 display settings ?
<stdint>
in kernel driver
<LongWork>
how do you do that ?
nighty has joined #linux-rockchip
holin has quit [Remote host closed the connection]
amstan has quit [Ping timeout: 240 seconds]
amstan has joined #linux-rockchip
amstan has joined #linux-rockchip
amstan has quit [Changing host]
czar_x has joined #linux-rockchip
czar_x has quit [Ping timeout: 240 seconds]
<ayaka>
LongWork: btw how do you use the MPI API
<ayaka>
with token(task) way or without
<ayaka>
the later one have a better performance and support parallel
<ayaka>
for the kernel you could remove a frequent from hdmi driver list
<ayaka>
frequency
beeno has joined #linux-rockchip
<LongChair>
ayaka: i ahve no idea what the token thing is . i use something similar to the decoder sample in the mpp tree
<LongChair>
better performance ? regarding what ? it can decode higher content ?
<LongChair>
if you can gimme pointers about what you mean i could have a look
beeno has quit [Quit: Page closed]
beeno has joined #linux-rockchip
descend has quit [Quit: Connection closed for inactivity]
beeno has quit []
beeno has joined #linux-rockchip
Laibsch has quit [Read error: Connection reset by peer]
Laibsch has joined #linux-rockchip
Laibsch has quit [Ping timeout: 240 seconds]
paulk-blaze has joined #linux-rockchip
descend has joined #linux-rockchip
cnxsoft has quit [Quit: cnxsoft]
paulk-blaze has quit [Ping timeout: 256 seconds]
paulk-blaze has joined #linux-rockchip
paulk-blaze has quit [Read error: Connection reset by peer]
paulk-blaze has joined #linux-rockchip
paulk-blaze has quit [Ping timeout: 260 seconds]
JohnDoe_71Rus has joined #linux-rockchip
descend has quit [Ping timeout: 258 seconds]
arnd has quit [Ping timeout: 258 seconds]
ojn has quit [Ping timeout: 258 seconds]
srao has quit [Ping timeout: 258 seconds]
<Omegamoon>
@beeno: I finally have LibreELEC running on the Ugoos UT3S... since you have the same device, would you be willing to do some testing?
<beeno>
Omegamoon
arnd has joined #linux-rockchip
<beeno>
Omegamoon I can try, although I'm probably not going to be able to do that immediately. I'm struggling to get the vpu to work
mac-l1 has joined #linux-rockchip
<beeno>
is it using dri or fbdev?
<Omegamoon>
it is using dri
<beeno>
so how would I install it?
<phh>
beeno: how/what are you trying for vpu?
<mac-l1>
beeno: hi! you asked why ctx->control(vpu_ctx,VPU_API_SET_VPUMEM_CONTEXT,(void*)vpu_display_pool)? it allocates your own fixed group of frame buffers associated with you current vpu context
<mac-l1>
it allows for good buffer control and also for blocked access to it
<beeno>
phh: I seem to be going nowhere with this now. When I use context->decode, it seems to not grab any bytes from the data, but if I use decode_sendstream/decode_getframe, it seems to take the bytes but I never receive a frame
<Omegamoon>
@beeno: by flashing a good old update.img firmware image :)
<beeno>
also if I use decode_sendstream then it crashes if I don't use vpu_display_pool
<mac-l1>
beeno: decode() isnt implemented in vpu_legacy part of mpp, so it cant work
<beeno>
gee ok, so I've been wasting my time with that one. There's a test file for it too.
<mac-l1>
i know... have had the same experience...
<beeno>
so question is, do I actually need to use vpu_display_pool or is it optional (obviously I want to use it)
descend has joined #linux-rockchip
<beeno>
Omegamoon: would that then have the latest mpp/vpu libs from rockchip?
<mac-l1>
in rockchips gstreamer they have one thread for feeding the input packets and another for waiting on decoded frames
<beeno>
I see you were setting VPU_API_SET_OUTPUT_BLOCK to 0 to prevent blocking. If it's at one, my readframe doesn't return, is that to be expected if I have not supplied enough data yet?
<mac-l1>
so they pump all frames continuously into the vpu in one thread. then use the vpu pool to control the blocking access to wait for newly decoded frames from vpu. so when mpp delivers a frame
<mac-l1>
it unblocks
<mac-l1>
right yes!
<beeno>
ok so I want a single thread which sends in data and then tries to read a frame (so I'll set that blocking to 0). Am I supposed to get a crash if I don't use vpu_display_pool?
wadim_ has quit [Quit: Leaving.]
<mac-l1>
dont know actually... i started without a pool too and then it seems to use an indefinite pool that gets exhausted or so
<mac-l1>
so i started to look at the vpu buffer allocator and extracted the essential stuff to simplify things.. quite a hassle...
<mac-l1>
using the vpu pool all buffer control is fixed and up to the app; might be better actually
<Omegamoon>
@beeno: latest mpp/vpu isn't in there yet, but is on the todo list ;)
<beeno>
I get the buffer allocation stuff, although the way you implemented that function to initially allocate them is some kind of C funkyness. I'm not entirely sure I understand it. Quite a few Frees in there
<beeno>
you say "up to the app" but the way I see it, it's going to allocate from that pool automatically as it needs it?
<mac-l1>
haha ... sure ... my stuff is just prototyping to the max to get some frames displayed .. checking if and how the stuff works ..
<mac-l1>
there are 2 blocking settings: one for the inputbuffers and one for outputbuffers, i put them all to zero
<mac-l1>
so then indeed mpp just allocates one. however when encoding frames i guess also the input buffer would be blocked
<beeno>
I don't believe I've been blocked on the input ever, what parameter would I set for that?
<beeno>
so I'm using this vpu_open_context and context->init. Should I be using them or is this library not working?
<mac-l1>
that one works for me too, so it is working. also the init needs to be without extra codec data (at least for hevc)
<beeno>
Omegamoon: If really in a rush to get that hardware video decoding working right now. If you ever get that in there then I'll try and see if I can get a chance to test it.
<mac-l1>
then you need to make a bufferpool (using openbufferpool, the createbufferpool didnt work for me)
<mac-l1>
and associate the bufferpool with the context
<beeno>
ok so that brings me to another point. I have this h264 binary stream. I checked it with HEVCESbrowser, and I can see the file contents is valid. Do I need to use something specific to send those bytes, or can I just send them in batches of my own choosing?
<mac-l1>
this was for me the only way to get the pool working correctly...
<beeno>
That's the code I refered to earlier. You seem to call VPUFreeLinear twice on each buffer... anyway you say it's working that way so I believe you
<beeno>
sorry, earlier I ment h265, not h264
<mac-l1>
you need to convert it to mp4toannexb bitstream first (this is different than the android vpu libs and machybris libs before: you could just send bytestream)
<beeno>
right now I'm trying to decode the h264_320x240_coding_7_for_dec.bin file according to the method in the test application, but it crashes before giving a single frame
<beeno>
does that annexb contain some kind of frame headers or something to allow you to split it?
<mac-l1>
also the extra codec data needs to be converted to annexb bitstream format first and then send to the decoder as first packet
<beeno>
ok this is getting more complicated than I wanted. So you say I need to do a format conversion on the whole file before hand?
<mac-l1>
for the hevc it seems so yes
<beeno>
how would one do that? I created a h265 stream in ffmpeg from input images.
<beeno>
btw, do you believe that vp8 file also needs to be in such format. I actually wanted to use vp8 but I'm not getting it to work either which is why I started trying the others
<mac-l1>
i used something like avconv -i $1 -c:v copy -bsf:v h264_mp4toannexb -an $1.h264 before
<mac-l1>
sorry beeno: have to go now, pick up my kid..
paulk-blaze has quit [Quit: Leaving]
<mac-l1>
Omegamoon: i have an uts3 too, and actually have kodi almost running with vpu on linux 4.4. might be interesting.
<Omegamoon>
@mac-l1: indeed that is interesting :) I am using the 4.4 kernel for LibreELEC also
<Omegamoon>
kernel is somewhat unstable currently... it reboots after a while... could you make your .dts for the ugoos available somewhere?
andoma has quit [Ping timeout: 240 seconds]
andoma has joined #linux-rockchip
lkcl has joined #linux-rockchip
andoma has quit [Ping timeout: 240 seconds]
andoma has joined #linux-rockchip
paulk-collins has joined #linux-rockchip
vickycq- has quit [Ping timeout: 240 seconds]
<LongWork>
phh: any idea on what ayaka was meaning earlier about mpp usage "with token(task) way or without" ?
vickycq- has joined #linux-rockchip
scelestic has quit [Read error: Connection reset by peer]
<LongWork>
mac-l1: are you using mpp as well ?
srao has joined #linux-rockchip
ojn has joined #linux-rockchip
vagrantc has joined #linux-rockchip
<mac-l1>
Omegamoon: oh misunderstanding: i dont have 4.4 on ugoos running, only on miqi. however 4.4 is also on firefly and i guess you could use that one on uts3?
<mac-l1>
i meant to say i have kodi on 4.4 (miqi) running with vpu and zercopy egl images, but still some yerks every few secs
<mac-l1>
LongWork: no, i just use the legacy vpu api... however it is more like a facade to mpp...
<beeno>
mac-l1: I've been trying to understand this AnnexB and AVCC. So seems to me the files are generally in AnnexB format (at least h264). So it's using these sequences of 00 00 00 01. So I wonder why you had to implement the conversion on a per packet base. Is this because once you grab it from avformat, these 00 00 00 01 data has been filtered out and now you need to put it back?
<mac-l1>
i actually didnt try to understand but just find a smart way to make it work. i noticed that my decoder did work for h264 but not h265. and that h265 needed the bs conversion.
<beeno>
ok I read your comment earlier and you said it was working for h264 so that makes sense. I'll look at a h265 output and try to confirm what you're saying at least
<mac-l1>
then debugging mpp lib i found h265 needs it and also the ctx->init couldnt handle the extradata. it needs to be fed to decoder as first packet to decode
scelestic has joined #linux-rockchip
<mac-l1>
as bs converted packet
<mac-l1>
so then i just decided to use bs conversion for both formats... it is actually implemented this way in kodi for most decoders..
<mac-l1>
does h264 work for you?
<beeno>
ok so using ffmpeg converting my image sequence to either h264 or hevc results in the annexb format
<beeno>
and that's correct according to their own docs
Laibsch has joined #linux-rockchip
<beeno>
no I've not gotten h264 to work and that's really my own problem because I was using that test source which seems to want the non AnnexB file format yet all my files are AnnexB
<beeno>
this is because I was trying to avoid using av_format
<beeno>
I was successfully doing the vp8 parsing myself but that didn't work with VPU. I wonder if it actually wants those to be in this AnnexB style as wekk
descend has quit [Quit: Connection closed for inactivity]
beeno has quit [Ping timeout: 240 seconds]
<LongChair>
mac-l1: both h264 & h265 need bitstreaming
<LongChair>
and you also need bistreamed extradata first for both
<LongChair>
bitstreamed
vagrantc has quit [Ping timeout: 240 seconds]
tlwoerner_ is now known as tlwoerner
lkcl has quit [Ping timeout: 240 seconds]
vagrantc has joined #linux-rockchip
utente has joined #linux-rockchip
mac-l1 has quit [*.net *.split]
jarekin has quit [*.net *.split]
jarekin has joined #linux-rockchip
mac-l1 has joined #linux-rockchip
mac-l1 has quit [*.net *.split]
jarekin has quit [*.net *.split]
jarekin has joined #linux-rockchip
mac-l1 has joined #linux-rockchip
Omegamoon has left #linux-rockchip [#linux-rockchip]