In my case
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210607063205.180031-1-val.zapod...@gmail.com/
v1 failed to apply due to
https://github.com/FFmpeg/FFmpeg/commit/575e52272d42f4278c6620f1a999c41425db2094
I suppose in your case it is
https://github.com/FFmpeg/FFmpeg/commit/8bcce5673a267
> 2021年5月31日 下午3:16，Steven Liu 写道：
>
> fix problem when set x to odd number in nv12 by cuda,
>
> test step:
> 1. ffmpeg -f lavfi testsrc2=s=176x144 -pix_fmt nv12 -t 1 output_overlay.yuv
> 1. ffmpeg -f lavfi testsrc2=s=352x288 -pix_fmt nv12 -t 1 output_main.yuv
> before this patch:
> overlay_cu
So I am resending still with that comment and a typo fixed to "ffplay". I
also found this:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20180501194013.9552-8-one...@gmail.com/
It way be nice to apply that too, but then again my problem is not that.
> 2021年5月28日 下午9:36，Steven Liu 写道：
>
> Signed-off-by: Steven Liu
> ---
> doc/examples/muxing.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/doc/examples/muxing.c b/doc/examples/muxing.c
> index fe1b9ded21..3986561b2f 100644
> --- a/doc/examples/muxing.c
>
Signed-off-by: Valerii Zapodovnikov
---
fftools/ffplay.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 0be1d90bf9..53bd9362fa 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -963,12 +963,12 @@ static void set_sdl_yuv_co
Do you know what command to use with
http://fate-suite.ffmpeg.org/dolby_e/16-11.pcm? I used -ac 6, but I dunno
everything else I used was not giving perfect sound (-f s16le -ac 6 was
most important to at least get something playable). Sigh. Also I suppose
sample rate will not be 48000 since it is
Pulled master and re-applied to resolve version update conflict
Kind regards,
Dennis Fleurbaaij
From b5fff34f545a107e07c9390a983e3a9aadb71a1c Mon Sep 17 00:00:00 2001
From: Dennis Fleurbaaij
Date: Mon, 7 Jun 2021 12:06:51 +0200
Subject: [PATCH] libavcodec: r12b decoder added
R12B is a format use
Missed this one, will give it a test.
Looks good to me so far.
smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link abo
Dennis Fleurbaaij:
> Pulled master and re-applied to resolve version update conflict
>
> Kind regards,
> Dennis Fleurbaaij
>
>
>
> +if (avctx->width % PIXELS_PER_BLOCK != 0) {
> +av_log(avctx, AV_LOG_ERROR, "image width not modulo 8\n");
> +return AVERROR_INVALIDDATA;
> +
Signed-off-by: James Almer
---
fftools/ffmpeg.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 04ddc9e60b..e97d879cb3 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2962,7 +2962,9 @@ static int init_input_stream(int ist_index, char *error
James Almer:
> On 5/21/2021 6:17 AM, Andreas Rheinhardt wrote:
>> Its documentation described the way user-supplied buffers worked
>> before 93016f5d1d280f9cb7856883af287fa66affc04c.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavcodec/internal.h | 16 ++--
>> 1 file changed
Michael Niedermayer:
> On Fri, May 21, 2021 at 11:17:34AM +0200, Andreas Rheinhardt wrote:
>> Up until now, ff_alloc_packet2() has a min_size parameter:
>> It is supposed to be a lower bound on the final size of the packet
>> to allocate. If it is not too far from the upper bound (namely,
>> if it
HDR10+ metadata is stored in the bit stream for HEVC. The story is different
for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
passed to packet side data an stored in the container (mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing
On Wed, Jun 2, 2021 at 1:31 PM James Zern
wrote:
> On Tue, Jun 1, 2021 at 6:47 PM Mohammad Izadi
> wrote:
> > [...]
> > +static av_cold int add_hdr10_plus(AVFifoBuffer *fifo, struct
> FrameHDR10Plus *data)
> > +{
> > +int err = av_fifo_grow(fifo, sizeof(FrameHDR10Plus));
>
> Prefer sizeof(va
Mohammad Izadi:
> HDR10+ metadata is stored in the bit stream for HEVC. The story is different
> for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
> passed to packet side data an stored in the container (mkv) for VP9.
>
> This CL is taking HDR10+ from AVFrame side data in
Soft Works (12021-06-05):
> And I agree to that disagreement. Also we shouldn't start acting as if
> the nonfree category wouldn't exist at all and everything that would
> fall into that category would suddenly no longer be acceptable.
This is exactly what we should do. We should not have accepted
Anton Khirnov (12021-06-05):
> 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.
So, now we have somebody who wants to w
From: zheng qian
Writes a general ARIB stream identifier descriptor, as well
as a data component descriptor which also includes a
pre-defined additional_arib_caption_info structure.
Signed-off-by: zheng qian
---
libavformat/mpegtsenc.c | 48 +
1 file cha
On Wed, Jun 2, 2021 at 1:34 PM James Zern
wrote:
> On Tue, Jun 1, 2021 at 6:23 PM Mohammad Izadi
> wrote:
> >
> > On Fri, May 28, 2021 at 4:49 AM Michael Niedermayer
>
> > wrote:
> >
> > > On Thu, May 27, 2021 at 09:44:10AM -0700, Mohammad Izadi wrote:
> > > > HDR10+ metadata is stored in the b
On Mon, Jun 7, 2021 at 8:09 PM Jan Ekström wrote:
>
> From: zheng qian
>
> Writes a general ARIB stream identifier descriptor, as well
> as a data component descriptor which also includes a
> pre-defined additional_arib_caption_info structure.
>
> Signed-off-by: zheng qian
> ---
For the record,
On Mon, Jun 7, 2021 at 9:51 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Mohammad Izadi:
> > HDR10+ metadata is stored in the bit stream for HEVC. The story is
> different for VP9 and cannot store the metadata in the bit stream. HDR10+
> should be passed to packet side data an
HDR10+ metadata is stored in the bit stream for HEVC. The story is different
for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
passed to packet side data an stored in the container (mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing
On Mon, 7 Jun 2021, Valerii Zapodovnikov wrote:
Signed-off-by: Valerii Zapodovnikov
---
fftools/ffplay.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 0be1d90bf9..53bd9362fa 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffpla
On Mon, Jun 07, 2021 at 10:39:19AM -0700, Mohammad Izadi wrote:
> HDR10+ metadata is stored in the bit stream for HEVC. The story is different
> for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
> passed to packet side data an stored in the container (mkv) for VP9.
>
> Th
Michael Niedermayer:
> On Mon, Jun 07, 2021 at 10:39:19AM -0700, Mohammad Izadi wrote:
>> HDR10+ metadata is stored in the bit stream for HEVC. The story is different
>> for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
>> passed to packet side data an stored in the contai
Thanks for the review Andreas!
I've addressed all your concerns besides the "& in the define", I didn't
know that the binary AND is implicit in this situation, any link for this?
Even if it is, I just find it much more pleasing to see the & there
somehow, is there some leniency for personal prefer
Dennis Fleurbaaij:
> Thanks for the review Andreas!
>
> I've addressed all your concerns besides the "& in the define", I didn't
> know that the binary AND is implicit in this situation, any link for this?
> Even if it is, I just find it much more pleasing to see the & there
> somehow, is there so
I cannot clarify it further, the issue is there on trac.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsub
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Nicolas George
> Sent: Monday, June 7, 2021 6:57 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH]avfilter: add Intel IPP library based x86
> optimized video scaling filte
Hi,
On Sun, Jun 6, 2021 at 10:42 PM James Almer wrote:
> From: Matthieu Patou
>
> The function name iszero() may collide with a function in glibc.
>
> Suggested-by: ffm...@fb.com
> Signed-off-by: James Almer
> ---
> tests/checkasm/vp9dsp.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 dele
On Mon, 7 Jun 2021, Valerii Zapodovnikov wrote:
I cannot clarify it further, the issue is there on trac.
And that ticket is bogus, because comparison is made between 4:2:0 and
4:4:4. And when the reporter says the colors are muddy, he means the pixel
format diffrerence, not the color spac
You are **very** wrong. This is YCbCr 101: 420 has all the same colors as
444 does. Just if one pixel is fixated the entagled pixels have less than
all possible colors. This is also not corners issues, it is reproducable on
one color all over the plane. Again, the workaround is to use ffplay -vf
s
On Mon, Jun 7, 2021 at 11:44 PM Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Nicolas George
> > Sent: Monday, June 7, 2021 6:57 PM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH]avfilter: a
On Tue, 8 Jun 2021, Valerii Zapodovnikov wrote:
You are **very** wrong. This is YCbCr 101: 420 has all the same colors as
444 does. Just if one pixel is fixated the entagled pixels have less than
all possible colors. This is also not corners issues, it is reproducable on
one color all over th
Enabled discovering a DirectShow device's color range, space, primaries,
transfer characteristics and chroma location, if the device exposes that
information. Sets them in the stream's codecpars.
Signed-off-by: Diederick Niehorster
Co-authored-by: Valerii Zapodovnikov
---
libavdevice/dshow.c
Some DirectShow devices (Logitech C920 webcam) expose each DirectShow format
they support twice, once without and once with extended color information.
During format selection, both match, this patch ensures that the format with
extended color information is selected if it is available, else it
This reverts commit 4f49ca7bbc75a9db4cdf93f27f95a668c751f160. This patch series
will implement this capability for avdevice/dshow, enabling configuration
discovery of DirectShow devices through the API, which is important for my use
case. It enables making proper GUIs presenting users with optio
Draw implementation in line with that of avdevice_list_devices
Signed-off-by: Diederick Niehorster
---
libavdevice/avdevice.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/libavdevice/avdevice.c b/libavdevice/avdevice.c
index 695b9143af..d73d36e1dd 100644
--- a/lib
NB: will break build, makes needed corresponding changes to avformat.
Signed-off-by: Diederick Niehorster
---
libavdevice/avdevice.c | 34 --
libavdevice/avdevice.h | 42 +-
libavdevice/internal.h | 33 ++
Signed-off-by: Diederick Niehorster
---
libavformat/avformat.h | 9 -
libavformat/version.h | 2 +-
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 6fd09f52cb..12197465bc 100644
--- a/libavformat/avformat.h
+++ b/libavf
Signed-off-by: Diederick Niehorster
---
libavformat/avformat.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 12197465bc..5e1e82a315 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -530,6 +530,7 @@ typedef str
When querying a range of formats of an avdevice, sometimes for a given format
the queried option is not available. This is not an error as the user is asking
for a valid capability, it just doesn't always apply to all the matching
formats of the device. This is now communicated through a special
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. Useful
when printing more info about an option than just its value. Usage wi
Signed-off-by: Diederick Niehorster
---
libavdevice/internal.h | 31 +++
libavdevice/utils.c| 48 ++
libavdevice/version.h | 2 +-
3 files changed, 80 insertions(+), 1 deletion(-)
diff --git a/libavdevice/internal.h b/libavdev
Needs to be moved up in file for upcoming implementation of
avdevice_capabilities_create.
Signed-off-by: Diederick Niehorster
---
libavdevice/dshow.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/libavdevice/dshow.c b/libavdevice/
After the avdevice capabilities API is implemented, the format context may be
reused after querying device capabilities in a later avformat_open_input call.
To enable this reuse, after releasing resources, make sure to also set the
corresponding pointers back to NULL. This correctly indicates th
This implements avdevice_capabilities_create for the dshow device
(avdevice_capabilities_free not needed as it would be no-op).
Signed-off-by: Diederick Niehorster
---
libavdevice/dshow.c | 384 +---
1 file changed, 365 insertions(+), 19 deletions(-)
dif
Signed-off-by: Diederick Niehorster
---
libavdevice/dshow.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index 082ae5f26c..c158a536d8 100644
--- a/libavdevice/dshow.c
+++ b/libavdevice/dshow.c
@@ -940,6 +940,
avformat_alloc_input_context function analogous to
avformat_alloc_output_context2, except that it does not take a filename
argument as guessing the format by just the filename does not make sense.
avformat_alloc_input_context can be used e.g. with the avdevice capabilities
API, which needs an a
Signed-off-by: Diederick Niehorster
---
configure | 2 +
doc/examples/.gitignore| 1 +
doc/examples/Makefile | 1 +
doc/examples/Makefile.example | 1 +
doc/examples/device_get_capabilities.c | 192
Signed-off-by: Diederick Niehorster
---
doc/examples/Makefile | 48 +--
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/doc/examples/Makefile b/doc/examples/Makefile
index de707bb3ca..7988ed4226 100644
--- a/doc/examples/Makefile
+++ b/doc/e
list_options true would crash when both a video and an audio device were
specified as input. Crash would occur on line 1618 (in this new rev) because
ctx->device_unique_name[otherDevType] would be NULL
Signed-off-by: Diederick Niehorster
---
libavdevice/dshow.c | 6 --
1 file changed, 4 in
While the capabilities API is in principle meant to be used with an allocated
format context belonging to an unopened device, small changes make it work for
an opened dshow device as well. So hereby done.
Signed-off-by: Diederick Niehorster
---
libavdevice/dshow.c | 36 +++-
Signed-off-by: Diederick Niehorster
---
doc/indevs.texi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/doc/indevs.texi b/doc/indevs.texi
index b377924c2f..685b1357a6 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -611,6 +611,12 @@ Save the currently used video capture filter dev
avdevice/dshow is a realtime device and as such does not support seeking.
Therefore, its demuxer format should define the AVFMT_NOBINSEARCH,
AVFMT_NOGENSEARCH and AVFMT_NO_BYTE_SEEK flags.
With these flags set, attempting to seek (with e.g. avformat_seek_file())
correctly yields -1 (operation no
Needed to enable programmatic discovery of DirectShow devices
Signed-off-by: Diederick Niehorster
---
libavdevice/dshow.c | 80 +
1 file changed, 73 insertions(+), 7 deletions(-)
diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index 389daa6380.
The list returned by get_device_list now contains info about what media
type(s), if any, can be provided by each device.
Signed-off-by: Diederick Niehorster
---
libavdevice/dshow.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index 5d7f065
GetTime may return an error indication that the sample has not timestamps, or
may return a NULL start time. In those cases, fall back to graph time
better debug message in case sample dropped: could now be audio or video frame
Signed-off-by: Diederick Niehorster
---
libavdevice/dshow_pin.c | 19
the list_devices option of dshow didn't indicate whether a specific device
provides audio or video output. This patch iterates through all media formats
of all pins exposed by the device to see what types it provides for capture,
and prints this to the console for each device. Importantly, this
The dshow plugin ignores timestamps for video frames provided by the DirectShow
device, instead using wallclock time, apparently because the implementer of
this code had a device that provided unreliable timestamps. Me (and others)
would like to use the device's timestamps. The new use_video_dev
Cleanup in case the show_analog_tv_tuner_audio_dialog was set was missing.
Signed-off-by: Diederick Niehorster
---
libavdevice/dshow_crossbar.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavdevice/dshow_crossbar.c b/libavdevice/dshow_crossbar.c
index 2438683cde..961defe690 100644
DirectShow source will pop up its configuration dialog when
AV_APP_TO_DEV_CONFIG is received. Implementation for several other possible
configuration dialogs is more involved and will be provided in the next commit.
Signed-off-by: Diederick Niehorster
---
libavdevice/dshow.c | 26 +
This patch series implements a series of features, mostly enhancing the
dshow avdevice, but also adding new functionality to avformat and
avutil. This whole patchset enabled users of the FFmpeg API to fully
query and control a dshow device, making FFmpeg a nice backend for any
program that needs ac
This control message can be used to programmatically ask a device to show its
configuration dialog.
Bumping avdevice version.
Signed-off-by: Diederick Niehorster
---
libavdevice/avdevice.h | 10 ++
libavdevice/version.h | 2 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --
Control messages are useful for programmatic control of not only outdevs but
also indevs.
Bumping avformat version.
Signed-off-by: Diederick Niehorster
---
libavdevice/avdevice.c | 8 +---
libavformat/avformat.h | 6 ++
libavformat/version.h | 4 ++--
3 files changed, 13 insertions(+),
An avdevice, regardless of whether its category says its an audio or video
device, may provide access to devices providing different media types, or even
single devices providing multiple media types. Also, some devices may provide
no media types. dshow is an example encompassing all of these ca
No need to query twice, use value we've already unconditionally got. Improve
variable names
Signed-off-by: Diederick Niehorster
---
libavdevice/dshow_pin.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/libavdevice/dshow_pin.c b/libavdevice/
This allows programmatic users of avdevice to start and stop the DirectShow
Capture graph (i.e. receive frames or not). This is important because now the
buffer fills up and starts dropping samples when enqueued packets are not read
out immediately after the demuxer is opened.
Signed-off-by: Di
Can you merge my mxfdec patch? Thank you. Maybe all my oldest patches too,
except XYZ patch to libopenjpeg, that is WIP, since openjpeg did not even
merge yet or did a release to support that wrapper option.
Listen, it is commonly known that ffplay is broken, Carl agrees. MPV is not
broken and is
The "show config dialog" command message can now also trigger dialog boxes for
the crossbar connecting pins filter the analog tuner audio / analog tuner
filters. _Untested_ as I do not have either device.
Signed-off-by: Diederick Niehorster
---
libavdevice/dshow.c | 52 +++
On 6/7/2021 8:04 PM, Diederick Niehorster wrote:
NB: will break build, makes needed corresponding changes to avformat.
Signed-off-by: Diederick Niehorster
---
libavdevice/avdevice.c | 34 --
libavdevice/avdevice.h | 42 +
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?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To
fftools now print info about what media type(s), if any, are provided by sink
and source avdevices. Furthermore, printing is done with av_log instead of
printf as the latter doesn't handle characters in some device names correctly
(e.g. "Microphone Array (Intel® Smart Sound Technology (Intel® SS
Actually it is commonly understood all over the world that limited range is
the default when not present. All video in the world except Dolby Vision
profile 5 (if using IPTPQc2) is limited range.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https
On Tue, Jun 8, 2021 at 2:28 AM Jan Ekström wrote:
>
> On Mon, Jun 7, 2021 at 8:09 PM Jan Ekström wrote:
> >
> > From: zheng qian
> >
> > Writes a general ARIB stream identifier descriptor, as well
> > as a data component descriptor which also includes a
> > pre-defined additional_arib_caption_in
Valerii Zapodovnikov:
> Actually it is commonly understood all over the world that limited range is
> the default when not present. All video in the world except Dolby Vision
> profile 5 (if using IPTPQc2) is limited range.
This has absolutely nothing to do with full/limited range, but rather
whet
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 atomic; this is not the same as splitting
by file/library.
But that is a moot point: James already told y
Von meinem iPhone gesendet
> Am 07.06.2021 um 12:09 schrieb Dennis Fleurbaaij :
>
> Pulled master and re-applied to resolve version update conflict
> R12B is a format used by BlackMagic DeckLink cards
How does the card produce avi files / why are you adding a fourcc?
Please elaborate, Carl
Ah, yes, that is AVColorRange, sorry. :( Haha.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
James Almer:
> On 6/7/2021 8:04 PM, Diederick Niehorster wrote:
>> NB: will break build, makes needed corresponding changes to avformat.
>>
>> Signed-off-by: Diederick Niehorster
>> ---
>> libavdevice/avdevice.c | 34 --
>> libavdevice/avdevice.h | 42 +--
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. ONE must to accelerate decoding forward in time to get low
latency.
I'll just chime in and say:
FIXME comments aren't that helpful. It would be more helpful to av_log when
you detect you've hit an unsupported situation.
As for SMPTE 240M vs BT.601 Y'CbCr matrices: yes, they're different. But
SDL doesn't support SMPTE 240M. It only supports:
SDL_YUV_CONVERSION_JP
On Mon, 7 Jun 2021, at 23:49, Jan Ekström wrote:
> If you just go without any rhetoric and just look at what "nonfree"
>
> We can start with the history of the option - originally added in
> 3fe142e2555ec8b527f2ff4cc517c015a114e91a (Jan, 2008) - to denote that
> due to the libamrnb/libamrwb wrappe
> Apr 29, 2021, 03:52 by d...@lynne.ee:
>
> > This patch allows for alternative loader implementations.
> >
> > Patch attached.
> >
>
> Forgot to fix a flag, v2 attached.
Hi Lynne:
I tried the following command:
"ffmpeg -init_hw_device vulkan=vul:0 -filter_hw_device vul -i 1080p.264 -vf
"hwuplo
Binutils 2.36 no longer supports bundling args with the preprocessor
option.
---
ffbuild/common.mak | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ffbuild/common.mak b/ffbuild/common.mak
index 32f5b997b5..9fbbf89130 100644
--- a/ffbuild/common.mak
+++ b/ffbuild/common.mak
@@ -
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.
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
Signed-off-by: Steven Liu
---
libavfilter/vf_overlay_cuda.c | 129 +++---
1 file changed, 120 insertions(+), 9 deletions(-)
diff --git a/libavfilter/vf_overlay_cuda.c b/libavfilter/vf_overlay_cuda.c
index 8a4d2c4312..9980b0137e 100644
--- a/libavfilter/vf_overlay_cuda
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: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 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.
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 be added. Else user cannot
92 matches
Mail list logo
