<chewitt>
I wouldn't assign too much weight to all the comments Maxime made in code
<chewitt>
His understanding of how things work is (was) incomplete; albeit at the time better than anyone else's
<rellla>
i tracked the pts in my app, tracked pts and pkts/frames in ffmpeg and at last the offsets in the kernel driver
<rellla>
and found out, that the problem is there.
<chewitt>
tracking stuff is the general issue with these drivers
<rellla>
though i did not have a look in the low level register code.
<chewitt>
the h264 firmware for g12a+ is known to be buggy
<chewitt>
but coincides with changes (in vendor kernels) to use hevc (driver) not vdec
<chewitt>
hence it's never been fixed
<rellla>
chewitt: at first i will revert the "disabling mpeg2 hw decode" commit and see what is the issue. if it is a pts one, maybe it's also the wiggle room thing
djrscally has quit [Ping timeout: 246 seconds]
<chewitt>
it would be handy to unbreak the mpeg2 driver .. sw decode isn't an issue on GXM and up, but older GXBB/GXL boards can't quite handle all 1080p streams
<chewitt>
the other biggie is investigating the 10-bit path on g12a and up, which currently wedges the board
<chewitt>
^ for HEVC
<chewitt>
sadly debugging this stuff is some way above my limited comprehension of kernel driver code
<rellla>
i'm not sure, if i want to dive into driver developing :) my last low level experience was with the mesa lima driver - and that was some time ago...
<chewitt>
I think mpeg2 is probably a simple fix
<rellla>
i will have a look at it
naoki has joined #linux-amlogic
<chewitt>
hevc probably requires a bit more effort as the deadlock complicates things, but I suspect the root cause is ultimately something quite simple done wrong
<rellla>
i wonder, why nobody reported such sync problems (with h264_v4l2m2m/vdec) with kodi? can kodi track framedrops?
<rellla>
maybe most of the users simply use coreelec and vendor code...
<phh>
fwiw I believe that on g12a+ the whole decoder needs to be completely rewritten to use the stateless-ish decoders, which will allow accurate frame/buffer tracking, but not sure anyone's available for that...
<phh>
(especially since newer Amlogic SoCs no longer have the hardware parser used by the current driver)
naoki has quit [Quit: naoki]
<chewitt>
lvrp16 sponsored some work on that last year, but IIRC it stalled on needing info from Amlogic at the same time as funding running out .. and it hasn't resumed yet
<chewitt>
rellla: kodi tracks framedrops
<chewitt>
but I guess the total impacted users are relatively low
<chewitt>
there are still more LE users running old/unsupported vendor code LE images than are running AMLGX images
<rellla>
i can try to replay the affected files with kodi and hopefully can confirm the problems.
<chewitt>
although AMLGX numbers continue to slowly increase over time
<chewitt>
in Kodi the 'd' (debug) key will bring up an OSD overlay with stats
<rellla>
... i'm no friend of relying on vendor/closed source/non-mainline code ...
<chewitt>
at some point the Amlogic vendor kernel will support V4L2/GBM things well enough that Kodi should "just work" again
<chewitt>
i'm told their latest 6.6 forward port isn't far off
<chewitt>
it's still ugly as hell code of course :)
<rellla>
is that mainline-based then?
<chewitt>
if you squint at the screen from the right angles
<chewitt>
the problem is .. they wrote their own DRM framework c.2011
<chewitt>
long before upstream had any way to do 4K and fancy stuff like 10-bit output and HDR
<chewitt>
and while many other bits have slowly embraced or been rebased onto newer subsystems
<chewitt>
the DRM stuff in the vendor kernel is still 3.10 forward ported to 3.14 > 4.9 > 5.15 > 6.6
<chewitt>
with extra "improvements" along the way to fix stuff and rip out support for older chips
<chewitt>
(ifdef can only get you so far..)
<phh>
chewitt: in Linux 5.15 vendor kernel v4l2 works ""good enough"", but ugh the driver code is absolutely horrible
<chewitt>
it's the inevitable result of closed-door development with no proper peer review
<chewitt>
all your ideas are brilliant and the focus is solely on clearing pass/fail QA checks
<chewitt>
how you got it to pass is irrelevant .. only the result counts
f_ has joined #linux-amlogic
f_ has quit [Remote host closed the connection]
f_ has joined #linux-amlogic
tsegers has quit [Remote host closed the connection]
tsegers has joined #linux-amlogic
tsegers has quit [Remote host closed the connection]
<chewitt>
2024-04-11 12:43:36.894 T:935 debug <general>: ffmpeg[0xb3a6910]: [mpeg2_v4l2m2m] Poll thinks src Q has space; none found
<rellla>
do you have a last working commit?
<rellla>
if it ever worked ...
<chewitt>
no clue, it wasn't something I was testing and it was long broken by the time I've realised
psydroid has joined #linux-amlogic
<chewitt>
it's also entirely possible that the ffmpeg version we're using has diverged from what the mpeg2 codec needs
<chewitt>
as JC is entirely focussed on H264 on RPi boards
<chewitt>
at least from a stateful perspective .. his other interest being HEVC for RPi4/5 but that's stateless
<chewitt>
we (me) persuaded him to allow testing with Amlogic on H264 and with RK/AW boards on stateless so the results are more likely to be robust and upstreamable
<chewitt>
(insert usual disclaimer about ffmpeg mailing lists)
<rellla>
i will have a look at the mpeg part if i could find some time.