| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| ndufresne | 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 | [00:02] |
| ....... (idle for 31mn) | ||
| jernej: in comparison, 120/135 for the software decoder, in gstreamer VA/Intel we score around 127 iirc | [00:35] | |
| ...................................................................................................... (idle for 8h29mn) | ||
| *** | dreamcat4 has quit IRC (Ping timeout: 260 seconds) | [09:04] |
| ........................... (idle for 2h10mn) | ||
| sailus | neg: Do you prefer to address the comments to the notifier set later, with the set going in sooner? | [11:14] |
| 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? ;) | [11:28] | |
| neg | 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 | [11:29] |
| sailus | Ack!
neg: I noticed Jacopo had comments, too, but nothing that couldn't wait a little I guess. Applied. | [11:33] |
| jmondi | 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 ) | [11:42] |
| neg | sailus: Thanks! | [11:48] |
| .... (idle for 16mn) | ||
| sailus | jmondi: I'd feel silly to write a patch that just removes one extra pair of parentheses. ;) | [12:04] |
| .... (idle for 17mn) | ||
| 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. | [12:21] | |
| ........ (idle for 37mn) | ||
| jmondi | 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 | [12:58] |
| ....... (idle for 30mn) | ||
| sailus | 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. | [13:30] |
| ............... (idle for 1h13mn) | ||
| jernej | 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 | [14:50] |
| ........... (idle for 51mn) | ||
| ndufresne | 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 | [15:42] |
| jernej | ndufresne: which soc do you have? | [15:45] |
| ndufresne | 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 | [15:45] |
| jernej | so H3 or H5? | [15:46] |
| ndufresne | H5
with linear YUV support sorry, it's H3 didn't know there was two tritium variants | [15:46] |
| jernej | well, NV12 is natively supported
tiled vs. linear shouldn't cause any difference imo | [15:47] |
| ndufresne | 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) | [15:48] |
| jernej | yeah, that's what I wonder too
I saw some signs comparing h265 md5 sums in BSP solution but nothing for h264 | [15:50] |
| ndufresne | 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 | [15:52] |
| jernej | true | [15:53] |
| ndufresne | 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 | [15:53] |
| jernej | yep, that's true
CI should help very much ndufresne: do you plan to make CI at Collabora? | [15:59] |
| ndufresne | 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) | [16:01] |
| pinchartl | sailus: yes. with the tools we have today we can't do much better. maybe in the future, when the tools will be improved :-) | [16:10] |
| sailus | pinchartl: Does that count as an ack? :-) | [16:11] |
| pinchartl | I suppose so :-) | [16:15] |
| sailus | pinchartl: Thanks!
Applied. | [16:29] |
| ...................... (idle for 1h46mn) | ||
| ndufresne | 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 | [18:19] |
| ..... (idle for 21mn) | ||
| jernej: just discovered I was missing "media: cedrus: h264: Fix check for presence of scaling matrix" | [18:42] | |
| jernej | ah, that should fix few cases :)
can you run suite again? | [18:42] |
| ndufresne | jernej: you said some validation from ezequielg was breaking some cases, do you have more info ?
(it's running) | [18:43] |
| jernej | no, it was false alarm | [18:43] |
| ndufresne | ah ok | [18:43] |
| jernej | how long does it take to complete one whole run? | [18:44] |
| ndufresne | 2 more tests passing ;-P 73/135
152.732s it's running 4 concurrent decode (well "concurrent", we only have 1 HW core) | [18:45] |
| jernej | you said 77/135 in the morning :) | [18:47] |
| ndufresne | 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) | [18:47] |
| jernej | I was just about to suggest that | [18:47] |
| ndufresne | anything I should worry about ? "alloc_contig_range: [5c060, 5c06a) PFNs busy" | [18:49] |
| jernej | what is your CMA size?
I suggest to set it to 256 MiB to be on the safe side | [18:50] |
| ndufresne | 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) | [18:51] |
| jernej | maybe | [18:51] |
| ndufresne | I've seen 12MB bitstream buffers ;-P | [18:52] |
| jernej | uh, that's big | [18:52] |
| ndufresne | jernej: ok, got 84/135 (failures=51, errors=2)
let's run that again, to see if it's stable | [18:53] |
| jernej | now we're getting somewhere
what's hantro score? | [18:53] |
| ndufresne | 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 | [18:54] |
| jernej | ok, that's good | [18:58] |
| ndufresne | 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 | [18:59] |
| jernej | that's same link | [19:00] |
| ndufresne | I'm only running ITU-T_H.264.1(2016-02)_AVCv1_bitstreams.zip atm
jernej: sorry, https://paste.centos.org/view/3f50a35f | [19:01] |
| jernej | ok, thanks
I guess I'll test it over the weekend | [19:01] |
| ndufresne | 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) | [19:02] |
| jernej | 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 | [19:05] |
| ndufresne | MVC (if it was supported) would be some sort of a challenge, as view don't usually get decoded in the same buffer ... | [19:05] |
| ezequielg | jernej: note that the md5 are yuv420
oh, you guys just figured that out. so don't read into how long fluster takes | [19:05] |
| ndufresne | jernej: that would likely speedup the test by a lot | [19:05] |
| ezequielg | we need md5 in nv12 and nv12_4l4 | [19:06] |
| ndufresne | in gst, I wanted to implement support to gen MD5 from any 4:2:0 as if it was yuv420p | [19:06] |
| jernej | ndufresne: kernel side: https://patchwork.linuxtv.org/project/linux-media/patch/20200520171457.11937-1-jernej.skrabec@siol.net/
but for ffmpeg I lost patch | [19:08] |
| ndufresne | oops ;-P | [19:10] |
| jernej | only libavcodec/v4l2_request.c needs to be updated | [19:11] |
| ndufresne | 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) | [19:11] |
| jernej | 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 | [19:12] |
| ndufresne | 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 ... | [19:14] |
| jernej | 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 | [19:24] |
| ........................ (idle for 1h57mn) | ||
| *** | mchehab has quit IRC (Ping timeout: 256 seconds)
koike_5 has quit IRC (Read error: Connection reset by peer) | [21:24] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |