From: Nicolas Dufresne <nicolas@ndufresne.ca>
To: Tomasz Figa <tfiga@chromium.org>, Philipp Zabel <p.zabel@pengutronix.de>
Cc: "Pawel Osciak" <posciak@chromium.org>,
"Linux Media Mailing List" <linux-media@vger.kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Hans Verkuil" <hverkuil@xs4all.nl>,
"Alexandre Courbot" <acourbot@chromium.org>,
kamil@wypas.org, a.hajda@samsung.com,
"Kyungmin Park" <kyungmin.park@samsung.com>,
jtp.park@samsung.com,
"Tiffany Lin (林慧珊)" <tiffany.lin@mediatek.com>,
"Andrew-CT Chen (陳智迪)" <andrew-ct.chen@mediatek.com>,
"Stanimir Varbanov" <stanimir.varbanov@linaro.org>,
todor.tomov@linaro.org,
"Paul Kocialkowski" <paul.kocialkowski@bootlin.com>,
"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>
Subject: Re: [RFC PATCH 1/2] media: docs-rst: Add decoder UAPI specification to Codec Interfaces
Date: Thu, 07 Jun 2018 13:49:39 -0400 [thread overview]
Message-ID: <d1f991320ad327dc952edd2b3a374bbf36e79efd.camel@ndufresne.ca> (raw)
In-Reply-To: <CAAFQd5Bk2VVdPW2C9erQ-vgWDV5ySZH+WeWGyqtrzNug2F1SuQ@mail.gmail.com>
Le jeudi 07 juin 2018 à 16:27 +0900, Tomasz Figa a écrit :
> > > I'd say no, but I guess that would mean that the driver never
> > > encounters it, because hardware wouldn't report it.
> > >
> > > I wonder would happen in such case, though. Obviously decoding of such
> > > stream couldn't continue without support in the driver.
> >
> > GStreamer supports decoding of variable resolution streams without
> > driver support by just stopping and restarting streaming completely.
>
> What about userspace that doesn't parse the stream on its own? Do we
> want to impose the requirement of full bitstream parsing even for
> hardware that can just do it itself?
We do it this way in GStreamer because we can and is more reliable with
existing drivers. I do think that the driver driven renegotiation is
superior as it allow a lot more optimization. Full reset is a just the
slowest possible method of renegotiating. It is not visually fantastic
with dynamic streams, like DASH and HLS. Though, we should think of a
way driver can signal that this renegotiation is supported.
Nicolas
next prev parent reply other threads:[~2018-06-07 17:49 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-05 10:33 [RFC PATCH 0/2] Document the V4L2 (stateful) Codec API Tomasz Figa
2018-06-05 10:33 ` [RFC PATCH 1/2] media: docs-rst: Add decoder UAPI specification to Codec Interfaces Tomasz Figa
2018-06-05 11:41 ` Philipp Zabel
2018-06-05 13:42 ` Tomasz Figa
2018-06-06 10:44 ` Philipp Zabel
2018-06-07 7:27 ` Tomasz Figa
2018-06-07 17:49 ` Nicolas Dufresne [this message]
2018-06-06 13:02 ` Alexandre Courbot
2018-06-05 13:10 ` Dave Stevenson
2018-06-06 9:03 ` Tomasz Figa
2018-06-06 13:13 ` Alexandre Courbot
2018-06-07 7:21 ` Hans Verkuil
2018-06-07 7:30 ` Tomasz Figa
2018-06-07 17:53 ` Nicolas Dufresne
2018-06-07 19:36 ` Hans Verkuil
2018-06-07 8:47 ` Hans Verkuil
2018-06-07 11:01 ` Philipp Zabel
2018-06-08 9:03 ` Tomasz Figa
2018-06-08 10:13 ` Hans Verkuil
2018-06-07 17:30 ` Nicolas Dufresne
2018-06-08 10:42 ` Tomasz Figa
2018-06-14 12:34 ` Stanimir Varbanov
2018-06-14 13:56 ` Nicolas Dufresne
2018-06-15 8:02 ` Tomasz Figa
2018-09-11 2:26 ` Nicolas Dufresne
2018-09-11 3:10 ` Tomasz Figa
2018-06-05 10:33 ` [RFC PATCH 2/2] media: docs-rst: Add encoder " Tomasz Figa
2018-06-05 11:53 ` Philipp Zabel
2018-06-05 12:31 ` Tomasz Figa
2018-06-05 14:22 ` Philipp Zabel
2018-06-06 9:17 ` Tomasz Figa
2018-06-06 9:40 ` Philipp Zabel
2018-06-06 10:37 ` Tomasz Figa
2018-06-07 7:27 ` Hans Verkuil
2018-06-07 10:32 ` Philipp Zabel
2018-06-07 10:54 ` Hans Verkuil
2018-06-07 11:02 ` Philipp Zabel
2018-06-07 9:21 ` Hans Verkuil
2018-06-07 10:39 ` Philipp Zabel
2018-06-11 7:49 ` Tomasz Figa
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=d1f991320ad327dc952edd2b3a374bbf36e79efd.camel@ndufresne.ca \
--to=nicolas@ndufresne.ca \
--cc=a.hajda@samsung.com \
--cc=acourbot@chromium.org \
--cc=andrew-ct.chen@mediatek.com \
--cc=hverkuil@xs4all.nl \
--cc=jtp.park@samsung.com \
--cc=kamil@wypas.org \
--cc=kyungmin.park@samsung.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=paul.kocialkowski@bootlin.com \
--cc=posciak@chromium.org \
--cc=stanimir.varbanov@linaro.org \
--cc=tfiga@chromium.org \
--cc=tiffany.lin@mediatek.com \
--cc=todor.tomov@linaro.org \
/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
all inboxes | Powered by JetHome®