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
@@
> 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
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
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:
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.
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
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".
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,
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
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
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
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
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®
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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 |
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
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
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
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
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
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
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
+++
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
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
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
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(-)
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
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
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
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
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
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
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
+++
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
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
---
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
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
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
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
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:
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
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
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
> -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
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
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
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
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
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.
>
>
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
+++
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, 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
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
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
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
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
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
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
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
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
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
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
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
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;
> +
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
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
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
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
> 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
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月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:
>
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
>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?
>
>
This reverts commit d6d407d2d758b404af0ce6a8ff46bf164db020a1.
Hack not needed after a2b1dd0ce301450a47c972745a6b33c4c273aa5d.
Will fix #7480 and #8904.
This will include e.g. CODECS="hvc1.2.4.L123.B0" into m3u8.
Signed-off-by: Valerii Zapodovnikov
---
libavformat/dashenc.c | 6 +-
1 file
Failed to apply, what is the exact way you want the patch?
Kind regards,
Dennis Fleurbaaij
+31 (0) 6 54 21 5365
On Sat, Jun 5, 2021 at 6:12 PM Valerii Zapodovnikov
wrote:
> That did work, cool.
>
>
88 matches
Mail list logo
