<ndufresne>
mjourdan, looks like it does not play all the frames, did you implement draining ?
return0e has joined #linux-amlogic
return0xe has quit [Ping timeout: 245 seconds]
<ndufresne>
mjourdan, ok, after adding special case for par 0/0, I got it working, and the PAR passed to kmssink is 64/45, provided by the parser as I expected
<ndufresne>
so it render 16:9 in Gst already
vagrantc has joined #linux-amlogic
<ndufresne>
mjourdan, iphone6s_4k.mov no longer works for me, I get CMA allocation failure
<ndufresne>
any idea ?
chewitt has quit [Ping timeout: 246 seconds]
chewitt has joined #linux-amlogic
vagrantc has quit [Quit: leaving]
Elpaulo has quit [Read error: Connection reset by peer]
Elpaulo has joined #linux-amlogic
distemper has quit [Quit: bye]
distemper has joined #linux-amlogic
chewitt has quit [Ping timeout: 245 seconds]
<mjourdan>
ndufresne: The current reserved memory for CMA is too small for 4K. You can change it in meson-gx.dtsi or via u-boot
<lvrp16>
is there a command I am missing to switch the gpio from output to input?
<lvrp16>
this is in u-boot
fedux has quit [Read error: Connection reset by peer]
fedux has joined #linux-amlogic
fedux has quit [Read error: Connection reset by peer]
fedux has joined #linux-amlogic
<narmstrong>
lvrp16: which GPIO do you want to trigger ?
<lvrp16>
narmstrong: read the value of the u-boot button BOOT_11
<narmstrong>
lvrp16: i can help you in ~1h
<lvrp16>
narmstrong: thanks no rush
<ndufresne>
mjourdan, ok, will do
<mjourdan>
ndufresne: btw, I pushed new stuff for H.264 PAR, and I also initialize the default values to 1:1 instead of 0:0
_whitelogger has joined #linux-amlogic
<ndufresne>
at the same time, Tomas underlines recently that the probing the caps before the output queue is ready and active isn't a good idea, so I'll probably just drop that
<mjourdan>
Imho in the case of a decoder cropcap should only be considered relevant after the first dqbuf. Anything before is undefined
<ndufresne>
well, I'd push further, after SRC_CHANGE event has bee fired
<ndufresne>
Do you implement that event already ?
<mjourdan>
Nope :<
<ndufresne>
well, me neither, but I really think it's a good idea
<ndufresne>
this way, for byte-stream like h264/mpeg2, if we have corrupted header, we can still get a sync
<mjourdan>
Yep I agree, @ldts also pushes for it (it's handled by ffmpeg).
<mjourdan>
Haven't had time to get around implementing it yet