From: Aman Karmani
deinterlaces CVPixelBuffers, i.e. AV_PIX_FMT_VIDEOTOOLBOX frames
for example, an interlaced mpeg2 file can be decoded by avcodec,
uploaded into a CVPixelBuffer, deinterlaced by metal, and then
encoded to h264 by VideoToolbox as follows:
ffmpeg \
-init_hw_device
Improves readability and slightly decreases codesize.
While just at it, also remove a check whether the packet list is
nonempty before freeing it, as freeing an empty list is fine
and basically a no-op.
Signed-off-by: Andreas Rheinhardt
---
libavformat/movenc.c | 36 ++---
Up until now, we had a PacketList structure which is actually
a PacketListEntry; a proper PacketList did not exist
and all the related functions just passed pointers to pointers
to the head and tail elements around. All these pointers were
actually consecutive elements of their containing structs,
This removes the last usage of sizeof(AVPacket) in the generic
muxing code.
Signed-off-by: Andreas Rheinhardt
---
libavformat/mux.c| 8 +---
libavformat/mxfenc.c | 8 ++--
2 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index b9c4
The packet given to muxers is not used afterwards; it is always
unreferenced by libavformat. Ergo muxers are allowed to keep
the references in the packets and e.g. move the ownership to
a packet list. This is what this commit does.
Signed-off-by: Andreas Rheinhardt
---
libavformat/aiffenc.c | 2
On Wed, Dec 15, 2021 at 06:37:13PM +0100, Michael Niedermayer wrote:
> Fixes: division by zero
> Fixes:
> 42198/clusterfuzz-testcase-minimized-ffmpeg_dem_MV_fuzzer-5054366405492736.fuzz
> Fixes:
> 4/clusterfuzz-testcase-minimized-ffmpeg_dem_MV_fuzzer-4561249331970048
>
> Found-by: continuous
On Wed, Dec 15, 2021 at 8:15 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
>
> Gerard Sole:
> > Adds support for concat demuxer to copy the side data information
> > from the input file to the resulting file. It will behave like the
> > metadata copy, where the metadata of the firs
On 12/15/2021 6:35 AM, Alan Kelly wrote:
Fixes so that fate under 64 bit Windows passes.
These functions replace all ff_hscale8to15_*_ssse3 when avx2 is available.
---
libswscale/swscale_internal.h | 2 +
libswscale/utils.c| 37 +++
libswscale/x86/Makefile | 1
On 12/15/2021 7:55 PM, Marton Balint wrote:
On Wed, 15 Dec 2021, James Almer wrote:
On 12/15/2021 6:32 PM, Marton Balint wrote:
On Wed, 15 Dec 2021, James Almer wrote:
On 12/15/2021 7:24 AM, Marton Balint wrote:
On Tue, 14 Dec 2021, James Almer wrote:
On 12/14/2021 3:54
On Wed, 15 Dec 2021, James Almer wrote:
On 12/15/2021 6:32 PM, Marton Balint wrote:
On Wed, 15 Dec 2021, James Almer wrote:
On 12/15/2021 7:24 AM, Marton Balint wrote:
On Tue, 14 Dec 2021, James Almer wrote:
On 12/14/2021 3:54 PM, Nicolas George wrote:
James Almer (1202
15 Dec 2021, 22:32 by ffm...@haasn.xyz:
> From: Niklas Haas
>
> This was renamed upstream quite a while ago (v3.112.0). Rename the
> option name as well for consistency (and expand the description just
> slightly).
>
> Signed-off-by: Niklas Haas
> ---
> libavfilter/vf_libplacebo.c | 6 +++---
>
On Thu, Nov 25, 2021 at 06:03:18PM +0100, Michael Niedermayer wrote:
> On Thu, Nov 25, 2021 at 10:51:15AM +0530, Gyan Doshi wrote:
> >
> >
> > On 2021-11-25 12:56 am, Michael Niedermayer wrote:
> > > On Wed, Nov 24, 2021 at 10:58:00AM +0530, Gyan Doshi wrote:
> > > >
> > > > On 2021-11-24 01:16
On 12/15/2021 6:32 PM, Marton Balint wrote:
On Wed, 15 Dec 2021, James Almer wrote:
On 12/15/2021 7:24 AM, Marton Balint wrote:
On Tue, 14 Dec 2021, James Almer wrote:
On 12/14/2021 3:54 PM, Nicolas George wrote:
James Almer (12021-12-14):
We add a const uint8_t* field to AVCh
On 12/15/2021 6:05 AM, Alan Kelly wrote:
On Tue, Dec 14, 2021 at 6:07 PM James Almer wrote:
On 12/14/2021 12:23 PM, Alan Kelly wrote:
Patch has been rebased from latest commits.
These functions replace all ff_hscale8to15_*_ssse3 when avx2 is
available.
---
libswscale/swscale_internal.
On Wed, 15 Dec 2021, James Almer wrote:
On 12/15/2021 7:24 AM, Marton Balint wrote:
On Tue, 14 Dec 2021, James Almer wrote:
On 12/14/2021 3:54 PM, Nicolas George wrote:
James Almer (12021-12-14):
We add a const uint8_t* field to AVChannelCustom. If the user wants to
allocate t
From: Niklas Haas
This was renamed upstream quite a while ago (v3.112.0). Rename the
option name as well for consistency (and expand the description just
slightly).
Signed-off-by: Niklas Haas
---
libavfilter/vf_libplacebo.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --gi
15 Dec 2021, 21:47 by ffm...@haasn.xyz:
> From: Niklas Haas
>
> This was renamed upstream quite a while ago (v3.112.0). Keep the old
> option name in libavfilter for backwards compatibility.
>
> Signed-off-by: Niklas Haas
> ---
> libavfilter/vf_libplacebo.c | 2 +-
> 1 file changed, 1 insertion
From: Niklas Haas
This was renamed upstream quite a while ago (v3.112.0). Keep the old
option name in libavfilter for backwards compatibility.
Signed-off-by: Niklas Haas
---
libavfilter/vf_libplacebo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_libplaceb
On Wed, Dec 15, 2021 at 12:20 PM Anton Khirnov wrote:
>
> Quoting Pierre-Anthony Lemieux (2021-12-15 01:17:26)
> > >
> > > Now the question is whether a malicious attacker can craft those two
> > > files to get access to anything they shouldn't. I suppose at the very
> > > least the attacker can g
Quoting Pierre-Anthony Lemieux (2021-12-15 01:17:26)
> >
> > Now the question is whether a malicious attacker can craft those two
> > files to get access to anything they shouldn't. I suppose at the very
> > least the attacker can get information that the user opened the file (by
> > adding an asse
Quoting Paul B Mahol (2021-12-15 10:32:26)
> Signed-off-by: Paul B Mahol
> ---
>
> Fixed decoding of https://0x0.st/-F5w.cdg
>
> ---
> libavcodec/cdgraphics.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Please add a test.
--
Anton Khirnov
_
Quoting Michael Niedermayer (2021-12-14 22:13:43)
> On Mon, Dec 13, 2021 at 04:20:41PM +0100, Anton Khirnov wrote:
> > It features in limiting the number of output frames (-frames option) and
> > currently can be incremented from two places:
> > - for video encoding (not streamcopy), in do_video_ou
Gerard Sole:
> Adds support for concat demuxer to copy the side data information
> from the input file to the resulting file. It will behave like the
> metadata copy, where the metadata of the first file is kept in the
> the output file.
>
> Extract the current code that already performs the strea
Gerard Sole (12021-12-15):
> Adds support for concat demuxer to copy the side data information
> from the input file to the resulting file. It will behave like the
> metadata copy, where the metadata of the first file is kept in the
> the output file.
>
> Extract the current code that already perf
Adds support for concat demuxer to copy the side data information
from the input file to the resulting file. It will behave like the
metadata copy, where the metadata of the first file is kept in the
the output file.
Extract the current code that already performs the stream side_data
copy into a s
On Wed, Dec 15, 2021 at 02:06:46PM +0800, Shiyou Yin wrote:
>
>
> > 2021年12月15日 上午11:51，Hao Chen 写道：
> >
> > ./ffmpeg -i 1_h264_1080p_30fps_3Mbps.mp4 -f rawvideo -y /dev/null -an
> > before: 170fps
> > after : 296fps
> >
> > V2: Update loongson_intrinsics.h to 1.0.3 in patch 2/7.
> > V3: Resub
Fixes: division by zero
Fixes:
42198/clusterfuzz-testcase-minimized-ffmpeg_dem_MV_fuzzer-5054366405492736.fuzz
Fixes:
4/clusterfuzz-testcase-minimized-ffmpeg_dem_MV_fuzzer-4561249331970048
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Si
Fixes: Timeout
Fixes:
42072/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PRORES_fuzzer-4957999452520448
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 1 +
1 file change
Andreas Rheinhardt:
> Should fix Coverity tickets #1473572 and #1473504.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/speedhq.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/speedhq.c b/libavcodec/speedhq.c
> index 91ba80ebd3..743dacc6ce 10064
Andreas Rheinhardt:
> Forgotten in 03b82b3ab9883cef017e513c7d0b3b986b3b3e7b.
>
> (Moving data to the front is only done to make existing
> initializations like H2645NAL nal = { NULL } not emit int->pointer
> conversion warnings.)
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/h2645_pa
Forgotten in 136865413c04760aeeda6079002bc3c1f9ae230a.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/tests/.gitignore | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/tests/.gitignore b/libavcodec/tests/.gitignore
index 69bf891f44..2acfc4e804 100644
--- a/libavco
They test libavfilter internal API, so they should be libavfilter
test programs (which implies: linked statically to libavfilter
to access internal APIs and linked normally (statically or dynamically
depending upon the build configuration) against all the other libs).
Right now, they are always li
On Wed, Dec 15, 2021 at 04:08:43PM +0100, Diederick C. Niehorster wrote:
> 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 Mi
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:
> > >
> > >
> > > The patches do not say in their commit mess
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:
> >
> > 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 Mi
On Tue, Dec 14, 2021 at 10:31:40PM +, Soft Works wrote:
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of Michael
> > Niedermayer
> > Sent: Tuesday, December 14, 2021 10:40 PM
> > To: FFmpeg development discussions and patches
> > Subject: Re: [FFmpeg-devel] [PATCH] MAI
On 12/15/2021 11:33 AM, Hendrik Leppkes wrote:
> Any more comments on this set? LGTM now, but others have also had
> comments before.
> I would prefer if this gets in soon before 5.0, so user-apps can start
> making use of this data.
No objections from me.
- Derek
> -Original Message-
> From: ffmpeg-devel On Behalf Of Paul B
> Mahol
> Sent: Wednesday, December 15, 2021 10:34 AM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] Politics
>
> On Tue, Dec 14, 2021 at 5:00 AM Soft Works wrote:
>
> >
> >
> > > -Origi
This function is quite small (96B with GCC 11.2 on x64 Ubuntu 21.10
at -O3), making it more economical to duplicate it into libavformat
instead of exporting it as avpriv: Doing so saves 2x24B in .dynsim,
2x16B in .dynstr, 2x2B .gnu.version, 24B in .rela.plt, 16B in .plt,
16B in .plt.sec (if enabled
Said table is 64 bytes long and exported so that it can be used both
in libavcodec and libavformat. This commit stops doing so and instead
duplicates it for shared builds, because the overhead of exporting the
symbol is bigger than 64 bytes. It consists of the length of the name of
the symbol (2x24
Signed-off-by: Andreas Rheinhardt
---
libavcodec/internal.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index a62f8dbd4e..d3ee0214c5 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -363,10 +363,4 @@ int ff_int_from_list_
These arrays have a size of 180 resp. six bytes. This does not
make it worthwhile to export them due to the overhead this occurs;
for x64 Elf/Linux/GNU: 2x2B version, 2x24B .dynsym, 24B .rela.dyn,
8B .got, 4B hash + twice the size of the name (here 20+23B).
Therefore these symbols are unavprived an
avpriv_mpeg4audio_sample_rates has a size of 64B and it is currently
avpriv; a clone of it exists in aacenctab.h and from there it is inlined
in aacenc.c (which also uses the avpriv version) and in the FLV muxer.
This means that despite it being avpriv both libavformat as well as
libavcodec have co
This group is mainly for the users of *_mpeg4audio_get_config2();
it is not for those who only use avpriv_mpeg4audio_sample_rates.
This is in preparation for splitting the latter into a file of its own;
if there were no CONFIG_EXTRA group for *_mpeg4audio_get_config2()
users, one would have to add
There are seven MJPEG-tables, five small (1x12, 4x17) and two
not small (2x162). These are all avpriv, despite this not being
worthwhile due to the overhead of exporting a symbol: The total
overhead for each symbol consists of two entries in .dynsym (24B each),
one entry in the importing library's
It is small (16 B) and therefore the overhead of exporting it more
than outweighs the size savings from not having duplicated symbols:
When the symbol is no longer avpriv, one saves twice the size of
the string containing the symbols name (2x30 byte), two entries
in .dynsym (24 bytes each on x64),
In case of shared builds, some object files containing tables
are currently duplicated into other libraries: log2_tab.c,
golomb.c, reverse.c. The check for whether this is duplicated
is simply whether CONFIG_SHARED is true. Yet this is crude:
E.g. libavdevice includes reverse.c for shared builds, b
libavcodec currently exports four avpriv symbols that deal with
PixelFormatTags: avpriv_get_raw_pix_fmt_tags, avpriv_find_pix_fmt,
avpriv_pix_fmt_bps_avi and avpriv_pix_fmt_bps_mov. The latter two are
lists of PixelFormatTags, the former returns such a list and the second
searches a list for a pixe
There is no mxfenc dependency any more since commit
b9a26b9d55f77ebbff3596e46be54bb5fed469d3.
Also remove a dnxhddata.h inclusion in mxfenc that was forgotten
in the very same commit.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/Makefile | 2 --
libavformat/mxfenc.c | 1 -
2 files changed,
On 12/15/2021 7:24 AM, Marton Balint wrote:
On Tue, 14 Dec 2021, James Almer wrote:
On 12/14/2021 3:54 PM, Nicolas George wrote:
James Almer (12021-12-14):
We add a const uint8_t* field to AVChannelCustom. If the user wants to
allocate the strings instead, and not worry about their lif
On Sun, Dec 12, 2021 at 12:56 PM Niklas Haas wrote:
>
> From: Niklas Haas
>
Any more comments on this set? LGTM now, but others have also had
comments before.
I would prefer if this gets in soon before 5.0, so user-apps can start
making use of this data.
- Hendrik
__
> 2021年12月15日 上午12:26，Michael Niedermayer 写道：
>
> On Tue, Dec 14, 2021 at 09:33:11PM +0800, Hao Chen wrote:
>> From: Shiyou Yin
>>
>> ./ffmpeg -i ../1_h264_1080p_30fps_3Mbps.mp4 -f rawvideo -y /dev/null -an
>> before:170
>> after :183
>>
>> Change-Id: I42ff23cc2dc7c32bd1b7e4274da9d9ec87065f2
James Almer (12021-12-14):
> You have a stream with four channels, you set up a custom order layout where
> you pick any four unused ids and call them OboeFL, OboeFR, PianoFL, PianoFR
> in u.map[], then split the streams (retaining strings and ids), pass them to
> channelmap using channelmap=map=Ob
James Almer (12021-12-14):
> There's "char name[16]". Bigger than a pointer (Could be 8 bytes instead,
> but then it's kinda small). The user will not have to worry about the
> lifetime of anything then.
I find the fixed-size limiting. Please seriously consider the
alternative: AVChannelLayout is
On Tue, 14 Dec 2021, James Almer wrote:
On 12/14/2021 3:54 PM, Nicolas George wrote:
James Almer (12021-12-14):
We add a const uint8_t* field to AVChannelCustom. If the user wants to
allocate the strings instead, and not worry about their lifetime, they
can
provide the layout with a cu
Fixes so that fate under 64 bit Windows passes.
These functions replace all ff_hscale8to15_*_ssse3 when avx2 is available.
---
libswscale/swscale_internal.h | 2 +
libswscale/utils.c| 37 +++
libswscale/x86/Makefile | 1 +
libswscale/x86/scale_avx2.asm | 112 +++
On Tue, Dec 14, 2021 at 5:00 AM Soft Works wrote:
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of Daniel
> > Cantarín
> > Sent: Tuesday, December 14, 2021 4:05 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] Politics
> >
> >
> > >
> > > As mentioned al
Signed-off-by: Paul B Mahol
---
Fixed decoding of https://0x0.st/-F5w.cdg
---
libavcodec/cdgraphics.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/cdgraphics.c b/libavcodec/cdgraphics.c
index 731d800666..c9e265fa53 100644
--- a/libavcodec/cdgraphics.c
+++ b/lib
On Tue, Dec 14, 2021 at 6:07 PM James Almer wrote:
> On 12/14/2021 12:23 PM, Alan Kelly wrote:
> > Patch has been rebased from latest commits.
> > These functions replace all ff_hscale8to15_*_ssse3 when avx2 is
> available.
> > ---
> > libswscale/swscale_internal.h | 2 +
> > libswscale/util
On Wed, 15 Dec 2021, Marton Balint wrote:
On Tue, 14 Dec 2021, James Almer wrote:
return channel_names[channel_id].name;
}
-static const struct {
+static inline void get_channel_str(AVBPrint *bp, const char *str,
+ enum AVChannel
On Tue, 14 Dec 2021, James Almer wrote:
return channel_names[channel_id].name;
}
-static const struct {
+static inline void get_channel_str(AVBPrint *bp, const char *str,
+ enum AVChannel channel_id)
+{
+ if (str)
+ av_bpri
Eoff, Ullysses A 于2021年12月15日周三 00:52写道：
> > > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > > index dcac46003e..39ce91b755 100644
> > > > > --- a/MAINTAINERS
> > > > > +++ b/MAINTAINERS
> > > > > @@ -226,7 +226,7 @@ Codecs:
> > > > >ptx.c Ivo van Poorten
>
Split packed data in case of its contains multiple show frame in some
non-standard bitstream. This can benefit decoder which can decode
continuously instead of interrupt with unexpected error.
Signed-off-by: Fei Wang
---
This is an improvement fix for my previous patch:
https://patchwork.ffmpeg.o
63 matches
Mail list logo
