jernej: and your score (well assuming I got everything properly built ;-P, is Ran 77/135 tests successfully in 197.029 secs
most of which is wrong MD5 sum
jernej: https://paste.centos.org/view/7dfb412f
jernej: in comparison, 120/135 for the software decoder, in gstreamer VA/Intel we score around 127 iirc
neg: Do you prefer to address the comments to the notifier set later, with the set going in sooner?
jmondi: Could you send a new version of the max9271 GPIO patch?
Or another one on top, that does a lot of nice cleanups all over the place? ;)
sailus: I'm a bit pressed for time in the near future, so I'm OK with the set to go in as is and I can improve ontop in a few weeks if that is OK for you
Ack!
neg: I noticed Jacopo had comments, too, but nothing that couldn't wait a little I guess.
Applied.
sailus: neg: iirc none of the comments I had on notifiers requires major reworks, removing bus autodiscovery can go on top
sailus: a new iteration of "media: max9271: Fix GPIO handling" is mostly just to add tags
have I missed a request for other cleanups in that driver ? (I'm sure there might be much more :D )
sailus: Thanks!
jmondi: I'd feel silly to write a patch that just removes one extra pair of parentheses. ;)
jmondi: On the ov5647, and particularly the last patch removing the configuration --- if the sensor outputs something else its configuration suggests, it may well be a problem with the driver, but it certainly suggests there's a hardware (or driver) problem on unicam side as well.
sailus: ah, didn't get it about the additional cleanup :)
sailus: I've seen unicam capturing 8-bits formats with other sensors
anyway it's fine ignoring the last patch, if that mode could be tested with other platforms that would really help knowing what's going on
hverkuil: Are you happy with Rob's answers?
I only noticed this when going through what's in Patchwork.
We don't have the graph schema in media tree but I don't think it really matters anyway.
hverkuil: Oh, it was pinchartl who commented this. Please ignore.
pinchartl: Regarding the DT graph schema patch --- are you happy with Rob's answers?
I guess we should convert video-interfaces.txt to YAML now.
ndufresne: that's a bit better :) did you do comparison between gstreamer and ffmpeg?
for request api I mean
I wonder if there is any difference or are the issues solely in HW and drivers
jernej: I'm working on that comparision, but with the two uAPI break that came back to back, it seems I need to do more work
jernej: I've looked at 2 test with bad MD5, but the output was visually good, so I'll need further comparision, the delta could be an off-by-one on luma or chroma, which could be a side effect of some colorconversion
I don't know what ffmpeg does internally in that regard, or even the HW, in an ideal world, we want to decode into native pixel format (sunxi tiled I think) and do the checksum from that data
ndufresne: which soc do you have?
for CI in the long run, I'd probably assest visually the buffers, and then simply use different MD5 for different HW, as it's not possible to fix the ASIC, but we want to catch regressions
the Tritium
so H3 or H5?
H5
with linear YUV support
sorry, it's H3
didn't know there was two tritium variants
well, NV12 is natively supported
tiled vs. linear shouldn't cause any difference imo
it shouldn't
but to be fair, we don't know if the IP is ITU compliant to start with ;-P
I know VC8000D is, since I can run fluster with the vendor reference decoder, and it passes ;-P
(well, mostly passes)
yeah, that's what I wonder too
I saw some signs comparing h265 md5 sums in BSP solution
but nothing for h264
jernej: so yeah, don't get too worried about the test results, since it's raw without visual assessment, from a LE perspective, being let's say off by on on luma of chroma is not a deal breaker
and from CI, we can simple use non-standard MD5 for regression testing
true
my idea is that for the same HW, GStreamer and FFMPEG so achieve the same results
and a machine should take care of that (CI)
I understood from talking from ezequielg that the process of enhancing uAPI is tedious, since you have to test on so many unrelated HW or wait for other maintainers to tests for you
yep, that's true
CI should help very much
ndufresne: do you plan to make CI at Collabora?
yes, but it's been dragging for so long
I'll follow the path of Mesa, they have a bridge between gitlab CI and the kernel ci labs
they also have some gitlab runners with real GPUs (so we could probably use it to test stuff like VA-API on Intel/AMD)
sailus: yes. with the tools we have today we can't do much better. maybe in the future, when the tools will be improved :-)
pinchartl: Does that count as an ack? :-)
I suppose so :-)
pinchartl: Thanks!
Applied.
jernej: I think I'm getting closer, probably a bug in gst, the decoding of the slice fails, as the driver mark the buffer to ERROR (aka done with error), we enter a no mans land with the HOLD feature
cc hverkuil ^
I need to further track what is happening, but also to understand what the appropriate error handling path when one of the slices failed
in this case it's just a bug, but it could in theory happen due to corruption
jernej: just discovered I was missing "media: cedrus: h264: Fix check for presence of scaling matrix"
ah, that should fix few cases :)
can you run suite again?
jernej: you said some validation from ezequielg was breaking some cases, do you have more info ?
(it's running)
no, it was false alarm
ah ok
how long does it take to complete one whole run?
2 more tests passing ;-P 73/135
152.732s
it's running 4 concurrent decode
(well "concurrent", we only have 1 HW core)
you said 77/135 in the morning :)
hmm, interesting ...
perhaps it's not stable, or there is bugs in concurency, let's so 1 job to see
(I thought it was 71 , sorry)
I was just about to suggest that
anything I should worry about ? "alloc_contig_range: [5c060, 5c06a) PFNs busy"
what is your CMA size?
I suggest to set it to 256 MiB to be on the safe side
I've asked for cma=320M
but perhaps with 4 decodes in parallel, that wasn't enough
(specially that we got some really dummy code to pick bitstream buffer size atm)
maybe
I've seen 12MB bitstream buffers ;-P
uh, that's big
jernej: ok, got 84/135 (failures=51, errors=2)
let's run that again, to see if it's stable
now we're getting somewhere
what's hantro score?
The errors are cases where the ffmpeg tool return non-zero, probably for the FMO and the ASO files
which are exactly 2 tests of the conformance
I'm not yet setup for that
but I suspect it will be better
we have less work to do, since it parser the slice headers for us
jernej: ok, running fluster with -j1 is stable, so 84/135
ok, that's good
jernej: latest report, https://paste.centos.org/view/d09e6a31
I think the other failures with -j4 was memory pressure
jernej: a script to download the ITU, https://paste.centos.org/view/d09e6a31
that's same link
I'm only running ITU-T_H.264.1(2016-02)_AVCv1_bitstreams.zip atm
jernej: sorry, https://paste.centos.org/view/3f50a35f
ok, thanks
I guess I'll test it over the weekend
what would be of interest in the long run is to try and cover Stereo/3D, as that is supported by RK/Hantro, and perhaps SVC if supported
of course for 3D, we'd need some signalling of the frame arrangement (side-by-side, top/bottom, etc)
ndufresne: I just remembered - here ffmpeg does conversion between nv12 and yuv420, but I have patches to enable yuv420 directly in VPU and also in ffmpeg
MVC (if it was supported) would be some sort of a challenge, as view don't usually get decoded in the same buffer ...
jernej: note that the md5 are yuv420
oh, you guys just figured that out.
so don't read into how long fluster takes
jernej: that would likely speedup the test by a lot
we need md5 in nv12 and nv12_4l4
in gst, I wanted to implement support to gen MD5 from any 4:2:0 as if it was yuv420p
ndufresne: kernel side: https://patchwork.linuxtv.org/project/linux-media/patch/20200520171457.11937-1-jernej.skrabec@siol.net/
but for ffmpeg I lost patch
oops ;-P
only libavcodec/v4l2_request.c needs to be updated
can userspace choose with ffmpeg ?
oh, btw, I said 84, but didn't substract the 2 error, so it's 82
on by older gst/rkvdec work I get 70 (no interlaced support)
ndufresne: HW formats are a bit tricky in ffmpeg
I guess it would be possible in the end, but currently it has list of supported formats in order of preference
s/would/will/
that's v4l2_request implementation limitation
I cannot blame, most decoder abstractions are base with the idea that the decoder decide of 1 formats that fits the stream
turns out being able to choose is more common in HW
jernej: btw, we found that slice decoding isn't working in gst ;-P
I thought I had fixed that few times already but eh ...
ndufresne: this should do it for ffmpeg: http://ix.io/2FIn
note that I didn't even test build it because I don't have appropriate setup at hand so YMMV
ndufresne: this one is better: http://ix.io/2FIt