Le mercredi 29 mai 2019 à 19:52 -0400, Nicolas Dufresne a écrit : > Le mercredi 29 mai 2019 à 16:55 -0400, Sven Van Asbroeck a écrit : > > Philipp and Fabio, > > > > On Wed, May 29, 2019 at 12:53 PM Fabio Estevam <festevam@xxxxxxxxx> wrote: > > > Does this patch from Philipp fix the problem? > > > https://git.pengutronix.de/cgit/pza/linux/commit/?h=imx-drm/fixes&id=137caa702f2308f7ef03876e164b0d0f3300712a > > > > I am now running 5.2-rc2 with Philipp's non-plus imx6q patch. > > > > Performance is still much worse than the Freescale baseline. > > > > I am not at all worried about vpu scaler performance, after all v8 is an > > in-progress patch. > > > > I am much more concerned about the CODA h264 slowdown. My 1080p30 test > > video runs at half the speed compared to the Freescale kernel. The best it > > can do is 28fps, which results in visible 'jerks' in the video. Note that > > this is without using the scaler. > > > > Questions: > > - is the performance slowdown a known issue? > > - is there anything I've missed in the gstreamer pipelines below? > > - is there anything I can do to help? > > > > A) mainline 5.2-rc2 with Philipp's latest non-plus patch: > > $ time gst-launch-1.0 filesrc > > location=/home/default/jellyfish-10-mbps-hd-h264.mkv ! matroskademux ! > > h264parse ! v4l2h264dec ! kmssink can-scale=0 sync=0 > > real 0m 32.01s > > kmssink element still have some issues as it renders using the legacy > KMS API and makes an synchronous vblank wait before returning. In many > cases, the proper workaround is to do: > > ... ! v4l2h264dec ! queue ! kmssink can-scale=0 sync=0 > > In order to measure the decoding performance without having the display > being involved you can also do: > > ... ! v4l2h264dec ! fpsdisplaysink text-overlay=0 video-sink=fakevideosink sync=0 -v > > In order to benefit from the best of this driver, you should also use > the latest GStreamer 1.16.0. It contains latest fixes from Philipp and > I, including some performance improvement. So I have done more tests with kmssink, and noticed a large drop in performance too. As I suspected, it's related to unreported latency (as this is not live, it's in fact processing-deadline). What I did to test this (this is stock 1.16.0, with the plugins-base-tools installed). GST_TRACERS="latency(flags=element+reported)" GST_DEBUG="GST_TRACER:7" gst-launch-1.0 filesrc location=Videos/jellyfish-10-mbps-hd-h264.mkv ! parsebin ! v4l2h264dec ! queue max-size-bytes=0 ! fpsdisplaysink text-overlay=0 video-sink="kmssink can-scale=0" 2> gst.log gst-stats-1.0 gst.log Which yield this (filtered the output): Element Latency Statistics: 0xf281c8.v4l2h264dec0.src: mean=338373215 min=83527400 max=424823314 Element Reported Latency: 0xf281c8.v4l2h264dec0: min=0 max=0 ts=0:00:01.786671738 So the decoder reports no latency, which is not a problem for offline playback, but has a 338 ms average latency (with variation from 83 to 424 ms). I think when that latency (this is the processing latency) goes up, QoS events are sent by the sink to the decoder which will do early skips in order to ensure a swift catch up, but also to skip any other processing in the case there would be some converter between the decoder and the sink. But it seems the skip algo is too agressive and makes things worst. I'll work on that. Meanwhile, you can workaround with: ... ! kmssink can-scale=0 qos=0 Now, if that pipeline was live, this would be a problem. For other decoders, we use V4L2_CID_MIN_BUFFERS_FOR_CAPTURE as the decoder latency in frames. That usually represent the DPB depth, but CODA capture queue is not actually the frames we are decoding to, but a pool of frames we convert into. I think to make CODA really usable for live playback with high depth DPB, we'll need a new control that expose this latency. Exposing it through this one would make userspace allocate too many buffers for now reason. > > > B) Freescale kernel: > > $ time gst-launch-0.10 filesrc > > location=/home/default/jellyfish-10-mbps-hd-h264.mkv ! decodebin ! > > mfw_v4lsink sync=0 > > Running time 0:00:14.781129554 render fps 59.941
Attachment:
signature.asc
Description: This is a digitally signed message part
