Re: [PATCH v7 0/4] Performance improvement of decoder

[Brandon Brnich]

Hi Jackson,

On 11/19/2025 12:25 AM, Jackson.lee wrote:
> From: Jackson Lee <jackson.lee@xxxxxxxxxxxxxxx>
>
> v4l2-compliance results:
> ========================
>
> v4l2-compliance 1.28.1-5233, 64 bits, 64-bit time_t
>
> Buffer ioctls:
>                  warn: v4l2-test-buffers.cpp(693): VIDIOC_CREATE_BUFS not supported
>                  warn: v4l2-test-buffers.cpp(693): VIDIOC_CREATE_BUFS not supported
>          test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
>          test CREATE_BUFS maximum buffers: OK
>          test VIDIOC_EXPBUF: OK
>          test Requests: OK (Not Supported)
>
> Total for wave5-dec device /dev/video0: 46, Succeeded: 46, Failed: 0, Warnings: 2
> Total for wave5-enc device /dev/video1: 46, Succeeded: 46, Failed: 0, Warnings: 0
>
> Fluster test results:
> =====================
>
> Running test suite JCT-VC-HEVC_V1 with decoder GStreamer-H.265-V4L2-Gst1.0 Using 3 parallel job(s)
> Ran 133/147 tests successfully              in 61.467 secs
>
> (1 test fails because of not supporting to parse multi frames, 1 test fails because of a missing frame and slight corruption,
>   2 tests fail because of sizes which are incompatible with the IP, 11 tests fail because of unsupported 10 bit format)
>
>
> Running test suite JVT-AVC_V1 with decoder GStreamer-H.264-V4L2-Gst1.0 Using 3 parallel job(s)
> Ran 78/135 tests successfully               in 45.083 secs
>
> (57 fail because the hardware is unable to decode  MBAFF / FMO / Field / Extended profile streams.)
>
> Running test suite JVT-FR-EXT with decoder GStreamer-H.264-V4L2-Gst1.0 Using 3 parallel job(s)
> Ran 25/69 tests successfully               in 15.176 secs
>
> (44 fail because the hardware does not support field encoded and 422 encoded stream)
>
> Seek test
> =====================
> 1. gst-play-1.0 seek.264
> 2. this will use waylandsink since gst-play-1.0 uses playbin.
>     if you don't want to hook up display,
>     you can run gst-play-1.0 seek.264 --videosink=fakevideosink instead
> 3. Let pipeline run for 2-3 seconds
> 4. press SPACE key to pause
> 5. press 0 to reset press SPACE to start again
>
> gst-play-1.0 seek.264 --videosink=fakevideosink Press 'k' to see a list of keyboard shortcuts.
> Now playing /root/seek.264
> Redistribute latency...
> Redistribute latency...
> Redistribute latency...
> Redistribute latency...
> Redistribute latency...aused
> 0:00:09.9 / 0:00:09.9
> Reached end of play list.
>
>
> Sequence Change test
> =====================
> gst-launch-1.0 filesrc location=./drc.h264 ! h264parse ! v4l2h264dec ! filesink location=./h264_output_420.yuv
> Setting pipeline to PAUSED ...
> Pipeline is PREROLLING ...
> Redistribute latency...
> Pipeline is PREROLLED ...
> Setting pipeline to PLAYING ...
> New clock: GstSystemClock
> Redistribute latency...
> Got EOS from element "pipeline0".
> Execution ended after 0:00:00.100759170
> Setting pipeline to NULL ...
> Freeing pipeline ...

I have performed all the same testing you have listed above on this 
series as well as some additional scenarios to validate performance and 
reliability. These tests were conducted using interrupts and the hrtimer 
case. The only difference I have is that my v4l2-compliance reports 47 
out of 47 tests passed instead of your 46 out of 46 - I'm sure this is 
just a version mismatch between us.

In these tests I have validated the bug I reported in patch 1 is now 
fixed. There are no more SError panics when logging is high.

I have also validated that 4K60, 2x4K30, and 8x1080p30 are meeting 
timing requirements. Those tests apply to both H264 and H265. These 
tests were conducted on TI's J784s4 SoC where I increased the CMA size 
so that Wave5 could have access to enough memory for these tests to 
work. Each of the mentioned scenarios were also ran for 30+ minutes just 
to ensure that longer running cases are valid as well.

For the series,

Tested-by: Brandon Brnich <b-brnich@xxxxxx>

Best,
Brandon