Missed from a5b2b22d9a45c9634e6947d43945ebafe121abec.
0001-MAINTAINERS-Remove-older-s3tc-entry.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, vis
Timo Rothenpieler:
> On 08.12.2023 11:01, Andreas Rheinhardt wrote:
>> Timo Rothenpieler:
>>> FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
>>> which then end up heap-allocated.
>>> By declaring any variable in a struct, or tree of structs, to be 32 byte
>>> aligned, it allo
Nuo Mi:
> Hi Andreas,
> thank you for the review.
> On Fri, Dec 8, 2023 at 8:17 PM Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
>
>>
>>> +
>>> +static int min_pu_arrays_init(VVCFrameContext *fc, const int
>> pic_size_in_min_pu)
>>> +{
>>> +if (fc->tab.pic_size_in_min_pu != pic
On Fri, 8 Dec 2023, Kalev Lember wrote:
On Fri, Dec 8, 2023 at 8:12 PM Cosmin Stejerean via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
As of what version of openh264 though is it safe to assume that ABI won't
change without soname changes? Since years ago ABI changes without soname
changes
On Fri, Dec 8, 2023 at 8:12 PM Cosmin Stejerean via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
> As of what version of openh264 though is it safe to assume that ABI won't
> change without soname changes? Since years ago ABI changes without soname
> changes were present there's likely to be som
> On Dec 8, 2023, at 11:07 AM, Kalev Lember wrote:
>
> On Fri, Dec 8, 2023 at 4:59 PM James Almer wrote:
>
>> Does the configure check ensure a new enough openh264 version is the
>> minimum supported?
>>
>
> Hm, I'd say that configure minimum version check is mostly orthogonal to
> the patc
On 12/8/2023 4:07 PM, Kalev Lember wrote:
On Fri, Dec 8, 2023 at 4:59 PM James Almer wrote:
Does the configure check ensure a new enough openh264 version is the
minimum supported?
Hm, I'd say that configure minimum version check is mostly orthogonal to
the patch here.
This patch just remov
On Fri, Dec 8, 2023 at 4:59 PM James Almer wrote:
> Does the configure check ensure a new enough openh264 version is the
> minimum supported?
>
Hm, I'd say that configure minimum version check is mostly orthogonal to
the patch here.
This patch just removes a check that made it error out if the
Attached.
0001-doc-filters-expand-documentation-on-libvmaf-filter.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-de
On Wed, Dec 6, 2023 at 9:54 AM Kyle Swanson wrote:
> Will push this tomorrow.
Pushed, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel
Timo Rothenpieler (12023-12-08):
> Is mixing the libraries really a scenario we need to care about/support?
No. We should merge all the libraries into a single libffmpeg.so. Having
separate libraries brings us no end of hassle and drawbacks, starting
with all the avpriv symbols and backward compat
On 08.12.2023 11:01, Andreas Rheinhardt wrote:
Timo Rothenpieler:
FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
which then end up heap-allocated.
By declaring any variable in a struct, or tree of structs, to be 32 byte
aligned, it allows the compiler to safely assume the
apply_welch_window_even_c: 617.5
apply_welch_window_even_rvv_f64: 235.0
apply_welch_window_odd_c:709.0
apply_welch_window_odd_rvv_f64: 256.5
---
libavcodec/lpc.c| 4 +-
libavcodec/lpc.h| 1 +
libavcodec/riscv/Makefile | 2 +
libavcodec/riscv/lpc_init.c |
If a sequence of JXL images is encapsulated in a container that has PTS
information, we should use the PTS information from the container. At
this time there is no container that does this, but if JPEG XL support
is ever added to NUT, AVTransport, or some other container, this commit
should allow t
On Fri, Dec 8, 2023 at 7:09 PM Jan Ekström wrote:
>
> On Fri, Dec 8, 2023 at 7:05 PM Jan Ekström wrote:
> >
> > On Fri, Dec 8, 2023 at 5:37 PM Dennis Mungai wrote:
> > >
> > > On Fri, 8 Dec 2023 at 15:14, Andreas Rheinhardt <
> > > andreas.rheinha...@outlook.com> wrote:
> > >
> > > > Jan Ekström
On Fri, Dec 8, 2023 at 7:05 PM Jan Ekström wrote:
>
> On Fri, Dec 8, 2023 at 5:37 PM Dennis Mungai wrote:
> >
> > On Fri, 8 Dec 2023 at 15:14, Andreas Rheinhardt <
> > andreas.rheinha...@outlook.com> wrote:
> >
> > > Jan Ekström:
> > > > From: Jan Ekström
> > > >
> > > > Attempts to base the fra
On Fri, Dec 8, 2023 at 5:37 PM Dennis Mungai wrote:
>
> On Fri, 8 Dec 2023 at 15:14, Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
>
> > Jan Ekström:
> > > From: Jan Ekström
> > >
> > > Attempts to base the fragmentation timing on other streams
> > > as most receivers expect media
On 12/8/2023 8:59 AM, Jan Ekström wrote:
On Sun, Nov 26, 2023 at 9:58 PM Jan Ekström wrote:
Differences to v3:
1. rebased on top of current master
2. moved the addition of multiple side data entries from a generic
av_frame_side_data_set_extend to avcodec as per request from James.
4. adopt
Add jpeg2000 subdescriptor in MXF file.
--- Begin Message ---
Signed-off-by: Cedric Le Barz
---
ffmpeg/libavformat/mxf.h| 1 +
ffmpeg/libavformat/mxfenc.c | 173 +++-
2 files changed, 173 insertions(+), 1 deletion(-)
diff --git a/ffmpeg/libavformat/mxf.h b/
Hi Andreas,
Thank you for the review.
On Fri, Dec 8, 2023 at 8:25 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
>
>
> Missing allocation check.
>
done.
>
>
> We know that sps and ps->sps_list[sps_id] don't coincide, so the latter
> will always be unreferenced. So you might just
Hi Andreas,
thank you for the review.
On Fri, Dec 8, 2023 at 8:17 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
>
> > +
> > +static int min_pu_arrays_init(VVCFrameContext *fc, const int
> pic_size_in_min_pu)
> > +{
> > +if (fc->tab.pic_size_in_min_pu != pic_size_in_min_pu) {
>
On 12/8/2023 5:15 AM, Kalev Lember wrote:
Years ago, openh264 releases often changed their ABI without changing
the library soname. To avoid running into ABI issues, a version check
was added to lavc libopenh264 code to error out at runtime in case the
build time and runtime openh264 versions don
On Fri, Dec 8, 2023 at 3:16 AM Kalev Lember wrote:
>
> Years ago, openh264 releases often changed their ABI without changing
> the library soname. To avoid running into ABI issues, a version check
> was added to lavc libopenh264 code to error out at runtime in case the
> build time and runtime ope
On Fri, 8 Dec 2023 at 15:14, Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Jan Ekström:
> > From: Jan Ekström
> >
> > Attempts to base the fragmentation timing on other streams
> > as most receivers expect media fragments to be more or less
> > aligned.
> >
> > Currently does not
Nuo Mi:
> ---
> libavcodec/vvc/Makefile |1 +
> libavcodec/vvc/vvc_ps.c | 1149 +++
> libavcodec/vvc/vvc_ps.h | 263 +
> libavcodec/vvc/vvcdec.h |7 +
> 4 files changed, 1420 insertions(+)
> create mode 100644 libavcodec/vvc/vvc_ps.c
> create
Nuo Mi:
> 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
>
> Features:
> + Support I, P, B frames
> + Support 8/10/12 bits, chroma 400, 420, 422,
On Fri, 8 Dec 2023, Kalev Lember wrote:
On Fri, Dec 8, 2023 at 1:00 PM Martin Storsjö wrote:
On Fri, 8 Dec 2023, Kalev Lember wrote:
> As for dlopening, I think instead of version checks, it would
make sense to
> try to dlsym() all of the actual required symbols, and e
Jan Ekström:
> From: Jan Ekström
>
> Attempts to base the fragmentation timing on other streams
> as most receivers expect media fragments to be more or less
> aligned.
>
> Currently does not support fragmentation on subtitle track
> only, as the subtitle packet queue timings would have to be
>
On Fri, Dec 8, 2023 at 1:00 PM Martin Storsjö wrote:
> On Fri, 8 Dec 2023, Kalev Lember wrote:
>
> > As for dlopening, I think instead of version checks, it would make sense
> to
> > try to dlsym() all of the actual required symbols, and error out in init
> if
> > anything is missing. That should
On Fri, 8 Dec 2023, Kalev Lember wrote:
As for dlopening, I think instead of version checks, it would make sense to
try to dlsym() all of the actual required symbols, and error out in init if
anything is missing. That should make it all super flexible and resilient to
e.g. struct size changes th
On Sun, Nov 26, 2023 at 9:58 PM Jan Ekström wrote:
>
> Differences to v3:
> 1. rebased on top of current master
> 2. moved the addition of multiple side data entries from a generic
>av_frame_side_data_set_extend to avcodec as per request from James.
> 4. adopted various things noted by reviews
On Fri, Sep 15, 2023 at 4:17 PM Jan Ekström wrote:
>
> Changes compared to v1:
>
> * General rebase.
> * A FATE test was added, together with the extension of the "transcode"
> test function to allow for dumping of packets' contents.
> * Simplified mov_write_ttml_document_from_queue's loop by ge
On Fri, Dec 8, 2023 at 9:39 AM Martin Storsjö wrote:
> I guess this seems reasonable to me, so LGTM.
>
> The version check would be more relevant if we would be dlopening the
> OpenH264 library (which pretty much is what one has to do in order to take
> advantage of the patent offer from Cisco),
Timo Rothenpieler:
> FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
> which then end up heap-allocated.
> By declaring any variable in a struct, or tree of structs, to be 32 byte
> aligned, it allows the compiler to safely assume the entire struct
> itself is also 32 byte ali
On Wed, Nov 29, 2023 at 11:57 AM Evgeny Pavlov wrote:
> On Tue, Nov 28, 2023 at 8:13 PM Mark Thompson wrote:
>
>> I upgraded to 23.11.1 and see no change - the colour information is still
>> missing in the header but not the stream, and the two different sequence
>> parameter sets are identical
Hi,
On Fri, 8 Dec 2023, Kalev Lember wrote:
This should no longer be an issue with newer openh264 releases and we
can drop the runtime version check and rely on upstream doing the right
thing and bump the library soname if the ABI changes, similar to how
other libraries are consumed in ffmpeg.
Years ago, openh264 releases often changed their ABI without changing
the library soname. To avoid running into ABI issues, a version check
was added to lavc libopenh264 code to error out at runtime in case the
build time and runtime openh264 versions don't match.
This should no longer be an issue
37 matches
Mail list logo
