From: Kamil Debski <k.debski@samsung.com>
To: "'Nicolas Dufresne'" <nicolas.dufresne@collabora.com>,
"'Wu-Cheng Li'" <wuchengli@chromium.org>,
pawel@osciak.com, mchehab@osg.samsung.com, hverkuil@xs4all.nl,
crope@iki.fi, standby24x7@gmail.com, ricardo.ribalda@gmail.com,
ao2@ao2.it, bparrot@ti.com,
"'Andrzej Hajda'" <a.hajda@samsung.com>
Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-api@vger.kernel.org
Subject: RE: [PATCH] v4l: add V4L2_CID_MPEG_VIDEO_FORCE_FRAME_TYPE.
Date: Fri, 15 Jan 2016 18:01:21 +0100 [thread overview]
Message-ID: <000301d14fb6$5cdd6370$16982a50$@samsung.com> (raw)
In-Reply-To: <1452798133.3306.3.camel@collabora.com>
Hi,
> From: Nicolas Dufresne [mailto:nicolas.dufresne@collabora.com]
> Sent: Thursday, January 14, 2016 8:02 PM
> To: Kamil Debski; 'Wu-Cheng Li'; pawel@osciak.com;
> mchehab@osg.samsung.com; hverkuil@xs4all.nl; crope@iki.fi;
> standby24x7@gmail.com; ricardo.ribalda@gmail.com; ao2@ao2.it;
> bparrot@ti.com; 'Andrzej Hajda'
> Cc: linux-media@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> api@vger.kernel.org
> Subject: Re: [PATCH] v4l: add
> V4L2_CID_MPEG_VIDEO_FORCE_FRAME_TYPE.
>
> Le jeudi 14 janvier 2016 à 18:21 +0100, Kamil Debski a écrit :
> > I had a look into the documentation of MFC. It is possible to force
> > two types of a frame to be coded.
> > The one is a keyframe, the other is a not coded frame. As I understand
> > this is a type of frame that means that image did not change from
> > previous frame. I am sure I seen it in an MPEG4 stream in a movie
> > trailer. The initial board with the age rating is displayed for a
> > couple of seconds and remains static. Thus there is one I-frame and a
> > number of non-coded frames.
> >
> > That is the reason why the control was implemented in MFC as a menu
> > and not a button. Thus the question remains - is it better to leave it
> > as a menu, or should there be two (maybe more in the future) buttons?
>
> Then I believe we need both. Because with the menu, setting I-Frame, I
> would expect to only receive keyframes from now-on. While the useful
> feature we are looking for here, is to get the next buffer (or nearby) to be a
> keyframe. It's the difference between creating an I-Frame only stream and
> requesting a key-frame manually for recovery (RTP use case).
> In this end, we should probably take that time to review the features we
> have as we need:
I think we had a discussion about this long, long time ago. Should it be
deterministic which frame Is encoded as a key frame? Should it be the
next queued frame, or the next processed frame? How to achieve this?
I vaguely remember that we discussed per buffer controls on the mailing
list, but I am not sure where the discussion went from there.
>
> - A way to trigger a key frame to be produce
> - A way to produce a I-Frame only stream
This control can be used to do this:
- V4L2_CID_MPEG_VIDEO_GOP_SIZE (It is not well documented as I can see ;) )
+ If set to 0 the encoder produces a stream with P only frames
+ if set to 1 the encoder produces a stream with I only frames
+ other values indicate the GOP size (I-frame interval)
> - A way to set the key-frame distance (in frames) even though this could
> possibly be emulated using the trigger.
As described above V4L2_CID_MPEG_VIDEO_GOP_SIZE can be used to achieve this.
>
> cheers,
>Nicolas
Best wishes,
--
Kamil Debski
Samsung R&D Institute Poland
next prev parent reply other threads:[~2016-01-15 17:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-13 12:03 [PATCH] v4l: add V4L2_CID_MPEG_VIDEO_FORCE_FRAME_TYPE Wu-Cheng Li
2016-01-13 12:03 ` Wu-Cheng Li
2016-01-13 16:43 ` Kamil Debski
2016-01-14 15:02 ` Nicolas Dufresne
2016-01-14 17:21 ` Kamil Debski
2016-01-14 19:02 ` Nicolas Dufresne
2016-01-15 17:01 ` Kamil Debski [this message]
2016-01-15 17:21 ` Nicolas Dufresne
2016-01-13 15:02 ` Nicolas Dufresne
2016-01-13 16:07 ` Wu-Cheng Li (李務誠)
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='000301d14fb6$5cdd6370$16982a50$@samsung.com' \
--to=k.debski@samsung.com \
--cc=a.hajda@samsung.com \
--cc=ao2@ao2.it \
--cc=bparrot@ti.com \
--cc=crope@iki.fi \
--cc=hverkuil@xs4all.nl \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@osg.samsung.com \
--cc=nicolas.dufresne@collabora.com \
--cc=pawel@osciak.com \
--cc=ricardo.ribalda@gmail.com \
--cc=standby24x7@gmail.com \
--cc=wuchengli@chromium.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