Re: [FFmpeg-devel] [PATCH v1 00/11] Add support for H266/VVC
On Tue, 13 Dec 2022 at 07:19, Nuo Mi wrote: > Hi Thomas, > Thank you for sending the patch set. > It seems the patchset is based on > https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=3487 > Please do not change the author's name. > > thank you > Some code regarding VVC parsing is based on another FFmpeg fork. This fork had been based on your patch set, it seems. On top of this, I did additional modifications to the parsing code and added the other code regarding format support and the decoder and encoder integration. It was not my intent to hide you as an author of the parsing code. Your patch set has been in an unmerged state for over 1.5 years now without new progress, so I assumed that these patches are kind of discontinued. Therefore I started submitting my own patchset to get VVC integrated into FFmpeg. I kept your original copyright notices in libavformat/vvcdec.c and livavcodec/vvc_parser.c. Apart from this, I am not sure how / where else this could be documented and how other authors can be appropriately referenced. Could you explain in more detail what you mean by changing the author's name? Do you have any suggestions on what to do in this case or how to change it? On Wed, Oct 19, 2022 at 3:26 PM wrote: > >> From: Thomas Siedel >> >> This patch set adds H266/VVC support. >> This includes parsing, muxing, demuxing, decoding and encoding. >> Decoding is done using the external library VVdeC >> (https://github.com/fraunhoferhhi/vvdec.git) and can be enabled with >> --enable-libvvdec. >> Encoding is done using the external library VVenC >> (https://github.com/fraunhoferhhi/vvenc.git) and can be enabled with >> --enable-libvvenc. >> >> Thomas Siedel (11): >> avcodec: add enum types for H266/VVC >> avcodec: add cbs for H266/VVC >> avcodec: enable cbs for H266/VVC >> avcodec: add bitstream parser for H266/VVC >> avcodec: add MP4 to annexb support for H266/VVC >> avformat: add demuxer and probe support for H266/VVC >> avformat: add muxer support for H266/VVC >> avcodec: add external decoder libvvdec for H266/VVC >> avcodec: add external encoder libvvenc for H266/VVC >> avformat: add ts stream types for H266/VVC >> avcodec: increase minor version for H266/VVC >> >> configure | 16 +- >> libavcodec/Makefile |6 + >> libavcodec/allcodecs.c|2 + >> libavcodec/bitstream_filters.c|2 + >> libavcodec/cbs.c |6 + >> libavcodec/cbs_h2645.c| 384 +++- >> libavcodec/cbs_h266.h | 791 +++ >> libavcodec/cbs_h266_syntax_template.c | 3010 + >> libavcodec/cbs_internal.h |3 +- >> libavcodec/cbs_sei.c | 29 + >> libavcodec/h2645_parse.c | 71 +- >> libavcodec/h266_metadata_bsf.c| 145 ++ >> libavcodec/libvvdec.c | 511 + >> libavcodec/libvvenc.c | 432 >> libavcodec/parsers.c |1 + >> libavcodec/version.h |2 +- >> libavcodec/vvc.h | 142 ++ >> libavcodec/vvc_mp4toannexb_bsf.c | 318 +++ >> libavcodec/vvc_paramset.c | 972 >> libavcodec/vvc_paramset.h | 429 >> libavcodec/vvc_parse_extradata.c | 241 ++ >> libavcodec/vvc_parse_extradata.h | 36 + >> libavcodec/vvc_parser.c | 588 + >> libavformat/Makefile |8 +- >> libavformat/allformats.c |2 + >> libavformat/demux.c |7 +- >> libavformat/isom.c|1 + >> libavformat/isom_tags.c |3 + >> libavformat/mov.c |6 + >> libavformat/movenc.c | 41 +- >> libavformat/mpeg.c|3 + >> libavformat/mpeg.h|1 + >> libavformat/mpegts.c |2 + >> libavformat/mpegts.h |1 + >> libavformat/mpegtsenc.c | 65 + >> libavformat/rawenc.c | 23 + >> libavformat/vvc.c | 918 >> libavformat/vvc.h | 99 + >> libavformat/vvcdec.c | 61 + >> 39 files changed, 9366 insertions(+), 12 deletions(-) >> create mode 100644 libavcodec/cbs_h266.h >> create mode 100644 libavcodec/cbs_h266_syntax_template.c >> create mode 100644 libavcodec/h266_metadata_bsf.c >> create mode 100644 libavcodec/libvvdec.c >> create mode 100644 libavcodec/libvvenc.c >> create mode 100644 libavcodec/vvc.h >> create mode 100644 libavcodec/vvc_mp4toannexb_bsf.c >> create mode 100644 libavcodec/vvc_paramset.c >> create mode 100644 libavcodec/vvc_paramset.h >> create mode 100644 libavcodec/vvc_parse_extradata.c >> create mode 100644 libavcodec/vvc_parse_extradata.h >> create mode 100644 libavcodec/vvc_parser.c >> create mode 100644 libavformat/
Re: [FFmpeg-devel] [PATCH v14 9/9] avcodec/evc: Changes in Changelog and MAINTAINERS files
-Original Message-
From: ffmpeg-devel On Behalf Of Michael
Niedermayer
Sent: środa, 14 grudnia 2022 22:36
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH v14 9/9] avcodec/evc: Changes in
Changelog and MAINTAINERS files
On Tue, Dec 13, 2022 at 08:33:29AM -0500, Ronald S. Bultje wrote:
> Hi David,
>
> On Tue, Dec 13, 2022 at 7:22 AM Dawid Kozinski/Multimedia (PLT)
> /SRPOL/Staff Engineer/Samsung Electronics wrote:
>
> > Should I leave the following lines:
> > + libxevd.c Dawid Kozinski
> > + libxeve.c,Dawid Kozinski
> > + evc.c, evc.hDawid Kozinski
> > + evcdec.c Dawid Kozinski
> > + evc_parser.c Dawid Kozinski
> >
> > or should I remove them?
> >
>
> Here's a question for you, and the answer probably becomes
> self-evident from that. If you, Dawid, stop working for Samsung, for
> example because you're starting your own business or Samsung fires you
> or Google hires you, or if Samsung stops sponsoring this new codec
> called "EVC" or stops contributing to this new library "libxeve". Will
> you, Dawid, still maintain these files?
>
> If the answer is yes, then you can shorten these lines ("evc*.[ch]: Dawid"
> & "livxev[ed].c: Dawid") and keep them.
>
> If the answer is no, then I think you should remove (or adjust) these
> lines, since they are (in their current form) inaccurate: you are not
> maintaining these files, your company is.
>
I think for code maintained by a company we still should list a person
because persons can be contacted while large companies are sometimes very
difficult to contact.
maybe
Dawid Kozinski (Samsung) or Samsung (Dawid Kozinski) or something like that
would specify this better
thx
Hi,
To be clear. We are not fighting for the right to push. The write access is
not our goal at the moment.
We just want to do our contribution to the FFMpeg project and provide
support for the EVC codec and the only reason we've added entries to the
MAINTENANCE file is to provide the information so others know who to contact
about the codec.
Yesterday I submitted new patches to the FFMepg patchwork and following what
Lynne said I removed our entries from the MAINTENANCE file.
However, If I understand you correctly, I shouldn't remove it, I should
though leave the information in the file.
So now I should restore what I removed.
Correct me if I'm wrong cause it's a bit confusing.
Anyway, we will restore previously removed information from the MAINTENANCE
file, information that points to the person who can handle EVC-related
queries, but please take a look at what we have uploaded to the patchwork.
Check if it is OK or do we need still to change something else.
BR
Dawid
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
"I am not trying to be anyone's saviour, I'm trying to think about the
future and not be sad" - Elon Musk
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] avformat/movenc: correct write_colr warning placement
On 2022-12-14 08:03 pm, Zhao Zhili wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of Gyan Doshi
Sent: 2022年12月14日 20:49
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v3] avformat/movenc: correct write_colr
warning placement
On 2022-12-14 06:10 pm, "zhilizhao(赵志立)" wrote:
On Dec 14, 2022, at 19:58, Gyan Doshi wrote:
The old warning is no longer applicable in the inner block after
c5b20cfe19.
---
libavformat/movenc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 7b00e65cdd..c427109609 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -2330,10 +2330,11 @@ static int mov_write_video_tag(AVFormatContext *s,
AVIOContext *pb, MOVMuxContex
av_stream_get_side_data(track->st, AV_PKT_DATA_ICC_PROFILE,
NULL)) {
int prefer_icc = mov->flags & FF_MOV_FLAG_PREFER_ICC ||
!has_color_info;
mov_write_colr_tag(pb, track, prefer_icc);
-} else if (mov->flags & FF_MOV_FLAG_WRITE_COLR) {
- av_log(mov->fc, AV_LOG_WARNING, "Not writing 'colr' atom. Format is
not MOV or MP4.\n");
}
+} else if (mov->flags & FF_MOV_FLAG_WRITE_COLR) {
+av_log(mov->fc, AV_LOG_WARNING, "Not writing 'colr' atom. Format is not
MOV or MP4 or AVIF.\n");
LGTM except the indentation.
Do you mean the log line?
Yes. You can fix it locally before push.
Thanks. Pushed as 9adf02247cd5f1c6cc404ab3dad317a40f4f6e0c
Regards,
Gyan
}
+
if (track->mode == MODE_MOV || track->mode == MODE_MP4) {
mov_write_clli_tag(pb, track);
mov_write_mdcv_tag(pb, track);
--
2.36.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] configure: support lsan as toolchain
On 12/7/22 17:08, James Darnley wrote:
---
configure | 5 +
1 file changed, 5 insertions(+)
diff --git a/configure b/configure
index f4eedfc207..eaa5ef6b20 100755
--- a/configure
+++ b/configure
@@ -4315,6 +4315,11 @@ case "$toolchain" in
add_cflags -fsanitize=address
add_ldflags -fsanitize=address
;;
+*-lsan)
+cc_default="${toolchain%-lsan}"
+add_cflags -fsanitize=leak
+add_ldflags -fsanitize=leak
+;;
*-msan)
cc_default="${toolchain%-msan}"
add_cflags -fsanitize=memory -fsanitize-memory-track-origins
ping
Any objections to this?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avcodec/x86/v210: add some comments to the improved avx2 function
--- libavcodec/x86/v210.asm | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/libavcodec/x86/v210.asm b/libavcodec/x86/v210.asm index 3b9e0761df..600a4ddc5f 100644 --- a/libavcodec/x86/v210.asm +++ b/libavcodec/x86/v210.asm @@ -65,18 +65,18 @@ cglobal v210_planar_unpack_%1, 5, 5, 6 + 2 * cpuflag(avx2), src, y, u, v, w mova m0, [srcq] %endif -pmullw m1, m0, m3 -pslld m0, 12 -psrlw m1, 6 ; yB yA u5 v4 y8 y7 v3 u3 y5 y4 u2 v1 y2 y1 v0 u0 -psrld m0, 22 ; 00 v5 00 y9 00 u4 00 y6 00 v2 00 y3 00 u1 00 y0 +pmullw m1, m0, m3 ; shifts the 1st and 3rd sample of each dword into the high 10 bits of each word +pslld m0, 12 ; shifts the 2nd sample of each dword into the high 10 bits of each dword +psrlw m1, 6 ; shifts the 1st and 3rd samples back into the low 10 bits +psrld m0, 22 ; shifts the 2nd sample back into the low 10 bits of each dword %if cpuflag(avx2) -vpblendd m2, m1, m0, 0x55 ; yB yA 00 y9 y8 y7 00 y6 y5 y4 00 y3 y2 y1 00 y0 +vpblendd m2, m1, m0, 0x55 ; merge the odd dwords from m0 and even from m1 ; yB yA 00 y9 y8 y7 00 y6 y5 y4 00 y3 y2 y1 00 y0 pshufb m2, m4 ; 00 00 yB yA y9 y8 y7 y6 00 00 y5 y4 y3 y2 y1 y0 vpermd m2, m6, m2 ; 00 00 00 00 yB yA y9 y8 y7 y6 y5 y4 y3 y2 y1 y0 movu [yq+2*wq], m2 -vpblendd m1, m1, m0, 0xaa ; 00 v5 u5 v4 00 u4 v3 u3 00 v2 u2 v1 00 u1 v0 u0 +vpblendd m1, m1, m0, 0xaa ; merge the even dwords from m0 and odd from m1 ; 00 v5 u5 v4 00 u4 v3 u3 00 v2 u2 v1 00 u1 v0 u0 pshufb m1, m5 ; 00 v5 v4 v3 00 u5 u4 u3 00 v2 v1 v0 00 u2 u1 u0 vpermq m1, m1, 0xd8; 00 v5 v4 v3 00 v2 v1 v0 00 u5 u4 u3 00 u2 u1 u0 pshufb m1, m7 ; 00 00 v5 v4 v3 v2 v1 v0 00 00 u5 u4 u3 u2 u1 u0 -- 2.38.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [RFC PATCH 2/2] avcodec/x86: add avx512icl function for v210dec
Ice Lake (Xeon Silver 4316): 2.01x faster (1147±36.8 vs. 571±38.2 decicycles)
compared with avx2
---
I think I can merge this with the existing macro without it being too ugly.
That might allow a plain avx512 version too but I can't say if that would be any
faster.
libavcodec/x86/v210-init.c | 10 ++-
libavcodec/x86/v210.asm| 60 +-
tests/checkasm/v210dec.c | 12
3 files changed, 74 insertions(+), 8 deletions(-)
diff --git a/libavcodec/x86/v210-init.c b/libavcodec/x86/v210-init.c
index 5db1fef98c..8b3677b8aa 100644
--- a/libavcodec/x86/v210-init.c
+++ b/libavcodec/x86/v210-init.c
@@ -17,7 +17,7 @@
*/
#include "libavutil/attributes.h"
-#include "libavutil/cpu.h"
+#include "libavutil/x86/cpu.h"
#include "libavcodec/v210dec.h"
extern void ff_v210_planar_unpack_unaligned_ssse3(const uint32_t *src,
uint16_t *y, uint16_t *u, uint16_t *v, int width);
@@ -28,6 +28,8 @@ extern void ff_v210_planar_unpack_aligned_ssse3(const
uint32_t *src, uint16_t *y
extern void ff_v210_planar_unpack_aligned_avx(const uint32_t *src, uint16_t
*y, uint16_t *u, uint16_t *v, int width);
extern void ff_v210_planar_unpack_aligned_avx2(const uint32_t *src, uint16_t
*y, uint16_t *u, uint16_t *v, int width);
+extern void ff_v210_planar_unpack_avx512icl(const uint32_t *src, uint16_t *y,
uint16_t *u, uint16_t *v, int width);
+
av_cold void ff_v210_x86_init(V210DecContext *s)
{
#if HAVE_X86ASM
@@ -42,6 +44,9 @@ av_cold void ff_v210_x86_init(V210DecContext *s)
if (HAVE_AVX2_EXTERNAL && cpu_flags & AV_CPU_FLAG_AVX2)
s->unpack_frame = ff_v210_planar_unpack_aligned_avx2;
+
+if (EXTERNAL_AVX512ICL(cpu_flags))
+s->unpack_frame = ff_v210_planar_unpack_avx512icl;
}
else {
if (cpu_flags & AV_CPU_FLAG_SSSE3)
@@ -52,6 +57,9 @@ av_cold void ff_v210_x86_init(V210DecContext *s)
if (HAVE_AVX2_EXTERNAL && cpu_flags & AV_CPU_FLAG_AVX2)
s->unpack_frame = ff_v210_planar_unpack_unaligned_avx2;
+
+if (EXTERNAL_AVX512ICL(cpu_flags))
+s->unpack_frame = ff_v210_planar_unpack_avx512icl;
}
#endif
}
diff --git a/libavcodec/x86/v210.asm b/libavcodec/x86/v210.asm
index 600a4ddc5f..f247737ed0 100644
--- a/libavcodec/x86/v210.asm
+++ b/libavcodec/x86/v210.asm
@@ -22,7 +22,21 @@
%include "libavutil/x86/x86util.asm"
-SECTION_RODATA 32
+SECTION_RODATA 64
+
+perm_y:
+db 0,1, 4,5, 6,7, 8,9, 12,13, 14,15, 16,17, 20,21
+db 22,23, 24,25, 28,29, 30,31, 32,33, 36,37, 38,39, 40,41
+db 44,45, 46,47, 48,49, 52,53, 54,55, 56,57, 60,61, 62,63
+times 16 db 0xff ; align to 64
+
+perm_uv:
+db 0,1, 4,5, 10,11, 16,17, 20,21, 26,27, 32,33, 36,37
+db 42,43, 48,49, 52,53, 58,59
+times 8 db 0xff ; align to 32
+db 2,3, 8,9, 12,13, 18,19, 24,25, 28,29, 34,35, 40,41
+db 44,45, 50,51, 56,57, 60,61
+times 8 db 0xff ; align to 32
; for AVX2 version only
v210_luma_permute: dd 0,1,2,4,5,6,7,7 ; 32-byte alignment required
@@ -34,6 +48,9 @@ v210_mult: dw 64,4,64,4,64,4,64,4
v210_luma_shuf: db 8,9,0,1,2,3,12,13,4,5,6,7,-1,-1,-1,-1
v210_chroma_shuf: db 0,1,8,9,6,7,-1,-1,2,3,4,5,12,13,-1,-1
+shift: times 4 dw 6, 2
+kmask: dw 0x, 0x
+
SECTION .text
%macro v210_planar_unpack 1
@@ -127,3 +144,44 @@ v210_planar_unpack aligned
INIT_YMM avx2
v210_planar_unpack aligned
%endif
+
+%if HAVE_AVX512ICL_EXTERNAL
+
+INIT_ZMM avx512icl
+
+cglobal v210_planar_unpack, 5, 5, 6, src, y, u, v, w
+movsxdifnidn wq, wd
+leayq, [yq+2*wq]
+adduq, wq
+addvq, wq
+negwq
+
+kmovw k1, [kmask] ; odd dword mask
+kmovw k2, [kmask+2] ; even dword mask
+
+VBROADCASTI128 m0, [shift]
+mova m1, [perm_y]
+mova m2, [perm_uv]
+
+.loop:
+movum3, [srcq]
+vpsllvw m4, m3, m0
+pslld m5, m3, 12
+psrlw m4, 6
+psrld m5, 22
+
+vpblendmd m3{k1}, m4, m5
+vpermbm3, m1, m3 ; could use vpcompressw
+movu [yq+2*wq], m3
+
+vpblendmd m5{k2}, m4, m5
+vpermbm5, m2, m5
+movu [uq+wq], ym5
+vextracti32x8 [vq+wq], zm5, 1
+
+add srcq, mmsize
+add wq, (mmsize*3)/8
+jl .loop
+RET
+
+%endif
diff --git a/tests/checkasm/v210dec.c b/tests/checkasm/v210dec.c
index 6aef519cc5..93993bae71 100644
--- a/tests/checkasm/v210dec.c
+++ b/tests/checkasm/v210dec.c
@@ -54,12 +54,12 @@ void checkasm_check_v210dec(void)
if (check_func(h.unpack_frame, "v210_unpack")) {
uint32_t src0[NUM_SAMPLES/3];
uint32_t src1[NUM_SAMPLES/3];
-uint16_t y0[NUM_SAMPLES/2];
-uint16_t y1[NUM_SAMPLES/2];
-uint16_t u0[NUM_SAMPLES/4];
-uint16_t u1[NUM_SAMPLES/4];
-uint16_t v0[NUM_SAMPLES/4];
-uint16_t v1[NUM_SAMPLES/4];
+uint16_t y0[NUM_SAMPLES/2 + 15];
+uint16_t y1[NUM_SAMPLES/2 + 15];
+uint16_t u0[NUM_SAMPLES/4 + 7];
+
Re: [FFmpeg-devel] [PATCH] lavc/videotoolbox: validate vt context in the decoder callback
Ping on this, Can I contribute somehow either to fix calling `av_videotoolbox_default_init` or at least update the docs? Best Regards, Alessandro On 11 Dec 2022, 11:57 +0200, Alessandro Di Nepi , wrote: > On 9 Dec 2022, 6:45 +0200, FFmpeg development discussions and patches > , wrote: > > Did you call av_videotoolbox_default_init() or > > av_videotoolbox_default_init2()? > Actually yes, I call `av_videotoolbox_default_init(context);` > > I think that’s why avctx->internal->hwaccel_priv_data is NULL. That code > > path is broken. > > Does remove the call of > > av_videotoolbox_default_init()/av_videotoolbox_default_init2() works for > > you? > Definitively yes, if I remove the call to `av_videotoolbox_default_init` the > context is fine. > > Thanks for sorting this out. I'd like to contribute and have this fixed or > documented for other people. > What should be the desired behavior? Calling `av_videotoolbox_default_init` > and having the context not NULL? > Or shall we remove the init at all? > > Best Regards ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] GSoC 2023
Hi, as we figured during the last dev meeting on December 2nd we want to apply again for GSoC 2023. I told mentors often enough already that it's a vital point in our applications to have a properly filled results page from the last GSoC we did. Last time no mentor cared about this - we can be quite sure that our application will fail if we don't have [1] up-to-date until we send our application. Also vital for the application are already existing project ideas so everyone interested in mentoring a project in 2023, please add your idea(s) to [2]. The application deadline is January 23rd, I will aim for sending an application mid January. Thanks, Thilo [1] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2022/Results [2] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2023 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/videotoolbox: validate vt context in the decoder callback
> -Original Message- > From: ffmpeg-devel On Behalf Of Alessandro > Di Nepi > Sent: 2022年12月15日 22:16 > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH] lavc/videotoolbox: validate vt context in > the decoder callback > > Ping on this, > Can I contribute somehow either to fix calling `av_videotoolbox_default_init` > or at least update the docs? Updating the docs doesn't work. This is a public API, it must be fixed properly: don't drop a feature, do what it was supposed to do. You can give a try, but I'm afraid it's a tricky regression. > > Best Regards, > Alessandro > On 11 Dec 2022, 11:57 +0200, Alessandro Di Nepi > , wrote: > > On 9 Dec 2022, 6:45 +0200, FFmpeg development discussions and patches > > , wrote: > > > Did you call av_videotoolbox_default_init() or > > > av_videotoolbox_default_init2()? > > Actually yes, I call `av_videotoolbox_default_init(context);` > > > I think that’s why avctx->internal->hwaccel_priv_data is NULL. That code > > > path is broken. > > > Does remove the call of > > > av_videotoolbox_default_init()/av_videotoolbox_default_init2() works for > > > you? > > Definitively yes, if I remove the call to `av_videotoolbox_default_init` > > the context is fine. > > > > Thanks for sorting this out. I'd like to contribute and have this fixed or > > documented for other people. > > What should be the desired behavior? Calling `av_videotoolbox_default_init` > > and having the context not NULL? > > Or shall we remove the init at all? > > > > Best Regards > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] GSoC 2023
Hello, Also, please don’t copy paste ideas from previous years. If the idea did not get picked up for years, it won’t be more useful this year. jb On Thu, 15 Dec 2022, at 15:42, Thilo Borgmann wrote: > Hi, > > as we figured during the last dev meeting on December 2nd we want to > apply again for GSoC 2023. > > I told mentors often enough already that it's a vital point in our > applications to have a properly filled results page from the last GSoC > we did. > Last time no mentor cared about this - we can be quite sure that our > application will fail if we don't have [1] up-to-date until we send our > application. > > Also vital for the application are already existing project ideas so > everyone interested in mentoring a project in 2023, please add your > idea(s) to [2]. > > The application deadline is January 23rd, I will aim for sending an > application mid January. > > Thanks, > Thilo > > [1] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2022/Results > [2] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2023 > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [REFUND-REQUEST] Travel to Developer Meeting
On 12/14/2022 11:32 PM, Stefano Sabatini wrote: > Approved on my side, pending Michael's approval. > > Please follow these instructions to prepare and send the reimbursement form: > https://www.spi-inc.org/treasurer/reimbursement-form/ > > and put me and Michael in CC: > > Let me know in private if you have issues with the paperwork. Done. Cheers, - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 0/7] MediaCodec encoder: Fix width/height alignment issue and add more options
On Wed, 2022-12-07 at 17:31 +0800, Zhao Zhili wrote: > From: Zhao Zhili > > v2: > Reorder 1/7 and 2/7. > > Zhao Zhili (7): > avcodec/mediacodecenc: make each encoder has its own option > avcodec/mediacodecenc: add bitrate_mode option > avcodec/mediacodecenc: add level option > avcodec/mediacodecenc: use bsf to handle crop > avcodec/mediacodecenc: remove the strategy to create DTS > avcodec/mediacodecenc: add max-bframes support > avcodec/mediacodecenc: add pts_as_dts option > > configure | 2 + > libavcodec/mediacodecenc.c | 294 +++-- > > libavcodec/version.h | 2 +- > 3 files changed, 256 insertions(+), 42 deletions(-) > Will apply tomorrow. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avcodec/jpeg2000dec: Move decoder structs to header files
From: caleb
This should pave way for HTJ2K decoding
---
libavcodec/jpeg2000dec.c | 96 +
libavcodec/jpeg2000dec.h | 126 +++
2 files changed, 127 insertions(+), 95 deletions(-)
create mode 100644 libavcodec/jpeg2000dec.h
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index c2b81ec103..7fc09cb558 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -42,101 +42,7 @@
#include "jpeg2000.h"
#include "jpeg2000dsp.h"
#include "profiles.h"
-
-#define JP2_SIG_TYPE0x6A502020
-#define JP2_SIG_VALUE 0x0D0A870A
-#define JP2_CODESTREAM 0x6A703263
-#define JP2_HEADER 0x6A703268
-
-#define HAD_COC 0x01
-#define HAD_QCC 0x02
-
-#define MAX_POCS 32
-
-typedef struct Jpeg2000POCEntry {
-uint16_t LYEpoc;
-uint16_t CSpoc;
-uint16_t CEpoc;
-uint8_t RSpoc;
-uint8_t REpoc;
-uint8_t Ppoc;
-} Jpeg2000POCEntry;
-
-typedef struct Jpeg2000POC {
-Jpeg2000POCEntry poc[MAX_POCS];
-int nb_poc;
-int is_default;
-} Jpeg2000POC;
-
-typedef struct Jpeg2000TilePart {
-uint8_t tile_index; // Tile index who refers the tile-part
-const uint8_t *tp_end;
-GetByteContext header_tpg; // bit stream of header if PPM header
is used
-GetByteContext tpg; // bit stream in tile-part
-} Jpeg2000TilePart;
-
-/* RMK: For JPEG2000 DCINEMA 3 tile-parts in a tile
- * one per component, so tile_part elements have a size of 3 */
-typedef struct Jpeg2000Tile {
-Jpeg2000Component *comp;
-uint8_t properties[4];
-Jpeg2000CodingStyle codsty[4];
-Jpeg2000QuantStyle qntsty[4];
-Jpeg2000POC poc;
-Jpeg2000TileParttile_part[32];
-uint8_t has_ppt;// whether this tile has a ppt
marker
-uint8_t *packed_headers;// contains packed headers.
Used only along with PPT marker
-int packed_headers_size;// size in bytes of the packed
headers
-GetByteContext packed_headers_stream; // byte context corresponding
to packed headers
-uint16_t tp_idx;// Tile-part index
-int coord[2][2];// border coordinates {{x0, x1}, {y0,
y1}}
-} Jpeg2000Tile;
-
-typedef struct Jpeg2000DecoderContext {
-AVClass *class;
-AVCodecContext *avctx;
-GetByteContext g;
-
-int width, height;
-int image_offset_x, image_offset_y;
-int tile_offset_x, tile_offset_y;
-uint8_t cbps[4];// bits per sample in particular components
-uint8_t sgnd[4];// if a component is signed
-uint8_t properties[4];
-
-uint8_t has_ppm;
-uint8_t *packed_headers; // contains packed headers. Used only
along with PPM marker
-int packed_headers_size;
-GetByteContext packed_headers_stream;
-uint8_t in_tile_headers;
-
-int cdx[4], cdy[4];
-int precision;
-int ncomponents;
-int colour_space;
-uint32_tpalette[256];
-int8_t pal8;
-int cdef[4];
-int tile_width, tile_height;
-unsignednumXtiles, numYtiles;
-int maxtilelen;
-AVRational sar;
-
-Jpeg2000CodingStyle codsty[4];
-Jpeg2000QuantStyle qntsty[4];
-Jpeg2000POC poc;
-uint8_t roi_shift[4];
-
-int bit_index;
-
-int curtileno;
-
-Jpeg2000Tile*tile;
-Jpeg2000DSPContext dsp;
-
-/*options parameters*/
-int reduction_factor;
-} Jpeg2000DecoderContext;
+#include "jpeg2000dec.h"
/* get_bits functions for JPEG2000 packet bitstream
* It is a get_bit function with a bit-stuffing routine. If the value of the
diff --git a/libavcodec/jpeg2000dec.h b/libavcodec/jpeg2000dec.h
new file mode 100644
index 00..b6410c1432
--- /dev/null
+++ b/libavcodec/jpeg2000dec.h
@@ -0,0 +1,126 @@
+/*
+ * JPEG 2000 image decoder
+ * Copyright (c) 2007 Kamil Nowosad
+ * Copyright (c) 2013 Nicolas Bertrand
+ * Copyright (c) 2022 Caleb Etemesi
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 U
[FFmpeg-devel] [PATCH 2/2] avcodec/jpeg2000dec: Add support for High Throughput HTJ2K decoding.
From: caleb
This is a revised patch with suggested changes from earlier and satisfies the
Google Summer of
Code 2022 FFmpeg project to add a HTJ2K decoder to FFmpeg.
---
libavcodec/Makefile|2 +-
libavcodec/jpeg2000.h |3 +
libavcodec/jpeg2000dec.c | 69 +-
libavcodec/jpeg2000dec.h |2 +
libavcodec/jpeg2000htdec.c | 1441
libavcodec/jpeg2000htdec.h | 28 +
6 files changed, 1529 insertions(+), 16 deletions(-)
create mode 100644 libavcodec/jpeg2000htdec.c
create mode 100644 libavcodec/jpeg2000htdec.h
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 98841ed07c..1ba9e09528 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -464,7 +464,7 @@ OBJS-$(CONFIG_JACOSUB_DECODER) += jacosubdec.o ass.o
OBJS-$(CONFIG_JPEG2000_ENCODER)+= j2kenc.o mqcenc.o mqc.o jpeg2000.o \
jpeg2000dwt.o
OBJS-$(CONFIG_JPEG2000_DECODER)+= jpeg2000dec.o jpeg2000.o
jpeg2000dsp.o \
- jpeg2000dwt.o mqcdec.o mqc.o
+ jpeg2000dwt.o mqcdec.o mqc.o
jpeg2000htdec.o
OBJS-$(CONFIG_JPEGLS_DECODER) += jpeglsdec.o jpegls.o
OBJS-$(CONFIG_JPEGLS_ENCODER) += jpeglsenc.o jpegls.o
OBJS-$(CONFIG_JV_DECODER) += jvdec.o
diff --git a/libavcodec/jpeg2000.h b/libavcodec/jpeg2000.h
index e5ecb4cbf9..b2a8e13244 100644
--- a/libavcodec/jpeg2000.h
+++ b/libavcodec/jpeg2000.h
@@ -189,6 +189,9 @@ typedef struct Jpeg2000Cblk {
Jpeg2000Pass *passes;
Jpeg2000Layer *layers;
int coord[2][2]; // border coordinates {{x0, x1}, {y0, y1}}
+/*HTJ2K settings */
+int zbp;
+int pass_lengths[2];
} Jpeg2000Cblk; // code block
typedef struct Jpeg2000Prec {
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 7fc09cb558..5c92baa88e 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -43,6 +43,7 @@
#include "jpeg2000dsp.h"
#include "profiles.h"
#include "jpeg2000dec.h"
+#include "jpeg2000htdec.h"
/* get_bits functions for JPEG2000 packet bitstream
* It is a get_bit function with a bit-stuffing routine. If the value of the
@@ -428,12 +429,13 @@ static int get_cox(Jpeg2000DecoderContext *s,
Jpeg2000CodingStyle *c)
c->cblk_style = bytestream2_get_byteu(&s->g);
if (c->cblk_style != 0) { // cblk style
if (c->cblk_style & JPEG2000_CTSY_HTJ2K_M || c->cblk_style &
JPEG2000_CTSY_HTJ2K_F) {
-av_log(s->avctx, AV_LOG_ERROR, "Support for High throughput JPEG
2000 is not yet available\n");
-return AVERROR_PATCHWELCOME;
+av_log(s->avctx,AV_LOG_TRACE,"High Throughput jpeg 2000
codestream.\n");
+s->is_htj2k = 1;
+} else {
+av_log(s->avctx, AV_LOG_WARNING, "extra cblk styles %X\n",
c->cblk_style);
+if (c->cblk_style & JPEG2000_CBLK_BYPASS)
+av_log(s->avctx, AV_LOG_WARNING, "Selective arithmetic coding
bypass\n");
}
-av_log(s->avctx, AV_LOG_WARNING, "extra cblk styles %X\n",
c->cblk_style);
-if (c->cblk_style & JPEG2000_CBLK_BYPASS)
-av_log(s->avctx, AV_LOG_WARNING, "Selective arithmetic coding
bypass\n");
}
c->transform = bytestream2_get_byteu(&s->g); // DWT transformation type
/* set integer 9/7 DWT in case of BITEXACT flag */
@@ -1058,13 +1060,15 @@ static int
jpeg2000_decode_packet(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile,
return incl;
if (!cblk->npasses) {
-int v = expn[bandno] + numgbits - 1 -
-tag_tree_decode(s, prec->zerobits + cblkno, 100);
+int zbp = tag_tree_decode(s,prec->zerobits + cblkno, 100);
+int v = expn[bandno] + numgbits - 1 - zbp;
+
if (v < 0 || v > 30) {
av_log(s->avctx, AV_LOG_ERROR,
"nonzerobits %d invalid or unsupported\n", v);
return AVERROR_INVALIDDATA;
}
+cblk->zbp = zbp;
cblk->nonzerobits = v;
}
if ((newpasses = getnpasses(s)) < 0)
@@ -1105,8 +1109,29 @@ static int jpeg2000_decode_packet(Jpeg2000DecoderContext
*s, Jpeg2000Tile *tile,
}
}
-if ((ret = get_bits(s, av_log2(newpasses1) + cblk->lblock)) <
0)
-return ret;
+if (newpasses > 1 && s->is_htj2k) {
+// Retrieve pass lengths for each pass
+int href_passes = (cblk->npasses + newpasses - 1) % 3;
+int segment_passes = newpasses - href_passes;
+int pass_bound = 2;
+int eb = 0;
+int extra_bit = newpasses > 2 ? 1 : 0;
+while (pass_bound <=segment_passes) {
+eb++;
+
[FFmpeg-devel] [REFUND-REQUEST] Dec 2 developer meeting
As alluded to by my previous email: Flight: 180.32 EUR Hotel (3 nights + breakfast): 287.40 EUR Shuttle bus: 5.90 EUR I unfortunately can't find receipts for the metro tickets and second bus ride back to the airport, so I've had to remove them from my refund request. That brings the total down to 473.62 EUR. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v14 9/9] avcodec/evc: Changes in Changelog and MAINTAINERS files
On Thu, Dec 15, 2022 at 02:11:28AM +0100, Lynne wrote: > Dec 14, 2022, 22:45 by mich...@niedermayer.cc: > > > On Tue, Dec 13, 2022 at 07:42:23PM +0100, Lynne wrote: > > > >> Dec 13, 2022, 13:22 by d.kozin...@samsung.com: > >> > >> > We made some changes in our EVC wrapper implementation and would like to > >> > submit new patches to patchwork, but it's still unclear to me how to deal > >> > with the MAINTAINERS file. > >> > > >> > Should I leave the following lines: > >> > + libxevd.c Dawid Kozinski > >> > + libxeve.c,Dawid Kozinski > >> > + evc.c, evc.hDawid Kozinski > >> > + evcdec.c Dawid Kozinski > >> > + evc_parser.c Dawid Kozinski > >> > > >> > or should I remove them? > >> > > >> > We are expecting a clear and consistent standpoint on this matter. > >> > > >> > >> Get rid of them. Michael has made it clear anyone on the list > >> must have commit rights. I'm not for blocking anyone from having > >> commit rights, but you've made zero contributions to the project > >> so far, and maintaining requires some level of dedication. > >> > > > > You surely have the right to object to Dawid having commit rights. > > And i understand your argument why, but that has nothing to do with > > me or the list. There are people on the MAINTAINERS list who do not > > have commit rights. > > for example the developers who i presume are paid by loongson to maintain > > the mips/loongson code do not currently have commit right. > > Seems a similar case to me > > > > You're making assumptions. You've said that anyone who's on maintainers > needs push rights. Then you said that unless someone explicitly asks not to > get push rights, they will if they're added to maintainers. Right now, the > person hasn't said anything, yet you're assuming he doesn't want push rights. There are many reasons why someone in MAINTAINERS might have no push access * lack of git knowledge * explicitly asked not to receive git write * messy patches submitted in the past * simply forgotten * a past reason which was not noticed that it no longer is true Once Dawids patches are applied, it will be easy to judge their quality based on the changes which where asked for in the review. One developer objected to Dawid having write access currently. If it was not for that i would tend toward giving Dawid write access if he wants to maintain the code. If he personally wants to maintain it or if he is paid to maintain it doesnt really matter. Whoever maintains code benefits from being able to change said code. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v14 9/9] avcodec/evc: Changes in Changelog and MAINTAINERS files
On Thu, Dec 15, 2022 at 10:14:40AM +0100, Dawid Kozinski/Multimedia (PLT)
/SRPOL/Staff Engineer/Samsung Electronics wrote:
>
>
>
>
> -Original Message-
> From: ffmpeg-devel On Behalf Of Michael
> Niedermayer
> Sent: środa, 14 grudnia 2022 22:36
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH v14 9/9] avcodec/evc: Changes in
> Changelog and MAINTAINERS files
>
> On Tue, Dec 13, 2022 at 08:33:29AM -0500, Ronald S. Bultje wrote:
> > Hi David,
> >
> > On Tue, Dec 13, 2022 at 7:22 AM Dawid Kozinski/Multimedia (PLT)
> > /SRPOL/Staff Engineer/Samsung Electronics wrote:
> >
> > > Should I leave the following lines:
> > > + libxevd.c Dawid Kozinski
> > > + libxeve.c,Dawid Kozinski
> > > + evc.c, evc.hDawid Kozinski
> > > + evcdec.c Dawid Kozinski
> > > + evc_parser.c Dawid Kozinski
> > >
> > > or should I remove them?
> > >
> >
> > Here's a question for you, and the answer probably becomes
> > self-evident from that. If you, Dawid, stop working for Samsung, for
> > example because you're starting your own business or Samsung fires you
> > or Google hires you, or if Samsung stops sponsoring this new codec
> > called "EVC" or stops contributing to this new library "libxeve". Will
> > you, Dawid, still maintain these files?
> >
> > If the answer is yes, then you can shorten these lines ("evc*.[ch]: Dawid"
> > & "livxev[ed].c: Dawid") and keep them.
> >
> > If the answer is no, then I think you should remove (or adjust) these
> > lines, since they are (in their current form) inaccurate: you are not
> > maintaining these files, your company is.
> >
>
> I think for code maintained by a company we still should list a person
> because persons can be contacted while large companies are sometimes very
> difficult to contact.
> maybe
> Dawid Kozinski (Samsung) or Samsung (Dawid Kozinski) or something like that
> would specify this better
>
> thx
>
> Hi,
> To be clear. We are not fighting for the right to push. The write access is
> not our goal at the moment.
> We just want to do our contribution to the FFMpeg project and provide
> support for the EVC codec and the only reason we've added entries to the
> MAINTENANCE file is to provide the information so others know who to contact
> about the codec.
>
> Yesterday I submitted new patches to the FFMepg patchwork and following what
> Lynne said I removed our entries from the MAINTENANCE file.
>
> However, If I understand you correctly, I shouldn't remove it, I should
> though leave the information in the file.
> So now I should restore what I removed.
> Correct me if I'm wrong cause it's a bit confusing.
I think the entry in some form is fine but
I would suggest to leave the entry out until the discussion with Lynne
reaches some consensus. And then after (we all mostly agree) add the entry
That way everyone can calmly discuss this
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add a separate list for those with push access
On Thu, Dec 15, 2022 at 02:13:49AM +0100, Lynne wrote: > This list is incomplete, and just contains those I could see > while looking at the recent git log. If it looks like I've forgotten you, I > definitely haven't! > We may complete the list at a later date. > > This makes it such that those who add themselves to MAINTAINERS do not > get push access by default, but rather, they have to request it > explicitly in a different commit. This used to be the situation > before it was changed at the start of this year and is pretty much what > everyone expects. > > Patch attached. > > MAINTAINERS | 15 +++ > 1 file changed, 15 insertions(+) > 6a083061d75f6655771bde377f96aadad19b21c6 > 0001-MAINTAINERS-add-a-separate-list-for-those-with-push-.patch > From 5c353412a25fd46c5077e5cf92ddfd6532eb46cb Mon Sep 17 00:00:00 2001 > From: Lynne > Date: Thu, 15 Dec 2022 02:05:00 +0100 > Subject: [PATCH] MAINTAINERS: add a separate list for those with push access > > This list is incomplete, and just contains those I could remember > while looking at the recent git log. > We may complete the list at a later date. > > This makes it such that those who add themselves to MAINTAINERS do not > get push access by default, but rather, they have to request it > explicitly in a different commit. > This used to be the situation > before it was changed at the start of this year. I remember no such change. What i do remember is really long ago trying to push people toward pushing in their own repository and sending pull requests similar to the kernel. But this was not popular so i droped the idea. Whereever code is maintained teh maintainer should have write access to that place other things become inconvenient quickly. maintainers who cannot change the code they maintain should stay an exception thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6] lavc: convert frame threading to the receive_frame() pattern
On Wed, Dec 14, 2022 at 02:50:59AM +0100, Timo Rothenpieler wrote: > From: Anton Khirnov > > Reorganize the code such that the frame threading code does not call the > decoders directly, but instead calls back into the generic decoding > code. This avoids duplicating the logic that wraps the decoder > invocation and will be useful in the following commits. > --- > libavcodec/decode.c| 62 ++--- > libavcodec/decode.h| 7 + > libavcodec/internal.h | 7 + > libavcodec/pthread_frame.c | 279 - > libavcodec/thread.h| 18 +-- > 5 files changed, 247 insertions(+), 126 deletions(-) i didnt review the code changes but seems working now thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] GSoC 2023
I have updated the page with the HTJ2K project. This is a good opportunity to ask for help completing the review of the patchset: https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=8078 All known issues have been resolved and it would be good to merge soon, i.e. beat the iron while it is hot. On Thu, Dec 15, 2022 at 6:47 AM Jean-Baptiste Kempf wrote: > > Hello, > > Also, please don’t copy paste ideas from previous years. If the idea did not > get picked up for years, it won’t be more useful this year. > > jb > > On Thu, 15 Dec 2022, at 15:42, Thilo Borgmann wrote: > > Hi, > > > > as we figured during the last dev meeting on December 2nd we want to > > apply again for GSoC 2023. > > > > I told mentors often enough already that it's a vital point in our > > applications to have a properly filled results page from the last GSoC > > we did. > > Last time no mentor cared about this - we can be quite sure that our > > application will fail if we don't have [1] up-to-date until we send our > > application. > > > > Also vital for the application are already existing project ideas so > > everyone interested in mentoring a project in 2023, please add your > > idea(s) to [2]. > > > > The application deadline is January 23rd, I will aim for sending an > > application mid January. > > > > Thanks, > > Thilo > > > > [1] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2022/Results > > [2] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2023 > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [REFUND-REQUEST] Dec 2 developer meeting
On Thu, Dec 15, 2022 at 8:11 PM Niklas Haas wrote: > > As alluded to by my previous email: > > Flight: 180.32 EUR > Hotel (3 nights + breakfast): 287.40 EUR > Shuttle bus: 5.90 EUR > > I unfortunately can't find receipts for the metro tickets and second bus > ride back to the airport, so I've had to remove them from my refund > request. That brings the total down to 473.62 EUR. Approved on my side, pending Michael's approval. Please follow these instructions to prepare and send the reimbursement form: https://www.spi-inc.org/treasurer/reimbursement-form/ and put me and Michael in CC: Let me know in private if you have issues with the paperwork. About the missing receipts, we can ask SPI officers if they have override mechanisms to cover such occurrences. Thanks, best regards, Stefano ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/jpeg2000dec: Move decoder structs to header files
etemesica...@gmail.com:
> From: caleb
>
> This should pave way for HTJ2K decoding
>
> ---
> libavcodec/jpeg2000dec.c | 96 +
> libavcodec/jpeg2000dec.h | 126 +++
> 2 files changed, 127 insertions(+), 95 deletions(-)
> create mode 100644 libavcodec/jpeg2000dec.h
>
> diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
> index c2b81ec103..7fc09cb558 100644
> --- a/libavcodec/jpeg2000dec.c
> +++ b/libavcodec/jpeg2000dec.c
> @@ -42,101 +42,7 @@
> #include "jpeg2000.h"
> #include "jpeg2000dsp.h"
> #include "profiles.h"
> -
> -#define JP2_SIG_TYPE0x6A502020
> -#define JP2_SIG_VALUE 0x0D0A870A
> -#define JP2_CODESTREAM 0x6A703263
> -#define JP2_HEADER 0x6A703268
> -
> -#define HAD_COC 0x01
> -#define HAD_QCC 0x02
> -
> -#define MAX_POCS 32
> -
> -typedef struct Jpeg2000POCEntry {
> -uint16_t LYEpoc;
> -uint16_t CSpoc;
> -uint16_t CEpoc;
> -uint8_t RSpoc;
> -uint8_t REpoc;
> -uint8_t Ppoc;
> -} Jpeg2000POCEntry;
> -
> -typedef struct Jpeg2000POC {
> -Jpeg2000POCEntry poc[MAX_POCS];
> -int nb_poc;
> -int is_default;
> -} Jpeg2000POC;
> -
> -typedef struct Jpeg2000TilePart {
> -uint8_t tile_index; // Tile index who refers the
> tile-part
> -const uint8_t *tp_end;
> -GetByteContext header_tpg; // bit stream of header if PPM
> header is used
> -GetByteContext tpg; // bit stream in tile-part
> -} Jpeg2000TilePart;
> -
> -/* RMK: For JPEG2000 DCINEMA 3 tile-parts in a tile
> - * one per component, so tile_part elements have a size of 3 */
> -typedef struct Jpeg2000Tile {
> -Jpeg2000Component *comp;
> -uint8_t properties[4];
> -Jpeg2000CodingStyle codsty[4];
> -Jpeg2000QuantStyle qntsty[4];
> -Jpeg2000POC poc;
> -Jpeg2000TileParttile_part[32];
> -uint8_t has_ppt;// whether this tile has a
> ppt marker
> -uint8_t *packed_headers;// contains packed headers.
> Used only along with PPT marker
> -int packed_headers_size;// size in bytes of the
> packed headers
> -GetByteContext packed_headers_stream; // byte context
> corresponding to packed headers
> -uint16_t tp_idx;// Tile-part index
> -int coord[2][2];// border coordinates {{x0, x1},
> {y0, y1}}
> -} Jpeg2000Tile;
> -
> -typedef struct Jpeg2000DecoderContext {
> -AVClass *class;
> -AVCodecContext *avctx;
> -GetByteContext g;
> -
> -int width, height;
> -int image_offset_x, image_offset_y;
> -int tile_offset_x, tile_offset_y;
> -uint8_t cbps[4];// bits per sample in particular components
> -uint8_t sgnd[4];// if a component is signed
> -uint8_t properties[4];
> -
> -uint8_t has_ppm;
> -uint8_t *packed_headers; // contains packed headers. Used only
> along with PPM marker
> -int packed_headers_size;
> -GetByteContext packed_headers_stream;
> -uint8_t in_tile_headers;
> -
> -int cdx[4], cdy[4];
> -int precision;
> -int ncomponents;
> -int colour_space;
> -uint32_tpalette[256];
> -int8_t pal8;
> -int cdef[4];
> -int tile_width, tile_height;
> -unsignednumXtiles, numYtiles;
> -int maxtilelen;
> -AVRational sar;
> -
> -Jpeg2000CodingStyle codsty[4];
> -Jpeg2000QuantStyle qntsty[4];
> -Jpeg2000POC poc;
> -uint8_t roi_shift[4];
> -
> -int bit_index;
> -
> -int curtileno;
> -
> -Jpeg2000Tile*tile;
> -Jpeg2000DSPContext dsp;
> -
> -/*options parameters*/
> -int reduction_factor;
> -} Jpeg2000DecoderContext;
> +#include "jpeg2000dec.h"
>
> /* get_bits functions for JPEG2000 packet bitstream
> * It is a get_bit function with a bit-stuffing routine. If the value of the
> diff --git a/libavcodec/jpeg2000dec.h b/libavcodec/jpeg2000dec.h
> new file mode 100644
> index 00..b6410c1432
> --- /dev/null
> +++ b/libavcodec/jpeg2000dec.h
> @@ -0,0 +1,126 @@
> +/*
> + * JPEG 2000 image decoder
> + * Copyright (c) 2007 Kamil Nowosad
> + * Copyright (c) 2013 Nicolas Bertrand
> + * Copyright (c) 2022 Caleb Etemesi
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY
Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add a separate list for those with push access
Dec 15, 2022, 20:34 by mich...@niedermayer.cc: > On Thu, Dec 15, 2022 at 02:13:49AM +0100, Lynne wrote: > >> This list is incomplete, and just contains those I could see >> while looking at the recent git log. If it looks like I've forgotten you, I >> definitely haven't! >> We may complete the list at a later date. >> >> This makes it such that those who add themselves to MAINTAINERS do not >> get push access by default, but rather, they have to request it >> explicitly in a different commit. This used to be the situation >> before it was changed at the start of this year and is pretty much what >> everyone expects. >> >> Patch attached. >> >> MAINTAINERS | 15 +++ >> 1 file changed, 15 insertions(+) >> 6a083061d75f6655771bde377f96aadad19b21c6 >> 0001-MAINTAINERS-add-a-separate-list-for-those-with-push-.patch >> From 5c353412a25fd46c5077e5cf92ddfd6532eb46cb Mon Sep 17 00:00:00 2001 >> From: Lynne >> Date: Thu, 15 Dec 2022 02:05:00 +0100 >> Subject: [PATCH] MAINTAINERS: add a separate list for those with push access >> >> This list is incomplete, and just contains those I could remember >> while looking at the recent git log. >> We may complete the list at a later date. >> >> This makes it such that those who add themselves to MAINTAINERS do not >> get push access by default, but rather, they have to request it >> explicitly in a different commit. >> >> This used to be the situation >> before it was changed at the start of this year. >> > > I remember no such change. > What i do remember is really long ago trying to push people toward pushing in > their own repository and sending pull requests similar to the kernel. But this > was not popular so i droped the idea. > > Whereever code is maintained teh maintainer should have write access to that > place other things become inconvenient quickly. > > maintainers who cannot change the code they maintain should stay an exception > This is exactly what changed. Before, maintainers who didn't get push access was the norm, not the standard. Regardless, if you agree with the patch, I see no reason to continue discussing this. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/jpeg2000dec: Add support for High Throughput HTJ2K decoding.
etemesica...@gmail.com:
> From: caleb
>
> This is a revised patch with suggested changes from earlier and satisfies the
> Google Summer of
> Code 2022 FFmpeg project to add a HTJ2K decoder to FFmpeg.
>
> ---
> libavcodec/Makefile|2 +-
> libavcodec/jpeg2000.h |3 +
> libavcodec/jpeg2000dec.c | 69 +-
> libavcodec/jpeg2000dec.h |2 +
> libavcodec/jpeg2000htdec.c | 1441
> libavcodec/jpeg2000htdec.h | 28 +
> 6 files changed, 1529 insertions(+), 16 deletions(-)
> create mode 100644 libavcodec/jpeg2000htdec.c
> create mode 100644 libavcodec/jpeg2000htdec.h
>
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 98841ed07c..1ba9e09528 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -464,7 +464,7 @@ OBJS-$(CONFIG_JACOSUB_DECODER) += jacosubdec.o
> ass.o
> OBJS-$(CONFIG_JPEG2000_ENCODER)+= j2kenc.o mqcenc.o mqc.o jpeg2000.o
> \
>jpeg2000dwt.o
> OBJS-$(CONFIG_JPEG2000_DECODER)+= jpeg2000dec.o jpeg2000.o
> jpeg2000dsp.o \
> - jpeg2000dwt.o mqcdec.o mqc.o
> + jpeg2000dwt.o mqcdec.o mqc.o
> jpeg2000htdec.o
> OBJS-$(CONFIG_JPEGLS_DECODER) += jpeglsdec.o jpegls.o
> OBJS-$(CONFIG_JPEGLS_ENCODER) += jpeglsenc.o jpegls.o
> OBJS-$(CONFIG_JV_DECODER) += jvdec.o
> diff --git a/libavcodec/jpeg2000.h b/libavcodec/jpeg2000.h
> index e5ecb4cbf9..b2a8e13244 100644
> --- a/libavcodec/jpeg2000.h
> +++ b/libavcodec/jpeg2000.h
> @@ -189,6 +189,9 @@ typedef struct Jpeg2000Cblk {
> Jpeg2000Pass *passes;
> Jpeg2000Layer *layers;
> int coord[2][2]; // border coordinates {{x0, x1}, {y0, y1}}
> +/*HTJ2K settings */
> +int zbp;
> +int pass_lengths[2];
> } Jpeg2000Cblk; // code block
>
> typedef struct Jpeg2000Prec {
> diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
> index 7fc09cb558..5c92baa88e 100644
> --- a/libavcodec/jpeg2000dec.c
> +++ b/libavcodec/jpeg2000dec.c
> @@ -43,6 +43,7 @@
> #include "jpeg2000dsp.h"
> #include "profiles.h"
> #include "jpeg2000dec.h"
> +#include "jpeg2000htdec.h"
>
> /* get_bits functions for JPEG2000 packet bitstream
> * It is a get_bit function with a bit-stuffing routine. If the value of the
> @@ -428,12 +429,13 @@ static int get_cox(Jpeg2000DecoderContext *s,
> Jpeg2000CodingStyle *c)
> c->cblk_style = bytestream2_get_byteu(&s->g);
> if (c->cblk_style != 0) { // cblk style
> if (c->cblk_style & JPEG2000_CTSY_HTJ2K_M || c->cblk_style &
> JPEG2000_CTSY_HTJ2K_F) {
> -av_log(s->avctx, AV_LOG_ERROR, "Support for High throughput JPEG
> 2000 is not yet available\n");
> -return AVERROR_PATCHWELCOME;
> +av_log(s->avctx,AV_LOG_TRACE,"High Throughput jpeg 2000
> codestream.\n");
> +s->is_htj2k = 1;
> +} else {
> +av_log(s->avctx, AV_LOG_WARNING, "extra cblk styles %X\n",
> c->cblk_style);
> +if (c->cblk_style & JPEG2000_CBLK_BYPASS)
> +av_log(s->avctx, AV_LOG_WARNING, "Selective arithmetic
> coding bypass\n");
> }
> -av_log(s->avctx, AV_LOG_WARNING, "extra cblk styles %X\n",
> c->cblk_style);
> -if (c->cblk_style & JPEG2000_CBLK_BYPASS)
> -av_log(s->avctx, AV_LOG_WARNING, "Selective arithmetic coding
> bypass\n");
> }
> c->transform = bytestream2_get_byteu(&s->g); // DWT transformation type
> /* set integer 9/7 DWT in case of BITEXACT flag */
> @@ -1058,13 +1060,15 @@ static int
> jpeg2000_decode_packet(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile,
> return incl;
>
> if (!cblk->npasses) {
> -int v = expn[bandno] + numgbits - 1 -
> -tag_tree_decode(s, prec->zerobits + cblkno, 100);
> +int zbp = tag_tree_decode(s,prec->zerobits + cblkno, 100);
> +int v = expn[bandno] + numgbits - 1 - zbp;
> +
> if (v < 0 || v > 30) {
> av_log(s->avctx, AV_LOG_ERROR,
> "nonzerobits %d invalid or unsupported\n", v);
> return AVERROR_INVALIDDATA;
> }
> +cblk->zbp = zbp;
> cblk->nonzerobits = v;
> }
> if ((newpasses = getnpasses(s)) < 0)
> @@ -1105,8 +1109,29 @@ static int
> jpeg2000_decode_packet(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile,
> }
> }
>
> -if ((ret = get_bits(s, av_log2(newpasses1) + cblk->lblock))
> < 0)
> -return ret;
> +if (newpasses > 1 && s->is_htj2k) {
> +// Retrieve pass lengths for each pass
> +int href_passes = (cblk->npasses + newpasses - 1) % 3;
> +int segment_passes = newpass
[FFmpeg-devel] [PATCH] avcodec/mediacodec_wrapper: include stdbool.h
From: Zhao Zhili Since NDK failed to do that: https://github.com/android/ndk/issues/1281 --- libavcodec/mediacodec_wrapper.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c index 7ddf93ccc7..4d6e9487b8 100644 --- a/libavcodec/mediacodec_wrapper.c +++ b/libavcodec/mediacodec_wrapper.c @@ -22,6 +22,7 @@ #include #include +#include #include #include #include -- 2.35.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavfilter/dnn/dnn_backend_openvino.c: fix openvino async mode
> -Original Message- > From: ffmpeg-devel On Behalf Of > Saliev, Rafik F > Sent: Monday, December 12, 2022 6:31 PM > To: ffmpeg-devel@ffmpeg.org > Subject: [FFmpeg-devel] [PATCH] libavfilter/dnn/dnn_backend_openvino.c: > fix openvino async mode > > Bugfix: The OpenVino DNN backend in the 'async' mode sets 'task- > >inference_done' to 'complete' prior to data copy from OpenVino output > buffer to task's output frame. > This order causes task destroy in ff_dnn_get_result_common() prior to > model output processing. > > Signed-off-by: Rafik Saliev > --- > libavfilter/dnn/dnn_backend_openvino.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > There's a warning at https://patchwork.ffmpeg.org/project/ffmpeg/patch/ph7pr11mb5887f1a68c19249217a6c09eda...@ph7pr11mb5887.namprd11.prod.outlook.com/, please fix and send v2 patch, 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-requ...@ffmpeg.org with subject "unsubscribe".
