the problem is the very last packet
can be shorter than default packet_size
so it's required to exclude it from
packet_size calculations.
fixes #10465
---
libavformat/cafenc.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/libavformat/cafenc.c b/libavformat/cafenc.c
On 2024-02-19 03:16 am, Vittorio Giovara wrote:
On Sun, Feb 18, 2024 at 8:02 PM Gyan Doshi wrote:
On 2024-02-18 11:33 pm, Anton Khirnov wrote:
Quoting Gyan Doshi (2024-02-18 05:06:30)
b) what "maximalist" interpretation?
A non-maximalist interpretation would be that a TC member is only
Signed-off-by: Marth64
---
doc/demuxers.texi | 5 +++
libavformat/Makefile | 2 +-
libavformat/dvdclut.c | 76 +++
libavformat/dvdclut.h | 37 +++
libavformat/dvdvideodec.c | 14
5 files changed, 133
v14: Nothing major, but some good grooming and feedback corrections.
Enjoy, all! Hope this can make the release!
* Don't set codec level framerate or closed caption properties,
also remove avcodec.h include as a result (CC flag detection remains,
due to its low overhead and for future use in
Replaces AVFormatContext.ts_id
Signed-off-by: James Almer
---
To be pushed as part of the bump set.
libavformat/avformat.h | 6 --
libavformat/mpegts.c | 9 +++--
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index
On Mon, Feb 19, 2024 at 2:17 AM Michael Niedermayer
wrote:
> On Sun, Feb 18, 2024 at 11:48:59PM +0100, Hendrik Leppkes wrote:
> > 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
On 17 Feb 2024, at 13:31, Rémi Denis-Courmont wrote:
> Le lauantaina 17. helmikuuta 2024, 13.46.27 EET Gyan Doshi a écrit :
>> As a TC member who is part of the disagreement, I believe your
>> participation is recused.
>
> Obviously not. We don't want to get into a situation whence TC members
On 2/17/2024 11:44 PM, Andreas Rheinhardt wrote:
AVCodecParameters.extradata is supposed to be allocated with
av_malloc(); av_realloc() and its wrappers do not guarantee
the proper alignment. Therefore parse the extradata twice:
Once to check its validity and to determine the eventual size
and a
Hi,
On Sun, Feb 18, 2024 at 5:34 PM Michael Niedermayer
wrote:
> More formally, you could define a "party to a disagreement" as
> all minimal sets of people whos non existence would resolve the
> disagreement
>
I think I agree with this interpretation of the rules.
Ronald
Hi Marton,
Thanks for the feedback!
I'm not sure what dynamic reconfiguration is, from some searching I think
it might be related to commands?
On Sun, Feb 18, 2024 at 7:08 PM Marton Balint wrote:
>
>
> On Sun, 18 Feb 2024, Stone Chen wrote:
>
> > In commit 6c45d34, a line was added that
On 2/18/2024 9:08 PM, Michael Niedermayer wrote:
On Sun, Feb 18, 2024 at 01:16:36PM -0300, James Almer wrote:
Save for the Microsoft C Runtime library, where free() can't handle aligned
buffers, aligned_malloc() should be available and working on all supported
targets.
Also, malloc() alone may
On Sun, Feb 18, 2024 at 11:48:59PM +0100, Hendrik Leppkes wrote:
> 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.
> > *
Hi Marton,
Thanks for the feedback!
I'm not sure what dynamic reconfiguration is, from some searching I think
it might be related to commands?
On Sun, Feb 18, 2024 at 7:08 PM Marton Balint wrote:
>
>
> On Sun, 18 Feb 2024, Stone Chen wrote:
>
> > In commit 6c45d34, a line was added that
On Sun, 18 Feb 2024, Stone Chen wrote:
In commit 6c45d34, a line was added that always sets rdiv to 0, overriding any
user input. This removes that line allowing user set values for 0rdiv, 1rdiv,
2rdiv, 3rdiv to apply as expected. This fixes ticket #10294.
This is likely not the correct
On Sun, Feb 18, 2024 at 01:16:36PM -0300, James Almer wrote:
> Save for the Microsoft C Runtime library, where free() can't handle aligned
> buffers, aligned_malloc() should be available and working on all supported
> targets.
> Also, malloc() alone may be sufficient if alignment requirement is
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 our decoders always output (properly signalled)
interlaced content as two
Andreas Rheinhardt:
> Forgotten in 50a8cbb23e9a982292bf7737004c97eba776c00e and
> a51279bbdea0d6db920d71980262bccd0ce78226.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/x86/fpel.h | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/libavcodec/x86/fpel.h
tor 2024-02-15 klockan 16:02 +0100 skrev Jerome Martinez:
> On 05/02/2024 01:19, Tomas Härdin wrote:
> > [...]
> > Which entry in the table would the provided file correspond to? To
> > me
> > it seems none of them fit. There's two fields, meaning two j2k
> > codestreams, in each corresponding
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
>
On Sun, Feb 18, 2024 at 11:34 PM Michael Niedermayer
wrote:
> Hi
>
> On Sun, Feb 18, 2024 at 07:20:43PM +0100, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-02-18 01:43:14)
> > > "If the disagreement involves a member of the TC"
> > > does IMHO not preclude commenting on a patch.
>
Hi
On Sun, Feb 18, 2024 at 07:20:43PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-02-18 01:43:14)
> > "If the disagreement involves a member of the TC"
> > does IMHO not preclude commenting on a patch.
> >
> > For a disagreement we need 2 parties. For example one party who
>
On Sun, Feb 18, 2024 at 10:25 PM Nicolas George wrote:
> Vittorio Giovara (12024-02-18):
> > While I value your insights, I'd like to offer a different
> > viewpoint regarding the practice of recusing oneself from discussions.
>
>
>
> That might be your viewpoint, but that is not what
On Sun, Feb 18, 2024 at 8:02 PM Gyan Doshi wrote:
>
>
> On 2024-02-18 11:33 pm, Anton Khirnov wrote:
> > Quoting Gyan Doshi (2024-02-18 05:06:30)
> >> b) what "maximalist" interpretation?
> > A non-maximalist interpretation would be that a TC member is only
> > excluded from voting when they
Vittorio Giovara (12024-02-18):
> While I value your insights, I'd like to offer a different
> viewpoint regarding the practice of recusing oneself from discussions.
That might be your viewpoint, but that is not what the rules we all
agreed upon say.
--
Nicolas George
On 18/02/2024 08:45, tong1.wu-at-intel@ffmpeg.org wrote:
From: Tong Wu
This implementation is based on D3D12 Video Encoding Spec:
https://microsoft.github.io/DirectX-Specs/d3d/D3D12VideoEncoding.html
Sample command line for transcoding:
ffmpeg.exe -hwaccel d3d12va -hwaccel_output_format
On Sun, Feb 18, 2024 at 7:40 PM Nicolas George wrote:
> Anton Khirnov (12024-02-18):
> > That is absurd and makes no sense.
>
> That makes absolute sense, unless you consider your opinion is worth
> more than the opinion of the other people in the project.
>
> A spot on the TC is
On 18/02/2024 08:45, tong1.wu-at-intel@ffmpeg.org wrote:
From: Tong Wu
VAAPI and D3D12VA can share rate control configuration codes. Hence, it
can be moved to base layer for simplification.
Signed-off-by: Tong Wu
---
libavcodec/hw_base_encode.c| 151
Sorry I think I didn't correctly attach the patch the first time.
On Sun, Feb 18, 2024 at 2:21 PM Stone Chen wrote:
> In commit 6c45d34, a line was added that always sets rdiv to 0, overriding
> any user input. This removes that line allowing user set values for 0rdiv,
> 1rdiv, 2rdiv, 3rdiv to
This callback is optional and should therefore only be set
if it actually does something.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_vp8.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/libavcodec/cbs_vp8.c b/libavcodec/cbs_vp8.c
index 065156c248..eabdef358f 100644
---
On 18/02/2024 08:45, tong1.wu-at-intel@ffmpeg.org wrote:
From: Tong Wu
Since VAAPI and future D3D12VA implementation may share the same dpb
logic and some other functions. A base layer encode context is introduced
as vaapi context's base and extract the related funtions to a common
file
Inside a function an extra ';' is a null statement;
but outside of it it simply must not happen.
So remove them.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vvc/vvc_itx_1d.c | 2 +-
libavcodec/x86/h26x/h2656dsp.h | 2 +-
libavcodec/x86/hevcdsp_init.c| 78
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vvc/vvcdsp.c | 18 --
libavcodec/vvc/vvcdsp_template.c | 2 +-
2 files changed, 1 insertion(+), 19 deletions(-)
diff --git a/libavcodec/vvc/vvcdsp.c b/libavcodec/vvc/vvcdsp.c
index 214dc4e6c0..d63b9bc9b3 100644
---
These arrays are currently accessed via uint16_t* pointers
although nothing guarantees their alignment. Furthermore,
this is problematic wrt the effective-type rules.
Fix this by using a union of arrays of uint8_t and uint16_t.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vvc/vvc_filter.c
max_bin_idx can be at most LMCS_MAX_BIN_SIZE - 1 here,
so pivot[LCMS_MAX_BIN_SIZE + 1] may be accessed,
but pivot has only LCMS_MAX_BIN_SIZE + 1 elements
(unless the values of pivot were so that it is always
assured that pivot[LCMS_MAX_BIN_SIZE] is always < sample
(which it is iff it is always <
In commit 6c45d34, a line was added that always sets rdiv to 0, overriding any
user input. This removes that line allowing user set values for 0rdiv, 1rdiv,
2rdiv, 3rdiv to apply as expected. This fixes ticket #10294.
Signed-off-by: Stone Chen
---
libavfilter/vf_convolution.c | 1 -
1 file
Rémi Denis-Courmont (12024-02-18):
> I trust that you do know the meaning of the auxillary "should". That very
> definitely and very obviously eliminates any "maximalist" interpretations.
Indeed. And I repeat what I already said in another mail:
If somebody dishonest wants to exploit that
Le sunnuntaina 18. helmikuuta 2024, 20.40.14 EET Nicolas George a écrit :
> The world is “involves”, its meaning is inherently maximalist.
The wording is very clear (emphasis added): "If the disagreement involves a
member of the TC, that member SHOULD recuse themselves from the decision."
I
On 2024-02-18 11:33 pm, Anton Khirnov wrote:
Quoting Gyan Doshi (2024-02-18 05:06:30)
b) what "maximalist" interpretation?
A non-maximalist interpretation would be that a TC member is only
excluded from voting when they authored the patch that is being
disputed.
If the promulgators meant
Rémi Denis-Courmont (12024-02-18):
> This is an utterly absurd interpretation. By that logic, a TC member would
> automatically become party to the disagreement by expressing an opinion
> within
> even the TC itself.
This is the most hypocritical argument put forward in this discussion
yet.
>
Le sunnuntaina 18. helmikuuta 2024, 2.43.14 EET Michael Niedermayer a écrit :
> > > You clearly are one of the parties to the disagreement, and "recuse
> > > themselves from the decision" is self-explanatory.
> >
> > Such a maximalist interpretation makes no sense - why should my opinion
> >
On 2/18/2024 3:38 PM, Marton Balint wrote:
On Sun, 18 Feb 2024, James Almer wrote:
On 2/18/2024 7:45 AM, Marton Balint wrote:
The old layout happened to be a native layout and therefore missed some
recently fixed layout parsing bugs.
Signed-off-by: Marton Balint
---
Anton Khirnov (12024-02-18):
> A non-maximalist interpretation would be that a TC member is only
> excluded from voting when they authored the patch that is being
> disputed.
If the rules were meant to be interpreted that way, they would have been
written “if the patch was proposed by a member of
Le sunnuntaina 18. helmikuuta 2024, 18.29.32 EET James Almer a écrit :
> Removing all the different target specific allocation functions in favor
> of the standard one. But your second point makes it moot, so patch
> withdrawn.
If you want to get code closer to standards for dealing with
On Sun, 18 Feb 2024, James Almer wrote:
On 2/18/2024 7:45 AM, Marton Balint wrote:
The old layout happened to be a native layout and therefore missed some
recently fixed layout parsing bugs.
Signed-off-by: Marton Balint
---
tests/fate/mov.mak | 2 +-
Le sunnuntaina 18. helmikuuta 2024, 18.16.36 EET James Almer a écrit :
> Save for the Microsoft C Runtime library, where free() can't handle aligned
> buffers, aligned_malloc() should be available and working on all supported
> targets.
> Also, malloc() alone may be sufficient if alignment
Le sunnuntaina 18. helmikuuta 2024, 18.27.35 EET Andreas Rheinhardt a écrit :
> 1. The function is called aligned_alloc (how did you test this?).
> 2. C11: "The value of alignment shall be a valid alignment supported by
> the implementation and the value of size shall be an integral multiple
> of
Quoting Michael Niedermayer (2024-02-18 01:43:14)
> "If the disagreement involves a member of the TC"
> does IMHO not preclude commenting on a patch.
>
> For a disagreement we need 2 parties. For example one party who
> wants a patch in and one who blocks the patch. or 2 parties where both
>
Quoting Gyan Doshi (2024-02-18 05:06:30)
> b) what "maximalist" interpretation?
A non-maximalist interpretation would be that a TC member is only
excluded from voting when they authored the patch that is being
disputed.
> - I think the current patch is fine, you don't. That's a disagreement
>
Quoting Andreas Rheinhardt (2024-02-18 16:10:06)
> The filename is freed with the OptionsContext and therefore
> there will be a use-after-free when reporting the filename
> in print_stream_maps(). So create a copy of the string.
>
> This is a regression since
On 2/18/2024 1:27 PM, Andreas Rheinhardt wrote:
James Almer:
Save for the Microsoft C Runtime library, where free() can't handle aligned
buffers, aligned_malloc() should be available and working on all supported
targets.
Also, malloc() alone may be sufficient if alignment requirement is low, so
James Almer:
> Save for the Microsoft C Runtime library, where free() can't handle aligned
> buffers, aligned_malloc() should be available and working on all supported
> targets.
> Also, malloc() alone may be sufficient if alignment requirement is low, so add
> a check for it.
>
> Signed-off-by:
Save for the Microsoft C Runtime library, where free() can't handle aligned
buffers, aligned_malloc() should be available and working on all supported
targets.
Also, malloc() alone may be sufficient if alignment requirement is low, so add
a check for it.
Signed-off-by: James Almer
---
configure
Feb 17, 2024, 20:53 by d...@lynne.ee:
> This fixes the previous commit and adds more cases (DCT-I and DST-I).
>
> I am holding off on defining a scale parameter for FFTs as I'd like
> to use a complex value for them.
>
> Patch attached.
>
Pushed mine, which also added D(C/S)Ts.
Otherwise the test may pass while ignoring errors from sanitizers.
Signed-off-by: Andreas Rheinhardt
---
tests/fate-run.sh | 44
1 file changed, 28 insertions(+), 16 deletions(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index
The filename is freed with the OptionsContext and therefore
there will be a use-after-free when reporting the filename
in print_stream_maps(). So create a copy of the string.
This is a regression since 8aed3911fc454e79697e183660bf30d31334a64b.
fate-lavf-mkv_attachment exhibits it (and reports a
Forgotten in e6b125e3be19fb341fd9a759ad0af3b39ba35e0c.
Signed-off-by: Andreas Rheinhardt
---
libavutil/tests/pixelutils.c | 8
1 file changed, 8 deletions(-)
diff --git a/libavutil/tests/pixelutils.c b/libavutil/tests/pixelutils.c
index f5ddeb329d..828a7580d2 100644
---
On 2/13/2024 2:39 PM, James Almer wrote:
If a custom layout is equivalent to a native one, check if it matches one of the
known layout names and print that instead.
Signed-off-by: James Almer
---
Should be applied after the patch this one is a reply to.
libavutil/channel_layout.c| 68
On 2/18/2024 7:45 AM, Marton Balint wrote:
The old layout happened to be a native layout and therefore missed some
recently fixed layout parsing bugs.
Signed-off-by: Marton Balint
---
tests/fate/mov.mak | 2 +-
tests/ref/fate/mov-mp4-pcm-float | 4 ++--
2 files changed, 3
James Almer:
> On 2/17/2024 11:41 PM, Andreas Rheinhardt wrote:
>> AVCodecParameters.extradata_size is an int.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavcodec/bsf/hevc_mp4toannexb.c | 2 +-
>> libavcodec/bsf/vvc_mp4toannexb.c | 2 +-
>> 2 files changed, 2 insertions(+), 2
ping
flow gg 于2024年1月30日周二 00:22写道：
> > I expect that it would be faster to make one large load, and then 4 small
> > stores, but that might work only for exactly 128-bit vectors?
>
> This seems to require vle128, so I didn't modify it.
>
> > That's not needed. You can use immediate values.
> >
On Thu, Feb 15, 2024 at 9:21 PM Lynne wrote:
>
> Feb 15, 2024, 20:18 by jee...@gmail.com:
>
> > This together with adjusting the inclusion define allows for the
> > build to not fail with latest Vulkan-Headers that contain the
> > stabilized Vulkan AV1 decoding definitions.
> >
> > Compilation
> 在 2024年2月18日，下午6:45，Marton Balint 写道：
>
> The old layout happened to be a native layout and therefore missed some
> recently fixed layout parsing bugs.
>
> Signed-off-by: Marton Balint
> ---
> tests/fate/mov.mak | 2 +-
> tests/ref/fate/mov-mp4-pcm-float | 4 ++--
> 2 files
The old layout happened to be a native layout and therefore missed some
recently fixed layout parsing bugs.
Signed-off-by: Marton Balint
---
tests/fate/mov.mak | 2 +-
tests/ref/fate/mov-mp4-pcm-float | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git
From: Tong Wu
This implementation is based on D3D12 Video Encoding Spec:
https://microsoft.github.io/DirectX-Specs/d3d/D3D12VideoEncoding.html
Sample command line for transcoding:
ffmpeg.exe -hwaccel d3d12va -hwaccel_output_format d3d12 -i input.mp4
-c:v hevc_d3d12va output.mp4
Signed-off-by:
From: Tong Wu
Flags field is added to support diffferent resource creation.
Signed-off-by: Tong Wu
---
doc/APIchanges| 3 +++
libavutil/hwcontext_d3d12va.c | 2 +-
libavutil/hwcontext_d3d12va.h | 8
libavutil/version.h | 2 +-
4 files changed, 13
From: Tong Wu
Signed-off-by: Tong Wu
---
Changelog | 1 +
1 file changed, 1 insertion(+)
diff --git a/Changelog b/Changelog
index c5fb21d198..6923c451c5 100644
--- a/Changelog
+++ b/Changelog
@@ -24,6 +24,7 @@ version :
- ffmpeg CLI options may now be used as -/opt , which is equivalent
From: Tong Wu
Get constraints and set recon frame format can be shared with other HW
encoder such as D3D12. Extract this part as a new function to base
layer.
Signed-off-by: Tong Wu
---
libavcodec/hw_base_encode.c | 58 +
libavcodec/hw_base_encode.h | 2 ++
From: Tong Wu
Signed-off-by: Tong Wu
---
libavcodec/hw_base_encode.c | 54 +
libavcodec/hw_base_encode.h | 3 +++
libavcodec/vaapi_encode.c | 52 +++
3 files changed, 61 insertions(+), 48 deletions(-)
diff --git
From: Tong Wu
VAAPI and D3D12VA can share rate control configuration codes. Hence, it
can be moved to base layer for simplification.
Signed-off-by: Tong Wu
---
libavcodec/hw_base_encode.c| 151
libavcodec/hw_base_encode.h| 34 ++
libavcodec/vaapi_encode.c
From: Tong Wu
Signed-off-by: Tong Wu
---
libavcodec/hw_base_encode.c | 40 +
libavcodec/hw_base_encode.h | 3 +++
libavcodec/vaapi_encode.c | 44 ++---
3 files changed, 45 insertions(+), 42 deletions(-)
diff --git
From: Tong Wu
When allocating the VAAPIEncodePicture, pic->input_surface can be
initialized right in the place. This movement simplifies the send_frame
logic and is the preparation for moving vaapi_encode_send_frame to the base
layer.
Signed-off-by: Tong Wu
---
libavcodec/vaapi_encode.c | 8
71 matches
Mail list logo
