From: Nicolas Dufresne <nicolas.dufresne@collabora.com>
To: Hsia-Jun Li <Randy.Li@synaptics.com>,
Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Cc: linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
"Hans Verkuil" <hverkuil@xs4all.nl>,
"Sakari Ailus" <sakari.ailus@iki.fi>,
"Andrzej Pietrasiewicz" <andrzej.p@collabora.com>,
"Michael Tretter" <m.tretter@pengutronix.de>,
"Jernej Škrabec" <jernej.skrabec@gmail.com>,
"Chen-Yu Tsai" <wens@csie.org>,
"Samuel Holland" <samuel@sholland.org>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
Subject: Re: Stateless Encoding uAPI Discussion and Proposal
Date: Wed, 30 Aug 2023 11:18:52 -0400 [thread overview]
Message-ID: <e5b416f54fb18363c88813ab3240e6f9c48081f9.camel@collabora.com> (raw)
In-Reply-To: <52e9b710-5011-656b-aebf-8d57e6496ddd@synaptics.com>
Le mercredi 23 août 2023 à 11:04 +0800, Hsia-Jun Li a écrit :
> > It was suggested so far to leave h264 slice headers writing to the driver. This
> > is motivated by H264 slice header not being byte aligned in size, so the
> H.264, H.265 has the byte_alignment() in nalu. You don't need skip bits
> feature which could be found in H1.
As you said so, I rechecked the H.264 grammar.
...
slice_header( )
slice_data( )
...
There is lot of variable size items in the slice_header() syntax and no padding
bits. And no padding at the start of any of the slice_data types. So no, the
slice_header() syntax in H.264 is not byte aligned like you are claiming here.
Its important to be super accurate about these things, as it will cause errors
to be made. Please always double check.
Nicolas
next prev parent reply other threads:[~2023-08-30 18:29 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-11 17:12 Stateless Encoding uAPI Discussion and Proposal Paul Kocialkowski
2023-07-11 18:18 ` Nicolas Dufresne
2023-07-12 14:07 ` Paul Kocialkowski
2023-07-25 3:33 ` Hsia-Jun Li
2023-07-25 12:15 ` Paul Kocialkowski
2023-07-26 2:49 ` Hsia-Jun Li
2023-07-26 19:53 ` Nicolas Dufresne
2023-07-27 2:45 ` Hsia-Jun Li
2023-07-27 17:10 ` Nicolas Dufresne
2023-07-26 8:18 ` Hans Verkuil
2023-08-09 14:43 ` Paul Kocialkowski
2023-08-09 17:24 ` Andrzej Pietrasiewicz
2023-07-21 18:19 ` Michael Grzeschik
2023-07-24 14:03 ` Nicolas Dufresne
2023-07-25 9:09 ` Paul Kocialkowski
2023-07-26 20:02 ` Nicolas Dufresne
2023-08-10 13:44 ` Paul Kocialkowski
2023-08-10 14:34 ` Nicolas Dufresne
2023-08-11 20:08 ` Paul Kocialkowski
2023-08-21 15:13 ` Nicolas Dufresne
2023-08-22 8:30 ` Hsia-Jun Li
2023-08-22 20:31 ` Nicolas Dufresne
2023-08-23 3:04 ` Hsia-Jun Li
2023-08-30 15:10 ` Nicolas Dufresne
2023-08-30 16:51 ` Randy Li
2023-08-30 15:18 ` Nicolas Dufresne [this message]
2023-08-31 9:32 ` Hsia-Jun Li
2023-08-23 8:05 ` Paul Kocialkowski
2023-11-15 13:19 ` Paul Kocialkowski
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=e5b416f54fb18363c88813ab3240e6f9c48081f9.camel@collabora.com \
--to=nicolas.dufresne@collabora.com \
--cc=Randy.Li@synaptics.com \
--cc=andrzej.p@collabora.com \
--cc=hverkuil@xs4all.nl \
--cc=jernej.skrabec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=m.tretter@pengutronix.de \
--cc=paul.kocialkowski@bootlin.com \
--cc=sakari.ailus@iki.fi \
--cc=samuel@sholland.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=wens@csie.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;
as well as URLs for NNTP newsgroup(s).