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
On Wed, Feb 22, 2023 at 9:42 PM Drew Abbott wrote:
>
> Hello,
>
> I am trying to build Chromium 110 with ffmpeg version 5.1.2. One of
> the errors I get while building has to do with the API for accessing
> first_dts. It looks like previously it was just a member of AVStream,
> but now it can only
On Mon, Feb 20, 2023 at 12:50 AM Neal Gompa wrote:
>
> On Sun, Feb 19, 2023 at 5:00 PM Kieran Kunhya wrote:
> >
> > On Sun, 19 Feb 2023 at 18:46, Lynne wrote:
> >
> > > Feb 19, 2023, 18:43 by kier...@obe.tv:
> > >
> > > > On Sun, 19 Feb 2023 at 17:36, Kieran Kunhya wrote:
> > > >
> > > >> Obvio
On Sat, Feb 18, 2023 at 6:50 PM Marth64 wrote:
>
> Signed-off-by: Marth64
> ---
> - Missed adding the profiles to actual codec descriptor in ac3dec_float
> - Formatting tidyness
>
> libavcodec/ac3dec.c | 3 +++
> libavcodec/ac3dec.h | 1 +
> libavcodec/ac3dec_float.c | 2 ++
> lib
On Sat, Feb 18, 2023 at 2:15 AM Marth64 wrote:
>
> Signed-off-by: Marth64
> ---
> libavcodec/avcodec.h| 2 ++
> libavcodec/codec_desc.c | 1 +
> libavcodec/mlpdec.c | 11 +++
> libavcodec/profiles.c | 5 +
> libavcodec/profiles.h | 1 +
> 5 files changed, 20 insertion
On Sat, Feb 18, 2023 at 2:15 AM Marth64 wrote:
>
> Signed-off-by: Marth64
> ---
> libavcodec/avcodec.h | 15 +--
> libavcodec/dca_syncwords.h | 3 +++
> libavcodec/dca_xll.c | 26 +-
> libavcodec/dca_xll.h | 3 +++
> libavcodec/profiles.c
On Sat, Feb 18, 2023 at 2:15 AM Marth64 wrote:
>
> Signed-off-by: Marth64
> ---
Another thing I noticed, you should add the profiles to the eac3
decoder AVCodec in ac3_float.c
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mai
On Sat, Feb 18, 2023 at 2:15 AM Marth64 wrote:
>
> Signed-off-by: Marth64
> ---
> libavcodec/ac3dec.c | 3 +++
> libavcodec/ac3dec.h | 1 +
> libavcodec/avcodec.h| 2 ++
> libavcodec/codec_desc.c | 1 +
> libavcodec/eac3dec.c| 11 ++-
> libavcodec/profiles.c | 5 ++
On Fri, Feb 17, 2023 at 7:45 PM Lynne wrote:
>
> Feb 17, 2023, 18:08 by jamr...@gmail.com:
>
> > On 2/17/2023 1:54 PM, Lynne wrote:
> >
> >> This reverts commit 26cb36f35746fe6ef53688b119852bfa6d555f62.
> >>
> >> All filters and all codecs (except wmavoice) have been ported for the
> >> lavu/tx AP
On Fri, Feb 17, 2023 at 10:09 AM Jean-Baptiste Kempf wrote:
>
> Hello,
>
> On Fri, 17 Feb 2023, at 04:43, Lynne wrote:
> > This small patchset mostly rewrites Vulkan to enable using multiplane
> > images,
>
> This is not small. We're talking about thousands of lines of code;
>
> And this changes
On Sun, Feb 12, 2023 at 1:53 AM Marth64 wrote:
> diff --git a/libavcodec/dca_syncwords.h b/libavcodec/dca_syncwords.h
> index 4d2cd5f56d..200702f89e 100644
> --- a/libavcodec/dca_syncwords.h
> +++ b/libavcodec/dca_syncwords.h
> @@ -33,4 +33,7 @@
> #defineDCA_SYNCWORD_SUBSTREAM_CORE 0x02
On Thu, Feb 9, 2023 at 10:02 PM Ziemowit Laski wrote:
>
> > FWIW, this setup is definitely being used by lots of others already - so
> > whenever there's such an issue, the main question to ask is why others
> > haven't run into the issue before. But improvements are definitely
> > welcome!
>
> Yo
On Thu, Feb 9, 2023 at 5:42 AM Marth64 wrote:
>
> Signed-off-by: Marth64
> ---
> Adds detection of spatial/object-based audio extensions in E-AC-3,
> TrueHD, and DCA XLL (DTS). This includes Atmos, DTS:X, and IMAX formats.
> Please let me know what I could improve, I'm learning still.
> Thank you
On Wed, Feb 8, 2023 at 2:08 PM Jean-Baptiste Kempf wrote:
>
> On Wed, 8 Feb 2023, at 10:47, Le Bao Tin Ha wrote:
> > Hello, you can found the explanation here:
> >
> > https://docs.kernel.org/userspace-api/media/v4l/pixfmt-yuv-planar.html
> >
> > "V4L2_PIX_FMT_NV12M_8L128 is similar to V4L2_PIX_FM
On Wed, Feb 1, 2023 at 3:33 PM Kristofer Björkström
wrote:
>
> From 6828ea418f0209dface9fbb23ff4657f66988f5e Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Kristofer=20Bj=C3=B6rkstr=C3=B6m?=
> Date: Wed, 1 Feb 2023 15:15:14 +0100
> Subject: [PATCH] configure: add --disable-he-aac option
> MIME-Versio
On Sat, Jan 21, 2023 at 10:30 PM Marvin Scholz wrote:
>
> Or do you mean that there should be a public devel branch where API/ABI
> breaking patches can be proposed for that will eventually be merged into
> master at a defined point in time together with major bump?
>
Yes, I'm talking about one c
On Sat, Jan 21, 2023 at 8:33 PM Marvin Scholz wrote:
> >
> > Alternatively, we could just not have an instability period at all.
> >
>
> Not having any instability period at all seems like a bad idea.
>
Actually that sounds like the best idea. You would just have to
prepare the bump in a branch a
On Tue, Jan 17, 2023 at 3:36 PM wrote:
>
> From: Pawday
>
> Thank you Andreas Rheinhardt for review
>
> Here the fixes for runtime "else" conditions
>
> ---
> libavcodec/avcodec.c | 16 +++-
> libavcodec/decode.c | 11 ---
> libavcodec/encode.c | 13 -
> libavco
On Tue, Jan 3, 2023 at 12:01 AM Christopher Degawa wrote:
>
> previouslly, it only was an issue with 32-bit clang from msys2's
> mingw32 repo, however, at some point with an update to gcc 12.2.0,
> the same issue popped up. Tested with a clean clone of ffmpeg, and even
> tested with n5.0, but the
On Thu, Dec 22, 2022 at 4:53 PM Mark Gaiser wrote:
>
> On Thu, Dec 22, 2022 at 11:40 AM Nicolas George wrote:
>
> > Mark Gaiser (12022-12-21):
> > > While this works just fine, it's limited in use because the cryptography
> > > details have to be passed on the command line. Applications that migh
On Tue, Dec 13, 2022 at 8:02 PM Carl Eugen Hoyos wrote:
>
> Am So., 27. Nov. 2022 um 18:42 Uhr schrieb Carl Eugen Hoyos
> :
> >
> > Am So., 27. Nov. 2022 um 18:16 Uhr schrieb Hendrik Leppkes
> > :
> > >
> > > On Sun, Nov 27, 2022 at 6:13 PM Carl
On Fri, Dec 9, 2022 at 12:49 PM Niklas Haas wrote:
>
> So, as was discussed at the last meeting, we should move towards
> removing YUVJ. I want to gather feedback on what appears to be to the
> major hurdle, and possible ways to solve it.
>
> The basic major issue is how to handle the case of comb
>
> And does running configure output VS project files, so that
> you can compile inside VS (I think this existed at some
> earlier time at least, but I was under the impression that
> it's broken)..?
>
This was never a feature, and likely never will be. We have our own
build system and its the on
1 - 100 of 2198 matches
Mail list logo
