linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <treding@nvidia.com>
To: Enric Balletbo Serra <eballetbo@gmail.com>
Cc: linux-fbdev@vger.kernel.org,
	Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
	linux-kernel@vger.kernel.org,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	Hans Verkuil <hans.verkuil@cisco.com>,
	Martin Bugge <marbugge@cisco.com>,
	Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Subject: Re: [PATCH] [media] hdmi: added functions for MPEG InfoFrames
Date: Tue, 17 Nov 2015 12:55:08 +0000	[thread overview]
Message-ID: <20151117125507.GD25715@ulmo.nvidia.com> (raw)
In-Reply-To: <CAFqH_514hjjgPHbP=u1nQ2FPoQe2zLuK5L2R6JcLXjOQdpqZ9g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3321 bytes --]

On Mon, Nov 16, 2015 at 05:28:24PM +0100, Enric Balletbo Serra wrote:
> Hello Thierry,
> 
> Many thanks for your comments.
> 
> 2015-11-16 12:50 GMT+01:00 Thierry Reding <treding@nvidia.com>:
> > On Sat, Nov 14, 2015 at 07:38:19PM +0100, Enric Balletbo i Serra wrote:
> >> The MPEG Source (MS) InfoFrame is in EIA/CEA-861B. It describes aspects of
> >> the compressed video stream that were used to produce the uncompressed
> >> video.
> >>
> >> The patch adds functions to work with MPEG InfoFrames.
> >>
> >> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> >> ---
> >>  drivers/video/hdmi.c | 156 +++++++++++++++++++++++++++++++++++++++++++++++++++
> >>  include/linux/hdmi.h |  24 ++++++++
> >>  2 files changed, 180 insertions(+)
> >
> > According to the CEA specification a source is expected to send this
> > type of infoframe once per video frame. I'm curious how you envision
> > this to be ensured. Would hardware provide a mechanism to store this
> > data and send the infoframe automatically? How would you ensure that
> > updates sent to the hardware match the upcoming frame?
> >
> 
> To be honest I'm not sure if I have the full picture. In the use case
> I'm trying there is a hardware mechanism to store the data and send
> the infoframe through a "Packet Send Control Register".

Okay, sounds like the hardware will automatically send out packets at
the right time. That still leaves open the issue of how to ensure this
is synchronized with userspace. Perhaps this could be done by attaching
a property to a framebuffer, so that we'd know what exact frame the meta
data is attached to and when to update the FIFOs for the infoframe.

Usually it's a good idea to send this type of patch as part of a larger
series precisely so that people can see how it is used. That should make
it easier to see if this is good enough or needs some more thought on
how to synchronize. Do you have any code that you could post that makes
use of this new infoframe?

> >> @@ -899,6 +978,41 @@ static void hdmi_audio_infoframe_log(const char *level,
> >>                       frame->downmix_inhibit ? "Yes" : "No");
> >>  }
> >>
> >> +static const char *hdmi_mpeg_picture_get_name(enum hdmi_mpeg_picture_type type)
> >> +{
> >> +     switch (type) {
> >> +     case HDMI_MPEG_PICTURE_TYPE_UNKNOWN:
> >> +             return "Unknown";
> >> +     case HDMI_MPEG_PICTURE_TYPE_I:
> >> +             return "Intra-coded picture";
> >> +     case HDMI_MPEG_PICTURE_TYPE_B:
> >> +             return "Bi-predictive picture";
> >> +     case HDMI_MPEG_PICTURE_TYPE_P:
> >> +             return "Predicted picture";
> >> +     }
> >
> > I'd have chosen the slightly more canonical "I-Frame", "P-Frame",
> > "B-Frame" here, but that's not a strong objection.
> >
> 
> I don't have any inconvenient to change, are the following names more
> canonical ?
> 
>        HDMI_MPEG_UNKNOWN_FRAME = 0x00,
>        HDMI_MPEG_I_FRAME = 0x01,
>        HDMI_MPEG_B_FRAME = 0x02,
>        HDMI_MPEG_P_FRAME = 0x03,

I wasn't very clear. What I meant was the names for the constants. At
least personally I know immediately what is meant when I see "I-Frame",
"P-Frame" or "B-Frame", whereas "Bi-predictive picture" needs more
thinking.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2015-11-17 12:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-14 18:38 [PATCH] [media] hdmi: added functions for MPEG InfoFrames Enric Balletbo i Serra
2015-11-16 11:50 ` Thierry Reding
2015-11-16 16:28   ` Enric Balletbo Serra
2015-11-17 12:55     ` Thierry Reding [this message]
2015-11-17 22:55       ` Enric Balletbo Serra
2015-11-19 11:51         ` Thierry Reding
2015-11-19 12:29           ` Enric Balletbo Serra
2015-12-09 12:10             ` Enric Balletbo Serra

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=20151117125507.GD25715@ulmo.nvidia.com \
    --to=treding@nvidia.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=eballetbo@gmail.com \
    --cc=hans.verkuil@cisco.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marbugge@cisco.com \
    --cc=mchehab@osg.samsung.com \
    --cc=plagnioj@jcrosoft.com \
    --cc=tomi.valkeinen@ti.com \
    /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).