On Tue, Jul 22, 2025 at 9:13 AM Nicolas George wrote:
>
> Hendrik Leppkes (HE12025-07-22):
> > Can we work towards enabling merging?
>
> We refused merging with pure Git not for technical reasons. Has this
> changed?
>
Merging does not necessarily imply an actual merge c
On Mon, Jul 21, 2025 at 3:03 AM Timo Rothenpieler wrote:
> >>
> >> * announce code.ffmpeg.org publically so people can start submitting
> >>and reviewing on it as an alternative to the ML
>
> Just be aware that merging is not possible, since the sync script will
> just force push anything merg
On Sun, Jul 20, 2025 at 11:15 AM Dash Santosh Sathyanarayanan
wrote:
>
> Regarding the while loop in hwcontext_d3d11va get_buffer, I understand
> the concern about introducing an unbounded wait. However, there have been
> a couple of issues reported in the past that highlight this problem:
>
> - h
On Sun, Jul 13, 2025 at 1:44 PM Michael Niedermayer
wrote:
>
> Hi all
>
> Do people want Forgejo or Gitlab on code.ffmpeg.org for testing?
>
> F. code.ffmpeg.org should run Forgejo
> G. code.ffmpeg.org should run Gitlab
>
F.
___
ffmpeg-devel mailing lis
On Sun, Jul 13, 2025 at 4:59 AM James Almer wrote:
>
> On 7/12/2025 9:32 PM, Michael Niedermayer wrote:
> > On Fri, Jul 11, 2025 at 04:04:17PM +, Timo Rothenpieler wrote:
> >> ffmpeg | branch: master | Timo Rothenpieler | Tue
> >> Jun 24 19:30:19 2025 +0200| [90fa9636efff84ec5a4b06815722c081
On Thu, Jun 26, 2025 at 2:58 AM Michael Niedermayer
wrote:
>
> Hi
>
> some people use webp apparently, and we have no decoder
>
libavcodec/webp.c is a decoder.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/l
On Tue, Jun 24, 2025 at 9:47 AM Dash Santosh Sathyanarayanan
wrote:
>
> This commit introduces a new hardware-accelerated video filter, scale_d3d11,
> which performs scaling and format conversion using Direct3D 11. The filter
> enables
> efficient GPU-based scaling and pixel format conversion (p0
On Fri, Jun 20, 2025 at 9:25 PM Timo Rothenpieler wrote:
>
> On 19.06.2025 22:21, Martin Storsjö wrote:
> > On Fri, 13 Jun 2025, Martin Storsjö wrote:
> >
> >> When running plain "cl", to get the MSVC version, it prints the
> >> version header on stderr, while the usage instructions are printed
>
On Tue, Jun 3, 2025 at 4:21 PM softworkz .
wrote:
>
> Making it explicit now in the form of the AVSubtitleFlowMode enum
> provides a number of benefits:
>
> - It finally provides an understandable explanation for why those two
> extra timing fields are needed
>
You say that, but I don't see tha
On Sun, Mar 23, 2025 at 9:35 PM James Almer wrote:
>
> On 3/23/2025 4:33 PM, Massimo Eynard wrote:
> > On 23/03/2025 20:01, James Almer wrote:
> >> On 3/22/2025 2:49 PM, Massimo Eynard wrote:
> >>> This patch adds support for decoding the fourth MLP substream
> >>> which contains the 16-channel pr
On Fri, Mar 7, 2025 at 6:23 PM Soft Works
wrote:
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Nicolas George
> > Sent: Freitag, 7. März 2025 10:44
> > To: FFmpeg development discussions and patches
> > Subject: Re: [FFmpeg-devel] [PATCH v3 1/4] avutil/log: Add cal
On Tue, Dec 17, 2024 at 2:44 PM Zhao Zhili
wrote:
>
>
>
> > On Dec 17, 2024, at 21:13, Martin Storsjö wrote:
> >
> > It's currently actually not used in MSVC builds, since
> > 6e49b8699657b808b7dc80033f2c3f2d0e029fa3.
> >
> > Older versions of MSVC (or, in particular, older versions of UCRT)
> >
On Sat, Nov 30, 2024 at 8:30 PM llyyr wrote:
>
> On 8/8/24 1:44 AM, llyyr wrote:
> > On 6/7/24 1:29 PM, Hendrik Leppkes wrote:
> >> On Fri, Jun 7, 2024 at 9:47 AM Hendrik Leppkes
> >> wrote:
> >>>
> >>> On Mon, May 27, 2024 at 3:47 PM lly
On Tue, Dec 3, 2024 at 12:54 PM Clément Péron wrote:
>
> On Mon, 2 Dec 2024 at 13:01, Timo Rothenpieler wrote:
> >
> > On 02/12/2024 12:03, Clément Péron wrote:
> > > Hi Timo,
> > >
> > > I try to look deeper into this and compare it with others codec.
> > > And I'm not 100% sure why only cuvidde
On Mon, Dec 2, 2024 at 11:28 AM Zhao Zhili
wrote:
>
>
> > On Dec 2, 2024, at 00:53, James Almer wrote:
> >
> > On 11/30/2024 6:13 AM, Zhao Zhili wrote:
> >> From: Zhao Zhili
> >> MSVC messed up standard C features, again.
> >> ---
> >> libavutil/mem_internal.h | 4
> >> 1 file changed, 4 i
On Sat, Nov 30, 2024 at 8:30 PM llyyr wrote:
>
> On 8/8/24 1:44 AM, llyyr wrote:
> > On 6/7/24 1:29 PM, Hendrik Leppkes wrote:
> >> On Fri, Jun 7, 2024 at 9:47 AM Hendrik Leppkes
> >> wrote:
> >>>
> >>> On Mon, May 27, 2024 at 3:47 PM lly
On Thu, Nov 14, 2024 at 10:57 AM Steve Lhomme wrote:
>
> Hi,
>
> For the record we have been running this in VLC for quite some time,
> only for Intel hardware.
> https://code.videolan.org/videolan/vlc/-/blob/3.0.x/contrib/src/ffmpeg/0001-avcodec-dxva2_hevc-add-support-for-parsing-HEVC-Rang.patch?
On Wed, Nov 6, 2024 at 2:27 PM Michael Niedermayer
wrote:
> > * you cannot expect a community of tens of people to make it their top
> > priority to bend over backwards to accommodate one person
>
> "one for all and all for one" seems a interresting concept for a team,
> but thats just my oppini
On Wed, Oct 30, 2024 at 4:52 PM Jose Santiago wrote:
> +static int interlaced_frame_from_fields(AVFrame *dst,
> +const AVFrame *field1,
> +const AVFrame *field2)
> +{
> +int i, ret = 0;
> +
> +av_frame_unref(ds
On Fri, Oct 18, 2024 at 5:09 PM Alexander Strasser via ffmpeg-devel
wrote:
>
> On 2024-10-18 16:36 +0200, Lynne via ffmpeg-devel wrote:
> > On 18/10/2024 14:41, Hendrik Leppkes wrote:
> > > On Fri, Oct 18, 2024 at 2:09 PM Alexander Strasser via ffmpeg-devel
> > &g
On Fri, Oct 18, 2024 at 2:09 PM Alexander Strasser via ffmpeg-devel
wrote:
> This caused differences
> with 2 fate tests depending on the zlib version used.
2 fate tests?
https://fate.ffmpeg.org/report.cgi?time=20241016173824&slot=x86_32-msvc14-dll-md-windows-native
This entire approach feels ex
On Mon, Oct 7, 2024 at 9:15 AM Lynne via ffmpeg-devel
wrote:
>
> If someone were to enable libglslang/libshaderc, and then disable
> all Vulkan filters, they would have the same issue as the earlier
> fix for libavcodec.
If you run such a setup, shouldn't the code that uses this then be excluded?
On Fri, Sep 20, 2024 at 1:24 AM Carlos Ruiz wrote:
>
> Hi!
>
> This is my first contribution to the project so please excuse any bad
> etiquette, I tried to read all the FAQs before posting. Would love to start
> by thanking everyone for such an amazing framework you've built!
>
> Anyway, here's m
On Fri, Aug 30, 2024 at 11:09 PM Jan Ekström wrote:
>
> On Fri, Aug 30, 2024 at 8:40 PM Hendrik Leppkes wrote:
> >
> > The code previously returned ENOMEM, despite this not being an
> > allocation problem, but rather a bitstream problem referring to data not
The code previously returned ENOMEM, despite this not being an
allocation problem, but rather a bitstream problem referring to data not
currently available.
Fixes playback of such streams, as it allows further processing of NAL
units after skipping the broken SEI NAL.
---
libavcodec/hevc/sei.c |
On Sat, Aug 17, 2024 at 3:27 PM Mike Lieman wrote:
>
> >
> > FP_INFINITE is a return value from fpclassify(), not a double.
> >
> > Does maybe using av_int2double(UINT64_C(0xFFF) << 52) help your slow
> > startup?
> >
>
> Sadly, no.
>
> double log = (fpclassify(val) == FP_ZERO ? av_int2double(UINT
On Tue, Aug 13, 2024 at 9:32 PM Dale Curtis wrote:
>
> Film grain support adds a huge amount of overhead to the H264Context
> structure for a feature that is rarely used. On low end devices or
> pages that have lots of media this bloats memory usage rapidly.
>
> This introduces a --disable-h264-fi
On Mon, Jul 22, 2024 at 2:14 PM Ramiro Polla wrote:
>
> On Mon, Jul 22, 2024 at 12:15 AM Hendrik Leppkes wrote:
> > On Mon, Jul 22, 2024 at 12:08 AM Stefan Oltmanns via ffmpeg-devel
> > wrote:
> > >
> > > Am 18.07.24 um 17:23 schrieb epira...@gmail.com:
>
On Mon, Jul 22, 2024 at 2:43 AM Stefan Oltmanns via ffmpeg-devel
wrote:
>
> Am 22.07.24 um 00:15 schrieb Hendrik Leppkes:
> > On Mon, Jul 22, 2024 at 12:08 AM Stefan Oltmanns via ffmpeg-devel
> > wrote:
> >>
> >> Am 18.07.24 um 17:23 schrieb epira...@gmail.
On Mon, Jul 22, 2024 at 12:08 AM Stefan Oltmanns via ffmpeg-devel
wrote:
>
> Am 18.07.24 um 17:23 schrieb epira...@gmail.com:
> >
> >>>
> >>> Well, the DLL directory is added to PATH by the VapourSynth installer,
> >>> but for safety reasons ffmpeg explictly tells the LoadLibrary function
> >>> to
On Sat, Jul 6, 2024 at 6:42 PM Michael Niedermayer
wrote:
>
> On Sat, Jul 06, 2024 at 02:11:30AM +0200, Hendrik Leppkes wrote:
> > On Fri, Jul 5, 2024 at 11:34 PM Michael Niedermayer
> > wrote:
> > > > /**
> > > > * The exact interpretati
On Fri, Jul 5, 2024 at 11:34 PM Michael Niedermayer
wrote:
> > /**
> > * The exact interpretation of these quality presets depends on the backend
> > * used, but the backend-invariant common settings are derived as follows:
> > */
> > enum AVScaleQuality {
> > AV_SCALE_ULTRAFAST = 1, /* no
On Wed, Jul 3, 2024 at 9:48 AM Bernardo Pilarz via ffmpeg-devel
wrote:
>
> Added the codec_name field, in which the unprocessed, not-interpreted codec
> name is stored.
> This is useful when codecs that are not handled by the libav
> (i.e. AV_CODEC_ID_NONE) are encountered, since the application m
On Mon, Jun 24, 2024 at 8:32 AM wrote:
>
> From: Fei Wang
>
> Otherwise, slice index will never update for hwaccel decode, and slice
> RPL will be always overlap into first one which use slice index to construct.
>
> Fixes hwaccel decoding after 47d34ba7fbb81
>
> Signed-off-by: Fei Wang
> ---
>
On Sat, Mar 23, 2024 at 12:14 PM Marton Balint wrote:
> +char *av_ts_make_time_string2(char *buf, int64_t ts, AVRational tb)
> +{
> +if (ts == AV_NOPTS_VALUE) {
> +snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
> +} else {
> +double val = av_q2d(tb) * ts;
> +double
On Mon, Jun 17, 2024 at 10:03 AM Zhao Zhili wrote:
>
>
>
> > On Jun 17, 2024, at 15:05, Anton Khirnov wrote:
> >
> > Quoting Zhao Zhili (2024-06-17 07:19:26)
> >> From: Zhao Zhili
> >>
> >> When thread_count be zero, it will be run on current thread like
> >> !HAVE_THREADS.
> >
> > Other APIs tr
On Fri, Jun 7, 2024 at 9:47 AM Hendrik Leppkes wrote:
>
> On Mon, May 27, 2024 at 3:47 PM llyyr wrote:
> >
> > instead of just resyncing and skipping a bunch of TS packets, leading to
> > a loss of frames.
> >
> > Before this, a stray byte with the value
On Mon, May 27, 2024 at 3:47 PM llyyr wrote:
>
> instead of just resyncing and skipping a bunch of TS packets, leading to
> a loss of frames.
>
> Before this, a stray byte with the value of 0x47 in TP_extra_header
> would throw off the detection of where TS packets start.
>
> A typical file that c
On Thu, May 30, 2024 at 11:50 AM Tomas Härdin wrote:
>
> tor 2024-05-30 klockan 10:54 +0300 skrev Rémi Denis-Courmont:
> > Can't we just use the compiler built-ins here? AFAIK, they (GCC,
> > LLVM) use the same algorithm if the CPU doesn't support native CTZ.
> > And they will pick the right instr
On Thu, May 23, 2024 at 10:38 AM wrote:
>
> From: llyyr
>
> Fields under the segmentation switch are never reset on a new frame, and
> retain the value from the previous frame. This bugs out a bunch of
> hwaccel drivers when segmentation is disabled but update_map isn't
> reset because they don't
On Wed, May 22, 2024 at 7:16 PM Lynne via ffmpeg-devel
wrote:
>
> On 22/05/2024 18:17, Philip Langdale via ffmpeg-devel wrote:
> > On Wed, 22 May 2024 11:10:31 -0400
> > "Ronald S. Bultje" wrote:
> >
> >> Hi,
> >>
> >> On Wed, May 22
On Thu, Feb 29, 2024 at 7:19 AM llyyr wrote:
>
> segmentation.update_map is never reset to 0 on a new frame, and retains
> the value from the previous frame. This bugs out a bunch of hwaccel
> drivers when segmentation.enabled is 0 but update_map isn't because
> they don't ignore values behind swi
On Tue, May 21, 2024 at 9:52 PM Lynne via ffmpeg-devel
wrote:
>
>
> It should be the case here, we shouldn't need reordering as NATIVE just
> lets you specify what order the elements appear in the bitstream.
NATIVE means "the FFmpeg native ordering", not "bitstream order".
CUSTOM lets you specify
On Thu, May 2, 2024 at 10:22 AM Andreas Rheinhardt
wrote:
>
> Before 0f8763fbea4e8816cd54c2a481d4c048fec58394, av1_frame_ref()
> and update_reference_list() could fail and therefore needed to
> be checked, which incidentally set ret. This is no longer happening,
> leading to a potential use of an
On Tue, Apr 30, 2024 at 8:49 PM Ondřej Fiala wrote:
>
> On Tue Apr 30, 2024 at 2:11 AM CEST, Hendrik Leppkes wrote:
> > On Mon, Apr 29, 2024 at 6:44 PM Ondřej Fiala wrote:
> > >
> > > I would really suggest you look at SourceHut.
> >
> > While Source
On Mon, Apr 29, 2024 at 6:44 PM Ondřej Fiala wrote:
>
> I would really suggest you look at SourceHut.
While SourceHut might be a slight improvement over the current
situation (and only slight), it being fundamentally still based on
email makes it inherit a lot of limitations and problems, and the
On Wed, Apr 10, 2024 at 3:19 PM Michael Niedermayer
wrote:
>
> On Tue, Apr 09, 2024 at 02:53:28PM +0200, Niklas Haas wrote:
> > On Sat, 06 Apr 2024 22:28:26 +0200 Michael Niedermayer
> > wrote:
> > > On Fri, Apr 05, 2024 at 07:44:52PM +0200, Niklas Haas wrote:
> > > > From: Niklas Haas
> > > >
On Wed, Apr 3, 2024 at 10:50 AM 정지우 | Eugene wrote:
>
> - typo(1) : Line 242 : RFIC7616 ->RFC7616
> - style(1) : make_digest_auth() , make_digest_auth_sha() : A1hash-> a1_hash
> and A2hash -> a2_hash
> - nit(3) : httpauth.c: Line 245,265,389:
> - nit(1) : httpauth.h: Line 85
>
> Signed-off-by: Eu
On Thu, Mar 28, 2024 at 10:12 AM wrote:
>
> From: Tong Wu
>
> HEVCHdrParams* receives a pointer which points to a dynamically
> allocated memory block. It causes the memcmp always returning 1.
> Add a function to do the comparision. A condition is also added to
> avoid malloc(0).
>
> Signed-off-b
On Tue, Mar 26, 2024 at 9:42 AM Muiz Yusuff wrote:
>
> From: Muiz
>
> All fields of the stuct use unnamed struct initialization.
> Also omit the field name for `AVOption::unit` to maintain consistency.
"unit" intentionally uses designated initializers, so that adding new
fields before it is more
On Sun, Feb 25, 2024 at 11:36 AM Mark Thompson wrote:
>
> On 25/02/2024 02:22, Водянников А.В. via ffmpeg-devel wrote:
> > From ed8fda62bbdbc62f7565891c935966c931d001ca Mon Sep 17 00:00:00 2001
> > From: Aleksoid
> > Date: Thu, 22 Feb 2024 19:15:48 +1000
> > Subject: [PATCH 1/2] Add support d
On Mon, Feb 19, 2024 at 12:44 AM Marton Balint wrote:
>
>
>
> On Fri, 16 Feb 2024, Anton Khirnov wrote:
>
> > Quoting Tomas Härdin (2024-02-03 20:58:20)
> >> I think people with knowledge how interlacing is handled in other
> >> formats and codecs might want to chime in.
> >
> > For MPEG codecs ou
On Sun, Feb 18, 2024 at 11:34 PM Michael Niedermayer
wrote:
>
> * A disagreement implies that there are 2 parties
> * And we assume here that what one party wants is better for FFmpeg than what
> the other wants.
> * The TC needs to find out which partys choice is better or suggest a 3rd
> choic
On Mon, Feb 12, 2024 at 11:22 AM Martin Storsjö wrote:
> >
> > diff --git a/.gitattributes b/.gitattributes
> > index 5a19b963b6..a900528e47 100644
> > --- a/.gitattributes
> > +++ b/.gitattributes
> > @@ -1,2 +1 @@
> > *.pnm -diff -text
> > -tests/ref/fate/sub-scc eol=crlf
>
> This change seems t
On Mon, Jan 1, 2024 at 3:54 PM Lynne wrote:
>
> Jan 1, 2024, 15:16 by nuomi2...@gmail.com:
>
> > vvc decoder plug-in to avcodec.
> > split frames into slices/tiles and send them to vvc_thread for further
> > decoding
> > reorder and wait for the frame decoding to be done and output the frame
> >
On Fri, Nov 17, 2023 at 6:04 PM Dmitry Rogozhkin
wrote:
>
> Guard against segfault running VLC decoding under msys2 [1]:
>
> Thread 33 received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 37728.0xadd0]
> ff_hwaccel_frame_priv_alloc (avctx=0x6447b00,
> hwaccel_picture_private=0x65df
On Tue, Nov 14, 2023 at 7:23 PM Dmitry Rogozhkin
wrote:
>
> Gurd against segfault running VLC decoding under msys2 [1]:
>
> Thread 33 received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 37728.0xadd0]
> ff_hwaccel_frame_priv_alloc (avctx=0x6447b00,
> hwaccel_picture_private=0x65dfd
On Tue, Nov 14, 2023 at 6:21 PM Michael Niedermayer
wrote:
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/h264_picture.c | 1 +
> libavcodec/h264_slice.c | 19 ++-
> libavcodec/h264dec.c | 1 +
> libavcodec/h264dec.h | 4
> 4 files changed, 24 inser
(vf_tonemap_opencl maintainer, added SIMD code to
> >> various bits of code, last active in git in 2020)
> >> John Stebbins (over 100 commits in FFmpeg, last active in git in
> >> 2020, 1 copyright match)
> >> Tobias Rapp(vf_readvitc mainatiner, last
On Thu, Nov 9, 2023 at 6:04 PM Rémi Denis-Courmont wrote:
>
> Le torstaina 9. marraskuuta 2023, 18.50.52 EET Michael Niedermayer a écrit :
> > that said, i checked ML subscribers and found
> > 16 of the people above to be currently subscribed with email addresses
> > that i found by greping their
On Tue, Oct 31, 2023 at 6:31 PM Michael Niedermayer
wrote:
>
> On Tue, Oct 31, 2023 at 07:19:41PM +0200, Rémi Denis-Courmont wrote:
> > Le tiistaina 31. lokakuuta 2023, 18.58.57 EET Michael Niedermayer a écrit :
> > > > That's not a credible solution for a library. All reverse dependency
> > > > d
On Tue, Oct 24, 2023 at 1:57 AM James Almer wrote:
>
> On 10/23/2023 8:49 PM, Hendrik Leppkes wrote:
> > On Tue, Oct 24, 2023 at 1:46 AM Hendrik Leppkes wrote:
> >>
> >> On Tue, Oct 24, 2023 at 1:24 AM James Almer wrote:
> >>>
> >>> This lay
On Tue, Oct 24, 2023 at 1:46 AM Hendrik Leppkes wrote:
>
> On Tue, Oct 24, 2023 at 1:24 AM James Almer wrote:
> >
> > This layout maps to ITU-R BS.2051-3 "Sound System C" and ITU-R BS.1196-8
> > "Channel
> > Configuration 14", and it being t
On Tue, Oct 24, 2023 at 1:24 AM James Almer wrote:
>
> This layout maps to ITU-R BS.2051-3 "Sound System C" and ITU-R BS.1196-8
> "Channel
> Configuration 14", and it being the first layout with top layer channels, it's
> best to use a different scheme to properly convey the presence and amount o
On Sat, Oct 14, 2023 at 6:02 AM xyz1001 wrote:
>
> dxva2 fail to init when decode h264 with baseline profile becase
> `prof_h264_high` does not contains `AV_PROFILE_H264_BASELINE` and
> `dxva_check_codec_compatibility` will return error
> ---
> libavcodec/dxva2.c | 3 ++-
> 1 file changed, 2 in
On Fri, Oct 6, 2023 at 3:47 PM Timo Rothenpieler wrote:
> I'm quite confused why this specific instance suddenly causes so much upset.
Because its bad form to break compilation of master, if all it took to
avoid that is change the order of pushing a tag to one repo and a
patch to another.
- Hend
On Fri, Oct 6, 2023 at 3:07 PM Timo Rothenpieler wrote:
>
> On 06/10/2023 14:29, Hendrik Leppkes wrote:
> > On Sun, Oct 1, 2023 at 1:39 PM Timo Rothenpieler
> > wrote:
> >>
> >> On 01.10.2023 04:06, James Almer wrote:
> >>> Fixes compilatio
On Sun, Oct 1, 2023 at 1:39 PM Timo Rothenpieler wrote:
>
> On 01.10.2023 04:06, James Almer wrote:
> > Fixes compilation after 05f8b2ca0f7e28775837a572c65ce9218f534ee2
>
> It's expected behaviour to break compilation with random inter-release
> versions of ffnvcodec.
> It's only reliable exactly
On Fri, Sep 29, 2023 at 3:55 PM Tristan Matthews wrote:
>
> Fixes: https://trac.ffmpeg.org/ticket/10596
> ---
> configure | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 20db1801ed..50ba6f772f 100755
> --- a/configure
> +++ b/configure
> @@
On Fri, Sep 22, 2023 at 11:14 AM Michael Koch
wrote:
>
> Is it ok if I remove the dead link to Python syntax, and replace it by
> this link to Wikipedia?
> https://en.wikipedia.org/wiki/Regular_expression
>
A more accurate page would probably to just point to the correct
python regex docs, eg:
ht
On Wed, Sep 6, 2023 at 12:14 AM Kacper Michajłow wrote:
>
> Other C++ standard libraries exist. Also, this is not a proper way to
> link the standard library anyway. Instead when a C++ dependency is
> detected, switch to the C++ compiler driver to properly link everything.
>
> Signed-off-by: Kacpe
On Tue, Aug 1, 2023 at 5:05 PM Andreas Rheinhardt
wrote:
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavfilter/avfilter.c | 44 +++---
> libavfilter/internal.h | 8
> 2 files changed, 24 insertions(+), 28 deletions(-)
>
> diff --git a/libavfilter
On Sat, Jul 29, 2023 at 11:54 AM Hendrik Leppkes wrote:
>
> On Sat, Jul 29, 2023 at 10:46 AM Marton Balint wrote:
> >
> >
> >
> > On Sat, 29 Jul 2023, Hendrik Leppkes wrote:
> >
> > > On Sat, Jul 29, 2023 at 2:26 AM Steven Liu wrote:
&g
On Sat, Jul 29, 2023 at 10:46 AM Marton Balint wrote:
>
>
>
> On Sat, 29 Jul 2023, Hendrik Leppkes wrote:
>
> > On Sat, Jul 29, 2023 at 2:26 AM Steven Liu wrote:
> >>
> >> read fourcc for video codec after VideoTagHeader read.
> >> passed as par
On Sat, Jul 29, 2023 at 2:26 AM Steven Liu wrote:
>
> read fourcc for video codec after VideoTagHeader read.
> passed as parameter to flv_same_video_codec.
>
Add the same parameter to flv_set_video_codec, and then you can remove
the entire backwards seek and just read it and adjust the size like
On Thu, Jul 27, 2023 at 4:38 AM Steven Liu wrote:
>
> fix segfaults:
> READ of size 1 at 0x610003b7 thread T0
> #0 0x7f928d in flv_same_video_codec ffmpeg/libavformat/flvdec.c:317:29
> #1 0x7f928d in flv_read_packet ffmpeg/libavformat/flvdec.c:1177
> #2 0x6ff32f in ff_read_packet f
The size offset was previously being accounted for in flv_set_video_codec
for h264 and mpeg4, instead of being directly accounted for in the spot
where its read, which desynced on HEVC streams.
For clarity, move the size offset directly to the parsing, similar to
how its done for all other header
On Tue, Jul 4, 2023 at 10:41 PM James Almer wrote:
>
> Uses the existing code for av_get_random_seed() to return a buffer with
> cryptographically secure random data, or an error if none could be generated.
>
> Signed-off-by: James Almer
> ---
> libavutil/random_seed.c | 54 +
On Sun, Jun 18, 2023 at 2:59 PM Lynne wrote:
>
> Jun 17, 2023, 20:37 by mich...@niedermayer.cc:
>
> > On Sat, Jun 17, 2023 at 08:08:11PM +0200, Paul B Mahol wrote:
> > [...]
> >
> >> Which library handles compressed stuff?
> >>
> >
> > For digital stuff like DAB/DVB/...
> >
> > sdrdemux in libavfo
On Thu, Jun 15, 2023 at 4:16 AM Iskandar Safarov wrote:
>
> ---
> libavcodec/get_buffer.c | 52 -
> 1 file changed, 51 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/get_buffer.c b/libavcodec/get_buffer.c
> index a04fd878de..b18af3be4a 100644
> --
On Tue, May 16, 2023 at 4:07 AM Xiang, Haihao
wrote:
>
> From: Haihao Xiang
>
> Intel MediaSDK and oneVPL expect contiguous allocation for data[i],
> however there are mandatory padding bytes between data[i] and data[i+1].
> when calling av_frame_get_buffer. So adding av_frame_get_buffer2 to
> al
On Mon, May 15, 2023 at 1:30 PM Hendrik Leppkes wrote:
>
> Apparently mpeg4 and VDPAU have the same issue. I can test and fix
> mpeg4, but do not have VDPAU setup, so .. untested commits incoming?
>
Tested and confirmed mpeg2 and mpeg4 are fixed for NVDEC, and elenril
tested VDPAU w
The matrix coefficients are stored permutated for the IDCT,
rather then in plain raster order, and need to be un-permutated
for the hardware.
---
libavcodec/vdpau_mpeg4.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vdpau_mpeg4.c b/libavcodec/vdpau_mpeg4.c
in
The matrix coefficients are stored permutated for the IDCT,
rather then in plain raster order, and need to be un-permutated
for the hardware.
---
libavcodec/vdpau_mpeg12.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vdpau_mpeg12.c b/libavcodec/vdpau_mpeg12.c
The matrix coefficients are stored permutated for the IDCT,
rather then in plain raster order, and need to be un-permutated
for the hardware.
---
libavcodec/nvdec_mpeg4.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/nvdec_mpeg4.c b/libavcodec/nvdec_mpeg4.c
in
The matrix coefficients are stored permutated for the IDCT,
rather then in plain raster order, and need to be un-permutated
for the hardware.
---
libavcodec/nvdec_mpeg12.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/nvdec_mpeg12.c b/libavcodec/nvdec_mpeg12.c
On Mon, May 15, 2023 at 12:51 PM Hendrik Leppkes wrote:
>
> mpeg2dec stores them permutated for the IDCT, nvdec expects them in
> plain raster order.
> ---
> libavcodec/nvdec_mpeg12.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/lib
mpeg2dec stores them permutated for the IDCT, nvdec expects them in
plain raster order.
---
libavcodec/nvdec_mpeg12.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/nvdec_mpeg12.c b/libavcodec/nvdec_mpeg12.c
index e10735587d..3b9ff60734 100644
--- a/libavcodec/
On Mon, May 15, 2023 at 8:04 AM Xiang, Haihao
wrote:
>
> From: Haihao Xiang
>
> The mfx implementation based on D3D11 is expected for an internal
> session on Windows, however sometimes this implemntation is not
> supported [1]. A fallback to the default mfx implementation is added in
> this patc
On Thu, May 11, 2023 at 11:32 AM Lynne wrote:
>
> May 11, 2023, 10:39 by ffm...@haasn.xyz:
>
> > From: Niklas Haas
> >
> > Recent versions of libplacebo have required Vulkan versions incompatible
> > with lavu Vulkan hwcontexts. While this is expected to change
> > eventually, breaking vf_libplac
On Thu, May 4, 2023 at 11:06 AM Christophe GARNIER
wrote:
>
> Hello,
>
> To build makemkv version 1.17.3 (makemkv-oss), I retreived he sources of
> ffmpeg from the git repository (git clone
> https://git.ffmpeg.org/ffmpeg.git ffmpeg).It appeared that the function
> av_mallocz_array is not present
On Wed, May 3, 2023 at 12:49 PM Michael Niedermayer
wrote:
>
> On Wed, May 03, 2023 at 12:05:54PM +0200, Hendrik Leppkes wrote:
> > On Tue, May 2, 2023 at 10:57 PM James Almer wrote:
> > > >
> > > > added
> > > > +{"same_none&
On Tue, May 2, 2023 at 10:57 PM James Almer wrote:
> >
> > added
> > +{"same_none" , "same origin check off" , 0 ,
> > AV_OPT_TYPE_CONST, { .i64 = AVFMT_SAME_ORIGIN_CHECK_NONE }, 0, INT_MAX,
> > D|E, "same_origin"},
>
> "none" sounds more natural.
>
> >
> >
> >> And do we
On Wed, Apr 26, 2023 at 2:32 PM Nicolas George wrote:
>
> Fix setting the assert level.
>
> Signed-off-by: Nicolas George
> ---
> libavutil/avassert.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavutil/avassert.h b/libavutil/avassert.h
> index 51e462bbae..8f3f72c80c 100644
> ---
On Fri, Mar 10, 2023 at 3:18 AM Marth64 wrote:
>
> Hi,
>
> If there is still interest I can refine this to match the latest ffmpeg
> branch. Thank you!
>
>
Your patches have already been merged to git master.
- Hendrik
___
ffmpeg-devel mailing list
ffm
On Wed, Mar 8, 2023 at 5:34 PM wrote:
>
> Le 2023-03-08 09:10, Hendrik Leppkes a écrit :
> > On Wed, Mar 8, 2023 at 4:02 PM wrote:
> >>
> >> I'm compiling with msvc and get some errors with PRIx64 and similars.
> >> For example:
> >>
On Wed, Mar 8, 2023 at 4:02 PM wrote:
>
> I'm compiling with msvc and get some errors with PRIx64 and similars.
> For example:
> snprintf(name, sizeof(name), "0x%"PRIx64, ch_layout);
>
> won't compile, but this work (with the extra space):
> snprintf(name, sizeof(name), "0x%" PRIx64, ch_layout);
>
On Fri, Dec 23, 2022 at 7:01 PM Wu Jianhua wrote:
>
> [PATCH v2] avcodec: add D3D12VA hardware accelerated H264, HEVC, VP9, and AV1
> decoding
>
> Patches attached.
>
The naming scheme on this seems to be rather inconsistent. Both
"d3d12dec" and "d3d12va" seem to be used in different places - pl
On Sat, Feb 18, 2023 at 8:43 PM Marth64 wrote:
>
> Signed-off-by: Marth64
The entire set looks good to me now. If there are no further
objections or comments, I'll apply it in a day or two.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.o
On Thu, Feb 23, 2023 at 3:37 PM copypaste wrote:
> It gets included because this platform does indeed have Video4Linux so some
> of the aarch64 stuff is relevant. Furthermore I think that the HEVC stuff
> includes it.
>
If its relevant for V4L or other hardware integration is fine and all
... b
1 - 100 of 2220 matches
Mail list logo
