> On Nov 9, 2022, at 10:41, 揚帆起航 wrote:
>
> I encountered an error in the files included in this patch when compiling
> Chromium. When I followed this patch to modify the ffmpeg file in the
> Chromium source code, the compilation no longer reported errors.
>
> Chromium regularly merges the lat
I encountered an error in the files included in this patch when compiling
Chromium. When I followed this patch to modify the ffmpeg file in the
Chromium source code, the compilation no longer reported errors.
Chromium regularly merges the latest revisions of ffmpeg through
Cherry-Pick. I also subm
> On Nov 9, 2022, at 03:48, uiopt...@gmail.com wrote:
>
> From: gz83
>
> Cross-compiling Chromium on Ubuntu 22.04 will encounter errors related
> to avformat, because Chromium regularly synchronizes upstream changes,
> so now submit code directly to upstream
> ---
> libavformat/flac_picture.c
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Clément Bœsch
> Sent: Tuesday, November 8, 2022 10:08 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Rework color quantization in
> palette{gen,use}
>
> On Sun, Nov 06, 2022 at
On Sun, Nov 06, 2022 at 08:19:24AM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Sat, Nov 5, 2022 at 2:54 PM Clément Bœsch wrote:
>
> > On Sat, Nov 05, 2022 at 04:44:39PM +0100, Paul B Mahol wrote:
> > [...]
> > > > Finally, I do believe a lot of other color filters could at least
> > benefit
> >
On Sun, Nov 06, 2022 at 06:30:22PM +0100, Michael Niedermayer wrote:
> On Sun, Nov 06, 2022 at 06:09:41PM +0100, Michael Niedermayer wrote:
> > On Sat, Nov 05, 2022 at 04:26:02PM +0100, Clément Bœsch wrote:
> > > Hi,
> > >
> > > This patchset essentially fixes a few core problems in these filters
On Sat, Nov 05, 2022 at 08:07:42PM +0100, Andreas Rheinhardt wrote:
[...]
> You are adding floating point to places where there was no floating
> point before (some other patches of this patchset do the same). Is this
> still bitexact across all supported arches?
> https://patchwork.ffmpeg.org/proj
On Sun, Nov 06, 2022 at 07:46:38PM +, Soft Works wrote:
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Clément Bœsch
> > Sent: Saturday, November 5, 2022 4:26 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: [FFmpeg-devel] Rework color quantization in palette{gen,u
From: gz83
Cross-compiling Chromium on Ubuntu 22.04 will encounter errors related
to avformat, because Chromium regularly synchronizes upstream changes,
so now submit code directly to upstream
---
libavformat/flac_picture.c | 3 ++-
libavformat/matroskadec.c | 10 +-
libavformat/mov.c
On Tue, 8 Nov 2022, James Almer wrote:
Should fix fate failures on Windowx x86 targets, where long is 32 bits.
Signed-off-by: James Almer
---
libavutil/tx_priv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/tx_priv.h b/libavutil/tx_priv.h
index 3195cb51b2..fb611
Should fix fate failures on Windowx x86 targets, where long is 32 bits.
Signed-off-by: James Almer
---
libavutil/tx_priv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/tx_priv.h b/libavutil/tx_priv.h
index 3195cb51b2..fb61119009 100644
--- a/libavutil/tx_priv.h
+
Quoting Nicolas George (2022-11-08 15:15:39)
> Anton Khirnov (12022-11-08):
> > This is false - there are zero demuxers returning EAGAIN due to network
> > blocking.
>
> There are devices who return EAGAIN due to device blocking.
Sure, and that's about it. And as I said before - there is no way t
On 11/8/22, Andreas Rheinhardt wrote:
> Andreas Rheinhardt:
>> postprocess.c currently has C, MMX, MMXEXT, 3DNow as well as
>> SSE2 versions of its internal functions. But given that only
>> ancient 32-bit x86 CPUs don't support SSE2, the MMX, MMXEXT
>> and 3DNow versions are obsolete and are ther
Andreas Rheinhardt:
> postprocess.c currently has C, MMX, MMXEXT, 3DNow as well as
> SSE2 versions of its internal functions. But given that only
> ancient 32-bit x86 CPUs don't support SSE2, the MMX, MMXEXT
> and 3DNow versions are obsolete and are therefore removed by
> this commit. This saves ab
>
> On 08.11.2022 15:25, Eran Kornblau wrote:
> >>
> >> -Original Message-
> >> From: ffmpeg-devel On Behalf Of
> >> Timo Rothenpieler
> >> Sent: Tuesday, 8 November 2022 13:33
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH] libx265: support ATSC A/53
> >> capt
On 08.11.2022 15:25, Eran Kornblau wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of Timo
Rothenpieler
Sent: Tuesday, 8 November 2022 13:33
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] libx265: support ATSC A/53 captions
The attached patch adds rendering o
>
> -Original Message-
> From: ffmpeg-devel On Behalf Of Timo
> Rothenpieler
> Sent: Tuesday, 8 November 2022 13:33
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] libx265: support ATSC A/53 captions
>
> >
> > The attached patch adds rendering of ATSC A/53 captions a
Anton Khirnov (12022-11-08):
> This is false - there are zero demuxers returning EAGAIN due to network
> blocking.
There are devices who return EAGAIN due to device blocking.
> So there really is no meaningful difference between REDO and EAGAIN.
There is a difference: REDO is internal, EAGAIN is
Quoting Nicolas George (2022-11-08 13:54:53)
> Anton Khirnov (12022-11-08):
> > There is no meaningful distinction between them, both mean "the demuxer
> > did some work, but did not produce a packet - should be called again".
>
> NAK, there a difference in semantics: AVEROR(EAGAIN) is for when da
On 24 Sep 2022, at 23:09, Marvin Scholz wrote:
> Add DISABLEDINSTHEADERS, a variable containing the headers of disabled
> libraries. This is needed so that Doxygen does not generate incomplete
> documentation when a component is disabled, which is quite unexpected
> behaviour and results in warnin
From: Niklas Haas
Instead of doing it ad-hoc in `filter_frame`. This is not a huge change
on its own, but paves the way for adding support for more formats in the
future, in particular formats other than AV_PIX_FMT_VULKAN.
---
libavfilter/vf_libplacebo.c | 35 ---
From: Niklas Haas
This is done only to the inputs, not the outputs, because we always
output vulkan hwframes.
Doing so also requires keeping track of backing textures for non-hwdec
formats, but is otherwise a mostly straightforward change to the format
query function. Special care needs to be ta
Anton Khirnov (12022-11-08):
> There is no meaningful distinction between them, both mean "the demuxer
> did some work, but did not produce a packet - should be called again".
NAK, there a difference in semantics: AVEROR(EAGAIN) is for when data is
not available for external reasons, typically net
Quoting Michael Niedermayer (2022-10-18 23:51:22)
> On Tue, Oct 18, 2022 at 02:36:55PM +0200, Anton Khirnov wrote:
> > It does the same thing as the block right below it.
> > ---
> > fftools/ffmpeg_mux_init.c | 10 --
> > 1 file changed, 10 deletions(-)
>
> This seems to make a difference
On Mon, 2022-09-19 at 14:08 +0800, Fei Wang wrote:
> On Wed, 2022-09-07 at 22:56 +0100, Mark Thompson wrote:
> > On 23/08/2022 09:19, Fei Wang wrote:
> > > From: Linjie Fu
> > >
> > > Add HWACCEL_CAP_INTERNAL_ALLOC flag to indicate hwaccels are able
> > > to
> > > re-allocate surface internally t
This can fix vp9 decode image corruption when the frame size is change,
but the pervious frames still be referenced.
Surfaces don't need to be bound to vaContext only after VAAPI 1.0.0:
https://github.com/intel/libva/commit/492b692005ccd0d8da190209d5b3ae7b7825f4b8
Signed-off-by: Fei Wang
---
li
The capacity can avoid hwaccel being uninited when do the reset. It
provides the method for hwaccel if it still want to use the previous
initialized configuration after reset. And the configuration can be
updated in AVHWAccel.init() if needed.
For example, when use vaapi vp9 decode dynamic resolut
On 08.11.2022 07:49, Eran Kornblau wrote:
Trying again…
From: Eran Kornblau
Sent: Monday, 17 October 2022 19:29
To: FFmpeg development discussions and patches
mailto:ffmpeg-devel@ffmpeg.org>>
Subject: [PATCH] libx265: support ATSC A/53 captions
Hi,
The attached patch adds rendering of ATSC A/
Lavf only supports a very limited approximation of non-blocking
behavior, so we should not return random EAGAINs to callers unless they
specifically requested it.
---
libavformat/demux.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavformat/demux.c b/libavformat/d
There is no meaningful distinction between them, both mean "the demuxer
did some work, but did not produce a packet - should be called again".
---
libavformat/demux.c | 12
libavformat/demux.h | 6 --
libavformat/flvdec.c | 14 +++---
libavformat/lxfdec.c | 2 +-
l
This is pointless now that demuxing always runs in a separate thread.
Remove special handling for AVERROR(EAGAIN), which should never be
returned now.
---
fftools/ffmpeg_demux.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c
index ee867cc1
Makes sure EAGAIN from the internal ASF demuxer is propagated to the RTP
demuxer. Will be important in following commits.
---
libavformat/rtpdec_asf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/rtpdec_asf.c b/libavformat/rtpdec_asf.c
index 72ead6975a..7824082d22 100644
--- a/l
---
fftools/ffmpeg_demux.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c
index 8ea5318148..b32bac217d 100644
--- a/fftools/ffmpeg_demux.c
+++ b/fftools/ffmpeg_demux.c
@@ -363,8 +363,9 @@ static int thread_start(Demuxer *d)
Thanks for all your replies!
Now I can refer to this, when being asked "Why CRC and not ...?" :)
Kind regards,
Peter
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link ab
34 matches
Mail list logo
