<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 ...
<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, http://dpaste.com/2J5MP7A
<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, https://pastebin.com/xd2CN0q2 <- 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>
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.
<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>
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
<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 */
<Ely>
WRITE_AOREG(AO_RTI_GEN_PWR_SLEEP0,
<Ely>
READ_AOREG(AO_RTI_GEN_PWR_SLEEP0) & ~0xc);
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
<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
<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 !
<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
<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>
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 ...)
<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
<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 ?
<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 http://linux-meson.com/doku.php?id=start ? 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
<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