narmstrong changed the topic of #linux-amlogic to: Amlogic mainline kernel development discussion - our wiki - ml - Publicly Logged on
steamport|sleep has quit [*.net *.split]
BlueMatt has quit [*.net *.split]
nobe has quit [*.net *.split]
brujah has quit [*.net *.split]
BlueMatt_ has joined #linux-amlogic
ChanServ has joined #linux-amlogic
mastertheknife has joined #linux-amlogic
aballier has joined #linux-amlogic
cosm has joined #linux-amlogic
Ely has joined #linux-amlogic
The_Coolest has joined #linux-amlogic
indy has joined #linux-amlogic
brujah has joined #linux-amlogic
mayorga has quit [Ping timeout: 248 seconds]
mayorga has joined #linux-amlogic
cthugha has joined #linux-amlogic
BlueMatt_ is now known as BlueMatt
BlueMatt has quit [Changing host]
BlueMatt has joined #linux-amlogic
ldevulder has quit [Ping timeout: 268 seconds]
steamport has joined #linux-amlogic
nobe has joined #linux-amlogic
mayorga has quit [Ping timeout: 245 seconds]
mayorga has joined #linux-amlogic
<ndufresne> Ely, I like you trick to drain the parser, and prevent adding an extra frame of latency (esparser_append_start_code())
<ndufresne> ah, I see, it's also needed to avoid having to allocate a ring buffer
<ndufresne> that's nice, zero-copy on input
<ndufresne> unlike endless glue, or coda
<ndufresne> it was quite annoying at first, cause for small video, the ring buffer ended up queueing everything, then every seek, we where reparsing the entire file ...
Elpaulo_m has quit [Ping timeout: 252 seconds]
Elpaulo_m has joined #linux-amlogic
jakogut_ has quit [Quit: jakogut_]
indy has quit [Ping timeout: 264 seconds]
Elpaulo_m has quit [Ping timeout: 260 seconds]
indy has joined #linux-amlogic
Elpaulo_m has joined #linux-amlogic
Elpaulo_m2 has joined #linux-amlogic
Elpaulo_m has quit [Ping timeout: 276 seconds]
Barada has joined #linux-amlogic
Barada has quit [Quit: Barada]
Barada has joined #linux-amlogic
Barada has quit [Quit: Barada]
Barada has joined #linux-amlogic
indy has quit [Quit: ZNC -]
indy has joined #linux-amlogic
brujah has quit [Ping timeout: 264 seconds]
mag has quit [Ping timeout: 248 seconds]
mag has joined #linux-amlogic
mag is now known as Guest8491
cthugha is now known as ldevulder
brujah has joined #linux-amlogic
tingoose has joined #linux-amlogic
<dlan> narmstrong: do you have the document for how to try the mainline uboot?
<narmstrong> dlan: this is a good indication
tingoose has quit [Ping timeout: 260 seconds]
<dlan> narmstrong: I will give it a try
<dlan> narmstrong: how to switch to uboot mainline if the emmc already have vendor uboot?
<narmstrong> dlan: you need to erase the first blocks of the emmc
<dlan> it seems from the doc, the board need to boot into linux first (with command dd available), then flash the uboot blob
<narmstrong> to flash to emmc yes, for sdcard no need
<dlan> em.. I would try SD card then
<dlan> it's simple
<dlan> thanks
Elpaulo_m has joined #linux-amlogic
Elpaulo_m2 has quit [Ping timeout: 260 seconds]
<narmstrong> Ely: hmm can you send me your meson/gxl/gxtvbb_vh264_mc fw ?
<narmstrong> I said nothing
Barada has quit [Ping timeout: 256 seconds]
<dlan> narmstrong: just tried your topic/gxl-usb-merge branch on p212 board, says "No controllers found" .. what am I missing?
Barada has joined #linux-amlogic
<narmstrong> dlan: oops I forgot to sync the p212 dtsi
<narmstrong> let me re-push the branch
<narmstrong> dlan: you can pull it back, beware I force-pushed
<chewitt> narmstrong: <= done for easier LE packaging
<chewitt> not sure where those fw come from?
<narmstrong> chewitt: I thin khe etracted them from the source headers
<narmstrong> chewitt: but @ndufresne is on it aswell !
<TobiasTh1Viking> Finally compiling pinctrl for meson6 on 4.16rc7 lets hope something works.
<narmstrong> TobiasTh1Viking: if it builds, it runs ! (first rule of the hopeful kernel developer)
<narmstrong> second rule : you put tons of prints to figure out why it work/doesn't work
<narmstrong> third rule: you spend 10 days on a single character issue you missed the first minutes of debugging
<TobiasTh1Viking> have it booting, with unstable ethernet. made a pinctrl, but it didn't work(because i didn't add it to dts). xdarklight gave me pointers. trying now with dts and more stuff patched.
<TobiasTh1Viking> but the aml8726-mx does boot!!
<narmstrong> hurray, now figure out why it works !
<TobiasTh1Viking> i'm not promising speed, nor expecting anyone else to play with a meson6. but given pointers i'm hoping to make everything on my board work(at the very least multi-core, usb, mmc, ethernet).
<TobiasTh1Viking> emphasis on hope.
<xdarklight> TobiasTh1Viking: :)
<dlan> narmstrong: still something missing, sounds the usb controller is probed but doesn't find the attached USB disk,
<xdarklight> TobiasTh1Viking: did you have a chance to boot it yet and see whether you get something in /sys/kernel/debug/pinctrl ?
<TobiasTh1Viking> xdarklight: no, sleepies and board was misbehaving. only just started compiling the kernel.
<TobiasTh1Viking> as in, git pull failed me 5 times... :/
<TobiasTh1Viking> ok, since i have people here. my board is a tv box. not dev board. that means, i have no direct access to any pins. In bringing up my board, will i also enable PWM? ADC? RTC?
<TobiasTh1Viking> will that just happen automagically after making GPIO interrupt and clock, etc, work?
<narmstrong> dlan: a regulator is missing, can you try "regulator dev HDMI_5V" and "regulator enable"
<narmstrong> before usb start
<xdarklight> TobiasTh1Viking: by defaults PWM, ADC, RTC (RTC is currently not supported by mainline, but support should be easy), etc. are disabled - you will add/enable them later when needed
<TobiasTh1Viking> as part of enabling other stuff, yes?
<xdarklight> yes
<TobiasTh1Viking> cool, just nice to know it will get fixed, even with my inferior board.
<TobiasTh1Viking> xdarklight: i have this thing i don't understand, <- line 1176, GROUP(i2s_in_ch01, 8, 28), // also 9, 11
<TobiasTh1Viking> i have a few things like that, that are defined twice. have two addresses.
<TobiasTh1Viking> is that normal?
<xdarklight> maybe the same signal is routed to two pins, let me check
<xdarklight> {.pad=PAD_GPIOX_20,.sig=SIG_I2S_IN_CH0,.enable=P_PIN_MUX_REG(8,28),.disable=NOT_EXIST},
<xdarklight> {.pad=PAD_GPIOE_0,.sig=SIG_I2S_IN_CH0,.enable=P_PIN_MUX_REG(9,11),.disable=NOT_EXIST},
<xdarklight> indeed, it is
<TobiasTh1Viking> so, how do i handle that?
<xdarklight> TobiasTh1Viking: have a look at pinctrl-meson8 - there's for example pwm_c_dv9_pins, pwm_c_dv29_pins and pwm_c_z_pins (PWM_C signal can be routed to GPIODV_9, GPIODV_29 and GPIOZ_8)
<TobiasTh1Viking> thx
<dlan> narmstrong: with the regular enabled, the usb storage just works fine. a side issue, a "usb reset" (follow a 'usb start') will trigger panic
<narmstrong> I know this issue, I need to debug it
<dlan> thanks for the great work ;-)
<dlan> I've tested by loading a mainline kernel, just works fine
<narmstrong> dlan: thanks for testing !
<narmstrong> xdarklight: the p212 needs the 5v regulator for usb like the potato !
<narmstrong> I’ll check for khadas vim aswell
fedux has joined #linux-amlogic
<TobiasTh1Viking> hm, so what should i define this as? "{.pad=PAD_GPIOX_17,.sig=SIG_UART_TX_B,.enable=P_PIN_MUX_REG(4,9),.disable=NOT_EXIST}," currently it is "GROUP(uart_tx_b0, 4, 9),". but i assume the "_b0" is wrong? should it be _x17
<xdarklight> TobiasTh1Viking: yep, I would use _x17 (and the other one as _x23: {.pad=PAD_GPIOX_23,.sig=SIG_UART_TX_B,.enable=P_PIN_MUX_REG(4,5),.disable=NOT_EXIST},)
<TobiasTh1Viking> cool. a lot of work to fix up.
<TobiasTh1Viking> how should this be named? "static const unsigned int uart_tx_b0_pins[] = { GPIOX_17, GPIOX_23 };" as tx_x_pins? or is the line just wrong?
<TobiasTh1Viking> uart_tx_x_pins[]
<xdarklight> it should be uart_tx_x17_pins with only GPIOX_17 and a separate uart_tx_x23_pins with only GPIOX_23
<TobiasTh1Viking> k
<xdarklight> multiple pins in that array are pretty rare, it's always the case where one GROUP definition controls more than one pin
<xdarklight> narmstrong: ok, let me know about the results then I'll send an updated series
<TobiasTh1Viking> xdarklight: you once told me to enable CONFIG_SMSC_PHY to make the ethernet work better. it actually made it work worse. but i'm assuming it makes no sense to look at that till we handle the FEC<->PHY link in pinctrl.
nobe has quit [Remote host closed the connection]
<TobiasTh1Viking> seriously git. i'ts been an hour...
nobe has joined #linux-amlogic
<xdarklight> TobiasTh1Viking: can you define "worse" (what is the behavior without CONFIG_SMSC_PHY and what's the behavior with it, do you have any kernel logs)?
<TobiasTh1Viking> oh, not sure i have logs anymore. without SMSC_PHY NFS root works with the kernel(it boots happily), but no MAC address and very very unstable.
<TobiasTh1Viking> with SMSC_PHY, i don't think it worked at all. but once git stops counting objects i'll get new logs.
<xdarklight> maybe "energy detect" has to be disabled on your board:
<TobiasTh1Viking> thx, i'll try that once compiled.
<TobiasTh1Viking> nice,will try that
<TobiasTh1Viking> can i do smsc.disable-energy-detect=1 on kernel cmdline? or do i need to do dts?
<xdarklight> doesn't seem that a parameter is supported: - so I believe you have to do it in .dts
<TobiasTh1Viking> grr,too much black magic there for me to do on my own, can you provide me a patch?
<xdarklight> add that within the "ethmac" node
<xdarklight> (below mac-address for example)
<TobiasTh1Viking> done, thx.
<TobiasTh1Viking> i'll be back once i have dmesg on linux-next
fedux has quit []
<narmstrong> Ely: [ 885.442069] vdec_s_fmt
<narmstrong> [ 885.443251] vdec_queue_setup
<narmstrong> Additional debug info:
<narmstrong> ERROR: from element /GstPipeline:pipeline0/v4l2video0dec:v4l2video0dec0: Failed to allocate required memory.
<narmstrong> [ 885.444754] vdec_close
<narmstrong> gstv4l2videodec.c(710): gst_v4l2_video_dec_handle_frame (): /GstPipeline:pipeline0/v4l2video0dec:v4l2video0dec0:
<narmstrong> Buffer pool activation failed
<narmstrong> my version is pretty ancient, i'll update it
<Ely> I only have the messages from 2 hours ago, my bouncer didn't buffer enough.. Might have missed things.
<Ely> narmstrong: Thanks for trying! Can you reproduce the DRM hang at boot ?
<narmstrong> nop, you can check on the logger anyway
<Ely> Ohhh we have a logger now
<narmstrong> Ely: yes, I'm checking why it does that
<Ely> ndufresne: Hehe, the esparser trick is actually also done by AML code. They just changed slightly the way they do it in S905X. Before that they send 2 commands to esparser, one with the buffer, another one with a fake start code. In newer versions they just append the fake start code to the end of the buffer. I don't know if the latter would also work on S805..
<narmstrong> Ely: you use ffmpeg from poky sumo right ?
<Ely> I have 3.4.2 with one patch that I manually added, 2e96f5278095d44f090a4d89507e62d27cccf3b9, v4l2_m2m: Fix integer overflow in timestamp handling
<Ely> However I'm not sure I have actually tested the decoder with the DRM layer enabled, maybe it screws up both IPs, let me check
<narmstrong> I don't see the vdec power bits in the gen_pwr_sleep_cntl0 reg in the s905x datasheet
<Ely> Mmh maybe they changed it ? But then how could I have successfully decoded things :/
<narmstrong> Ely: can you recall the ffmpeg cmdline you use ?
<Ely> ffmpeg -c:v h264_v4l2m2m -i input.mp4 -pix_fmt nv21 -f rawvideo -y /dev/null
Barada has quit [Quit: Barada]
<Ely> I hardcode the buffer numbers so maybe gst is not happy with that
<Ely> chewitt: They're extracted from in-tree firmware in aml buildroot 3.14 kernel
<narmstrong> [ 282.075874] Buffer 8 decode error: 00000200
<narmstrong> [ 282.091408] Buffer 17 decode error: 00000200
<narmstrong> [ 282.083650] Buffer 9 decode error: 00000200
<narmstrong> [ 282.107087] Buffer 10 decode error: 00000200
<narmstrong> [ 282.099176] Buffer 18 decode error: 00000200
<Ely> I only tested 2 files, one 720p another one 1080p, it's very likely not everything will work :/
<narmstrong> does it need v4l2_m2m: Fix integer overflow in timestamp handling ?
<narmstrong> it fails, then it works later on
<Ely> Not really no. The patch will allow ffmpeg to decode frames beyond a certain timestamp, but if you only need to decode like the first 1000 frames it should be ok (depending on framerate)
<Ely> the buffer decode errors are defintely bad
<Ely> what file are you testing with so I can replicate ?
<Ely> I'm afraid the 2 files I tested it with are.. not very legal so I can't share. Maybe i should have gone with bunny or tears of steel :D
<narmstrong> I have [ 610.593210] Timed out waiting for an input slot. Trying again.. at the EOF is it normal ?
<narmstrong> not really EOF
<Ely> It's not but hopefully you can Ctrl-C from that
<narmstrong> maybe it's the timestamp fix missing
<Ely> nah I also got those on sunflower 1080p
* Ely makes a list of everything that's buggy
<narmstrong> hmm `$ ffplay -f rawvideo -pixel_format nv21 decode.raw` doesnt work
<narmstrong> Ely: what do you usually use ?
<Ely> ffplay -f rawvideo -pix_fmt nv21 -s 1920x1080 output.raw
<Ely> you can add in a -framerate 2
<Ely> If decoding went well you should see the video with the 8 bytes swap, making weird columns
<narmstrong> yep, it worked !
<Ely> great
<Ely> first time the results are replicated by someone else, happy times
<Ely> So AML code definitely does this for power on
<Ely> /* vdec1 power on */
Barada has joined #linux-amlogic
<narmstrong> ok, you stop the vpu_intr_clk !
dsd has joined #linux-amlogic
<Ely> you need that one ?
<narmstrong> I forgot this one
<Ely> Oh.
<Ely> :D
<narmstrong> yep, it's the clock for the graphics interrupt !
<narmstrong> my bad, i should have used it
<Ely> Maybe it's not even needed for vdec!
<ndufresne> Ely, we'll have to try to know, the interrupt iirc is just to indicate the completion of previous frame, in byte-stream mode you don't know the size of what you are parsing, so the next start code tells you the your done with previous
<Ely> What's weird though is that they kill that clock in amstream_release
<Ely> wouldn't that kill the display everytime you stop a decoding session ?
<narmstrong> weird
<narmstrong> i will investigate
<ndufresne> Elpaulo, but v4l2 only accepts "framed" input, so we know were the end is, and then you save 1 frame latency
<ndufresne> Ely, ^
<narmstrong> the amlogic vdec code and display are really tied together
<ndufresne> it's a TV stack after all ;-P
<ndufresne> ever seen how Broadcom handles this ?
<narmstrong> @Ely + //clk_disable_unprepare(pd->vpu_intr_clk);
<narmstrong> and it works...
<Ely> hurray
gnufan1 has joined #linux-amlogic
<Ely> ndufresne: Yup sure (and you know on the spot if the first frames was parsed successfully instead of waiting for the second one)
<Ely> But as soon as your start getting bframes you get latency on the output so latency on the input isn't that big a deal anyway
gnufan has quit [Ping timeout: 276 seconds]
<ndufresne> Ely, right, depends on your use case, in VVoIP we don't usually enable B-Frames
afaerber has joined #linux-amlogic
<ndufresne> Oh, it will also simply the EOS handling
<ndufresne> there was a weird hack in endless code for that
<ndufresne> sorry, I mean, it may simplify
<Ely> narmstrong: nevermind, amports_switch_gate implements ref counting, it's basically inside a small clock framework
<Ely> ndufresne: true true
<ndufresne> Ely, fyi, when b-frame are enabled, we need to declare the buffering latency through V4L2_CID_MIN_BUFFERS_FOR_OUTPUT
<Ely> oh good to know
<ndufresne> it's a combination of this and increasing the number of buffers in reqbufs
<ndufresne> The problem with increasing in reqbufs is that userspace would need to reqbufs twice (which effectivally alloc/free/alloc in v4l2)
<ndufresne> So with the control, users space will just to the match base on it's use case and allocate the right amount once
<ndufresne> (GStreamer does not implement any fallback for this)
<ndufresne> so in Gst, if you don't have this, you ended with stalls or really low framerate (starvation)
<Ely> I see
* ndufresne mentioning because I remember the Stanimir spent quite some time debugging this because asking me ;-P
<Ely> right now I'm hardcoding the number of input/output buffers in the driver but I have a feeling from narmstrong gst tests that gstreamer doesn't like that very much
<ndufresne> haha, gst is picky
<ndufresne> and zero-copy, unlike ffmpeg that copies the frames as soon as they come out, so the HW buffers remains in the codec
<Ely> yeh that's great
<ndufresne> narmstrong, btw, GST_DEBUG="v4l2*:7" that will come out on stderr, you can through traces at me whenever you need, I'm quite trained at this ;-P
<Ely> I have a feeling ffmpeg does something else with the buffers before outputting them, because there's a massive performance gap between -f rawvideo -y /dev/null and -f null -
<narmstrong> ndufresne: I'll think of it !
<narmstrong> Ely: with -f null /dev/null all the frames gets an error with bbb_sunflower_1080p_60fps_normal.mp4
<narmstrong> yep, all frames has a decode error 200
<Ely> damn I don't have that
* ndufresne read the full back log, nice progress !
<narmstrong> .mp4 -pix_fmt nv21 -f rawvideo -y /dev/null
<Ely> nevermind I got them too
<Ely> well now I need to check why gstreamer refuses the driver, and why those specific bitstreams generate problems
Elpaulo_m2 has joined #linux-amlogic
Elpaulo_m has quit [Ping timeout: 260 seconds]
* Ely wasn't prepared for the 200 dependencies needed for bitbake gstreamer1.0-plugins-good
<narmstrong> ah ah
<ndufresne> yeah, yocto lacks a way to get a gst subset
<ndufresne> I run Fedora 27 on the Potato atm, makes my life easier, and build a subset of gst on the board itself, using a prefix
<Ely> isn't that terribly slow still ? I know compiling C++ on arm is torture
<Ely> ndufresne: though yocto allows you to disable certain parts with packageconfig
<narmstrong> ndufresne: //
<narmstrong> ndufresne: you must tell us how you run fedora on the potato !!!
<narmstrong> ndufresne: sorry
<Ely> ndufresne: v4l2h264dec is not in plugins-good ?
<narmstrong> "we received 1 buffer from device '/dev/video0', we want at least 2"
<Ely> who does he think he is, buffers are expensive!
<dlan> narmstrong: ever head the story of "how to put elephant into refrigerator"? same as run fedora on the board
<Ely> yeah I hardcode the input buffers to 1, most likely this is it
<ndufresne> narmstrong, Ely: " allocated 1 mmap buffers out of 2 requested"
<ndufresne> GStreamer won't work with less then 2 buffers
<ndufresne> can you just let userspace pick whatever number of buffers it requested ?
<ndufresne> that will get you further
<Ely> yes it's the goal of course
<Ely> hardcoding to 1 was easier for testing purposes
<Ely> (and also because ffmpeg will use 1 even if you give it more.. :D)
<ndufresne> yeah, I guess you didn't have to q/dq
<ndufresne> which is silly, because it means the HW won't be decoding while doign memcpy
<ndufresne> (or rendering to screen)
<ndufresne> they problem didn't got up to usin this in VLC
<ndufresne> * s/problem/probably
<narmstrong> Ely: it should render to screen if you use `! videoconvert ! videoscale ! fbdevsink`
<narmstrong> I have some noise if I run `gst-launch-1.0 videotestsrc num-buffers=1000 pattern=snow ! video/x-raw, framerate=60/1, width=1920, height=1080 !
<narmstrong> videoconvert ! videoscale ! fbdevsink`
<Ely> is v4l2h264dec in bad or ugly ?
<Ely> narmstrong: okay thanks
<narmstrong> good
<Ely> mh I have good but
<Ely> WARNING: erroneous pipeline: no element "v4l2h264dec"
<ndufresne> narmstrong, change fbdevsink with kmssink driver-name=meson
<ndufresne> it will use page flip at least
<ndufresne> Ely, HW probe failed, the element was not generated
<narmstrong> ndufresne: I must find out why yocto hasn't built kmssink...
<ndufresne> sometimes when doing dev you will have to trash register
<ndufresne> rm ~/.cache/gstreamer-1.0/registry.*.bin
<Ely> ah indeed the package for v4l2 isn't there, the configure step must have thrown it away.. How can I force it to build ?
<ndufresne> and then GST_DEBUG="v4l2*:7" gst-inspect-1.0 /usr/lib/gstreamer-1.0/
<ndufresne> to debug
<narmstrong> Ely: I have to add some patches to the yocto gstreamer phlugins good
<ndufresne> that's 1.12.4 right ?
<Ely> yes
<Ely> though the gst-inspect step seems good..
<Ely> v4l2video0dec: V4L2 Video Decoder
* ndufresne checking if the probes aren't disabled by default on that version
<ndufresne> ah, that's my answer, they are in place
<ndufresne> narmstrong, no, it's just a convenience so you can use plane kmssink, instead of kmssink driver-name=meson
<Ely> still, 'WARNING: erroneous pipeline: no element "v4l2h264dec"'
<ndufresne> Ely, change "v4l2h264dec"' -> v4l2video0dec:
<ndufresne> as enumerated, stable names are 1.14 material
<Ely> ahh I see
<Ely> seems okay now.
<ndufresne> it's much nicer with stable name, but we don't merge non-trivial stuff like this in stable branches, so that's why it's only in the latest stable
<narmstrong> damn, kms is not enabled by default in poky
<ndufresne> btw 1.14 is out, so it's probably just a matter of days for yocto to provide updates recipes
<narmstrong> ndufresne: not in sumo i think
* ndufresne always fork multimedia/
<ndufresne> yeah, it's a bit outdated,
<ndufresne> yesterday we released 1.12.5, a strongly recommended update, and we have 1.14.0, normally yocto waits for the .1 update
<ndufresne> I didn't know ndec and dv was providing updates
<ndufresne> ndec (Nicolas Dechesne, Lead of Linaro Qualcomm landing team) and dv (Carlos Rafael Giani) who's maintainer (still?) of gstreamer-imx
Barada has quit [Quit: Barada]
Elpaulo_m2 has quit [Quit: Quit]
Barada has joined #linux-amlogic
Barada has quit [Client Quit]
<Ely> narmstrong: silly question, but do I need to do anything to configure the display before launching the pipeline ? I don't have x11/xrandr or anything, so the link seems inactive
<narmstrong> Ely: hdmi does not work ?
<Ely> I mean, I guess it does? It's probed correctly in dmesg
<Ely> but there's certainly no autoconfiguration
<Ely> should I see the screen telling it's configured in a certain mode at boot ?
<narmstrong> ndufresne: `kmssink driver-name=meson force-modesetting=true connector-id=31` works but the videotestsrc is damn slow !
<narmstrong> Ely: no, it will take the monitor closest prefered mode
<Ely> so it should autoconfigure the hdmi link at boot ?
<narmstrong> yes
<Ely> ok
<narmstrong> then you could use `! kmssink driver-name=meson force-modesetting=true connector-id=31`
<narmstrong> with videoscale
<ndufresne> narmstrong, sure, it an non-optimized test pattern generator
<ndufresne> it builds pattern from scratch everytime, no caching
<Ely> I'm afraid my old TV stays in "no signal" :<
<Ely> let me try with my desktop screen
<ndufresne> narmstrong, not sure why you need to force all this though, e.g. connector-id
<ndufresne> might depend on the setup
<narmstrong> Yes otherwise it uses the cvbs connector
<ndufresne> I think I was using driver-name=meson can-scale=0
<narmstrong> Which is always enabled
<ndufresne> ah, and it has a mode ?
<narmstrong> Yes
yann has joined #linux-amlogic
<ndufresne> ok, I don't know how cvbs works
<ndufresne> ah, that's the analog one, is that enabled on the Potato ?
<ndufresne> anyway
<ndufresne> ideas is that long term, the decoder will output dmabuf, and the driver will render it in the format it is
<narmstrong> ndufresne: yes it's enabled on the board, and for drm users it's the same as hdmi...
<narmstrong> there is no connector priority or whatsoever
<narmstrong> X and mutter takes HDMI since it has bigger display modes
yann has quit [Ping timeout: 264 seconds]
<ndufresne> hmm, I guess we could add this heuristic in kmssink
<narmstrong> nobody does it well
<narmstrong> too generic !
<ndufresne> kmssink started as being a test tool, and something to show the car back camera while booting ...
<ndufresne> but now people would like to drive multiple planes, and have their app draw on primary at the same time
<ndufresne> I keep telling them what they want is a compositor, but it looks like people seek for something simpler
* ndufresne have doubt that if we add all this to gst kmssink it will be simpler in the end)
<narmstrong> Maybe kmscompositorsink
<narmstrong> But why they don’t use wayland on primary and kmssink on the overlay ?
<ndufresne> legacy drm api does not support that, and you cannot have multiple commiters like this in atomic
<ndufresne> you want the compositor to coordinate, so if you driver an overlay inside a window, both are transformed, moved, updated together
yann has joined #linux-amlogic
<narmstrong> sure
<ndufresne> I think the mistake wayladn dev did is to make the video surface implicit rather then explcit
<narmstrong> at least it's easier to sort than with X11 ^^
<ndufresne> while saying that, Daniel S. was pretty positive that he'll get his weston automatic overlay usage in place
<ndufresne> he tried a while ago on legacy drm, and found how broken the API was, and that's why he got interested in help with atomic apis
<ndufresne> his idea is that wayland app don't need to know, the compositor should dynamically transit from GL to Overlay, and be able to literally shut down the GPU whenever possibl
<narmstrong> ok, i'm quite a newbie on these overlay issues
<narmstrong> same for the legacy drm
<ndufresne> hopefully it will be past someday
<narmstrong> Ely: strange, your monitor should support one of the formats I added... like 800x600 or 1024x768
<narmstrong> ndufresne: yeah hopefully
<Ely> narmstrong: the cable wasn't plugged to the end, I have a console on my TV now :)
<Ely> trying to run gst with fbdevsink, I bumped the num_buffers to 2 but it's still failing elsewhere
<narmstrong> Ely: ah ah, common issue
<ndufresne> (fbdevsink is ... as maintained as DirectFB ...)
<narmstrong> try `! kmssink driver-name=meson force-modesetting=true connector-id=31`
<ndufresne> (that's gonna be hard to remember)
<Ely> I need to rebuilt plugins bad with kms hold on
<narmstrong> but maybe I badly enabled 2 buffer :-D
<narmstrong> ndufresne: do you know how to force the sink to gst-play-1.0 ?
<narmstrong> to use kmssink
<Ely> narmstrong: I'm adding support for 1+ buffers but just bumping the number in vdec_queue_setup might not be enough
<narmstrong> `gst-launch-1.0 filesrc location=bbb_sunflower_1080p_60fps_normal.mp4 ! parsebin ! v4l2video0dec ! videoconvert ! fakesink` works and ends linke ffmpeg
<narmstrong> but connecting it to kmssink goes in `QTDemux:qtdemux0: Internal data stream error.`
<ndufresne> narmstrong, yes, gst-play-1.0 --videosink="kmssink ..." file
<narmstrong> works, but the decoder stalls too fast
<ndufresne> we might need to add this patch if the driver is atomic,
<narmstrong> `gst-play-1.0 --videosink="kmssink driver-name=meson force-modesetting=true connector-id=31" bbb_sunflower_1080p_60fps_normal.mp4`
<ndufresne> "stalls to fast" what does it mean ?
<narmstrong> the decoder goes in `Timed out waiting for an input slot. Trying again..` before anything is rendered
<Ely> yup I get the same..
<ndufresne> ah, so all buffers are consumed, 2 is not enough
<Ely> 2 buffers with gstreamer hangs, 1 buffer with ffmpeg works
<ndufresne> at the same time, I'm expecting a videoconvert here ....
<Ely> ndufresne: no, this message means we have queued 24 buffers into the HW and none have been freed - most likely the decoder is hung
<ndufresne> hmm, strange ...
<ndufresne> can you paste a trace of that ?
<Ely> definitely a problem in the driver. Maybe I shouldn't queue them so fast one after another, maybe 24 is too big, etc..
<ndufresne> try adding GST_DEBUG_NO_COLOR=1
<ndufresne> Ely, in endless code, they read the DPB depth, and limits the number frame in the vfifo to that
<Ely> ah, interesting
<ndufresne> not sure what ffmpeg does, but gstreamer just push to the decoder whenever there is free buffers
<Ely> ffmpeg does the same, with 1 buffer
<ndufresne> ah, I see, you probably push the first one again and again
<Ely> no as soon as it's pushed into the esparser it's marked as DONE and given back to userspace
<ndufresne> in theory, gst could work with 1, if we hack away the check
<ndufresne> haha, that's seems like a bad idea ;-P
<ndufresne> should be as soon as the esparser interrupt occur you mark it has done
<ndufresne> otherwise we'll start writing into that buffers before the parser is done
<Ely> oh yeah that's what I meant sorry
<Ely> we wait for the interrupt, then mark the buffer done
<ndufresne> ah, make more sense
<ndufresne> I don't get why running with 1 buffer makes a difference ...
<Ely> Another clue would be that gst doesn't give us back the output buffers
<Ely> I only up the semaphore when I get an output buffer back from userland and recycle it into the HW
<Ely> mh, with more printk added, I can see I'm setting to DONE a few buffers, gst even gives me back the first one, and suddenly nothing for 300ms and stop_stream
<Ely> no valid frames found
<Ely> ERROR: pipeline doesn't want to preroll.
<Ely> ERROR: from element /GstPipeline:pipeline0/v4l2video0dec:v4l2video0dec0: No valid frames decoded before end of stream
<Ely> Which is weird since my logs clearly show that I marked 3 CAPTURE buffers as done
<narmstrong> do gst supports N21M ?
<Ely> Same with GST_DEBUG_NO_COLOR=1. I haven't tried with 1 buffer yet but it seems to indicate the HW is ok with 2.. just for some reason the capture buffers are discarded or something? I'm using fakesink
yann has quit [Ping timeout: 260 seconds]
<ndufresne> narmstrong, I believe so
<ndufresne> yes, it's there
<ndufresne> Ely, ah, maybe you don't have CMD_STOP ?
<ndufresne> so gst gets an EOS, calls CMD_STOP, fails, trya nd queue an empty buffer, fails, give up, forward eos, everything stops
yann has joined #linux-amlogic
<ndufresne> Ely, can you make a run with GST_DEBUG="v4l2*:7" GST_DEBUG_NO_COLOR=1 gst-... 2> gst.log
<ndufresne> and paste the log ?
<Ely> yep I'm doing so but the output is 5MB :D
<ndufresne> oops
<ndufresne> Ely, if you run with GST_DEBUG=2 ?
<ndufresne> any warning / error &
<ndufresne> ?
<ndufresne> do you set the payload size correctly ?
<ndufresne> gst drops buffers that have a bytesused smaller then the frame size
<ndufresne> that's because this code is shared with UVC, and UVC can push corrupted frames
<Ely> Duration invalid, not setting latency
<Ely> Driver should never set v4l2_buffer.field to ANY
<Ely> Uncertain or not enough buffers, enabling copy threshold
<ndufresne> ok, nothing to worry about
<Ely> it is triggering an EOS and I don't have CMD_STOP so
<Ely> maybe that's why
<ndufresne> lovely, allocated 24 mmap buffers out of 2 requested
<Ely> :D
<Ely> yeah the CAPTURE is hardcoded at 24, OUTPUT at 2
<ndufresne> I need to fix gst at some point, it will stupidly queue 23 buffers, before checking if one can be dequeued
<ndufresne> in this case, because we don't have zero-copy on encoded data, only 1 is needed
<Ely> The line that bothers me is :<v4l2video0dec0:pool:src> end of stream reached
tingoose has joined #linux-amlogic
<Ely> it comes out of nowhere
<ndufresne> it means your driver have returned EPIPE on a DQBUF calls
<Ely> :/
<ndufresne> this is a special case added for exynos mfc
<ndufresne> most driver will flag the last buffer with FLAG_LAST, but with the mfc firmware, we don't know yet
<Ely> But my driver has this..
<Ely> .vidioc_dqbuf = v4l2_m2m_ioctl_dqbuf,
<Ely> and I don't think this can return EPIPE
<ndufresne> it's weird though, I don't see "broken pipe signals last buffer" trace from gst_v4l2_allocator_dqbuf
<Ely> are EPIPE and FLAG_LAST the only ways to trigger an end of stream gst side ?
* ndufresne looking further
<ndufresne> ah wait, gst support the legacy "empty buffer"
<ndufresne> so you probably don't set the payload size before calling done
<Ely> ah nvm the helper can return EPIPE but like.. the condition for it shouldn't be true
<ndufresne> so it triggers the legacy EOS
<Ely> ah that seems right
<ndufresne> lin 1357 of gstv4l2bufferpool.c, /* An empty buffer on capture indicates the end of stream */
<Ely> I only set timestamp & sequence
dsd has quit [Ping timeout: 256 seconds]
* ndufresne taking a note that we lack a warning there
<ndufresne> "Warning empty buffer received, assuming legacy EOS marker, please please port your driver.")
<Ely> good idea :)
<ndufresne> though, I'm still considering dropping all this legacy support
<ndufresne> no one uses that in prod really ...
<Ely> muuuch better
<Ely> fakesink seems ok
<Ely> now onto kmssink
<Ely> holy crap it works
<Ely> There's still the ugly 8-byte endianness of course but
<Ely> I got video on my TV :D
<ndufresne> yeah, I started having in this weirdo format into videocovnert, but wasn't sure
yann has quit [Ping timeout: 248 seconds]
dsd has joined #linux-amlogic
<ndufresne> s/having/hacking
<ndufresne> So it is just 8 bytes revered, or do I also need to reverse the bits in each bytes ?
<Ely> no it's only the bytes
<Ely> and of course the blocks..
<Ely> which I temporarily disabled for the sake of testing but will have to reenable for the full pipeline in the future iirc
<ndufresne> we'll need to come up with a name, I don't understand why they added linearization support, without fixing the byte order ...
<ndufresne> what I'm thinking is the easyest is just to add those format to V4L2, and I'll do the same in gst
<ndufresne> they normal raw formats, just weird
<ndufresne> memory can be mapped by CPU without problem
<ndufresne> maybe NV21_64BE
<ndufresne> Ely, what the tiles size in bytes ?
<ndufresne> 32x32 or 64x32 ?
<Ely> I'm honestly not sure, I still don't fully understand the formazt
<Ely> code says 32x32 but unsure if you can trust it
<ndufresne> it's different if it's in pixel or bytes
<ndufresne> if in bytes, then you likely have the same in both planes (the usual thing)
<ndufresne> Clearly something transfers 64bit words in BE, and the receiver assumes it's LE
<ndufresne> it all looks like an HW bug they didn't fix
<ndufresne> what I'm clear is that the accelerator do 64bit, in big endian
<ndufresne> * do 64bit writes
brujah has quit [Ping timeout: 256 seconds]
<Ely> I could give you one tiled and one linear frames if you need
<Ely> videoconvert n-threads=4 takes 250% of the CPU but the playback is smooth
<Ely> I wonder if I can use audio over hdmi on lepotato ? And enable this in the pipeline ?
<ndufresne> well, if you use gst-play-1.0, and you have appropriate audio decoder it "should just work" tm
<ndufresne> up to FHD, the CPU should survive
<ndufresne> but for 4K it won't
dsd has quit [Ping timeout: 276 seconds]
<ndufresne> I'm quite happy that it works, was much shorter then with venus
<ndufresne> (to get first frame out of gst)
<Ely> haha
<Ely> but much work had to be done gst side no ?
<Ely> and I did inspire my driver a lot from venus so.. might explain it as well
<Ely> I can't believe I skipped the bytesused part
<ndufresne> in theory, userspace don't really need that
dsd has joined #linux-amlogic
<ndufresne> because raw video frames have well known size
<ndufresne> but samsung drivers likes to allocate short buffer, crashing userspace in random ways, so I added checks (e.g. if it was not of the eos check, it would have failed elsewhere
* ndufresne really want to reproduce this in the next few days, and then I'll get infinit source of raw frame to implement SW conversion
<Ely> I'll cleanup and push. It's still hacky but oh well
<ndufresne> it's just the beginning, the fun part is ahead, adding all resolutions, enabling seek ;-P
<ndufresne> and maybe we'll beat venus by getting renegotiation to work
<ndufresne> do we have any clue about which profiles are supported ?
<Ely> you mean basline, main, high, etc?
<ndufresne> yes, and levels
<Ely> so profiles should be all 4:2:0. I've seen very subtle clues about 4:4:4 but really unsure.
<ndufresne> long term, I'd like drivers (even decoders) to implement the associated CIDs (decoder would be RO), so we can detect sooner if a stream is incompatible with the HW
<Ely> levels I don't remember the correspondance but it's 4k30 (probably can push to 4k60) for H.264, 4k60 HEVC (can also do Main10)
<ndufresne> hmm, main10 implies 10bit, let's see what horror storry amlogic 10bit pixel format will be ;-P
<ndufresne> I had to add some format from Xilinx recently, was ... interesting
* ndufresne need some food
<Ely> to be honest I'm scared to dive into the hevc code
<Ely> it's 3x bigger than the h.264 one
<ndufresne> nothing says it should all come out at the same time ;-P
<ndufresne> but VP9 and HEVC would be cool
<Ely> VP9 is another horror story on its own
<ndufresne> did you see all the old codecs they also support ?
<Ely> I'd like to try mpeg4 but even that will be hard. V4L2 only has one pixfmt for "mpeg4" but amlogic has 4 different firmwares for divx versions
<ndufresne> haha, fun
fedux has joined #linux-amlogic
<Ely> mpeg 1/2/4, h263, h264, hevc, vp9, jpeg
<Ely> mostly
<ndufresne> and we need to figure-out if it's really h263 or sorenson spark, it's a surprise in general
<ndufresne> often jpeg drivers need huge tabled of .. I'm not sure what
<ndufresne> a interesting fact is that H264/VP9 is all Google Chrome implements
<Ely> of course it's all that youtube uses
<Ely> :D
<Ely> I pushed the relevant bits
<Ely> now gotta figure out why some bitstreams fail and actually start cleaning the driver..
<Ely> btw, how do I tell gst-play to use kms ? and ffmpeg for ac3 decoding ?
* Ely needs some food too, brb
libv_ has joined #linux-amlogic
libv has quit [Ping timeout: 260 seconds]
libv_ has quit [Ping timeout: 260 seconds]
libv has joined #linux-amlogic
<narmstrong> Ely: great ! For audio you can find the relevant patches on the meta-meson yocto Linux patches
<narmstrong> I sent a gst -play cmd for Kim’s earlier
<narmstrong> *kms
<Ely> narmstrong: ah yes indeed thanks
<Ely> When you get some time, can you please try with the latest commit ?
<Ely> gst-launch-1.0 filesrc location=/foo/bar ! parsebin ! v4l2video0dec ! videoconvert n-threads=4 ! kmssink driver-name=meson force-modesetting=true connector-id=31
<ndufresne> Ely, for kmssink, add --videosink="kmssink driver-name=meson force-modesetting=true connector-id=31"
<Ely> yep thanks ndufresne
<ndufresne> for AC3 audio, there is nothing to be done, just make sure you have gst-ffmpeg installed
<ndufresne> btw, I have an MXQ TV box from Tronfy, is that known to anyone ?
<dsd> ndufresne: thats what we used for prototyping the Endless s805 product
<ndufresne> right, now I remember why I have this ;-P
<ndufresne> dsd, did you see Ely's progress today on the codec mainline driver (en devenir)
<ndufresne> dsd, I was mostly windering if anyone else was using this to test S805 with the mainline effort
<dsd> i've been glancing briefly at these conversations, nice to see it happening
<dsd> i dont think we've used the tronfy box in a long time, but we liked it because it was a near match to amlogic's reference design, so it might work or nearly with existing upstream stuff
<dsd> whats devenir?
<ndufresne> up coming
<ndufresne> or becoming
<ndufresne> can't resist adding french all over, I'm playing with "Le Potato" ;-P
fedux has quit []
<xdarklight> jbrunet: hey Jerome. I'm curious: since clock rate protection and the clock controller updates are going into v4.17, what about audio support? will you send that for review after v4.17-rc1 is out?
<xdarklight> (I can live with a "no" - I was just wondering :) )
<xdarklight> narmstrong: do you mind if I merge the S905D and S905X/S905W columns in ? I did the same for S802 and S812 since the differences are minor and I don't think they will ever run "out of sync"
tingoose has quit [Ping timeout: 256 seconds]
<Ely> funnily enough, the decoder likes gstreamer much better
<Ely> FFmpeg has a tendency to hold its buffers a bit too long which can lead to stalls
<narmstrong> I must test !
<narmstrong> Ely: is it smooth ?
<Ely> 720p30 1080p30 are smooth
<Ely> 1080p60 is smooth decoder side but completely kills the pipeline
<narmstrong> xdarklight: hmmm the s905d has some camera I/f, lcd output and dvb ports, like gxbb and GXM
<Ely> there's a lot of overhead with convert and the sink it seems
<narmstrong> Ely: it’s the same for sw decoding in kodi, the sw rendering is the slow path
<narmstrong> It would be interesting to have this running in kodi because they have a great OpenGL-Es drm/kms renderer
<Ely> It's almost weird because 30fps plays at like 25~30fps, but 60fps plays at 1fps.
<ndufresne> Ely, maybe there is something special that needs to be done when the decoder goes underrun ?
<Ely> how do you mean ?
<xdarklight> narmstrong: ah, but S905X doesn't have DVB and LCD output?
<ndufresne> Ely, just reading you gave me the impression that if you stop giving back output buffer, that triggers the stalls
<narmstrong> Nop
<Ely> ndufresne: yes exactly
<narmstrong> xdarklight: basically the s905x is the same as s905d with less pins
<narmstrong> Ely: this explains some errors with -f null on ffmpeg
<Ely> ndufresne: in order to tell the decoder that he can uses its buffers, you must tell him explicitely that you are no longer using one
<Ely> ndufresne: and one can only do that once the buffer is queued back, so that we are certain userspace is done with it
<narmstrong> Ely: maybe you are giving them back too fast ?
<Ely> narmstrong: I'm talking about the BUF_TYPE_VIDEO_CAPTURE buffers (decoder -> userspace), are you talking about these as well ?
<narmstrong> Yep
<narmstrong> Maybe you mark them free to quickly
<Ely> well.. I mark them when the data is ready, I don't think it has an impact on anything
<Ely> just ffmpeg likes to buffer them and give them back in chunks for some reason
<Ely> anyway, there's more to it, I need to precisely evaluate what those stalls are and where the blocker is
<narmstrong> Can you monitor which one the decoder gives back ? To see if some of them were lost
<Ely> yep I'll have to log everything
<narmstrong> Does amlogic use scratch 7 & 8 like you do ?
<narmstrong> (Ignore, i have found the code and yes)
<Ely> yes :)
<narmstrong> They seem to give back a buffer once at a time then rearm the timer
<Ely> yes they have a loop that ticks at 100hz
<narmstrong> With put_interval to hz/100
<Ely> and does the housekeeping and such
<narmstrong> Yep
<Ely> it's similiar to what I do
yann has joined #linux-amlogic
<xdarklight> narmstrong: I guess I'll leave it as it is then, thanks for the hint!
<narmstrong> Ely: made it work !
<Ely> woo
<Ely> you got crappy, choppy video on a screen ? If so it's working :D
<narmstrong> Yep !
<narmstrong> Not smooth at all ^^ but it plays
<Ely> even the 30fps ?
<narmstrong> Yep
<narmstrong> With which stream do you test ?
tingoose has joined #linux-amlogic
yann has quit [Ping timeout: 264 seconds]
<Ely> is "somewhat okay"
<narmstrong> It plays a 1fps for me...
<Ely> damn
<Ely> even with n-threads=4 ?
<Ely> then again I guess it depends on the resolution of your output
<narmstrong> What is your output resolution ?
<Ely> mmh how can I know ?
<Ely> /sys/class/drm/card0/card0-HDMI-A-1/modes shows 1920x1080 amongs the modes but I don't think it is
<narmstrong> It’s smooth if I add max-lateness=-1
<narmstrong> In suspend the half vsync rate issue that @ndufresne gave us
<narmstrong> And it doesn’t look smooth because of the byte swapping...
<Ely> yes I also noticed it gave a "framerate choppy" impression
<Ely> for some reason I can get it much smoother with sync=false but the video is still "synced", i.e it's not too slow or fast
* Ely probably doesn't understand sync=false
<ndufresne> narmstrong, for that you'll need to apply that attach patch on that bug
<ndufresne> sync=0 has not effect on kmssink, because of the naive synch
<narmstrong> Doing it right now
<ndufresne> it does ModeSetPlane/Flip/WaitForFlip
<ndufresne> with atomic driver you want to skip Flip/WaitForFlip
<ndufresne> because drmModeSetPlane blocks already
<ndufresne> (it's terrible what the driver do, but eh)
<Ely> mmh but for some reason sync=false is much, much smoother
<ndufresne> QoS, you don't declare any latency, but you likely have latency
<ndufresne> and you have processing latency
<Ely> ah I see..
<Ely> btw ndufresne, just to make sure: it's not the driver's responsibility to make things synced right ? The decoder just decodes as fast as it cans with what userspace provides and that's it ?
<Ely> -s
<ndufresne> yes
<ndufresne> synchronization always take place at the last step
<Ely> kk makes sense
fedux has joined #linux-amlogic
* ndufresne heading home
<ndufresne> I should log in, but in case, have a good weekend !
<Ely> Thanks man you as well
<Ely> narmstrong: you wanna see something cool ? Launch a gst pipeline, stop it, then launch a ffmpeg -c:v h264_v4l2m2m -i input -f null -
<narmstrong> Damn i can’t test right now
<Ely> ah no worries :P
<narmstrong> You are allowed to spoil it !
<Ely> you should see what's on my TV.. The display keeps displaying the last frame it had for some reason, and you can see what I think is the multiple internal states of the decoder
<narmstrong> It must be cool ! The decoder must keep some frames as base for other frames
trem has joined #linux-amlogic
commavir has quit [Ping timeout: 245 seconds]
commavir has joined #linux-amlogic
The_Coolest has quit [Ping timeout: 264 seconds]
trem has quit [Quit: Leaving]
tingoose has quit [Remote host closed the connection]
<ndufresne> I wonder what's happens if we start two decoder at the same time ...
dsd has quit [Quit: Lost terminal]
fedux has quit []
<Ely> most likely the universe collapses because there's no lock against it