linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Tretter <m.tretter@pengutronix.de>
To: Benjamin Bara - SKIDATA <Benjamin.Bara@skidata.com>
Cc: "linux-arm@lists.infradead.org" <linux-arm@lists.infradead.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	Richard Leitner - SKIDATA <Richard.Leitner@skidata.com>,
	"p.zabel@pengutronix.de" <p.zabel@pengutronix.de>
Subject: Re: [i.MX6][CODA] certain resolutions are not working in YUYV format
Date: Mon, 16 Dec 2019 18:21:01 +0100	[thread overview]
Message-ID: <20191216182101.3676c280@litschi.hi.pengutronix.de> (raw)
In-Reply-To: <c79be4d41e414ae5b50ba1e26544b6c2@skidata.com>

Hi Benjamin,

On Fri, 13 Dec 2019 12:02:25 +0000, Benjamin Bara - SKIDATA wrote:
> we are currently facing a problem with the i.MX6DL and MPEG4-2 encoded videos.
> The decoder seem to fail to decode videos of certain resolutions (video output becomes green).
> For the latest test run, we used Linux kernel 5.4.2 and GStreamer version 1.16.1.
> 
> When hunting the problem down, it seems like the problem is related to the YUY2 (= YUYV) output format.
> Unfortunately, gst always takes YUY2 as the default format for the v4l2mpeg4dec sink pad and 
> forcing a different format does not work (video becomes even more green).
> 
> We saw commit d40e98c13b3e7cb1aa16e9c14f35db3c8c3dd033, which added YUYV if VDOA is used,
> but could not find anything related in the i.MX 6Dual/6Quad VPU API Linux Reference Manual except:
> "One pixel value of a component occupies one byte and the frame data is in YCbCr 4:2:0 format 
> for H.264, H.264 and MPEG-4 codecs." [sic] (Rev. L3.0.35_1.1.0, 01/2013)

The VDOA is documented in the "i.MX 6Dual/6Quad Applications Processor
Reference Manual" because it is not part of the VPU IP core, but an
i.MX-specific adapter between the VPU and the IPU. It is managed by the
coda driver to provide a better abstraction to user space.

If you use a different format other than YUYV (or disable the VDOA
using the disable_vdoa module parameter), you bypass the VDOA and
directly get whatever the VPU is producing.

> 
> For debug purposes, we changed the dst_formats of the decoder driver to only support YUV420 (= I420).
> All tested resolutions are working with this setup.

Not sure if I understand correctly. Did you remove all other formats
except for YUV420 from the driver? Once you did that, all resolutions
are decoded correctly? What happens if you force the driver to produce
NV12 as destination format?

The height of the working resolutions seems to be a multiple of 16,
which is the macroblock size. Thus, there might be a problem with the
cropping the destination frames. Do you see the problems only with
videos that are encoded by the CODA or also with other mpeg4 encoded
videos?

Michael

> 
> Does anyone else face similar issues?
> 
> Please just drop me a mail if we should perform further debug actions or provide further debug output.
> 
> BR,
> Benjamin
> 
> 
> *gst-launch pipeline to reproduce the error:*
> gst-launch-1.0 -v videotestsrc ! video/x-raw,width=480,height=270 ! v4l2mpeg4enc output-io-mode=4 ! \
> 	v4l2mpeg4dec ! xvimagesink
> 
> *failing gst-launch pipeline to force the I420 format:*
> gst-launch-1.0 -v videotestsrc ! video/x-raw,width=480,height=270 ! v4l2mpeg4enc output-io-mode=4 ! \
> 	v4l2mpeg4dec ! video/x-raw,format=I420 ! xvimagesink
> 
> *some other failing resolutions:*
> - 320x200
> - 400x270
> - 400x300
> - 480x250
> - 480x270
> - 480x500
> - 640x200
> - 800x600
> 
> *working resolutions:*
> - 320x240
> - 1024x576
> - ...
> 
> *resulting dmesg output:*
> [ 6159.838070] coda 2040000.vpu: CODA_COMMAND_SEQ_INIT failed, error code = 0x1
> [ 6159.895636] coda 2040000.vpu: errors in 504 macroblocks
> [ 6159.900877] coda 2040000.vpu: decoded frame index out of range: 0
> [ 6160.963450] coda 2040000.vpu: CODA PIC_RUN timeout
> [ 6162.003422] coda 2040000.vpu: CODA PIC_RUN timeout
> 
> *verbose output of failing gst-launch pipeline (GST_DEBUG=1):*
> Setting pipeline to PAUSED ...
> Pipeline is PREROLLING ...
> /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0.GstPad:src: caps = video/x-raw, format=(string)I420, width=(int)480, height=(int)270, framerate=(fraction)30/1, multiview-mode=(string)mono, interlace-mode=(string)progressive, colorimetry=(string)bt601, pixel-aspect-ratio=(fraction)1/1
> /GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = video/x-raw, format=(string)I420, width=(int)480, height=(int)270, framerate=(fraction)30/1, multiview-mode=(string)mono, interlace-mode=(string)progressive, colorimetry=(string)bt601, pixel-aspect-ratio=(fraction)1/1
> /GstPipeline:pipeline0/v4l2mpeg4enc:v4l2mpeg4enc0.GstPad:src: caps = video/mpeg, mpegversion=(int)4, systemstream=(boolean)false, profile=(string)simple, level=(string)5, width=(int)480, height=(int)270, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1, interlace-mode=(string)progressive, colorimetry=(string)bt601, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono
> /GstPipeline:pipeline0/v4l2mpeg4dec:v4l2mpeg4dec0.GstPad:sink: caps = video/mpeg, mpegversion=(int)4, systemstream=(boolean)false, profile=(string)simple, level=(string)5, width=(int)480, height=(int)270, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1, interlace-mode=(string)progressive, colorimetry=(string)bt601, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono
> Redistribute latency...
> /GstPipeline:pipeline0/v4l2mpeg4enc:v4l2mpeg4enc0.GstPad:sink: caps = video/x-raw, format=(string)I420, width=(int)480, height=(int)270, framerate=(fraction)30/1, multiview-mode=(string)mono, interlace-mode=(string)progressive, colorimetry=(string)bt601, pixel-aspect-ratio=(fraction)1/1
> /GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:sink: caps = video/x-raw, format=(string)I420, width=(int)480, height=(int)270, framerate=(fraction)30/1, multiview-mode=(string)mono, interlace-mode=(string)progressive, colorimetry=(string)bt601, pixel-aspect-ratio=(fraction)1/1
> /GstPipeline:pipeline0/v4l2mpeg4dec:v4l2mpeg4dec0.GstPad:src: caps = video/x-raw, format=(string)YUY2, width=(int)480, height=(int)270, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)1/1, chroma-site=(string)jpeg, colorimetry=(string)bt601, framerate=(fraction)30/1
> /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0.GstPad:sink: caps = video/x-raw, format=(string)YUY2, width=(int)480, height=(int)270, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)1/1, chroma-site=(string)jpeg, colorimetry=(string)bt601, framerate=(fraction)30/1
> Pipeline is PREROLLED ...
> Setting pipeline to PLAYING ...
> 
> 

  reply	other threads:[~2019-12-16 17:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-13 12:02 [i.MX6][CODA] certain resolutions are not working in YUYV format Benjamin Bara - SKIDATA
2019-12-16 17:21 ` Michael Tretter [this message]
2019-12-17 11:52   ` Benjamin Bara - SKIDATA
2020-02-11  8:01     ` Benjamin Bara - SKIDATA
2020-02-26 16:22       ` Michael Tretter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191216182101.3676c280@litschi.hi.pengutronix.de \
    --to=m.tretter@pengutronix.de \
    --cc=Benjamin.Bara@skidata.com \
    --cc=Richard.Leitner@skidata.com \
    --cc=linux-arm@lists.infradead.org \
    --cc=linux-media@vger.kernel.org \
    --cc=p.zabel@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).