Re: [FFmpeg-devel] [FFmpeg-cvslog] doc/filters: clarify behaviour of weights in amix
I do not see this patch on the mailing list. -- Anton Khirnov ___ 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] [FFmpeg-cvslog] doc/filters: clarify behaviour of weights in amix
Quoting Gyan Doshi (2022-08-09 11:22:39) > I am a docs maintainer so I push these directly. All patches should go through the mailing list, so other people get the opportunity to comment on them. -- Anton Khirnov ___ 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] [FFmpeg-cvslog] doc/filters: clarify behaviour of weights in amix
On 2022-08-09 02:57 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2022-08-09 11:22:39) I am a docs maintainer so I push these directly. All patches should go through the mailing list, so other people get the opportunity to comment on them. I do that for more extensive changes. As the guidelines say, "Send your changes as patches to the ffmpeg-devel mailing list, and if the code maintainers say OK, you may commit. This does not apply to files you wrote and/or maintain." Regards, Gyan ___ 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] mov: Compare frag times in correct time base when seeking a stream without a corresponding sidx
> On Aug 3, 2022, at 9:18 PM, Derek Buitenhuis
> wrote:
>
> Some muxers, such as GPAC, create files with only one sidx, but two streams
> muxed into the same fragments pointed to by this sidx.
>
> Prevously, in such a case, when we seeked in such files, we fell back
> to, for example, using the sidx associated with the video stream, to
> seek the audio stream, leaving the seekhead in the wrong place.
>
> We can still do this, but we need to take care to compare timestamps
> in the same time base.
>
> Signed-off-by: Derek Buitenhuis
> ---
> libavformat/mov.c | 40 +---
> 1 file changed, 21 insertions(+), 19 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index a09a762d91..c101a1acdd 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -1271,15 +1271,18 @@ static int64_t
> get_stream_info_time(MOVFragmentStreamInfo * frag_stream_info)
> return frag_stream_info->tfdt_dts;
> }
>
> -static int64_t get_frag_time(MOVFragmentIndex *frag_index,
> - int index, int track_id)
> +static int64_t get_frag_time(AVFormatContext *s, AVStream *dst_st,
> + MOVFragmentIndex *frag_index, int index)
> {
> MOVFragmentStreamInfo * frag_stream_info;
> +MOVStreamContext *sc = dst_st->priv_data;
> int64_t timestamp;
> -int i;
> +int i, j;
>
> -if (track_id >= 0) {
> -frag_stream_info = get_frag_stream_info(frag_index, index, track_id);
> +// If the stream is referenced by any sidx, limit the search
> +// to fragments that referenced this stream in the sidx
> +if (sc->has_sidx) {
> +frag_stream_info = get_frag_stream_info(frag_index, index,
> dst_st->id);
> if (frag_stream_info->sidx_pts != AV_NOPTS_VALUE)
> return frag_stream_info->sidx_pts;
> if (frag_stream_info->first_tfra_pts != AV_NOPTS_VALUE)
> @@ -1288,28 +1291,27 @@ static int64_t get_frag_time(MOVFragmentIndex
> *frag_index,
> }
>
> for (i = 0; i < frag_index->item[index].nb_stream_info; i++) {
> +AVStream *frag_stream = NULL;
> frag_stream_info = &frag_index->item[index].stream_info[i];
> +for (j = 0; j < s->nb_streams; j++)
> +if (s->streams[j]->id == frag_stream_info->id)
> +frag_stream = s->streams[j];
> timestamp = get_stream_info_time(frag_stream_info);
> -if (timestamp != AV_NOPTS_VALUE)
> -return timestamp;
> +if (timestamp != AV_NOPTS_VALUE) {
> +if (frag_stream)
> +return av_rescale_q(timestamp, frag_stream->time_base,
> dst_st->time_base);
> +else
> +return timestamp;
It’s suspicious to return a timestamp with unknown timebase.
> +}
> }
> return AV_NOPTS_VALUE;
> }
>
> -static int search_frag_timestamp(MOVFragmentIndex *frag_index,
> +static int search_frag_timestamp(AVFormatContext *s, MOVFragmentIndex
> *frag_index,
> AVStream *st, int64_t timestamp)
> {
> int a, b, m, m0;
> int64_t frag_time;
> -int id = -1;
> -
> -if (st) {
> -// If the stream is referenced by any sidx, limit the search
> -// to fragments that referenced this stream in the sidx
> -MOVStreamContext *sc = st->priv_data;
> -if (sc->has_sidx)
> -id = st->id;
> -}
>
> a = -1;
> b = frag_index->nb_items;
> @@ -1318,7 +1320,7 @@ static int search_frag_timestamp(MOVFragmentIndex
> *frag_index,
> m0 = m = (a + b) >> 1;
>
> while (m < b &&
> - (frag_time = get_frag_time(frag_index, m, id)) ==
> AV_NOPTS_VALUE)
> + (frag_time = get_frag_time(s, st, frag_index, m)) ==
> AV_NOPTS_VALUE)
> m++;
>
> if (m < b && frag_time <= timestamp)
> @@ -8806,7 +8808,7 @@ static int mov_seek_fragment(AVFormatContext *s,
> AVStream *st, int64_t timestamp
> if (!mov->frag_index.complete)
> return 0;
>
> -index = search_frag_timestamp(&mov->frag_index, st, timestamp);
> +index = search_frag_timestamp(s, &mov->frag_index, st, timestamp);
> if (index < 0)
> index = 0;
> if (!mov->frag_index.item[index].headers_read)
> --
> 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".
Re: [FFmpeg-devel] [FFmpeg-cvslog] doc/filters: clarify behaviour of weights in amix
Quoting Gyan Doshi (2022-08-09 11:36:22) > > > On 2022-08-09 02:57 pm, Anton Khirnov wrote: > > Quoting Gyan Doshi (2022-08-09 11:22:39) > >> I am a docs maintainer so I push these directly. > > All patches should go through the mailing list, so other people get the > > opportunity to comment on them. > > I do that for more extensive changes. > > As the guidelines say, > > "Send your changes as patches to the ffmpeg-devel mailing list, and if > the code maintainers say OK, you may commit. This does not apply to > files you wrote and/or maintain." That documentation is outdated, almost nobody pushes directly anymore without submitting patches to the ML. I also see no good reason to NOT make the patches public. Being a maintainer does not make one infallible. -- Anton Khirnov ___ 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] [FFmpeg-cvslog] doc/filters: clarify behaviour of weights in amix
On 2022-08-09 03:15 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2022-08-09 11:36:22) On 2022-08-09 02:57 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2022-08-09 11:22:39) I am a docs maintainer so I push these directly. All patches should go through the mailing list, so other people get the opportunity to comment on them. I do that for more extensive changes. As the guidelines say, "Send your changes as patches to the ffmpeg-devel mailing list, and if the code maintainers say OK, you may commit. This does not apply to files you wrote and/or maintain." That documentation is outdated, almost nobody pushes directly anymore without submitting patches to the ML. Patch welcome. Regards, Gyan ___ 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] [FFmpeg-cvslog] doc/filters: clarify behaviour of weights in amix
On Tue, Aug 9, 2022 at 5:36 PM Gyan Doshi wrote: > > > On 2022-08-09 02:57 pm, Anton Khirnov wrote: > > Quoting Gyan Doshi (2022-08-09 11:22:39) > >> I am a docs maintainer so I push these directly. > > All patches should go through the mailing list, so other people get the > > opportunity to comment on them. > > I do that for more extensive changes. > > As the guidelines say, > > "Send your changes as patches to the ffmpeg-devel mailing list and if > the code maintainers say OK, you may commit. This does not apply to > files you wrote and/or maintain." That should make the intent of the sentence quoted clear. Ronald > ___ 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] [FFmpeg-cvslog] doc/filters: clarify behaviour of weights in amix
On 2022-08-09 04:00 pm, Ronald S. Bultje wrote: On Tue, Aug 9, 2022 at 5:36 PM Gyan Doshi wrote: On 2022-08-09 02:57 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2022-08-09 11:22:39) I am a docs maintainer so I push these directly. All patches should go through the mailing list, so other people get the opportunity to comment on them. I do that for more extensive changes. As the guidelines say, "Send your changes as patches to the ffmpeg-devel mailing list and if the code maintainers say OK, you may commit. This does not apply to files you wrote and/or maintain." That should make the intent of the sentence quoted clear. 'This' refers to the entire preceding sentence. If it was otherwise, it would be incompatible with the 2nd way mentioned at http://www.ffmpeg.org/developer.html#Contributing I'm not wedded to the policy as stated in the current docs, but the current docs are clear that maintainers can push directly. Doc patch(es) welcome. Regards, Gyan ___ 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] avcodec/mpegpicture: Move mb_var, mc_mb_var and mb_mean to MpegEncCtx
Andreas Rheinhardt:
> These tables are only used by encoders and only for the current picture;
> ergo they need not be put into the picture at all, but rather into
> the encoder's context. They also don't need to be refcounted,
> because there is only one owner.
>
> In contrast to this, the earlier code refcounts them which
> incurs unnecessary overhead. These references are not unreferenced
> in ff_mpeg_unref_picture() (they are kept in order to have something
> like a buffer pool), so that several buffers are kept at the same
> time, although only one is needed, thereby wasting memory.
>
> The code also propagates references to other pictures not part of
> the pictures array (namely the copy of the current/next/last picture
> in the MpegEncContext which get references of their own). These
> references are not unreferenced in ff_mpeg_unref_picture() (the
> buffers are probably kept in order to have something like a pool),
> yet if the current picture is a B-frame, it gets unreferenced
> at the end of ff_mpv_encode_picture() and its slot in the picture
> array will therefore be reused the next time; but the copy of the
> current picture also still has its references and therefore
> these buffers will be made duplicated in order to make them writable
> in the next call to ff_mpv_encode_picture(). This is of course
> unnecessary.
>
> Finally, ff_find_unused_picture() is supposed to just return
> any unused picture and the code is supposed to work with it;
> yet for the vsynth*-mpeg4-adap tests the result depends upon
> the content of these buffers; given that this patchset
> changes the content of these buffers (the initial content is now
> the state of these buffers after encoding the last frame;
> before this patch the buffers used came from the last picture
> that occupied the same slot in the picture array) their ref-files
> needed to be changed. This points to a bug somewhere (if one removes
> the initialization, one gets uninitialized reads in
> adaptive_quantization in ratecontrol.c).
>
> Signed-off-by: Andreas Rheinhardt
> ---
> The decoder-part of the vsynth*-h263-obmc tests also has problems
> with returning random pictures in ff_find_unused_picture().
> Probably a bug in preview_obmc() or so. Anyway, next thing is to
> add proper buffer-pools for these buffers to remove the
> needs_realloc-hack.
>
> libavcodec/motion_est.c | 14 ++--
> libavcodec/mpegpicture.c| 30 ++---
> libavcodec/mpegpicture.h| 9
> libavcodec/mpegvideo.h | 6 +
> libavcodec/mpegvideo_enc.c | 17 ++
> libavcodec/ratecontrol.c| 7 +++---
> libavcodec/svq1enc.c| 6 ++---
> tests/ref/seek/vsynth_lena-mpeg4-adap | 28 +++
> tests/ref/vsynth/vsynth1-mpeg4-adap | 8 +++
> tests/ref/vsynth/vsynth2-mpeg4-adap | 8 +++
> tests/ref/vsynth/vsynth3-mpeg4-adap | 8 +++
> tests/ref/vsynth/vsynth_lena-mpeg4-adap | 8 +++
> 12 files changed, 64 insertions(+), 85 deletions(-)
>
> diff --git a/libavcodec/motion_est.c b/libavcodec/motion_est.c
> index 29ab41dc8c..d17ffe42b4 100644
> --- a/libavcodec/motion_est.c
> +++ b/libavcodec/motion_est.c
> @@ -895,7 +895,6 @@ void ff_estimate_p_frame_motion(MpegEncContext * s,
> int P[10][2];
> const int shift= 1+s->quarter_sample;
> int mb_type=0;
> -Picture * const pic= &s->current_picture;
>
> init_ref(c, s->new_picture->data, s->last_picture.f->data, NULL,
> 16*mb_x, 16*mb_y, 0);
>
> @@ -917,8 +916,8 @@ void ff_estimate_p_frame_motion(MpegEncContext * s,
> varc = s->mpvencdsp.pix_norm1(pix, s->linesize) -
> (((unsigned) sum * sum) >> 8) + 500;
>
> -pic->mb_mean[s->mb_stride * mb_y + mb_x] = (sum+128)>>8;
> -pic->mb_var [s->mb_stride * mb_y + mb_x] = (varc+128)>>8;
> +s->mb_mean[s->mb_stride * mb_y + mb_x] = (sum+128)>>8;
> +s->mb_var [s->mb_stride * mb_y + mb_x] = (varc+128)>>8;
> c->mb_var_sum_temp += (varc+128)>>8;
>
> if (s->motion_est != FF_ME_ZERO) {
> @@ -965,7 +964,7 @@ void ff_estimate_p_frame_motion(MpegEncContext * s,
>
> vard = s->mecc.sse[0](NULL, pix, ppix, s->linesize, 16);
>
> -pic->mc_mb_var[s->mb_stride * mb_y + mb_x] = (vard+128)>>8;
> +s->mc_mb_var[s->mb_stride * mb_y + mb_x] = (vard+128)>>8;
> c->mc_mb_var_sum_temp += (vard+128)>>8;
>
> if (c->avctx->mb_decision > FF_MB_DECISION_SIMPLE) {
> @@ -1509,7 +1508,7 @@ void ff_estimate_b_frame_motion(MpegEncContext * s,
>
> score= ((unsigned)(score*score + 128*256))>>16;
> c->mc_mb_var_sum_temp += score;
> -s->current_picture.mc_mb_var[mb_y*s->mb_stride + mb_x] = score;
> //FIXME use SSE
> +s->mc_mb_var[mb_y*s->mb_stride + mb_x] = score; //FIXME use SSE
> s->mb_type[mb_y*s->mb_stride + mb_x]= CANDIDATE_MB_TYPE_DIRECT0;
>
> return;
> @@ -1574,7 +1573,7
Re: [FFmpeg-devel] [RFC] git and signing commits and tags
On Tue, Aug 09, 2022 at 12:36:53AM +0200, Michael Niedermayer wrote: > On Mon, Aug 08, 2022 at 09:26:52PM +0200, Lynne wrote: > > Aug 8, 2022, 16:50 by mich...@niedermayer.cc: > > > > > Given the recent server issues, i wonder if we should suggest/recommand > > > and document signing commits and tags > > > > > > i tried to push such commit to github and it nicely says "verified" > > > https://github.com/michaelni/FFmpeg/commit/75f196acd16fb0c0ca7a94f0c66072e7c6f736bf > > > > > > Ive generated a new gpg key for this experiment as i dont have my > > > main key on the box used for git development and also using more > > > modern eliptic curve stuff (smaller keys & sigs) > > > i will upload this key to the keyservers in case it becomes the > > > one i use for git. > > > > > > > I sign all of my commits, > > I didnt notice, but thats good as it also proofs it works with no ill > sideeffects > > Where can i find your public key ? it seems its not on the keyservers i > checked Your key seems only on openpgp.org but that strips userids unless the owner approves it (i presume for GDPR) making the key not work gpg --keyserver hkps://keys.openpgp.org --recv-keys FE50139C680572CAFD521F8DA2FEA5F03F034464 gpg: key A2FEA5F03F034464: no user ID gpg: Total number processed: 1 gpg --list-keys FE50139C680572CAFD521F8DA2FEA5F03F034464 gpg: error reading key: No public key gpg --recv-keys FE50139C680572CAFD521F8DA2FEA5F03F034464 gpg: keyserver receive failed: No data [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Homeopathy is like voting while filling the ballot out with transparent ink. Sometimes the outcome one wanted occurs. Rarely its worse than filling out a ballot properly. 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 1/3] checkasm/hevc_add_res: add 12bit test
On Thu, 23 Jun 2022, J. Dekker wrote:
Signed-off-by: J. Dekker
---
tests/checkasm/hevc_add_res.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/tests/checkasm/hevc_add_res.c b/tests/checkasm/hevc_add_res.c
index 0c896adaca..f17d121939 100644
--- a/tests/checkasm/hevc_add_res.c
+++ b/tests/checkasm/hevc_add_res.c
@@ -36,14 +36,14 @@
} \
} while (0)
-#define randomize_buffers2(buf, size) \
+#define randomize_buffers2(buf, size, mask) \
do { \
int j;\
for (j = 0; j < size; j++)\
-AV_WN16A(buf + j * 2, rnd() & 0x3FF); \
+AV_WN16A(buf + j * 2, rnd() & mask); \
} while (0)
-static void compare_add_res(int size, ptrdiff_t stride, int overflow_test)
+static void compare_add_res(int size, ptrdiff_t stride, int overflow_test, int
mask)
{
LOCAL_ALIGNED_32(int16_t, res0, [32 * 32]);
LOCAL_ALIGNED_32(int16_t, res1, [32 * 32]);
@@ -53,7 +53,7 @@ static void compare_add_res(int size, ptrdiff_t stride, int
overflow_test)
declare_func_emms(AV_CPU_FLAG_MMX, void, uint8_t *dst, int16_t *res,
ptrdiff_t stride);
randomize_buffers(res0, size);
-randomize_buffers2(dst0, size);
+randomize_buffers2(dst0, size, mask);
if (overflow_test)
res0[0] = 0x8000;
memcpy(res1, res0, sizeof(*res0) * size);
@@ -69,6 +69,7 @@ static void compare_add_res(int size, ptrdiff_t stride, int
overflow_test)
static void check_add_res(HEVCDSPContext h, int bit_depth)
{
int i;
+int mask = bit_depth == 8 ? 0x : bit_depth == 10 ? 0x03FF : 0x07FF;
Previously we always used the mask 0x03FF, while we now use 0x for 8
bit. I presume that means that for 8 bit, we mask two pixels with one
0x (and keep all bits), and previously we accidentally masked out
everything but the lowest two bits, from every other pixel, in 8 bit mode?
The patch LGTM, but it'd be good to acknowledge this existing issue in the
commit message.
// Martin
___
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] [RFC] git and signing commits and tags
On Tue, Aug 09, 2022 at 12:59:52PM +0200, Michael Niedermayer wrote: > On Tue, Aug 09, 2022 at 12:36:53AM +0200, Michael Niedermayer wrote: > > On Mon, Aug 08, 2022 at 09:26:52PM +0200, Lynne wrote: > > > Aug 8, 2022, 16:50 by mich...@niedermayer.cc: > > > > > > > Given the recent server issues, i wonder if we should suggest/recommand > > > > and document signing commits and tags > > > > > > > > i tried to push such commit to github and it nicely says "verified" > > > > https://github.com/michaelni/FFmpeg/commit/75f196acd16fb0c0ca7a94f0c66072e7c6f736bf > > > > > > > > Ive generated a new gpg key for this experiment as i dont have my > > > > main key on the box used for git development and also using more > > > > modern eliptic curve stuff (smaller keys & sigs) > > > > i will upload this key to the keyservers in case it becomes the > > > > one i use for git. > > > > > > > > > > I sign all of my commits, > > > > I didnt notice, but thats good as it also proofs it works with no ill > > sideeffects > > > > Where can i find your public key ? it seems its not on the keyservers i > > checked > > Your key seems only on openpgp.org but that strips userids unless the owner > approves it > (i presume for GDPR) making the key not work > > gpg --keyserver hkps://keys.openpgp.org --recv-keys > FE50139C680572CAFD521F8DA2FEA5F03F034464 > gpg: key A2FEA5F03F034464: no user ID > gpg: Total number processed: 1 > > gpg --list-keys FE50139C680572CAFD521F8DA2FEA5F03F034464 > gpg: error reading key: No public key > > gpg --recv-keys FE50139C680572CAFD521F8DA2FEA5F03F034464 > gpg: keyserver receive failed: No data found your key with google here: https://lynne.ee/extra/A2FEA5F03F034464.asc thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. 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 2/3] lavc/aarch64: reformat add_res funcs
On Thu, 23 Jun 2022, J. Dekker wrote: Signed-off-by: J. Dekker --- libavcodec/aarch64/hevcdsp_idct_neon.S | 216 - 1 file changed, 108 insertions(+), 108 deletions(-) LGTM, thanks! // Martin ___ 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 3/3] lavc/aarch64: hevc_add_res add 12bit variants
On Thu, 23 Jun 2022, J. Dekker wrote: hevc_add_res_4x4_12_c: 46.0 hevc_add_res_4x4_12_neon: 18.7 hevc_add_res_8x8_12_c: 194.7 hevc_add_res_8x8_12_neon: 25.2 hevc_add_res_16x16_12_c: 716.0 hevc_add_res_16x16_12_neon: 69.7 hevc_add_res_32x32_12_c: 3820.7 hevc_add_res_32x32_12_neon: 261.0 Signed-off-by: J. Dekker --- libavcodec/aarch64/hevcdsp_idct_neon.S| 148 -- libavcodec/aarch64/hevcdsp_init_aarch64.c | 34 ++--- 2 files changed, 97 insertions(+), 85 deletions(-) LGTM. The patch is a bit hard to inspect thoroughly (to see exactly how little has changed) due to the functions being moved around at the same time as they're modified, but I checked and the changes do look fine. By splitting things up in individual macros for each function, (e.g. add_res_4x4, add_res_8x8 etc, then add_res setting the mask and calling the others) you could keep the code in place and make the diff even easier to read, but it's not strictly necessary. // Martin ___ 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 3/3] lavc/aarch64: hevc_add_res add 12bit variants
On Tue, 9 Aug 2022, Martin Storsjö wrote: On Thu, 23 Jun 2022, J. Dekker wrote: hevc_add_res_4x4_12_c: 46.0 hevc_add_res_4x4_12_neon: 18.7 hevc_add_res_8x8_12_c: 194.7 hevc_add_res_8x8_12_neon: 25.2 hevc_add_res_16x16_12_c: 716.0 hevc_add_res_16x16_12_neon: 69.7 hevc_add_res_32x32_12_c: 3820.7 hevc_add_res_32x32_12_neon: 261.0 Signed-off-by: J. Dekker --- libavcodec/aarch64/hevcdsp_idct_neon.S| 148 -- libavcodec/aarch64/hevcdsp_init_aarch64.c | 34 ++--- 2 files changed, 97 insertions(+), 85 deletions(-) LGTM. The patch is a bit hard to inspect thoroughly (to see exactly how little has changed) due to the functions being moved around at the same time as they're modified, but I checked and the changes do look fine. By splitting things up in individual macros for each function, (e.g. add_res_4x4, add_res_8x8 etc, then add_res setting the mask and calling the others) you could keep the code in place and make the diff even easier to read, but it's not strictly necessary. Actually, I do want you to make a change here. The only single thing that differs between the 10 and 12 bit versions, is what the mask register is initialized to. It's totally a waste of space to produce two near-identical versions of everything. Instead I'd suggest making just two frontend functions, which sets the mask register and then calls the (non-exported) 16 bit generic function. Also, have a look at e.g. vp9mc_16bpp_neon.S, where we have something similar: .macro do_8tap_v_func type, filter, offset, size, bpp function ff_vp9_\type\()_\filter\()\size\()_v_\bpp\()_neon, export=1 uxtwx4, w4 mvniv1.8h, #((0xff << (\bpp - 8)) & 0xff), lsl #8 movrel x5, X(ff_vp9_subpel_filters), 256*\offset add x6, x5, w6, uxtw #4 mov x5, #\size .if \size >= 8 b \type\()_8tap_8v ... For your case, you don't need anything else than the mvni instruction and then a branch to the actual implementation. // Martin ___ 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] [RFC] git and signing commits and tags
Hi, Am Montag, 8. August 2022, 21:26:52 CEST schrieb Lynne: > Aug 8, 2022, 16:50 by mich...@niedermayer.cc: > > > Given the recent server issues, i wonder if we should suggest/recommand > > and document signing commits and tags > > > > i tried to push such commit to github and it nicely says "verified" > > https://github.com/michaelni/FFmpeg/commit/75f196acd16fb0c0ca7a94f0c66072e7c6f736bf > > > > Ive generated a new gpg key for this experiment as i dont have my > > main key on the box used for git development and also using more > > modern eliptic curve stuff (smaller keys & sigs) > > i will upload this key to the keyservers in case it becomes the > > one i use for git. > > > > I sign all of my commits, I think it should be recommended but > not required. > > One downside is that you can sign commits from others with your > own key (for instance when pushing a patch from someone along > with your commits, and signing all at once via rebase), which can be > misleading, so it takes some work to reorder commits or push them > in stages so this doesn't happen. It makes sense that it's the > committer who's signing it, but git or github don't make a distinction > when it comes to signing. Since Git is kind of a blockchain (it includes the hash of the predecessor commits) you technically sign the entire tree anyways not just the individual commit. Especially in a rebase, the original author signs the original commit hash (which changes in a rebase), so it is not possible to use the same signature again. But I understand that a direct mapping between author and singing person would be nice. For releases, I think that the attacker model is important. The typical scenario is that one clones the repository, than checkouts a tag and compiles FFmpeg. For that one wants to know that the code is not manipulated by a third party (a person not trusted by the FFmpeg project). If the last commit is signed then, the user know that they can trust the entire code. If they checkout a random commit that is not signed, they cannot be sure that the set of changes up to the next signed commit of an FFmpeg author comes from a person trusted by FFmpeg. But for that it doesn't matter which of the devs has signed the commit. So I think for end users a signed release commit is most valuable, individual commits are valuable, too, and it's important that the signature must always come from a person trusted by the FFmpeg project. Best, Gerion > ___ > 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". > signature.asc Description: This is a digitally signed message part. ___ 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] [FFmpeg-cvslog] doc/filters: clarify behaviour of weights in amix
On Tue, Aug 9, 2022 at 12:46 PM Gyan Doshi wrote: > > > > On 2022-08-09 04:00 pm, Ronald S. Bultje wrote: > > On Tue, Aug 9, 2022 at 5:36 PM Gyan Doshi wrote: > > > >> > >> On 2022-08-09 02:57 pm, Anton Khirnov wrote: > >>> Quoting Gyan Doshi (2022-08-09 11:22:39) > I am a docs maintainer so I push these directly. > >>> All patches should go through the mailing list, so other people get the > >>> opportunity to comment on them. > >> I do that for more extensive changes. > >> > >> As the guidelines say, > >> > >> "Send your changes as patches to the ffmpeg-devel mailing list > > > > and > > > > > > if > >> the code maintainers say OK, you may commit. This does not apply to > >> files you wrote and/or maintain." > > > > That should make the intent of the sentence quoted clear. > > 'This' refers to the entire preceding sentence. If it was otherwise, it > would be incompatible with the 2nd way mentioned at > http://www.ffmpeg.org/developer.html#Contributing > > I'm not wedded to the policy as stated in the current docs, but the > current docs are clear that maintainers can push directly. > If several people disagree on the interpretation, its clearly not as "clear" as you claim it to be. - Hendrik ___ 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/aarch64: add hevc chroma loop filter 8-12bit
On Thu, 23 Jun 2022, J. Dekker wrote:
Signed-off-by: J. Dekker
---
libavcodec/aarch64/Makefile | 3 +-
libavcodec/aarch64/hevcdsp_deblock_neon.S | 168 ++
libavcodec/aarch64/hevcdsp_init_aarch64.c | 14 ++
3 files changed, 184 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/aarch64/hevcdsp_deblock_neon.S
Passes FATE, I never completed the checkasm for loop_filter, working on
that currently alongside the luma loop filter. This asm can also go
into hevcdsp_sao_neon.S if you would prefer not creating an extra file
for it.
Having a separate file for deblocking is totally fine - much rather that,
than lumping unrelated pieces together.
It'd be great to have a checkasm test for it before it goes in - see the
existing checkasm tests for h264/vp8/vp9 for examples of how to do that.
diff --git a/libavcodec/aarch64/hevcdsp_deblock_neon.S
b/libavcodec/aarch64/hevcdsp_deblock_neon.S
new file mode 100644
index 00..d21ad0a54f
--- /dev/null
+++ b/libavcodec/aarch64/hevcdsp_deblock_neon.S
@@ -0,0 +1,168 @@
+/* -*-arm64-*-
+ * vim: syntax=arm64asm
+ *
+ * Copyright (c) 2014 Seppo Tomperi
+ * Copyright (c) 2022 J. Dekker
+ *
+ * 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 USA
+ */
+
+
+#include "libavutil/aarch64/asm.S"
+#include "neon.S"
+
+.macro hevc_loop_filter_chroma_start bitdepth
+ldr w14, [x2]
+ldr w15, [x2, #4]
+.if \bitdepth > 8
+lsl w14, w14, #(\bitdepth - 8)
+lsl w15, w15, #(\bitdepth - 8)
+.endif
+addsw2, w14, w15
+b.eq1f
+dup v16.4h, w14
+dup v17.4h, w15
+trn1v16.2d, v16.2d, v17.2d
+.if \bitdepth == 10
+mvniv19.8h, #0xFC, lsl #8 // movi #0x03FF
+.endif
+.if \bitdepth == 12
Nit; this can be .elif
+mvniv19.8h, #0xF0, lsl #8 // movi #0x0FFF
+.endif
+.if \bitdepth > 8
+moviv18.8h, #0
+.endif
+neg v17.8h, v16.8h
+.endm
+
+.macro hevc_loop_filter_chroma_body bitdepth
+.if \bitdepth <= 8
+uxtlv0.8h, v0.8b // p1
+uxtlv1.8h, v1.8b // p0
+uxtlv2.8h, v2.8b // q0
+uxtlv3.8h, v3.8b // q1
+.endif
+sub v5.8h, v2.8h, v1.8h // q0 - p0
+sub v6.8h, v0.8h, v3.8h // p1 - q1
+shl v5.8h, v5.8h, #2
+add v5.8h, v6.8h, v5.8h
+srshr v5.8h, v5.8h, #3
+sminv5.8h, v5.8h, v16.8h
+smaxv5.8h, v5.8h, v17.8h
+sqadd v1.8h, v1.8h, v5.8h // p0 + delta
+sqsub v2.8h, v2.8h, v5.8h // q0 - delta
+.if \bitdepth <= 8
+sqxtun v1.8b, v1.8h
+sqxtun v2.8b, v2.8h
+.else
+sminv1.8h, v1.8h, v19.8h
+sminv2.8h, v2.8h, v19.8h
+smaxv1.8h, v1.8h, v18.8h
+smaxv2.8h, v2.8h, v18.8h
+.endif
+.endm
+
+.macro hevc_h_loop_filter_chroma bitdepth
+function ff_hevc_h_loop_filter_chroma_\bitdepth\()_neon, export=1
+hevc_loop_filter_chroma_start \bitdepth
+sub x0, x0, x1, lsl #1
+.if \bitdepth > 8
+ld1 {v0.8h}, [x0], x1
+ld1 {v1.8h}, [x0], x1
+ld1 {v2.8h}, [x0], x1
+ld1 {v3.8h}, [x0]
+.else
+ld1 {v0.8b}, [x0], x1
+ld1 {v1.8b}, [x0], x1
+ld1 {v2.8b}, [x0], x1
+ld1 {v3.8h}, [x0]
+.endif
+hevc_loop_filter_chroma_body \bitdepth
+sub x0, x0, x1, lsl #1
+.if \bitdepth > 8
+st1 {v1.8h}, [x0], x1
+st1 {v2.8h}, [x0]
+.else
+st1 {v1.8b}, [x0], x1
+st1 {v2.8b}, [x0]
+.endif
+1: ret
+endfunc
+.endm
+
+.macro hevc_v_loop_filter_chroma bitdepth
+function ff_hevc_v_loop_filter_chroma_\bitdepth\()_neon, export=1
+hevc_loop_filter_chroma_start \bitdepth
+.if \bitdepth > 8
+sub x0, x0, #8
+ld1 {v20.8h}, [x0], x1
+ld1 {v21.8h}, [x0], x1
+
Re: [FFmpeg-devel] [FFmpeg-cvslog] doc/filters: clarify behaviour of weights in amix
On 2022-08-09 04:55 pm, Hendrik Leppkes wrote: On Tue, Aug 9, 2022 at 12:46 PM Gyan Doshi wrote: On 2022-08-09 04:00 pm, Ronald S. Bultje wrote: On Tue, Aug 9, 2022 at 5:36 PM Gyan Doshi wrote: On 2022-08-09 02:57 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2022-08-09 11:22:39) I am a docs maintainer so I push these directly. All patches should go through the mailing list, so other people get the opportunity to comment on them. I do that for more extensive changes. As the guidelines say, "Send your changes as patches to the ffmpeg-devel mailing list and if the code maintainers say OK, you may commit. This does not apply to files you wrote and/or maintain." That should make the intent of the sentence quoted clear. 'This' refers to the entire preceding sentence. If it was otherwise, it would be incompatible with the 2nd way mentioned at http://www.ffmpeg.org/developer.html#Contributing I'm not wedded to the policy as stated in the current docs, but the current docs are clear that maintainers can push directly. If several people disagree on the interpretation, its clearly not as "clear" as you claim it to be. Yes, but only one person (Ronald) disagreed. Anton said it was outdated. But your objection is weird considering that Ronald affirmed that the intent was clear. That intent just happens to be opposite to what I think it is. This continued discussion is pointless. All this needs is a patch for what the new unambiguous policy should be. Regards, Gyan ___ 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] lavc/aarch64: new 8-bit hevc 16x16 idct
On Thu, 23 Jun 2022, J. Dekker wrote:
old:
hevc_idct_16x16_8_c: 5366.2
hevc_idct_16x16_8_neon: 1493.2
new:
hevc_idct_16x16_8_c: 5363.2
hevc_idct_16x16_8_neon: 943.5
Co-developed-by: Rafal Dabrowa
Signed-off-by: J. Dekker
---
libavcodec/aarch64/hevcdsp_idct_neon.S| 666 ++
libavcodec/aarch64/hevcdsp_init_aarch64.c | 3 +-
2 files changed, 668 insertions(+), 1 deletion(-)
Throughout the new code, you have e.g. "add x5, x5, x4, lsl 2", where the
"lsl 2" breaks assembling with MS armasm64 - it's missing the '#' on the
constant 2.
Also, for loads/stores, it seems to be missing the same '#' for
postincrement, e.g. "ld1 {v16.8h, v17.8h, v18.8h, v19.8h}, [x4], 64". Also
"mov x4, 64". Apparently armasm64 doesn't have a problem with that, but it
would still be good to have it consistent with the rest.
This idct is significantly faster than the one we currently have, I
suspect its for a couple reasons: 1) it's only written for 8bit
I don't see how that would change anything? Isn't the only thing that
differs between 8 and 10/12 bit in the existing implementation about how
much to scale down at the end? All other intermediate values are the same
size?
2) it's unrolled signficantly more. It comes at a hefty cost of roughly
2.25x the object size.
If by that, you mean that the existing code works on 4 elements at a time
(i.e. mostly operating on .4h vectors), while this one operates on .8h
vectors, then yes, that's most probably the biggest source of the speedup
(even if a lot of the intermediate stuff happens in .4s vectors). The
existing code was ported from the 32 bit arm version (which probably had
to stick to 4 elements at a time due to register availability there),
while it probably could have been made double width when it was ported to
64 bit.
I'm wondering if this idct is salvagable, or the one we have should just
be improved instead.
Well, my honest opinion is:
- I don't quite understand the current code (I've worked on the
vp8/vp9/av1 IDCTs a fair amount, but the HEVC one seems to be different
enough that I don't recognize all the concepts here.
- The current implementation would need to be reformatted if kept
- The current implementation does have some rather clear high level
structure though, e.g. when looking at the idct_16x16 macro.
- The new implementation seems to be just one hge function. If you
know it by heart, it's probably good, but it's really hard to get an
overview of if you're not familiar with the HEVC IDCTs.
As for steps forward:
- Is it possible to widen the existing implementation to operate on 8
elements instead of 4? I think that would bring it up to par with this
one.
- Can you get some high level structure to the new implementation so that
it becomes understandable? Either lots of more comments explaining what's
happening and why, or splitting it up in smaller macros.
Some more comments on the code itself below:
+// void ff_hevc_idct_16x16_8_neon(int16_t *coeffs, int col_limit)
+function ff_hevc_idct_16x16_8_neon_new, export=1
+sub sp, sp, 64
+st1 {v8.16b, v9.16b, v10.16b, v11.16b}, [sp]
+sub sp, sp, 32
+st1 {v14.16b, v15.16b}, [sp]
+mov x3, 0
+mov x2, x0
+1: mov x4, x2
+mov x5, 32
+ld1 {v16.8h}, [x4], x5
+ld1 {v17.8h}, [x4], x5
+ld1 {v18.8h}, [x4], x5
+ld1 {v19.8h}, [x4], x5
+ld1 {v20.8h}, [x4], x5
+ld1 {v21.8h}, [x4], x5
+ld1 {v22.8h}, [x4], x5
+ld1 {v23.8h}, [x4], x5
+ld1 {v24.8h}, [x4], x5
+ld1 {v25.8h}, [x4], x5
+ld1 {v26.8h}, [x4], x5
+ld1 {v27.8h}, [x4], x5
+ld1 {v28.8h}, [x4], x5
+ld1 {v29.8h}, [x4], x5
+ld1 {v30.8h}, [x4], x5
+ld1 {v31.8h}, [x4], x5
+cmp x1, 12
+b.hs5f
+// limit2 below 16
+bic x4, x1, 1
+adr x5, .LimitMask
+cbnzx3, 3f
+// columns 0 .. 7 - cleanup of indexes 5 .. 7
+ld1 {v0.8h}, [x5]
+adr x5, 2f
+add x5, x5, x4, lsl 2
+add x5, x5, x4, lsl 1
+br x5
+2: and v17.16b, v17.16b, v0.16b// col_limit 0..1 ->
limit2 == 4..5
+and v19.16b, v19.16b, v0.16b
+b 5f
I don't really know what these jump tables do and how it corresponds to
things in the existing implementation - but I guess that can be one part
of what makes things faster too.
The existing implementation does an 16x16 transform by first doing 4x
transforms for an 4x16 piece of
[FFmpeg-devel] [PATCH 2/2] arm: rv40dsp: Change stride parameters to ptrdiff_t
These were missed when h264_chroma_mc_func was changed in e4a94d8b36c48d95a7d412c40d7b558422ff659c. Signed-off-by: Martin Storsjö --- libavcodec/arm/rv40dsp_init_arm.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libavcodec/arm/rv40dsp_init_arm.c b/libavcodec/arm/rv40dsp_init_arm.c index 92d2867e04..2e584af475 100644 --- a/libavcodec/arm/rv40dsp_init_arm.c +++ b/libavcodec/arm/rv40dsp_init_arm.c @@ -49,11 +49,11 @@ DECL_QPEL_Y(1); DECL_QPEL_Y(2); DECL_QPEL_Y(3); -void ff_put_rv40_chroma_mc8_neon(uint8_t *, const uint8_t *, int, int, int, int); -void ff_put_rv40_chroma_mc4_neon(uint8_t *, const uint8_t *, int, int, int, int); +void ff_put_rv40_chroma_mc8_neon(uint8_t *, const uint8_t *, ptrdiff_t, int, int, int); +void ff_put_rv40_chroma_mc4_neon(uint8_t *, const uint8_t *, ptrdiff_t, int, int, int); -void ff_avg_rv40_chroma_mc8_neon(uint8_t *, const uint8_t *, int, int, int, int); -void ff_avg_rv40_chroma_mc4_neon(uint8_t *, const uint8_t *, int, int, int, int); +void ff_avg_rv40_chroma_mc8_neon(uint8_t *, const uint8_t *, ptrdiff_t, int, int, int); +void ff_avg_rv40_chroma_mc4_neon(uint8_t *, const uint8_t *, ptrdiff_t, int, int, int); void ff_rv40_weight_func_16_neon(uint8_t *, uint8_t *, uint8_t *, int, int, ptrdiff_t); void ff_rv40_weight_func_8_neon(uint8_t *, uint8_t *, uint8_t *, int, int, ptrdiff_t); -- 2.32.0 (Apple Git-132) ___ 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] arm: vc1sdp: Change stride parameters to ptrdiff_t
This was missed in db54426975e124e98e5130ad01316cb7afd60630. Signed-off-by: Martin Storsjö --- In practice, ptrdiff_t and int are the same type on arm, so these didn't cause any warnings and haven't been caught due to that. --- libavcodec/arm/vc1dsp_init_neon.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/libavcodec/arm/vc1dsp_init_neon.c b/libavcodec/arm/vc1dsp_init_neon.c index 46fd80a837..b5615624d5 100644 --- a/libavcodec/arm/vc1dsp_init_neon.c +++ b/libavcodec/arm/vc1dsp_init_neon.c @@ -33,12 +33,12 @@ void ff_vc1_inv_trans_4x8_dc_neon(uint8_t *dest, ptrdiff_t stride, int16_t *bloc void ff_vc1_inv_trans_8x4_dc_neon(uint8_t *dest, ptrdiff_t stride, int16_t *block); void ff_vc1_inv_trans_4x4_dc_neon(uint8_t *dest, ptrdiff_t stride, int16_t *block); -void ff_vc1_v_loop_filter4_neon(uint8_t *src, int stride, int pq); -void ff_vc1_h_loop_filter4_neon(uint8_t *src, int stride, int pq); -void ff_vc1_v_loop_filter8_neon(uint8_t *src, int stride, int pq); -void ff_vc1_h_loop_filter8_neon(uint8_t *src, int stride, int pq); -void ff_vc1_v_loop_filter16_neon(uint8_t *src, int stride, int pq); -void ff_vc1_h_loop_filter16_neon(uint8_t *src, int stride, int pq); +void ff_vc1_v_loop_filter4_neon(uint8_t *src, ptrdiff_t stride, int pq); +void ff_vc1_h_loop_filter4_neon(uint8_t *src, ptrdiff_t stride, int pq); +void ff_vc1_v_loop_filter8_neon(uint8_t *src, ptrdiff_t stride, int pq); +void ff_vc1_h_loop_filter8_neon(uint8_t *src, ptrdiff_t stride, int pq); +void ff_vc1_v_loop_filter16_neon(uint8_t *src, ptrdiff_t stride, int pq); +void ff_vc1_h_loop_filter16_neon(uint8_t *src, ptrdiff_t stride, int pq); void ff_put_pixels8x8_neon(uint8_t *block, const uint8_t *pixels, ptrdiff_t line_size, int rnd); -- 2.32.0 (Apple Git-132) ___ 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] [RFC] git and signing commits and tags
Aug 9, 2022, 13:02 by mich...@niedermayer.cc: > On Tue, Aug 09, 2022 at 12:59:52PM +0200, Michael Niedermayer wrote: > >> On Tue, Aug 09, 2022 at 12:36:53AM +0200, Michael Niedermayer wrote: >> > On Mon, Aug 08, 2022 at 09:26:52PM +0200, Lynne wrote: >> > > Aug 8, 2022, 16:50 by mich...@niedermayer.cc: >> > > >> > > > Given the recent server issues, i wonder if we should suggest/recommand >> > > > and document signing commits and tags >> > > > >> > > > i tried to push such commit to github and it nicely says "verified" >> > > > https://github.com/michaelni/FFmpeg/commit/75f196acd16fb0c0ca7a94f0c66072e7c6f736bf >> > > > >> > > > Ive generated a new gpg key for this experiment as i dont have my >> > > > main key on the box used for git development and also using more >> > > > modern eliptic curve stuff (smaller keys & sigs) >> > > > i will upload this key to the keyservers in case it becomes the >> > > > one i use for git. >> > > > >> > > >> > > I sign all of my commits, >> > >> > I didnt notice, but thats good as it also proofs it works with no ill >> > sideeffects >> > >> > Where can i find your public key ? it seems its not on the keyservers i >> > checked >> >> Your key seems only on openpgp.org but that strips userids unless the owner >> approves it >> (i presume for GDPR) making the key not work >> >> gpg --keyserver hkps://keys.openpgp.org --recv-keys >> FE50139C680572CAFD521F8DA2FEA5F03F034464 >> gpg: key A2FEA5F03F034464: no user ID >> gpg: Total number processed: 1 >> >> gpg --list-keys FE50139C680572CAFD521F8DA2FEA5F03F034464 >> gpg: error reading key: No public key >> >> gpg --recv-keys FE50139C680572CAFD521F8DA2FEA5F03F034464 >> gpg: keyserver receive failed: No data >> > > found your key with google here: > https://lynne.ee/extra/A2FEA5F03F034464.asc > I just pushed it to keyserver.ubuntu.com, the only still working server I found, surprisingly. Seems a few months ago sks (a protocol/sever? to share keys between servers) was deprecated and most servers went down, and the GDPR also took some out. Sad. There's some work done to make a new protocol/server apparently. I'm very sure I pushed my key to the MIT server back when I made it in 2019, but that server also seems like it's forgotten my key and not accepting it. I once imported all maintainer keys listed in MAINTAINERS and found many were revoked (I think compn's), while some used triple DES. The oldest key I found for a maintainer is actually Nicolas George's key, a triple DES from 2001! Maybe we should clean up the list of keys. ___ 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/9] avcodec/wmv2dec: Zero mb_type array for I pictures
Up until now, ff_wmv2_decode_secondary_picture_header() only
set the mb_type array for non I-pictures, so that the decoding
process uses the earlier values of this array; this affects
the output of the wmv8-x8intra FATE-test (which this patch
therefore updates). These earlier values were set when decoding
earlier frames or when the buffer was initially zero-allocated.
A consequence of this is that the output of this test would be
random if ff_find_unused_picture() would select the unused picture
to return at random. Furthermore decoding from a keyframe onwards
depends upon the earlier state of the decoder.
This patch therefore zeroes said array when decoding an I picture.
(It is not claimed that zero is the right value to fill the array with.
I just don't know.)
Signed-off-by: Andreas Rheinhardt
---
Would be nice if someone knowledgeable about wmv2 could take at
whether zero is the right init value.
libavcodec/wmv2dec.c| 4 +
tests/ref/fate/wmv8-x8intra | 644 ++--
2 files changed, 326 insertions(+), 322 deletions(-)
diff --git a/libavcodec/wmv2dec.c b/libavcodec/wmv2dec.c
index 6d9b72d123..22eb012f56 100644
--- a/libavcodec/wmv2dec.c
+++ b/libavcodec/wmv2dec.c
@@ -242,6 +242,10 @@ int ff_wmv2_decode_secondary_picture_header(MpegEncContext
*s)
WMV2DecContext *const w = (WMV2DecContext *) s;
if (s->pict_type == AV_PICTURE_TYPE_I) {
+/* Is filling with zeroes really the right thing to do? */
+memset(s->current_picture_ptr->mb_type, 0,
+ sizeof(*s->current_picture_ptr->mb_type) *
+ s->mb_height * s->mb_stride);
if (w->j_type_bit)
w->j_type = get_bits1(&s->gb);
else
diff --git a/tests/ref/fate/wmv8-x8intra b/tests/ref/fate/wmv8-x8intra
index c9ed2733e7..8802d03834 100644
--- a/tests/ref/fate/wmv8-x8intra
+++ b/tests/ref/fate/wmv8-x8intra
@@ -7,21 +7,21 @@
0, 3, 3,1, 115200, 0x8911d86f
0, 4, 4,1, 115200, 0x7c5dd82e
0, 5, 5,1, 115200, 0x7c5ed82e
-0, 30, 30,1, 115200, 0xd323d838
-0, 31, 31,1, 115200, 0x6e7479ab
-0, 32, 32,1, 115200, 0x14674bf6
-0, 33, 33,1, 115200, 0x074c2e3d
-0, 34, 34,1, 115200, 0x9b3025ef
-0, 35, 35,1, 115200, 0x76882dae
-0, 36, 36,1, 115200, 0xedf3421b
-0, 37, 37,1, 115200, 0xb5378486
-0, 38, 38,1, 115200, 0xc4a53420
-0, 39, 39,1, 115200, 0x559cb60f
-0, 40, 40,1, 115200, 0xcc034ddd
-0, 41, 41,1, 115200, 0xb77b7779
-0, 42, 42,1, 115200, 0x0ad9c3e6
-0, 43, 43,1, 115200, 0x4e673027
-0, 44, 44,1, 115200, 0x54717979
+0, 30, 30,1, 115200, 0x03fbd838
+0, 31, 31,1, 115200, 0x37c879b2
+0, 32, 32,1, 115200, 0xd5994bfc
+0, 33, 33,1, 115200, 0x4b662e3e
+0, 34, 34,1, 115200, 0x2f1925ea
+0, 35, 35,1, 115200, 0xc5912db0
+0, 36, 36,1, 115200, 0x76c4421f
+0, 37, 37,1, 115200, 0x5cc8848b
+0, 38, 38,1, 115200, 0x75e63425
+0, 39, 39,1, 115200, 0x1a29b620
+0, 40, 40,1, 115200, 0x60c64de9
+0, 41, 41,1, 115200, 0xc7ac7783
+0, 42, 42,1, 115200, 0xb056c3ee
+0, 43, 43,1, 115200, 0xa57d3030
+0, 44, 44,1, 115200, 0x2864797c
0, 45, 45,1, 115200, 0xf9e557c9
0, 46, 46,1, 115200, 0xbdcf6358
0, 47, 47,1, 115200, 0xd55c7bb7
@@ -82,156 +82,156 @@
0,102,102,1, 115200, 0x78bb8f95
0,103,103,1, 115200, 0x9c71d03f
0,104,104,1, 115200, 0xbe5db887
-0,105,105,1, 115200, 0xa88e00d0
-0,106,106,1, 115200, 0xc7b50827
-0,107,107,1, 115200, 0xf9155ed3
-0,108,108,1, 115200, 0x8dd72d44
-0,109,109,1, 115200, 0xee38183a
-0,110,110,1, 115200, 0xea2b6329
-0,111,111,1, 115200, 0xf556c2b3
-0,112,112,1, 115200, 0x90edebf9
-0,113,113,1, 115200, 0x4f440fdf
-0,114,114,1, 115200, 0xfdec7a9d
-0,115,115,1, 115200, 0xc7927952
-0,116,116,1, 115200, 0xdd475704
-0,117,117,1, 115200, 0
[FFmpeg-devel] [PATCH 2/9] avcodec/mpegutils: Combine multiple av_log statements
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegutils.c | 101 +++--
1 file changed, 57 insertions(+), 44 deletions(-)
diff --git a/libavcodec/mpegutils.c b/libavcodec/mpegutils.c
index 4cbc474543..395bd38ff5 100644
--- a/libavcodec/mpegutils.c
+++ b/libavcodec/mpegutils.c
@@ -100,6 +100,59 @@ void ff_draw_horiz_band(AVCodecContext *avctx,
}
}
+static char get_type_mv_char(int mb_type)
+{
+// Type & MV direction
+if (IS_PCM(mb_type))
+return 'P';
+else if (IS_INTRA(mb_type) && IS_ACPRED(mb_type))
+return 'A';
+else if (IS_INTRA4x4(mb_type))
+return 'i';
+else if (IS_INTRA16x16(mb_type))
+return 'I';
+else if (IS_DIRECT(mb_type) && IS_SKIP(mb_type))
+return 'd';
+else if (IS_DIRECT(mb_type))
+return 'D';
+else if (IS_GMC(mb_type) && IS_SKIP(mb_type))
+return 'g';
+else if (IS_GMC(mb_type))
+return 'G';
+else if (IS_SKIP(mb_type))
+return 'S';
+else if (!USES_LIST(mb_type, 1))
+return '>';
+else if (!USES_LIST(mb_type, 0))
+return '<';
+else {
+av_assert2(USES_LIST(mb_type, 0) && USES_LIST(mb_type, 1));
+return 'X';
+}
+}
+
+static char get_segmentation_char(int mb_type)
+{
+if (IS_8X8(mb_type))
+return '+';
+else if (IS_16X8(mb_type))
+return '-';
+else if (IS_8X16(mb_type))
+return '|';
+else if (IS_INTRA(mb_type) || IS_16X16(mb_type))
+return ' ';
+
+return '?';
+}
+
+static char get_interlacement_char(int mb_type)
+{
+if (IS_INTERLACED(mb_type))
+return '=';
+else
+return ' ';
+}
+
void ff_print_debug_info2(AVCodecContext *avctx, AVFrame *pict, uint8_t
*mbskip_table,
uint32_t *mbtype_table, int8_t *qscale_table, int16_t
(*motion_val[2])[2],
int mb_width, int mb_height, int mb_stride, int
quarter_sample)
@@ -211,51 +264,11 @@ void ff_print_debug_info2(AVCodecContext *avctx, AVFrame
*pict, uint8_t *mbskip_
}
if (avctx->debug & FF_DEBUG_MB_TYPE) {
int mb_type = mbtype_table[x + y * mb_stride];
-// Type & MV direction
-if (IS_PCM(mb_type))
-av_log(avctx, AV_LOG_DEBUG, "P");
-else if (IS_INTRA(mb_type) && IS_ACPRED(mb_type))
-av_log(avctx, AV_LOG_DEBUG, "A");
-else if (IS_INTRA4x4(mb_type))
-av_log(avctx, AV_LOG_DEBUG, "i");
-else if (IS_INTRA16x16(mb_type))
-av_log(avctx, AV_LOG_DEBUG, "I");
-else if (IS_DIRECT(mb_type) && IS_SKIP(mb_type))
-av_log(avctx, AV_LOG_DEBUG, "d");
-else if (IS_DIRECT(mb_type))
-av_log(avctx, AV_LOG_DEBUG, "D");
-else if (IS_GMC(mb_type) && IS_SKIP(mb_type))
-av_log(avctx, AV_LOG_DEBUG, "g");
-else if (IS_GMC(mb_type))
-av_log(avctx, AV_LOG_DEBUG, "G");
-else if (IS_SKIP(mb_type))
-av_log(avctx, AV_LOG_DEBUG, "S");
-else if (!USES_LIST(mb_type, 1))
-av_log(avctx, AV_LOG_DEBUG, ">");
-else if (!USES_LIST(mb_type, 0))
-av_log(avctx, AV_LOG_DEBUG, "<");
-else {
-av_assert2(USES_LIST(mb_type, 0) && USES_LIST(mb_type,
1));
-av_log(avctx, AV_LOG_DEBUG, "X");
-}
-
-// segmentation
-if (IS_8X8(mb_type))
-av_log(avctx, AV_LOG_DEBUG, "+");
-else if (IS_16X8(mb_type))
-av_log(avctx, AV_LOG_DEBUG, "-");
-else if (IS_8X16(mb_type))
-av_log(avctx, AV_LOG_DEBUG, "|");
-else if (IS_INTRA(mb_type) || IS_16X16(mb_type))
-av_log(avctx, AV_LOG_DEBUG, " ");
-else
-av_log(avctx, AV_LOG_DEBUG, "?");
-
-if (IS_INTERLACED(mb_type))
-av_log(avctx, AV_LOG_DEBUG, "=");
-else
-av_log(avctx, AV_LOG_DEBUG, " ");
+av_log(avctx, AV_LOG_DEBUG, "%c%c%c",
+ get_type_mv_char(mb_type),
+ get_segmentation_char(mb_type),
+ get_interlacement_char(mb_type));
}
}
av_log(avctx, AV_LOG_DEBUG, "\n");
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above,
[FFmpeg-devel] [PATCH 3/9] avcodec/mpegutils: Constify ff_print_debug_info2, ff_draw_horiz_band
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegutils.c | 11 ++-
libavcodec/mpegutils.h | 9 +
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/libavcodec/mpegutils.c b/libavcodec/mpegutils.c
index 395bd38ff5..ff9418232b 100644
--- a/libavcodec/mpegutils.c
+++ b/libavcodec/mpegutils.c
@@ -49,7 +49,7 @@ static int add_mb(AVMotionVector *mb, uint32_t mb_type,
}
void ff_draw_horiz_band(AVCodecContext *avctx,
-AVFrame *cur, AVFrame *last,
+const AVFrame *cur, const AVFrame *last,
int y, int h, int picture_structure,
int first_field, int low_delay)
{
@@ -68,7 +68,7 @@ void ff_draw_horiz_band(AVCodecContext *avctx,
return;
if (avctx->draw_horiz_band) {
-AVFrame *src;
+const AVFrame *src;
int offset[AV_NUM_DATA_POINTERS];
int i;
@@ -153,9 +153,10 @@ static char get_interlacement_char(int mb_type)
return ' ';
}
-void ff_print_debug_info2(AVCodecContext *avctx, AVFrame *pict, uint8_t
*mbskip_table,
- uint32_t *mbtype_table, int8_t *qscale_table, int16_t
(*motion_val[2])[2],
- int mb_width, int mb_height, int mb_stride, int
quarter_sample)
+void ff_print_debug_info2(AVCodecContext *avctx, AVFrame *pict,
+ const uint8_t *mbskip_table, const uint32_t
*mbtype_table,
+ const int8_t *qscale_table, int16_t (*const
motion_val[2])[2],
+ int mb_width, int mb_height, int mb_stride, int
quarter_sample)
{
if ((avctx->export_side_data & AV_CODEC_EXPORT_DATA_MVS) && mbtype_table
&& motion_val[0]) {
const int shift = 1 + quarter_sample;
diff --git a/libavcodec/mpegutils.h b/libavcodec/mpegutils.h
index c92f9192db..386110bb8c 100644
--- a/libavcodec/mpegutils.h
+++ b/libavcodec/mpegutils.h
@@ -127,15 +127,16 @@ enum OutputFormat {
*
* @param h is the normal height, this will be reduced automatically if needed
*/
-void ff_draw_horiz_band(AVCodecContext *avctx, AVFrame *cur, AVFrame *last,
+void ff_draw_horiz_band(AVCodecContext *avctx, const AVFrame *cur, const
AVFrame *last,
int y, int h, int picture_structure, int first_field,
int low_delay);
/**
* Print debugging info for the given picture.
*/
-void ff_print_debug_info2(AVCodecContext *avctx, AVFrame *pict, uint8_t
*mbskip_table,
- uint32_t *mbtype_table, int8_t *qscale_table, int16_t
(*motion_val[2])[2],
- int mb_width, int mb_height, int mb_stride, int
quarter_sample);
+void ff_print_debug_info2(AVCodecContext *avctx, AVFrame *pict,
+ const uint8_t *mbskip_table, const uint32_t
*mbtype_table,
+ const int8_t *qscale_table, int16_t (*const
motion_val[2])[2],
+ int mb_width, int mb_height, int mb_stride, int
quarter_sample);
#endif /* AVCODEC_MPEGUTILS_H */
--
2.34.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] [PATCH 4/9] avcodec/mpegpicture: Remove always-true checks
Of all the buffers that are made writable, three are always allocated
and the other four are allocated iff any one of them is allocated;
so one can replace the seven checks for existence with one.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegpicture.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
index f32f8d061b..dc79662143 100644
--- a/libavcodec/mpegpicture.c
+++ b/libavcodec/mpegpicture.c
@@ -49,21 +49,22 @@ static void av_noinline free_picture_tables(Picture *pic)
static int make_tables_writable(Picture *pic)
{
-int ret, i;
#define MAKE_WRITABLE(table) \
do {\
-if (pic->table &&\
- (ret = av_buffer_make_writable(&pic->table)) < 0)\
-return ret;\
+int ret = av_buffer_make_writable(&pic->table); \
+if (ret < 0) \
+return ret; \
} while (0)
MAKE_WRITABLE(mbskip_table_buf);
MAKE_WRITABLE(qscale_table_buf);
MAKE_WRITABLE(mb_type_buf);
-for (i = 0; i < 2; i++) {
-MAKE_WRITABLE(motion_val_buf[i]);
-MAKE_WRITABLE(ref_index_buf[i]);
+if (pic->motion_val_buf[0]) {
+for (int i = 0; i < 2; i++) {
+MAKE_WRITABLE(motion_val_buf[i]);
+MAKE_WRITABLE(ref_index_buf[i]);
+}
}
return 0;
--
2.34.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] [PATCH 5/9] avutil/buffer: Never poison returned buffers
Poisoning returned buffers is based around the implicit assumption that the contents of said buffers are transient. Yet this is not true for the buffer pools used by the various hardware contexts which store important state in there that needs to be preserved. Furthermore, the current code is also based on the assumption that the complete buffer pointed to by AVBuffer->data coincides with AVBufferRef->data; yet an implementation might store some data of its own before the actual user-visible data (accessible via AVBufferRef) which would be broken by the current code. (This is of course yet more proof that the AVBuffer API is not the right tool for the hardware contexts.) Signed-off-by: Andreas Rheinhardt --- I already sent this patch last October, but didn't apply it due to lack of feedback. Future patches of mine depend upon this and therefore I am sending it again. libavutil/buffer.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/libavutil/buffer.c b/libavutil/buffer.c index 54590be566..e4562a79b1 100644 --- a/libavutil/buffer.c +++ b/libavutil/buffer.c @@ -341,9 +341,6 @@ static void pool_release_buffer(void *opaque, uint8_t *data) BufferPoolEntry *buf = opaque; AVBufferPool *pool = buf->pool; -if(CONFIG_MEMORY_POISONING) -memset(buf->data, FF_MEMORY_POISON, pool->size); - ff_mutex_lock(&pool->mutex); buf->next = pool->pool; pool->pool = buf; -- 2.34.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] [PATCH 6/9] avcodec/mpegpicture: Move encoding_error and mb_var_sum to MpegEncCtx
These fields are only ever set by the encoder for the current picture
and for no other picture. So only one set of these values needs to
exist, so move them to MpegEncContext.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegpicture.c | 5 -
libavcodec/mpegpicture.h | 5 -
libavcodec/mpegvideo.h | 5 -
libavcodec/mpegvideo_enc.c | 25 -
libavcodec/ratecontrol.c | 17 -
libavcodec/snowenc.c | 8
6 files changed, 28 insertions(+), 37 deletions(-)
diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
index dc79662143..c57f149752 100644
--- a/libavcodec/mpegpicture.c
+++ b/libavcodec/mpegpicture.c
@@ -376,16 +376,11 @@ int ff_mpeg_ref_picture(AVCodecContext *avctx, Picture
*dst, Picture *src)
}
dst->field_picture = src->field_picture;
-dst->mb_var_sum = src->mb_var_sum;
-dst->mc_mb_var_sum = src->mc_mb_var_sum;
dst->b_frame_score = src->b_frame_score;
dst->needs_realloc = src->needs_realloc;
dst->reference = src->reference;
dst->shared = src->shared;
-memcpy(dst->encoding_error, src->encoding_error,
- sizeof(dst->encoding_error));
-
return 0;
fail:
ff_mpeg_unref_picture(avctx, dst);
diff --git a/libavcodec/mpegpicture.h b/libavcodec/mpegpicture.h
index 62589595d0..a1455ee13c 100644
--- a/libavcodec/mpegpicture.h
+++ b/libavcodec/mpegpicture.h
@@ -71,16 +71,11 @@ typedef struct Picture {
int field_picture; ///< whether or not the picture was encoded in
separate fields
-int64_t mb_var_sum; ///< sum of MB variance for current frame
-int64_t mc_mb_var_sum; ///< motion compensated MB variance for
current frame
-
int b_frame_score;
int needs_realloc; ///< Picture needs to be reallocated (eg due
to a frame size change)
int reference;
int shared;
-
-uint64_t encoding_error[MPEGVIDEO_MAX_PLANES];
} Picture;
/**
diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
index 47619c1976..1ddf8034aa 100644
--- a/libavcodec/mpegvideo.h
+++ b/libavcodec/mpegvideo.h
@@ -236,10 +236,13 @@ typedef struct MpegEncContext {
uint8_t (*p_field_select_table[2]); ///< Only the first element is
allocated
uint8_t (*b_field_select_table[2][2]); ///< Only the first element is
allocated
-/* The following three arrays are encoder-only */
+/* The following fields are encoder-only */
uint16_t *mb_var; ///< Table for MB variances
uint16_t *mc_mb_var;///< Table for motion compensated MB variances
uint8_t *mb_mean; ///< Table for MB luminance
+int64_t mb_var_sum; ///< sum of MB variance for current frame
+int64_t mc_mb_var_sum; ///< motion compensated MB variance for
current frame
+uint64_t encoding_error[MPEGVIDEO_MAX_PLANES];
int motion_est; ///< ME algorithm
int me_penalty_compensation;
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index a34fb66eac..d45e15a039 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -1783,11 +1783,10 @@ vbv_retry:
ff_write_pass1_stats(s);
for (i = 0; i < 4; i++) {
-s->current_picture_ptr->encoding_error[i] =
s->current_picture.encoding_error[i];
-avctx->error[i] += s->current_picture_ptr->encoding_error[i];
+avctx->error[i] += s->encoding_error[i];
}
ff_side_data_set_encoder_stats(pkt, s->current_picture.f->quality,
- s->current_picture_ptr->encoding_error,
+ s->encoding_error,
(avctx->flags&AV_CODEC_FLAG_PSNR) ?
MPEGVIDEO_MAX_PLANES : 0,
s->pict_type);
@@ -2792,7 +2791,7 @@ static int encode_thread(AVCodecContext *c, void *arg){
/* note: quant matrix value (8) is implied here */
s->last_dc[i] = 128 << s->intra_dc_precision;
-s->current_picture.encoding_error[i] = 0;
+s->encoding_error[i] = 0;
}
if(s->codec_id==AV_CODEC_ID_AMV){
s->last_dc[0] = 128*8/13;
@@ -3370,13 +3369,13 @@ static int encode_thread(AVCodecContext *c, void *arg){
if(s->mb_x*16 + 16 > s->width ) w= s->width - s->mb_x*16;
if(s->mb_y*16 + 16 > s->height) h= s->height- s->mb_y*16;
-s->current_picture.encoding_error[0] += sse(
+s->encoding_error[0] += sse(
s, s->new_picture->data[0] + s->mb_x*16 +
s->mb_y*s->linesize*16,
s->dest[0], w, h, s->linesize);
-s->current_picture.encoding_error[1] += sse(
+s->encoding_error[1] += sse(
s, s->new_picture->data[1] + s->mb_x*8 +
s->mb_y*s->uvlinesize*chr_h,
[FFmpeg-devel] [PATCH 7/9] avcodec/mpegvideo_enc: Don't copy Picture unnecessarily
Also add const where possible.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_enc.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index d45e15a039..2cd4db27bc 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -1249,15 +1249,14 @@ static int estimate_best_b_count(MpegEncContext *s)
FF_LAMBDA_SHIFT;
for (i = 0; i < s->max_b_frames + 2; i++) {
-Picture pre_input, *pre_input_ptr = i ? s->input_picture[i - 1] :
-s->next_picture_ptr;
-uint8_t *data[4];
+const Picture *pre_input_ptr = i ? s->input_picture[i - 1] :
+ s->next_picture_ptr;
if (pre_input_ptr && (!i || s->input_picture[i - 1])) {
-pre_input = *pre_input_ptr;
+const uint8_t *data[4];
memcpy(data, pre_input_ptr->f->data, sizeof(data));
-if (!pre_input.shared && i) {
+if (!pre_input_ptr->shared && i) {
data[0] += INPLACE_OFFSET;
data[1] += INPLACE_OFFSET;
data[2] += INPLACE_OFFSET;
@@ -1266,17 +1265,17 @@ static int estimate_best_b_count(MpegEncContext *s)
s->mpvencdsp.shrink[scale](s->tmp_frames[i]->data[0],
s->tmp_frames[i]->linesize[0],
data[0],
- pre_input.f->linesize[0],
+ pre_input_ptr->f->linesize[0],
width, height);
s->mpvencdsp.shrink[scale](s->tmp_frames[i]->data[1],
s->tmp_frames[i]->linesize[1],
data[1],
- pre_input.f->linesize[1],
+ pre_input_ptr->f->linesize[1],
width >> 1, height >> 1);
s->mpvencdsp.shrink[scale](s->tmp_frames[i]->data[2],
s->tmp_frames[i]->linesize[2],
data[2],
- pre_input.f->linesize[2],
+ pre_input_ptr->f->linesize[2],
width >> 1, height >> 1);
}
}
--
2.34.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] [PATCH 8/9] avcodec/mpegvideo_enc: Remove redundant check
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_enc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 2cd4db27bc..4840d80fe8 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -1252,7 +1252,7 @@ static int estimate_best_b_count(MpegEncContext *s)
const Picture *pre_input_ptr = i ? s->input_picture[i - 1] :
s->next_picture_ptr;
-if (pre_input_ptr && (!i || s->input_picture[i - 1])) {
+if (pre_input_ptr) {
const uint8_t *data[4];
memcpy(data, pre_input_ptr->f->data, sizeof(data));
--
2.34.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] [PATCH 9/9] avcodec/mpegvideo_enc: Remove redundant cast
Signed-off-by: Andreas Rheinhardt --- libavcodec/mpegvideo_enc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c index 4840d80fe8..63fa0663d3 100644 --- a/libavcodec/mpegvideo_enc.c +++ b/libavcodec/mpegvideo_enc.c @@ -1154,7 +1154,7 @@ static int load_input_picture(MpegEncContext *s, const AVFrame *pic_arg) for (i = flush_offset; i < MAX_PICTURE_COUNT /*s->encoding_delay + 1*/; i++) s->input_picture[i - flush_offset] = s->input_picture[i]; -s->input_picture[encoding_delay] = (Picture*) pic; +s->input_picture[encoding_delay] = pic; return 0; } -- 2.34.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".
Re: [FFmpeg-devel] [RFC] git and signing commits and tags
On Tue, Aug 09, 2022 at 07:50:13PM +0200, Lynne wrote: > Aug 9, 2022, 13:02 by mich...@niedermayer.cc: > > > On Tue, Aug 09, 2022 at 12:59:52PM +0200, Michael Niedermayer wrote: > > > >> On Tue, Aug 09, 2022 at 12:36:53AM +0200, Michael Niedermayer wrote: > >> > On Mon, Aug 08, 2022 at 09:26:52PM +0200, Lynne wrote: > >> > > Aug 8, 2022, 16:50 by mich...@niedermayer.cc: > >> > > > >> > > > Given the recent server issues, i wonder if we should > >> > > > suggest/recommand > >> > > > and document signing commits and tags > >> > > > > >> > > > i tried to push such commit to github and it nicely says "verified" > >> > > > https://github.com/michaelni/FFmpeg/commit/75f196acd16fb0c0ca7a94f0c66072e7c6f736bf > >> > > > > >> > > > Ive generated a new gpg key for this experiment as i dont have my > >> > > > main key on the box used for git development and also using more > >> > > > modern eliptic curve stuff (smaller keys & sigs) > >> > > > i will upload this key to the keyservers in case it becomes the > >> > > > one i use for git. > >> > > > > >> > > > >> > > I sign all of my commits, > >> > > >> > I didnt notice, but thats good as it also proofs it works with no ill > >> > sideeffects > >> > > >> > Where can i find your public key ? it seems its not on the keyservers i > >> > checked > >> > >> Your key seems only on openpgp.org but that strips userids unless the > >> owner approves it > >> (i presume for GDPR) making the key not work > >> > >> gpg --keyserver hkps://keys.openpgp.org --recv-keys > >> FE50139C680572CAFD521F8DA2FEA5F03F034464 > >> gpg: key A2FEA5F03F034464: no user ID > >> gpg: Total number processed: 1 > >> > >> gpg --list-keys FE50139C680572CAFD521F8DA2FEA5F03F034464 > >> gpg: error reading key: No public key > >> > >> gpg --recv-keys FE50139C680572CAFD521F8DA2FEA5F03F034464 > >> gpg: keyserver receive failed: No data > >> > > > > found your key with google here: > > https://lynne.ee/extra/A2FEA5F03F034464.asc > > > > I just pushed it to keyserver.ubuntu.com, the only still working server > I found, surprisingly. Seems a few months ago sks (a protocol/sever? > to share keys between servers) was deprecated and most servers went > down, and the GDPR also took some out. Sad. There's some work done > to make a new protocol/server apparently. > I'm very sure I pushed my key to the MIT server back when I made it in 2019, > but that server also seems like it's forgotten my key and not accepting it. yes, i was also scratching my head yesterday about this keyserver apocalypse the script below was what i ended up writing but iam not sure its usefull #!/bin/bash gpg --keyserver hkps://pgp.mit.edu --recv-keys $* & gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys $* & gpg --keyserver hkps://keys.openpgp.org --recv-keys $* & gpg --keyserver hkps://keys.gnupg.net --recv-keys $* & gpg --keyserver hkps://keyserver.pgp.com--recv-keys $* & > > I once imported all maintainer keys listed in MAINTAINERS and found many > were revoked (I think compn's), while some used triple DES. The oldest key > I found for a maintainer is actually Nicolas George's key, a triple DES from > 2001! > Maybe we should clean up the list of keys. yes maybe we also should collect the full public keys and not just the hashes this list of hashes came from a time where obtaining a key from a hash was trivial thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Take away the freedom of one citizen and you will be jailed, take away the freedom of all citizens and you will be congratulated by your peers in Parliament. 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 1/2] MAINTAINERS: Add ED25519 key for tag/commit signing experiment
On Mon, Aug 08, 2022 at 04:50:07PM +0200, Michael Niedermayer wrote: > From: Michael Niedermayer > > Signed-off-by: Michael Niedermayer > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 7ed15f96f6..ed2ec0b90c 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -626,6 +626,7 @@ Leo Izen (thebombzen) B6FD 3CFC 7ACF 83FC 9137 > 6945 5A71 C331 FD2F A19A > Loren Merritt ABD9 08F4 C920 3F65 D8BE 35D7 1540 DAA7 060F > 56DE > Lynne FE50 139C 6805 72CA FD52 1F8D A2FE A5F0 3F03 > 4464 > Michael Niedermayer 9FF2 128B 147E F673 0BAD F133 611E C787 040B > 0FAB > + DD1E C9E8 DE08 5C62 9B3E 1846 B18E 8928 B394 > 8D64 > Nicolas George24CE 01CE 9ACC 5CEB 74D8 8D9D B063 D997 36E5 > 4C93 > Niklas Haas (haasn) 1DDB 8076 B14D 5B48 32FC 99D9 EB52 DA9C 02BA > 6FB4 > Nikolay Aleksandrov 8978 1D8C FB71 588E 4B27 EAA8 C4F0 B5FC E011 > 13B1 will apply this one and attempt to start using it for commits [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange 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".
[FFmpeg-devel] [PATCH v2] doc/git-howto.texi: Document commit signing
From: Michael Niedermayer
Signed-off-by: Michael Niedermayer
---
doc/git-howto.texi | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/doc/git-howto.texi b/doc/git-howto.texi
index 874afabbbc..48389751a4 100644
--- a/doc/git-howto.texi
+++ b/doc/git-howto.texi
@@ -187,11 +187,18 @@ to make sure you don't have untracked files or deletions.
git add [-i|-p|-A]
@end example
-Make sure you have told Git your name and email address
+Make sure you have told Git your name, email address and GPG key
@example
git config --global user.name "My Name"
git config --global user.email my@@email.invalid
+git config --global user.signingkey ABCDEF0123245
+@end example
+
+Enable signing all commits or use -S
+
+@example
+git config --global commit.gpgsign true
@end example
Use @option{--global} to set the global configuration for all your Git
checkouts.
@@ -423,6 +430,19 @@ git checkout -b svn_23456 $SHA1
where @var{$SHA1} is the commit hash from the @command{git log} output.
+@chapter gpg key generation
+
+If you have no gpg key yet, we recommand that you create a ed25519 based key
as it
+is small, fast and secure. Especially it results in small signatures in git.
+
+@example
+gpg --default-new-key-algo "ed25519/cert,sign+cv25519/encr"
--quick-generate-key "hu...@server.com"
+@end example
+
+When genarting a key, make sure the email specified matches the email used in
git as some sites like
+github consider mismatches a reason to declare such commits unverified. After
generating a key you
+can add it to the MAINTAINER file and upload it to a keyserver.
+
@chapter Pre-push checklist
Once you have a set of commits that you feel are ready for pushing,
--
2.17.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".
Re: [FFmpeg-devel] [PATCH v2] doc/git-howto.texi: Document commit signing
On 8/9/2022 4:34 PM, Michael Niedermayer wrote:
From: Michael Niedermayer
Signed-off-by: Michael Niedermayer
---
doc/git-howto.texi | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/doc/git-howto.texi b/doc/git-howto.texi
index 874afabbbc..48389751a4 100644
--- a/doc/git-howto.texi
+++ b/doc/git-howto.texi
@@ -187,11 +187,18 @@ to make sure you don't have untracked files or deletions.
git add [-i|-p|-A]
@end example
-Make sure you have told Git your name and email address
+Make sure you have told Git your name, email address and GPG key
@example
git config --global user.name "My Name"
git config --global user.email my@@email.invalid
+git config --global user.signingkey ABCDEF0123245
+@end example
+
+Enable signing all commits or use -S
+
+@example
+git config --global commit.gpgsign true
@end example
Use @option{--global} to set the global configuration for all your Git checkouts.
@@ -423,6 +430,19 @@ git checkout -b svn_23456 $SHA1
where @var{$SHA1} is the commit hash from the @command{git log} output.
+@chapter gpg key generation
+
+If you have no gpg key yet, we recommand that you create a ed25519 based key
as it
Recommend.
+is small, fast and secure. Especially it results in small signatures in git.
+
+@example
+gpg --default-new-key-algo "ed25519/cert,sign+cv25519/encr" --quick-generate-key
"hu...@server.com"
+@end example
+
+When genarting a key, make sure the email specified matches the email used in
git as some sites like
Generating
+github consider mismatches a reason to declare such commits unverified. After
generating a key you
+can add it to the MAINTAINER file and upload it to a keyserver.
Maybe link some external documentation about gpg keys, explaining the
difference between public and private keys, how to encrypt the private
one with a passphrase, etc.
Sites like gitlab tell you to not attempt to upload private keys, so i
imagine quite a lot of people have mistakenly done so in the past.
+
@chapter Pre-push checklist
Once you have a set of commits that you feel are ready for pushing,
___
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 10/11] avcodec/mpegvideo: Move setting mb_height to ff_mpv_init_context_frame
It is the proper place to set it, directly besides mb_width and
mb_stride. The reason for doing it the way it is done now seems
to be that the code does not create more slice contexts than necessary
(i.e. not more than one per row), so that this number needs to be
known before setting the number of slices. But this can always be
arranged by just moving the code that sets the number of slices.
Signed-off-by: Andreas Rheinhardt
---
Unfortunately, there is another place where these values are set:
ff_vc1_parse_frame_header_adv() sets mb_height; it might change it
by one.
libavcodec/mpegvideo.c | 32
libavcodec/mpegvideo_dec.c | 6 --
2 files changed, 16 insertions(+), 22 deletions(-)
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index 1405176c06..ff08168362 100644
--- a/libavcodec/mpegvideo.c
+++ b/libavcodec/mpegvideo.c
@@ -526,6 +526,11 @@ int ff_mpv_init_context_frame(MpegEncContext *s)
{
int y_size, c_size, yc_size, i, mb_array_size, mv_table_size, x, y;
+if (s->codec_id == AV_CODEC_ID_MPEG2VIDEO && !s->progressive_sequence)
+s->mb_height = (s->height + 31) / 32 * 2;
+else
+s->mb_height = (s->height + 15) / 16;
+
s->mb_width = (s->width + 15) / 16;
s->mb_stride = s->mb_width + 1;
s->b8_stride = s->mb_width * 2 + 1;
@@ -747,28 +752,12 @@ av_cold int ff_mpv_common_init(MpegEncContext *s)
if (s->encoding && s->avctx->slices)
nb_slices = s->avctx->slices;
-if (s->codec_id == AV_CODEC_ID_MPEG2VIDEO && !s->progressive_sequence)
-s->mb_height = (s->height + 31) / 32 * 2;
-else
-s->mb_height = (s->height + 15) / 16;
-
if (s->avctx->pix_fmt == AV_PIX_FMT_NONE) {
av_log(s->avctx, AV_LOG_ERROR,
"decoding to AV_PIX_FMT_NONE is not supported.\n");
return AVERROR(EINVAL);
}
-if (nb_slices > MAX_THREADS || (nb_slices > s->mb_height && s->mb_height))
{
-int max_slices;
-if (s->mb_height)
-max_slices = FFMIN(MAX_THREADS, s->mb_height);
-else
-max_slices = MAX_THREADS;
-av_log(s->avctx, AV_LOG_WARNING, "too many threads/slices (%d),"
- " reducing to %d\n", nb_slices, max_slices);
-nb_slices = max_slices;
-}
-
if ((s->width || s->height) &&
av_image_check_size(s->width, s->height, 0, s->avctx))
return AVERROR(EINVAL);
@@ -799,6 +788,17 @@ av_cold int ff_mpv_common_init(MpegEncContext *s)
if ((ret = ff_mpv_init_context_frame(s)))
goto fail;
+if (nb_slices > MAX_THREADS || (nb_slices > s->mb_height && s->mb_height))
{
+int max_slices;
+if (s->mb_height)
+max_slices = FFMIN(MAX_THREADS, s->mb_height);
+else
+max_slices = MAX_THREADS;
+av_log(s->avctx, AV_LOG_WARNING, "too many threads/slices (%d),"
+ " reducing to %d\n", nb_slices, max_slices);
+nb_slices = max_slices;
+}
+
#if FF_API_FLAG_TRUNCATED
s->parse_context.state = -1;
#endif
diff --git a/libavcodec/mpegvideo_dec.c b/libavcodec/mpegvideo_dec.c
index 7caaf0596d..93ba4e31b3 100644
--- a/libavcodec/mpegvideo_dec.c
+++ b/libavcodec/mpegvideo_dec.c
@@ -208,12 +208,6 @@ int ff_mpv_common_frame_size_change(MpegEncContext *s)
s->next_picture_ptr =
s->current_picture_ptr = NULL;
-// init
-if (s->codec_id == AV_CODEC_ID_MPEG2VIDEO && !s->progressive_sequence)
-s->mb_height = (s->height + 31) / 32 * 2;
-else
-s->mb_height = (s->height + 15) / 16;
-
if ((s->width || s->height) &&
(err = av_image_check_size(s->width, s->height, 0, s->avctx)) < 0)
goto fail;
--
2.34.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] [PATCH 11/11] avcodec/mpegpicture: Always reset motion val buffer
Codecs call ff_find_unused_picture() to get the index of
an unused picture; said picture may have buffers left
from using it previously (these buffers are intentionally
not unreferenced so that it might be possible to reuse them;
this is mpegvideo's version of a bufferpool). They should
not make any assumptions about which picture they get.
Yet somehow this is not true when decoding OBMC: Returning
random empty pictures (instead of the first one) leads
to nondeterministic results; similarly, explicitly
rezeroing the buffer before handing it over to the codec
changes the outcome of the h263-obmc tests, but it makes it
independent of the returned pictures. Therefore this commit
does so.
(No, this commit is not intended to be applied. I just hope
to arouse the interest of people familiar with H.263
to look at this issue.)
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegpicture.c | 4
tests/ref/vsynth/vsynth1-h263-obmc | 4 ++--
tests/ref/vsynth/vsynth2-h263-obmc | 4 ++--
tests/ref/vsynth/vsynth_lena-h263-obmc | 4 ++--
4 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
index c57f149752..2192f74cea 100644
--- a/libavcodec/mpegpicture.c
+++ b/libavcodec/mpegpicture.c
@@ -280,6 +280,10 @@ int ff_alloc_picture(AVCodecContext *avctx, Picture *pic,
MotionEstContext *me,
for (i = 0; i < 2; i++) {
pic->motion_val[i] = (int16_t (*)[2])pic->motion_val_buf[i]->data
+ 4;
pic->ref_index[i] = pic->ref_index_buf[i]->data;
+/* FIXME: The output of H.263 with OBMC depends upon
+ * the earlier content of the buffer; therefore we
+ * reset it here. */
+memset(pic->motion_val_buf[i]->data, 0,
pic->motion_val_buf[i]->size);
}
}
diff --git a/tests/ref/vsynth/vsynth1-h263-obmc
b/tests/ref/vsynth/vsynth1-h263-obmc
index b7a267a8cb..aed283ed53 100644
--- a/tests/ref/vsynth/vsynth1-h263-obmc
+++ b/tests/ref/vsynth/vsynth1-h263-obmc
@@ -1,4 +1,4 @@
7dec64380f375e5118b66f3b1e24 *tests/data/fate/vsynth1-h263-obmc.avi
657320 tests/data/fate/vsynth1-h263-obmc.avi
-844f7ee27fa122e199fe20987b41a15c
*tests/data/fate/vsynth1-h263-obmc.out.rawvideo
-stddev:8.16 PSNR: 29.89 MAXDIFF: 113 bytes: 7603200/ 7603200
+2a69f6b37378aa34418dfd04ec98c1c8
*tests/data/fate/vsynth1-h263-obmc.out.rawvideo
+stddev:8.38 PSNR: 29.66 MAXDIFF: 116 bytes: 7603200/ 7603200
diff --git a/tests/ref/vsynth/vsynth2-h263-obmc
b/tests/ref/vsynth/vsynth2-h263-obmc
index 2cef7f551b..c0dcc3239e 100644
--- a/tests/ref/vsynth/vsynth2-h263-obmc
+++ b/tests/ref/vsynth/vsynth2-h263-obmc
@@ -1,4 +1,4 @@
2d8a58b295e03f94e6a41468b2d3909e *tests/data/fate/vsynth2-h263-obmc.avi
208522 tests/data/fate/vsynth2-h263-obmc.avi
-4a939ef99fc759293f2e609bfcacd2a4
*tests/data/fate/vsynth2-h263-obmc.out.rawvideo
-stddev:6.10 PSNR: 32.41 MAXDIFF: 90 bytes: 7603200/ 7603200
+3500b4227c1e6309ca5213414599266f
*tests/data/fate/vsynth2-h263-obmc.out.rawvideo
+stddev:6.19 PSNR: 32.29 MAXDIFF: 111 bytes: 7603200/ 7603200
diff --git a/tests/ref/vsynth/vsynth_lena-h263-obmc
b/tests/ref/vsynth/vsynth_lena-h263-obmc
index 5b963107f6..78d7cc7277 100644
--- a/tests/ref/vsynth/vsynth_lena-h263-obmc
+++ b/tests/ref/vsynth/vsynth_lena-h263-obmc
@@ -1,4 +1,4 @@
3c6946f808412ac320be9e0c36051ea2 *tests/data/fate/vsynth_lena-h263-obmc.avi
154730 tests/data/fate/vsynth_lena-h263-obmc.avi
-588d992d9d8096da8bdc5027268da914
*tests/data/fate/vsynth_lena-h263-obmc.out.rawvideo
-stddev:5.39 PSNR: 33.49 MAXDIFF: 82 bytes: 7603200/ 7603200
+737af7fb166e2260ba049ae6bc30673d
*tests/data/fate/vsynth_lena-h263-obmc.out.rawvideo
+stddev:5.42 PSNR: 33.44 MAXDIFF: 77 bytes: 7603200/ 7603200
--
2.34.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".
Re: [FFmpeg-devel] [PATCH 1/2] avformat/mov: Rework the AVIF parser to handle multiple items
On Tue, Aug 2, 2022 at 9:54 AM James Zern wrote: > > Andreas, > > On Thu, Jul 28, 2022 at 11:25 AM Vignesh Venkatasubramanian > wrote: > > > > Stores the item ids of all the items found in the file and > > processes the primary item at the end of the meta box. This patch > > does not change any behavior. It sets up the code for parsing > > alpha channel (and possibly images with 'grid') in follow up > > patches. > > > > Signed-off-by: Vignesh Venkatasubramanian > > --- > > libavformat/isom.h | 6 ++ > > libavformat/mov.c | 143 +++-- > > 2 files changed, 92 insertions(+), 57 deletions(-) > > > > Any more comments on this one? > Applied. ___ 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] doc/git-howto.texi: Document commit signing
On Tue, Aug 09, 2022 at 04:38:56PM -0300, James Almer wrote:
> On 8/9/2022 4:34 PM, Michael Niedermayer wrote:
> > From: Michael Niedermayer
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > doc/git-howto.texi | 22 +-
> > 1 file changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/git-howto.texi b/doc/git-howto.texi
> > index 874afabbbc..48389751a4 100644
> > --- a/doc/git-howto.texi
> > +++ b/doc/git-howto.texi
> > @@ -187,11 +187,18 @@ to make sure you don't have untracked files or
> > deletions.
> > git add [-i|-p|-A]
> > @end example
> > -Make sure you have told Git your name and email address
> > +Make sure you have told Git your name, email address and GPG key
> > @example
> > git config --global user.name "My Name"
> > git config --global user.email my@@email.invalid
> > +git config --global user.signingkey ABCDEF0123245
> > +@end example
> > +
> > +Enable signing all commits or use -S
> > +
> > +@example
> > +git config --global commit.gpgsign true
> > @end example
> > Use @option{--global} to set the global configuration for all your Git
> > checkouts.
> > @@ -423,6 +430,19 @@ git checkout -b svn_23456 $SHA1
> > where @var{$SHA1} is the commit hash from the @command{git log} output.
> > +@chapter gpg key generation
> > +
> > +If you have no gpg key yet, we recommand that you create a ed25519 based
> > key as it
>
> Recommend.
>
> > +is small, fast and secure. Especially it results in small signatures in
> > git.
> > +
> > +@example
> > +gpg --default-new-key-algo "ed25519/cert,sign+cv25519/encr"
> > --quick-generate-key "hu...@server.com"
> > +@end example
> > +
> > +When genarting a key, make sure the email specified matches the email used
> > in git as some sites like
>
> Generating
ok
>
> > +github consider mismatches a reason to declare such commits unverified.
> > After generating a key you
> > +can add it to the MAINTAINER file and upload it to a keyserver.
>
> Maybe link some external documentation about gpg keys, explaining the
> difference between public and private keys,
what do you recommend ?
> how to encrypt the private one
> with a passphrase, etc.
Have you tried to generate a gpg key without a passphrase ?
I just tried, and failed, gpg keeps asking for a passphrase until you enter
one or kill it. It kept haunting me and asking for a passphrase even after
trying ctrl-c
> Sites like gitlab tell you to not attempt to upload private keys,
ok
> so i
> imagine quite a lot of people have mistakenly done so in the past.
imagine?
but what do you suggest? we can document how someone can create a key
upload it and so on. You can provide me with a url that describes a
working documentation for that, i surely do not have one. alot of
documentations are somewhat bad. Many keyservers have died recently
some existing keys like DSA seem to have some affinity to SHA1, and
SHA1 is rejected today while at the same time still default on many
setups, the one documentation i saw today to fix that DSA/SHA1 issue
requires you to have a backup as it breaks your keys and is wrong.
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
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 v7 1/2] avformat: refactor ff_stream_encode_params_copy() to stream_params_copy()
On Mon, Aug 8, 2022 at 7:50 AM Pierre-Anthony Lemieux wrote:
>
> On Mon, Aug 8, 2022 at 7:48 AM Andreas Rheinhardt
> wrote:
> >
> > p...@sandflow.com:
> > > From: Pierre-Anthony Lemieux
> > >
> > > Addresses http://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/299726.html
> > >
> > > ---
> > > libavformat/avformat.c | 66
> > > libavformat/fifo.c | 8 ++---
> > > libavformat/internal.h | 11 +++
> > > libavformat/mux.h| 9 --
> > > libavformat/mux_utils.c | 28 -
> > > libavformat/segment.c| 6 ++--
> > > libavformat/tee.c| 7 ++---
> > > libavformat/webm_chunk.c | 6 ++--
> > > 8 files changed, 86 insertions(+), 55 deletions(-)
> > >
> > > diff --git a/libavformat/avformat.c b/libavformat/avformat.c
> > > index 30d6ea6a49..19c7219471 100644
> > > --- a/libavformat/avformat.c
> > > +++ b/libavformat/avformat.c
> > > @@ -235,6 +235,72 @@ int ff_stream_side_data_copy(AVStream *dst, const
> > > AVStream *src)
> > > return 0;
> > > }
> > >
> > > +/**
> > > + * Copy all stream parameters from source to destination stream, with the
> > > + * exception of the index field, which is usually set by
> > > avformat_new_stream().
> > > + *
> > > + * @param dst pointer to destination AVStream
> > > + * @param src pointer to source AVStream
> > > + * @return >=0 on success, AVERROR code on error
> > > + */
> > > +static int stream_params_copy(AVStream *dst, const AVStream *src)
> > > +{
> > > +int ret;
> > > +
> > > +dst->id = src->id;
> > > +dst->time_base = src->time_base;
> > > +dst->start_time = src->start_time;
> > > +dst->duration= src->duration;
> > > +dst->nb_frames = src->nb_frames;
> > > +dst->disposition = src->disposition;
> > > +dst->discard = src->discard;
> > > +dst->sample_aspect_ratio = src->sample_aspect_ratio;
> > > +dst->avg_frame_rate = src->avg_frame_rate;
> > > +dst->event_flags = src->event_flags;
> > > +dst->r_frame_rate= src->r_frame_rate;
> > > +dst->pts_wrap_bits = src->pts_wrap_bits;
> > > +
> > > +av_dict_free(&dst->metadata);
> > > +ret = av_dict_copy(&dst->metadata, src->metadata, 0);
> > > +if (ret < 0)
> > > +return ret;
> > > +
> > > +ret = avcodec_parameters_copy(dst->codecpar, src->codecpar);
> > > +if (ret < 0)
> > > +return ret;
> > > +
> > > +ret = ff_stream_side_data_copy(dst, src);
> > > +if (ret < 0)
> > > +return ret;
> > > +
> > > +av_packet_unref(&dst->attached_pic);
> > > +if (src->attached_pic.data) {
> > > +ret = av_packet_ref(&dst->attached_pic, &src->attached_pic);
> > > +if (ret < 0)
> > > +return ret;
> > > +}
> > > +
> > > +return 0;
> > > +}
> > > +
> > > +AVStream *ff_stream_clone(AVFormatContext *dst_ctx, const AVStream *src)
> > > +{
> > > +AVStream *st;
> > > +int ret;
> > > +
> > > +st = avformat_new_stream(dst_ctx, NULL);
> > > +if (!st)
> > > +return NULL;
> > > +
> > > +ret = stream_params_copy(st, src);
> > > +if (ret < 0) {
> > > +ff_remove_stream(dst_ctx, st);
> > > +return NULL;
> > > +}
> > > +
> > > +return st;
> > > +}
> > > +
> > > AVProgram *av_new_program(AVFormatContext *ac, int id)
> > > {
> > > AVProgram *program = NULL;
> > > diff --git a/libavformat/fifo.c b/libavformat/fifo.c
> > > index ead2bdc5cf..55d413b952 100644
> > > --- a/libavformat/fifo.c
> > > +++ b/libavformat/fifo.c
> > > @@ -505,13 +505,11 @@ static int fifo_mux_init(AVFormatContext *avf,
> > > const AVOutputFormat *oformat,
> > > avf2->flags = avf->flags;
> > >
> > > for (i = 0; i < avf->nb_streams; ++i) {
> > > -AVStream *st = avformat_new_stream(avf2, NULL);
> > > +AVStream *st = NULL;
> > > +
> > > +st = ff_stream_clone(avf2, avf->streams[i]);
> >
> > I don't know why you stopped initializing st directly with its eventual
> > value (if I see this corrently, the line wouldn't be overlong). I can
> > fix this upon commit if you allow. Anyway, I will apply this in two days
> > unless there are any comments from anyone else.
>
> I thought if() was not favored.
>
> Please modify as you see fit.
>
> Thanks.
Couldn't this entire code block be simplified to the following?
for (i = 0; i < avf->nb_streams; ++i)
if (!ff_stream_clone(avf2, avf->streams[i]))
return AVERROR(ENOMEM);
Happy to submit a revised patch if it helps.
>
> >
> > > if (!st)
> > > return AVERROR(ENOMEM);
> > > -
> > > -ret = ff_stream_encode_params_copy(st, avf->streams[i]);
> > > -if (ret < 0)
> > > -return ret;
> > > }
> > >
> > > return 0;
> > > diff --git a/libavformat/internal.h b/libavformat/internal.h
> > > index b6b8fbf56f..9b07cfb271 100644
> > > --- a/libavformat/in
