On Tue, Nov 12, 2024 at 9:44 AM martin schitter wrote:
>
>
>
> On 12.11.24 08:51, Martin Storsjö wrote:
> > On Tue, 12 Nov 2024, martin schitter wrote:
> >
> >> The git history of Patches here on this mailinglist are usually
> >> rewritten whenever one of the reviewers requests some change, but th
On Mon, Nov 11, 2024 at 12:53 AM James Almer wrote:
>
> On 11/10/2024 8:44 PM, Michael Niedermayer wrote:
> > Hi all
> >
> > as we will likely have 15k available from STF "2024" for another
> > task/project
> > what should it be used for ?
> >
> > I think the obvious options are:
> >
> > 1. gitla
On Wed, Oct 23, 2024 at 2:04 AM martin schitter wrote:
>
>
>
> On 22.10.24 22:33, Diederick C. Niehorster wrote:
> > I am writing about machine vision, not machine learning or computer
> > vision. So there are no uncommon small bit sizes, we're dealing with
> >
On Wed, Oct 23, 2024 at 8:44 AM James Almer wrote:
>
> On 10/21/2024 4:57 PM, Martin Schitter wrote:
> > ---
> > libavcodec/Makefile| 1 +
> > libavcodec/allcodecs.c | 1 +
> > libavcodec/dnxucdec.c | 338 +
> > 3 files changed, 340 insertions(
Hi Martin,
Thanks for writing in!
On Tue, Oct 22, 2024 at 11:41 AM martin schitter wrote:
>
>
>
> On 22.10.24 08:50, Diederick C. Niehorster wrote:
> >> I want to pick up a discussion i started last week
> >> (https://ffmpeg.org/pipermail/ffmpeg-devel/2024-Octo
Ping.
Is the below a viable scheme or are there concerns to consider in this
initial design stage?
Thanks and all the best,
Dee
On Tue, Oct 15, 2024 at 8:55 AM Diederick C. Niehorster
wrote:
>
> Hi All,
>
> I want to pick up a discussion i started last week
> (https://ffmpe
Hi All,
I want to pick up a discussion i started last week
(https://ffmpeg.org/pipermail/ffmpeg-devel/2024-October/334585.html)
in a new thread, with the relevant information nicely organized. This
is about adding pixel formats common in machine vision to ffmpeg
(though i understand some formats m
Hi Lynne,
On Wed, Oct 9, 2024 at 12:52 AM Lynne via ffmpeg-devel
wrote:
>
> On 08/10/2024 21:17, Diederick C. Niehorster wrote:
> > Dear Lynne,
> >
> > On Tue, Oct 8, 2024 at 1:11 PM Lynne via ffmpeg-devel
> > wrote:
> >
> > Thank you for your quick
Dear Lynne,
On Tue, Oct 8, 2024 at 1:11 PM Lynne via ffmpeg-devel
wrote:
Thank you for your quick and helpful answer! However I have several questions.
> We have support for AV_PIX_FMT_BAYER_RGGB16, since its a common Bayer
> layout that cinema cameras output, so its definitely within the scope
Hi All,
I am using ffmpeg for a library to interface with machine vision
cameras that i am developing (not yet released),it allows storing the
streams with really nice performance directly to, e.g., x264/mp4
(thanks ffmpeg!). For this, i am looking to support some new pixel
formats as input format
On Thu, Apr 25, 2024 at 12:50 AM Tomas Härdin wrote:
> A large long term project that would help immensely with security is
> moving to a proper parsing framework, rather than the present shotgun
> parsing approach. But this might be such a large undertaking that it's
> better to start from scratc
On Fri, Apr 19, 2024, 19:35 Zhao Zhili wrote:
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> Niklas Haas
> > Sent: 2024年4月19日 22:50
> > To: FFmpeg development discussions and patches
> > Subject: Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
> >
> > On Thu, 18 Apr 202
On Mon, Mar 4, 2024 at 11:39 PM Marton Balint wrote:
> On Mon, 4 Mar 2024, Anton Khirnov wrote:
>
> > Native access is from the code that declared the options, foreign access
> > is from code that is using the options. Forbid foreign access to
> > AVOption.offset/default_val, for which there is n
On Sun, Mar 3, 2024 at 3:55 PM Anton Khirnov wrote:
> Quoting Marton Balint (2024-02-26 20:38:46)
> > The more I think about it, it is actually a broader problem.
> >
> > You are changing the semantics of existing AV_OPT_TYPE_xxx types. So
> > previously an option with AV_OPT_TYPE_STRING used to
On Mon, Feb 5, 2024 at 8:59 PM Anton Khirnov wrote:
> diff --git a/configure b/configure
> index f72533b7d2..1bb9e23f19 100755
> --- a/configure
> +++ b/configure
> @@ -5517,21 +5517,20 @@ if test "$?" != 0; then
> die "C compiler test failed."
> fi
>
> -add_cppflags -D_ISOC99_SOURCE
> +add_
On Wed, Jan 31, 2024 at 12:17 PM Niklas Haas wrote:
>
> From: Niklas Haas
>
> diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
> index fe7e6ace27..37110bc32f 100644
> --- a/libavfilter/vf_drawtext.c
> +++ b/libavfilter/vf_drawtext.c
> @@ -1152,7 +1152,7 @@ static int config_inpu
On Mon, Jan 29, 2024 at 9:10 PM Vittorio Giovara
wrote:
>
> On Mon, Jan 29, 2024 at 8:22 PM Michael Niedermayer
> wrote:
>
> > > I have yet to see an actual project of "this magnitude" materialize as a
> > proposal.
> >
> > you can suggest one ?
> >
>
> libavscale!
Not being a regular, this may
On Sun, Jan 14, 2024 at 4:15 PM Jeffrey Knockel wrote:
>
> Previously AV_PIX_FMT_RGB8 was documented as "RGB 3:3:2,
> (msb)2R 3G 3B(lsb)". While the RGB 3:3:2 part is correct, the latter
> part should be: (msb)3R 3G 2B(lsb). This commit also updates the
> format's pixdesc description to be (msb)
On Fri, Sep 22, 2023 at 10:39 AM Michael Koch
wrote:
>
> (?i)customer.?support
> (?i)customer.?care
> (?i)customer.?service
>
> What's the meaning of (?i) and .?
> I can't find that in Python syntax description.
>
This is regular expression syntax, not python syntax. There are some
nice online to
On Mon, May 1, 2023 at 12:13 PM Nicolas George wrote:
> Hi.
>
> Three years ago, I shared some brief thoughts about embedding the
> documentation in the libraries. For example, that would allow GUI
> applications to open help dialogs about specific options.
>
> To see what it would need, I wrote
On Fri, Dec 9, 2022 at 1:45 PM Niklas Haas wrote:
> Oh, you are right. So that presents an alternative to 4 - rather than an
> encoder flag, we can tie the auto-conversion in fftools to be tied to
> the strict_std_compliance check.
>
> I will try implementing this approach, it may be the best com
Hi,
On Mon, Oct 31, 2022 at 1:33 AM wrote:
>
> From: Mark Reid
>
> This patch series adds swscale input/output support for the packed rgb float
> formats.
> A few of the filters also needed support the larger 96/128 bit packed pixel
> sizes.
>
> I also plan to eventually add lossless unscaled
On Fri, Aug 26, 2022 at 1:42 PM Sebastian Beckmann
wrote:
>
> Adds an option to use constant bitrate instead of average bitrate to the
> videotoolbox encoders. This is enabled via -constant_bit_rate true.
> macOS 13 is required for this option to work.
>
> Signed-off-by: Sebastian Beckmann
> ---
On Tue, Jul 12, 2022, 13:02 Abhishek Gorecha
wrote:
> Hi, When we try to give rtp stream as input we are not able to process.
> Can anyone help us out here
>
>
>
> Wrong list. Post on ffmpeg-user. Also provide full details, like this no
> one can help you of course
__
On Tue, May 10, 2022 at 7:25 PM Andreas Rheinhardt
wrote:
>
> Diederick Niehorster:
> > This reverts commit 4f49ca7bbc75a9db4cdf93f27f95a668c751f160. The next
> > few patches clean up the API and implement this capability for
> > avdevice/dshow.
> >
> > Bumping avformat and avdevice version.
> >
>
Hi Andreas,
On Thu, May 5, 2022 at 2:47 PM Andreas Rheinhardt
wrote:
>
> No AVOutputFormat has this set. It is not removed immediately despite
> being private because of the libavdevice<->libavformat situation.
> The fact that this field is private is also the reason why no FF_API_*
> define has
Ping for the series, especially the first commit in the series which
should spark some discussion.
Thanks!
Dee
On Wed, Mar 30, 2022 at 2:18 PM Diederick Niehorster wrote:
>
> This patch series implements a series of features, mostly enhancing the
> dshow avdevice, but also adding new functionali
Ping for the below.
On Tue, Apr 19, 2022 at 10:13 AM Diederick Niehorster wrote:
>
> Fix for f125c504d8fece6420bb97767f9e72414c26312a, requested_sample_rate
> and such should be used.
>
> Signed-off-by: Diederick Niehorster
> ---
> libavdevice/dshow.c | 6 +++---
> 1 file changed, 3 insertions(
On Tue, Apr 19, 2022 at 8:10 AM Roger Pack wrote:
>
> LGTM.
Not LGTM, see below
> On Wed, Apr 13, 2022 at 10:15 AM James Almer wrote:
> >
> > Remnant from f125c504d8fece6420bb97767f9e72414c26312a
> >
> > Signed-off-by: James Almer
> > ---
> > libavdevice/dshow.c | 8
> > 1 file chang
Hi Michael,
On Tue, Mar 29, 2022 at 11:08 PM Michael Niedermayer
wrote:
>
> On Tue, Mar 29, 2022 at 01:40:26AM +0200, Diederick C. Niehorster wrote:
> > Hi Michael,
> >
> > On Tue, Mar 29, 2022 at 1:31 AM Michael Niedermayer
> > wrote:
> > >
> >
Hi Michael,
On Tue, Mar 29, 2022 at 1:31 AM Michael Niedermayer
wrote:
>
> Hi all
>
> I intend to do a 5.0.1 release from the release/5.0 branch in the next days
> as its high time to make a new release with all the bugfixes
> so if you want to backport something please do so
Could you include t
On Fri, Mar 25, 2022 at 6:26 PM Michael Niedermayer
wrote:
>
> On Fri, Mar 25, 2022 at 03:10:39PM +0100, Diederick Niehorster wrote:
> > This example also shows use of get_device_list API.
> >
> > Also improve capability API doc in avdevice.h: now point to this example
> > instead of rough example
On Tue, Mar 22, 2022 at 3:10 PM Roger Pack wrote:
>
> On Tue, Mar 22, 2022 at 7:40 AM wrote:
> >
> > From: Romain Beauxis
> >
> > diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
> > index 6039578ff9..4ee3f6e194 100644
> > --- a/libavdevice/dshow.c
> > +++ b/libavdevice/dshow.c
> > @@ -552
On Thu, Mar 3, 2022 at 1:07 PM Martin Storsjö wrote:
> While swscale can be reconfigured with sws_setColorspaceDetails,
> the in/out ranges also need to be set before calling
> sws_init_context, otherwise the initialization might choose
> fastpaths that don't take the ranges into account.
>
> The
Hi Andreas,
On Mon, Jan 3, 2022 at 12:03 PM Diederick C. Niehorster
wrote:
> Hi Andreas,
>
> Thanks for the comments!
>
> On Mon, Jan 3, 2022 at 11:02 AM Andreas Rheinhardt
> wrote:
> >
> > Diederick Niehorster:
> > > As per discussion on the list (
&g
Hi Gyan,
On Tue, Jan 4, 2022 at 1:05 PM Gyan Doshi wrote:
>
> On 2022-01-04 04:06 pm, Diederick C. Niehorster wrote:
> > On Tue, Jan 4, 2022 at 5:10 AM Gyan Doshi wrote:
> >> On 2022-01-04 05:02 am, Roger Pack wrote:
> >>> These LGTM. Feel free to add you
On Tue, Jan 4, 2022 at 5:10 AM Gyan Doshi wrote:
> On 2022-01-04 05:02 am, Roger Pack wrote:
> > These LGTM. Feel free to add yourself as a dshow maintainer if so
> > interested, as well! :)
>
> I assume these need to be pushed too.
Yes thanks, please push. Would be good to get in before the rel
Hi Andreas,
Thanks for the comments!
On Mon, Jan 3, 2022 at 11:02 AM Andreas Rheinhardt
wrote:
>
> Diederick Niehorster:
> > As per discussion on the list (
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2021-June/281513.html, see
> > especially https://ffmpeg.org/pipermail/ffmpeg-devel/2021-June
FWIW, the macro
#define AV_MAKE_MAJOR_MINOR_FUNC_NAME(name,major,minor)
AV_GLUE(av,name)AV_GLUE(_version_,major)AV_GLUE(_,minor)
doesn't compile on patchwork
(https://patchwork.ffmpeg.org/check/49062/), but worked fine for me on
MSVC. Is MSVC non-compliant somehow? Suggestions appreciated, I'm no
s
On Fri, Dec 24, 2021 at 4:09 AM rcombs wrote:
>
> This patchset is also available as a GitHub pull request for review
> simplicity:
> https://github.com/FFmpeg/FFmpeg/pull/380
>
> - Reduce hardcoding of pixfmt lists, preferring deriving properties from
> pixdesc
> - Fix big-endian support for P[
Hi Hendrik,
On Tue, Dec 21, 2021 at 2:35 PM Hendrik Leppkes wrote:
>
> On Tue, Dec 21, 2021 at 2:11 PM Diederick C. Niehorster
> wrote:
> >
> > Hi Hendrik,
> >
> > Thanks for the review! Comments/questions below:
> >
> > On Tue, Dec 21, 2021 at 1:35
Hi Hendrik,
Thanks for the review! Comments/questions below:
On Tue, Dec 21, 2021 at 1:35 PM Hendrik Leppkes wrote:
>
> On Tue, Dec 21, 2021 at 1:15 PM Diederick Niehorster
> wrote:
> >
> > Enabled discovering a DirectShow device's color range, space, primaries,
> > transfer characteristics an
Hi Andreas,
On Mon, Dec 20, 2021 at 9:01 AM Diederick C. Niehorster
wrote:
>
> On Mon, Dec 20, 2021 at 2:04 AM Andreas Rheinhardt
> wrote:
> >
> > Diederick Niehorster:
> > > // store to device_list output
> > > if (av_
Hi Andreas,
On Mon, Dec 20, 2021 at 1:59 AM Andreas Rheinhardt
wrote:
>
> Diederick Niehorster:
> > diff --git a/libavdevice/avdevice.h b/libavdevice/avdevice.h
> > index 8370bbc7f2..6f24976dcc 100644
> > --- a/libavdevice/avdevice.h
> > +++ b/libavdevice/avdevice.h
> > @@ -457,6 +457,8 @@ void
On Mon, Dec 20, 2021 at 2:27 AM Andreas Rheinhardt
wrote:
>
> Diederick Niehorster:
> > @@ -545,11 +759,40 @@ dshow_cycle_formats(AVFormatContext *avctx, enum
> > dshowDeviceType devtype,
> > } else {
> > av_log(avctx, AV_LOG_INFO, " pixel_format=%s",
> > a
On Mon, Dec 20, 2021 at 2:04 AM Andreas Rheinhardt
wrote:
>
> Diederick Niehorster:
> > // store to device_list output
> > if (av_reallocp_array(&(*device_list)->devices,
> > (*device_list)->nb_devices + 1,
> > @@ -412,6 +417,
Hi Michael,
On Wed, Dec 15, 2021 at 3:52 PM Michael Niedermayer
wrote:
>
> On Tue, Dec 14, 2021 at 05:42:01PM +0100, Diederick C. Niehorster wrote:
> > Hi Michael,
> >
> > On Tue, Dec 14, 2021 at 5:19 PM Michael Niedermayer
> > wrote:
> > >
> > &
Hi Michael,
On Tue, Dec 14, 2021 at 5:19 PM Michael Niedermayer
wrote:
>
> On Mon, Dec 13, 2021 at 10:27:33PM +0100, Diederick C. Niehorster wrote:
> > Hi Michael,
> >
> > On Mon, Dec 13, 2021 at 4:26 PM Michael Niedermayer
> > wrote:
> > >
> > >
Hi Michael,
On Mon, Dec 13, 2021 at 4:26 PM Michael Niedermayer
wrote:
>
> If you know of any major issues which need to be done before the release do
> them
> now. If you know of any issues which are release-blocking list them in a reply
> here please.
Not major, but
https://ffmpeg.org/piperm
Top-posting on purpose:
Several core developers stated to be in favor of locking lavd<->lavf
together at the minor version, for instance since it solves a lot of
the problems the intimate linking between the two libraries creates.
Should this be turned into a patch somehow (i'm not sure how to do
On Sat, Aug 14, 2021, 11:26 Nicolas George wrote:
>
> I agree. But it is important to remember that before seriously
> considering any deep change, it would be necessary to actively poll the
> silent individual-minority-work-majority.
>
Is there a mechanism to trigger such a vote? I hope the cor
On Thu, Aug 12, 2021 at 3:45 PM wrote:
> I agree with softworkz here. There are skilled programmers who like mailing
> lists, and ones that don't. Same goes with unskilled prorammers as well. The
> times are changing and the project needs to be ready for that. Not everyone
> even likes mailing
On Tue, Aug 3, 2021 at 4:22 PM Andreas Rheinhardt
wrote:
>
> Diederick Niehorster:
> > list_options true would crash when both a video and an audio device were
> > specified as input. Crash would occur on line 1588 (in this new rev)
> > because ctx->device_unique_name[otherDevType] would be NULL
>
ping for the series
On Sat, Jul 17, 2021 at 4:27 PM Diederick C. Niehorster
wrote:
>
> On Wed, Jul 7, 2021 at 8:46 AM Diederick C. Niehorster
> wrote:
> >
> > On Tue, Jul 6, 2021 at 11:20 AM Diederick Niehorster
> > wrote:
> > >
> > > This patch s
On Wed, Jul 7, 2021 at 8:46 AM Diederick C. Niehorster
wrote:
>
> On Tue, Jul 6, 2021 at 11:20 AM Diederick Niehorster
> wrote:
> >
> > This patch series implements a series of features, mostly enhancing the
> > dshow avdevice, but also adding new functionality
On Tue, Jul 6, 2021 at 11:20 AM Diederick Niehorster wrote:
>
> This patch series implements a series of features, mostly enhancing the
> dshow avdevice, but also adding new functionality to avformat.
> This whole patchset enabled users of the FFmpeg API to fully
> query and control a dshow device
On Thu, Jun 17, 2021 at 3:41 AM Andreas Rheinhardt
wrote:
>
> Diederick Niehorster:
> > fftools now print info about what media type(s), if any, are provided by
> > sink and source avdevices.
> >
> > Signed-off-by: Diederick Niehorster
> > ---
> > fftools/cmdutils.c | 34
On Thu, Jun 17, 2021 at 4:46 AM Andreas Rheinhardt
wrote:
>
> You are typedefing twice; this is only valid since C11; before that,
> typedefs were subject to the one-definition-rule. This will break older
> compilers for no benefit whatsoever, so please don't typedef here.
>
replaced by
struct AV
On Wed, Jun 16, 2021 at 12:45 PM Andreas Rheinhardt
wrote:
> Cost: It might force you to update more libraries, thereby increasing
> download (or upload if you are the distributor) size.
> Benefit: Besides fixing the horrible libavformat-libavdevice
> relationship (we are currently not able to add
On Wed, Jun 16, 2021 at 11:33 AM Andreas Rheinhardt
wrote:
>
> Nicolas George:
> > Andreas Rheinhardt (12021-06-16):
> >> Yes, because one is allowed to use an old libavdevice together with a
> >> new libavformat.
> >
> > Why do we allow that? What is the actual benefit?
> >
> AFAIK: Nothing. And
On Tue, Jun 15, 2021 at 10:18 AM Michael Niedermayer
wrote:
>
> On Mon, Jun 14, 2021 at 02:50:32PM -0300, James Almer wrote:
> > On 6/14/2021 1:56 PM, Michael Niedermayer wrote:
> > > On Fri, Jun 11, 2021 at 10:30:48PM +0200, Diederick Niehorster wrote:
> > > > Enabled discovering a DirectShow dev
On Wed, Jun 16, 2021 at 12:23 AM James Almer wrote:
>
> I guess a configure option to look for the API used by this patch would
> be needed, making this new code optional.
No need luckily, i have a workaround for all but the
AMCONTROL_COLORINFO_PRESENT symbol. I'll define that one if not
already
On Thu, Dec 31, 2020 at 2:33 PM <(unknown sender)> wrote:
>
> This mail is about a project I have to make FFmpeg's API and
> infrastructure more convenient. For a common introduction, see this
> thread:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/274167.html
>
> Global mutable state h
On Thu, Dec 31, 2020 at 9:52 PM wrote:
>
> On 31/12/2020 13:36, Nicolas George wrote:
> > This mail is about a project I have to make FFmpeg's API and
> > infrastructure more convenient. For a common introduction, see this
> thread:
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/27416
On Thu, Dec 31, 2020 at 2:35 PM wrote:
>
> This mail is about a project I have to make FFmpeg's API and
> infrastructure more convenient. For a common introduction, see this
> thread:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/274167.html
>
> For each simple type, including enumerat
Reorganized a bit for easier replying.
Also, while i think this is an important discussion, i do not see why
it should stop de-deprecation of a good API. Deprecating the device
capabilities API cleaned up avformat a bit, but various other function
pointers are left. A redesign would clean them all
Nicolas, I agree with what you said, and you obviously have given this
more thought than me. Your and Anton's replies provide two by now
pretty clear different views, I hope more will chime in.
I will only highlight some things below.
On Fri, Jun 11, 2021 at 3:17 PM Nicolas George wrote:
> Input
On Fri, Jun 11, 2021 at 10:38 PM Diederick Niehorster wrote:
>
> This function allows formatting an option value stored in a double (such
> as the min and max fields of an AVOption, or min_value and max_value of
> an AVOptionRange) properly, e.g. 1 for a AV_OPT_TYPE_PIXEL_FMT -> yuyv422.
>
> Usefu
On Thu, Jun 10, 2021 at 12:08 PM Diederick C. Niehorster
wrote:
>
> On Thu, Jun 10, 2021 at 11:39 AM Diederick C. Niehorster
> wrote:
> > So in av_opt_get(), I'd do something like this:
> > AVBPrint buf;
> > av_bprint_init(&buf, 0, AV_BPRINT_SIZE_AUTOM
On Tue, Jun 8, 2021 at 1:45 AM Andreas Rheinhardt
wrote:
> This has absolutely nothing to do with full/limited range, but rather
> whether the AVOptionRange contains an interval or a single value.
> (Not that I know why this needs to be set explicitly and not implicitly
> via is_range = value_min
Let me respond on two levels.
Before exploring the design space of a separation of libavdevice and
libavformat below, I think it is important to first comment on the
current state (and whether the AVDevice Capabilities part of my patch
series should be blocked by this discussion).
Importantly, I
On Thu, Jun 10, 2021 at 11:39 AM Diederick C. Niehorster
wrote:
> So in av_opt_get(), I'd do something like this:
> AVBPrint buf;
> av_bprint_init(&buf, 0, AV_BPRINT_SIZE_AUTOMATIC);
> // 1. call internal print function, with &buf
> // ...
> // 2
(NB: I have reorganized your reply a bit to make it for me to respond to)
On Wed, Jun 9, 2021 at 1:54 PM Nicolas George wrote:
>
> The critical part is the API of the new public function, because this we
> cannot fix later.
>
> Unfortunately, to get a good API, you will not be able to reuse the
>
On Wed, Jun 9, 2021 at 8:18 PM Anton Khirnov wrote:
>
> Quoting Diederick C. Niehorster (2021-06-05 16:51:32)
> > On Sat, Jun 5, 2021 at 4:36 PM Anton Khirnov wrote:
> > > Sorry to rain on your parade, but I don't think we should go ahead with
> > > this befo
On Wed, Jun 9, 2021 at 1:20 PM Nicolas George wrote:
> Thanks for explaining. Then "data: int (device-specific)" should be
> enough, if you also document the device-specific value in the user
> documentation of each device.
>
> That means in patch 14, "Documentation of dialog variable:" should be
On Wed, Jun 9, 2021 at 1:15 PM Nicolas George wrote:
>
> What matters is not what you see in the console but what data is really
> written on the stream. Programs that read from the ffmpeg process and
> use the output to build a command line, all in a binary-clean way,
> should succeed.
>
> You ca
On Tue, Jun 8, 2021 at 5:01 PM Michael Niedermayer
wrote:
> On Tue, Jun 08, 2021 at 01:03:56AM +0200, Diederick Niehorster wrote:
> > Enabled discovering a DirectShow device's color range, space, primaries,
> transfer characteristics and chroma location, if the device exposes that
> information.
On Tue, Jun 8, 2021 at 4:32 PM Nicolas George wrote:
>
> Diederick Niehorster (12021-06-08):
> Please wrap this.
Will do.
> > -int av_opt_get(void *obj, const char *name, int search_flags, uint8_t
> > **out_val)
> > +static int print_option(void* dst, enum AVOptionType type, int
> > search_fla
On Tue, Jun 8, 2021 at 2:09 PM Nicolas George wrote:
>
> Diederick Niehorster (12021-06-08):
> > -*caps = av_mallocz(sizeof(**caps));
> > +*caps = av_mallocz(sizeof(AVDeviceCapabilitiesQuery));
>
> var = malloc(sizeof(*var)) is preferred over var = malloc(type), because
> if you change the
On Tue, Jun 8, 2021 at 2:02 PM Nicolas George wrote:
>
> Diederick Niehorster (12021-06-08):
> > +/**
> > + * Request to show configuration dialog.
> > + *
> > + * If device has a configuration dialog of type indicated by
> > + * data, show it.
> > + *
> > + * data: in
On Tue, Jun 8, 2021 at 2:00 PM Nicolas George wrote:
> Maybe wrap the commit message at 60 columns.
Will do
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or emai
On Tue, Jun 8, 2021 at 1:57 PM Nicolas George wrote:
>
> The feature looks useful. But the printing must go to stdout, not to
> logging, because it is meant to be readable by scripts.
Done. Only problem is that now a device of mine that should be called
"Microphone Array (Intel® Smart Sound Tech
On Tue, Jun 8, 2021 at 3:30 PM Michael Niedermayer
wrote:
> On Tue, Jun 08, 2021 at 01:04:05AM +0200, Diederick Niehorster wrote:
>
> brakes build
> CC libavdevice/utils.o
> libavdevice/utils.c:64:29: error: field ‘query_type’ has incomplete type
> enum DshowCapQueryType query_type;
>
didn't have the patchst anymore and already processed comments in later
patches, so 02/35 and 05/35 became out of 33. Noticed that too late. Hope
that doesn't confuse anything. Else we'll get it on -v2 of this series
(which there will certainly be), where i think i'll throttle sending a bit
(someho
FWIW,
On Sat, Jun 5, 2021 at 11:36 PM Diederick C. Niehorster
wrote:
> When implementing the avdevice capabilities API, I have run into three
> things regarding the AVOptionRange fields (libavutil/opt.h, lines
> 310-328)
>
> 1. an enum AVOptionType field "type" should b
On Tue, Jun 8, 2021 at 2:13 AM Valerii Zapodovnikov
wrote:
> Actually I do not know how well will this work. Did you ever play any
> stream? Even if you play it without forcing seeking you are allowed to
> search forth due to how latency works. That problem with latency was only
> fixed in CMAF.
On Tue, Jun 8, 2021 at 1:29 AM Valerii Zapodovnikov
wrote:
> Who knows what BS code "TODO figure out math. For now just drop them."
> means? Is PTS of the mentioned there can be even theoretically valid or
> not?
>
No, I don't know. I am guessing it refers to wraparound? I also don't
understand
On Tue, Jun 8, 2021 at 1:45 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> This has absolutely nothing to do with full/limited range, but rather
> whether the AVOptionRange contains an interval or a single value.
> (Not that I know why this needs to be set explicitly and not impl
On Tue, Jun 8, 2021 at 1:54 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Diederick Niehorster:
> > NB: will break build, makes needed corresponding changes to avformat.
> >
>
> Then said changes should be part of this patch. Patches should be
> logically self-contained and atom
On Tue, Jun 8, 2021 at 1:26 AM James Almer wrote:
> On 6/7/2021 8:04 PM, Diederick Niehorster wrote:
> Instead of removing the struct altogether, just keep its typedef here.
> That way the functions below and any libavformat struct can still use
> AVDeviceCapabilitiesQuery as an incomplete type.
>From a distance, the patch looks like its in the correct format and
everything (generated by git format-patch, right?). Is it against
current HEAD? There may be a conflict
On Mon, Jun 7, 2021 at 8:02 AM Dennis Fleurbaaij
wrote:
>
> Failed to apply, what is the exact way you want the patch?
>
> K
On Sun, Jun 6, 2021 at 6:15 AM Andreas Rheinhardt
wrote:
> Diederick C. Niehorster:
> > See other mails: the bit of documentation in avdevice.h (lines
> > 334--402) suggest the capabilities API is supposed to be used on an
> > unopened device. It would make sense: probe the d
When implementing the avdevice capabilities API, I have run into three
things regarding the AVOptionRange fields (libavutil/opt.h, lines
310-328)
1. an enum AVOptionType field "type" should be added. Else user cannot
know how to interpret the returned value(s), which are all doubles.
NB: for the a
On Sat, Jun 5, 2021 at 2:25 PM Andreas Rheinhardt
wrote:
> Diederick Niehorster:
> > This implements avdevice_capabilities_create and avdevice_capabilities_free
> > for the dshow device.> > +
> > +if (ranges) {
> > +if (query_type == CAP_QUERY_FRAME_SIZE) {
> > +
On Sat, Jun 5, 2021 at 4:36 PM Anton Khirnov wrote:
> Sorry to rain on your parade, but I don't think we should go ahead with
> this before deciding what is to be done with libavdevice. The last
> discussion about it died without being resolved, but the issues are
> still present.
I understand. I
On Sat, Jun 5, 2021 at 2:41 PM Andreas Rheinhardt
wrote:
>
> Have you looked at
> 2ff40b98ecbd9befadddc8fe665a391f99bfca32/0a071f7124beaf0929f772a8618ac1b6c17b0222?
I have, but didn't know what to do with it. Are you suggesting
reverting part of those two commits? The bit of documentation of the
On Sat, Jun 5, 2021 at 8:51 AM Andreas Rheinhardt
wrote:
>
> Diederick Niehorster:
> > +
> > +// since there is no equivalent of avformat_alloc_output_context2 for
> > an input context,
> > +// so we get this dirty code that users shouldn't have to write
> > +fmt_ctx = avformat_al
Fri, Jun 4, 2021 at 2:22 PM Diederick C. Niehorster
wrote:
>
> Hi Nicolas,
>
> On Fri, Jun 4, 2021 at 11:06 AM Nicolas George wrote:
> > I do not understand: you did send them as a large patch series. Twice,
> > by the way, which is confusing.
>
> Yes, the first s
Hi Nicolas,
On Fri, Jun 4, 2021 at 11:06 AM Nicolas George wrote:
> I do not understand: you did send them as a large patch series. Twice,
> by the way, which is confusing.
Yes, the first series got messed up, send it a second time correctly.
I've cleaned up patchwork, it only shows the right on
Hi Nicolas,
On Wed, Jun 2, 2021 at 2:37 PM Nicolas George wrote:
> Excellent. Applications that use the advanced features of libavdevice
> and serve as test beds for these features are sorely needed.
>
> The project has no real system to make engagements about something like
> this, but I can say
1 - 100 of 101 matches
Mail list logo
