Re: [FFmpeg-devel] [PATCH] fix sidx size being doubled in offset. fixes an issue where if the video size was very specific, ffmpeg would hang from not filling the sidx_pts for all streams, due to not
On Sun, Jan 27, 2019 at 10:51:12 -0500, agrecascino...@gmail.com wrote: > Subject: [FFmpeg-devel] [PATCH] fix sidx size being doubled in offset. fixes > an issue where if the video size was very specific, ffmpeg would hang from > not filling the > sidx_pts for all streams, due to not reading the last sidx lump. for > #7572 Please split your commit message into a leading line, an empty line, and then the explanatory text. And the leading line should be something like (note the prefix): > avformat/mov: fix sidx size being doubled in offset I'm not sure your commit message is easy to be understand, but I'll let others worry about that. Thanks, Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fix sidx size being doubled in offset. fixes an issue where if the video size was very specific, ffmpeg would hang from not filling the sidx_pts for all streams, due to not
On Thu, Jan 31, 2019 at 10:16:00 +0100, Moritz Barsnick wrote: > Please split your commit message into a leading line, an empty line, > and then the explanatory text. Forget this, I didn't see V3 of your patch. D'uh, Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: Allow to query number of consumed bytes using the new API
30.01.19 21:42 - jannis_wth:
> 30.01.19 21:02 - James Almer:
>> I guess avctx->internal->last_pkt_props could work for this, but it may
>> not be consistent across decoders.
>
> avctx->internal->last_pkt_props stores the properties of the last passed
> packet, and does not get updated on decoding frames. Since I set the
> input-packets size to a constant (size is unknown) this is not very
> helpfull..
My bad, avctx->internal->last_pkt_props works as expected. Thank you James.
>From 2c9eee171e512a25c73c8ed144c8a130abb2d2a4 Mon Sep 17 00:00:00 2001
From: user
Date: Thu, 31 Jan 2019 10:28:22 +0100
Subject: [PATCH 1/1] avcodec: Allow to query number of consumed bytes using
the new API
Currently the only way to get the number of consumed bytes is by using
the deprecated decode_audio4() API. This patch adds a simple function
to fix this.
Signed-off-by: Jannis Kambs
---
libavcodec/avcodec.h | 9 +
libavcodec/utils.c | 5 +
2 files changed, 14 insertions(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index f554c53f0e..43bf84e58b 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -5714,6 +5714,15 @@ int av_get_audio_frame_duration(AVCodecContext *avctx, int frame_bytes);
*/
int av_get_audio_frame_duration2(AVCodecParameters *par, int frame_bytes);
+/**
+ * This function allows to get the number of remaining bytes after
+ * avcodec_receive_frame() has been called.
+ *
+ * @param avctx the codec context
+ * @return number of remaining bytes from the input AVPacket.
+ */
+int avcodec_get_remaining_size(AVCodecContext *avctx);
+
#if FF_API_OLD_BSF
typedef struct AVBitStreamFilterContext {
void *priv_data;
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index d519b16092..998e77524e 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1727,6 +1727,11 @@ int av_get_audio_frame_duration2(AVCodecParameters *par, int frame_bytes)
frame_bytes);
}
+int avcodec_get_remaining_size(AVCodecContext *avctx)
+{
+return avctx->internal->last_pkt_props->size;
+}
+
#if !HAVE_THREADS
int ff_thread_init(AVCodecContext *s)
{
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/gifdec: Optimize gif_fill() by using av_memset_bytes()
Improves speed for 780/clusterfuzz-testcase-6393552642768896 from 95 sec to 60
sec
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/gifdec.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/libavcodec/gifdec.c b/libavcodec/gifdec.c
index 2115da163f..c85f310140 100644
--- a/libavcodec/gifdec.c
+++ b/libavcodec/gifdec.c
@@ -86,11 +86,7 @@ static void gif_read_palette(GifState *s, uint32_t *pal, int
nb)
static void gif_fill(AVFrame *picture, uint32_t color)
{
-uint32_t *p = (uint32_t *)picture->data[0];
-uint32_t *p_end = p + (picture->linesize[0] / sizeof(uint32_t)) *
picture->height;
-
-for (; p < p_end; p++)
-*p = color;
+av_memset_bytes(picture->data[0], picture->linesize[0] * picture->height,
&color, 4);
}
static void gif_fill_rect(AVFrame *picture, uint32_t color, int l, int t, int
w, int h)
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avutil: export av_memset_bytes()
This function is useful in more cases than just imgutils
Signed-off-by: Michael Niedermayer
---
doc/APIchanges | 3 +++
libavutil/imgutils.c | 8 ++--
libavutil/imgutils.h | 10 ++
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 784a5e5bd2..dc239cbd47 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -21,6 +21,9 @@ API changes, most recent first:
2019-01-08 - xx - lavu 56.26.100 - frame.h
Add AV_FRAME_DATA_REGIONS_OF_INTEREST
+201x-xx-xx - xx - lavu 56.xx.xxx - imgutils.h
+ Add av_memset_bytes()
+
2018-12-21 - 2744d6b364 - lavu 56.25.100 - hdr_dynamic_metadata.h
Add AV_FRAME_DATA_DYNAMIC_HDR_PLUS enum value, av_dynamic_hdr_plus_alloc(),
av_dynamic_hdr_plus_create_side_data() functions, and related structs.
diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
index afc73e2def..3cc186b79f 100644
--- a/libavutil/imgutils.c
+++ b/libavutil/imgutils.c
@@ -494,11 +494,7 @@ int av_image_copy_to_buffer(uint8_t *dst, int dst_size,
return size;
}
-// Fill dst[0..dst_size] with the bytes in clear[0..clear_size]. The clear
-// bytes are repeated until dst_size is reached. If dst_size is unaligned (i.e.
-// dst_size%clear_size!=0), the remaining data will be filled with the
beginning
-// of the clear data only.
-static void memset_bytes(uint8_t *dst, size_t dst_size, uint8_t *clear,
+void av_memset_bytes(uint8_t *dst, size_t dst_size, uint8_t *clear,
size_t clear_size)
{
int same = 1;
@@ -636,7 +632,7 @@ int av_image_fill_black(uint8_t *dst_data[4], const
ptrdiff_t dst_linesize[4],
int plane_h = ((height + ( 1 << chroma_div) - 1)) >> chroma_div;
for (; plane_h > 0; plane_h--) {
-memset_bytes(data, bytewidth, &clear_block[plane][0],
clear_block_size[plane]);
+av_memset_bytes(data, bytewidth, &clear_block[plane][0],
clear_block_size[plane]);
data += dst_linesize[plane];
}
}
diff --git a/libavutil/imgutils.h b/libavutil/imgutils.h
index 5b790ecf0a..2f0f4b9106 100644
--- a/libavutil/imgutils.h
+++ b/libavutil/imgutils.h
@@ -269,6 +269,16 @@ int av_image_fill_black(uint8_t *dst_data[4], const
ptrdiff_t dst_linesize[4],
enum AVPixelFormat pix_fmt, enum AVColorRange range,
int width, int height);
+/**
+ * Fill dst[0..dst_size] with the bytes in clear[0..clear_size]. The clear
+ * bytes are repeated until dst_size is reached. If dst_size is unaligned (i.e.
+ * dst_size%clear_size!=0), the remaining data will be filled with the
beginning
+ * of the clear data only.
+ */
+void av_memset_bytes(uint8_t *dst, size_t dst_size, uint8_t *clear,
+ size_t clear_size);
+
+
/**
* @}
*/
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] zmbvenc: don't sum the entropy when blocks are equal
On Sun, 20 Jan 2019 at 15:16, Tomas Härdin wrote: > > Hi. Just to say, I tried setting up additional score_tabs for the > > bottom/right partial blocks. Unfortunately, after implementing it and > > ironing out the bugs, the new score tables actually caused a slight > > increase in file size! > > After a little informal investigation with a couple of videos, my > findings > > were that increasing the divisor - '(i / (double)(ZMBV_BLOCK * > ZMBV_BLOCK * > > some_factor))' - would generally lead to slight compression improvements. > > Given the score table is still "valid" for smaller blocks, and given the > > extra complexity of adding the score tables, plus the fact that it may > > generally hurt the compression, I'm inclined to leave it with the one > score > > table. But there may be potential to improve the current compression > > method in future, by somehow tuning the divisor for better results > > generally. > > Huh, that's strange. Sounds like something that warrants a comment in > the code. I also see we have an answer do Carl's question: you're still > experimenting with this :) I think we can hold off on pushing anything > until you feel happy with the result > Hi. Sorry, I had missed Carl's question. Regrettably my work on this has been slow since my initial patch submissions, but I think I'm close to submitting some final changes. Thanks for your patience so far. I have recently made two helpful realisations about the above score table problem: 1. The entropy calculation in block_cmp() omits the score of histogram[0] from the final sum. It's tempting to do this to bias the scores in favour of 0-bytes, but in reality, blocks with a majority of 0 (or any other byte) will already be naturally favoured by the entropy score anyway, and this bias will fail to penalise blocks with an "average" (i.e. high entropy) number of 0's in them. The exact implications are difficult to ponder, but in practical terms this error does tend to produce worse results in the video compression. Not massively so, but it's still noticeable. (Math is a harsh mistress, and will often look unkindly on such flagrant attempts to circumvent her laws.. :) 2. As long as the blocks being compared are the same size as each other, the entropy-based score comparisons (without the above bias) are unaffected by the base of the log, or the divisor used. (Mathematically, if 'a+b=c+d', then if 'a*log(a) + b*log(b) < c*log(c) + d*log(d)' then it is also true that 'a*log(a/N) + b*log(b/N) < c*log(c/N) + d*log(d/N)'. If that doesn't make sense, it helps to note that 'log(a/N) = log(a) - log(N)', so the log(N)'s cancel out.) This means that we can use a single score table for all block sizes! It only needs to be big enough for the largest block size, then it produces optimal scores for all blocks up to that size. It does mean that partial blocks with uniform bytes won't have a score of 0, but this property of entropy is not actually important when scoring the blocks. (Overall, this is a significant relief, because my attempts at multiple score tables resulted in a lot of tricky decisions about how best to keep the code DRY and minimise complexity, and I wasn't really happy with my solution.) I am planning to organise my submission into two patches. I intend for one to focus on problems/inefficiencies in block comparisons/score tables. The other will be focused on motion estimation, i.e. the range of MV's that are compared, and to a very small extent, the order they're compared in. This avoids the overhead of patching each individual issue separately, but it will provide a logical split between the two main areas of change. Kind regards, Matthew ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fix sidx size being doubled in offset. fixes an issue where if the video size was very specific, ffmpeg would hang from not filling the sidx_pts for all streams, due to not
sorry i sent my first two emails about 4 days ago and after waiting a few days i just decided to subscribe and resubmit my patches. i think they just got through now. Sent from my iPhone > On Jan 31, 2019, at 4:16 AM, Moritz Barsnick wrote: > >> On Thu, Jan 31, 2019 at 10:16:00 +0100, Moritz Barsnick wrote: >> Please split your commit message into a leading line, an empty line, >> and then the explanatory text. > > Forget this, I didn't see V3 of your patch. > > D'uh, > Moritz > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavfi/vf_nlmeans: Improve the performance for nlmeans
Remove the pdiff_lut_scale in nlmeans, when search the weight_luttable
in nlmeans_slices(), the old way need to the float-point arithmetic
using pdiff_lut_scale. This change will avoid using pdiff_lut_scale
in the weight_lut table search, it's will improve the performance about
12%. (1080P size picture).
Use the profiling cmd like:
perf stat -a -d -r 5 ./ffmpeg -i input -an -vf nlmeans=s=30 -vframes 10 \
-f null /dev/null
without this change:
when s=1.0(default value) 63s
s=30.0 72s
after this change:
s=1.0(default value) 56s
s=30.0 63s
Signed-off-by: Jun Zhao
---
libavfilter/vf_nlmeans.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/libavfilter/vf_nlmeans.c b/libavfilter/vf_nlmeans.c
index 82e779c..72eb819 100644
--- a/libavfilter/vf_nlmeans.c
+++ b/libavfilter/vf_nlmeans.c
@@ -43,8 +43,7 @@ struct weighted_avg {
float sum;
};
-#define WEIGHT_LUT_NBITS 9
-#define WEIGHT_LUT_SIZE (1< 300 * 300 * log(255)
typedef struct NLMeansContext {
const AVClass *class;
@@ -63,7 +62,6 @@ typedef struct NLMeansContext {
struct weighted_avg *wa;// weighted average of every
pixel
ptrdiff_t wa_linesize; // linesize for wa in struct
size unit
float weight_lut[WEIGHT_LUT_SIZE]; // lookup table mapping
(scaled) patch differences to their associated weights
-float pdiff_lut_scale; // scale factor for patch
differences before looking into the LUT
uint32_t max_meaningful_diff; // maximum difference
considered (if the patch difference is too high we ignore the pixel)
NLMeansDSPContext dsp;
} NLMeansContext;
@@ -401,8 +399,7 @@ static int nlmeans_slice(AVFilterContext *ctx, void *arg,
int jobnr, int nb_jobs
const uint32_t patch_diff_sq = e - d - b + a;
if (patch_diff_sq < s->max_meaningful_diff) {
-const unsigned weight_lut_idx = patch_diff_sq *
s->pdiff_lut_scale;
-const float weight = s->weight_lut[weight_lut_idx]; //
exp(-patch_diff_sq * s->pdiff_scale)
+const float weight = s->weight_lut[patch_diff_sq]; //
exp(-patch_diff_sq * s->pdiff_scale)
wa[x].total_weight += weight;
wa[x].sum += weight * src[x];
}
@@ -527,10 +524,9 @@ static av_cold int init(AVFilterContext *ctx)
s->pdiff_scale = 1. / (h * h);
s->max_meaningful_diff = -log(1/255.) / s->pdiff_scale;
-s->pdiff_lut_scale = 1./s->max_meaningful_diff * WEIGHT_LUT_SIZE;
-av_assert0((s->max_meaningful_diff - 1) * s->pdiff_lut_scale <
FF_ARRAY_ELEMS(s->weight_lut));
+av_assert0((s->max_meaningful_diff - 1) < FF_ARRAY_ELEMS(s->weight_lut));
for (i = 0; i < WEIGHT_LUT_SIZE; i++)
-s->weight_lut[i] = exp(-i / s->pdiff_lut_scale * s->pdiff_scale);
+s->weight_lut[i] = exp(-i * s->pdiff_scale);
CHECK_ODD_FIELD(research_size, "Luma research window");
CHECK_ODD_FIELD(patch_size, "Luma patch");
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avutil: export av_memset_bytes()
On Thu, Jan 31, 2019 at 14:09:01 +0100, Michael Niedermayer wrote: > This function is useful in more cases than just imgutils [...] > libavutil/imgutils.c | 8 ++-- > libavutil/imgutils.h | 10 ++ If so, couldn't it be placed in libavutil/mem.[ch]? It seems appropriate. Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] zmbvenc: don't sum the entropy when blocks are equal
tor 2019-01-31 klockan 13:31 + skrev Matthew Fearnley: > > On Sun, 20 Jan 2019 at 15:16, Tomas Härdin wrote: > > > > Hi. Just to say, I tried setting up additional score_tabs for the > > > bottom/right partial blocks. Unfortunately, after implementing it and > > > ironing out the bugs, the new score tables actually caused a slight > > > increase in file size! > > > After a little informal investigation with a couple of videos, my > > > > findings > > > were that increasing the divisor - '(i / (double)(ZMBV_BLOCK * > > > > ZMBV_BLOCK * > > > some_factor))' - would generally lead to slight compression improvements. > > > Given the score table is still "valid" for smaller blocks, and given the > > > extra complexity of adding the score tables, plus the fact that it may > > > generally hurt the compression, I'm inclined to leave it with the one > > > > score > > > table. But there may be potential to improve the current compression > > > method in future, by somehow tuning the divisor for better results > > > generally. > > > > Huh, that's strange. Sounds like something that warrants a comment in > > the code. I also see we have an answer do Carl's question: you're still > > experimenting with this :) I think we can hold off on pushing anything > > until you feel happy with the result > > > > Hi. > Sorry, I had missed Carl's question. Regrettably my work on this has been > slow since my initial patch submissions, but I think I'm close to > submitting some final changes. Thanks for your patience so far. > > I have recently made two helpful realisations about the above score table > problem: > > 1. The entropy calculation in block_cmp() omits the score of histogram[0] > from the final sum. > It's tempting to do this to bias the scores in favour of 0-bytes, but in > reality, blocks with a majority of 0 (or any other byte) will already be > naturally favoured by the entropy score anyway, and this bias will fail to > penalise blocks with an "average" (i.e. high entropy) number of 0's in them. > The exact implications are difficult to ponder, but in practical terms this > error does tend to produce worse results in the video compression. Not > massively so, but it's still noticeable. Did you try combining the statistics of the current MV with the statistics of the previous block, to bias the choice in favor of similar bytes? Could work like a cheap order-1 entropy model. > 2. As long as the blocks being compared are the same size as each other, > the entropy-based score comparisons (without the above bias) are unaffected > by the base of the log, or the divisor used. > (Mathematically, if 'a+b=c+d', then if 'a*log(a) + b*log(b) < c*log(c) + > d*log(d)' then it is also true that 'a*log(a/N) + b*log(b/N) < c*log(c/N) + > d*log(d/N)'. > If that doesn't make sense, it helps to note that 'log(a/N) = log(a) - > log(N)', so the log(N)'s cancel out.) Convenient observation :) > I am planning to organise my submission into two patches. I intend for one > to focus on problems/inefficiencies in block comparisons/score tables. The > other will be focused on motion estimation, i.e. the range of MV's that are > compared, and to a very small extent, the order they're compared in. > This avoids the overhead of patching each individual issue separately, but > it will provide a logical split between the two main areas of change. Sounds good! /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavcodec/rscc.c: add missing semicolon
Signed-off-by: Mateusz Brzostek
---
libavcodec/rscc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/rscc.c b/libavcodec/rscc.c
index e4b51973d8..7d4e842cd3 100644
--- a/libavcodec/rscc.c
+++ b/libavcodec/rscc.c
@@ -64,7 +64,7 @@ typedef struct RsccContext {
/* zlib interaction */
uint8_t *inflated_buf;
uLongf inflated_size;
-int valid_pixels
+int valid_pixels;
} RsccContext;
static av_cold int rscc_init(AVCodecContext *avctx)
--
2.20.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/rscc.c: add missing semicolon
On 1/31/2019 12:36 PM, Mateusz wrote:
> Signed-off-by: Mateusz Brzostek
> ---
> libavcodec/rscc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/rscc.c b/libavcodec/rscc.c
> index e4b51973d8..7d4e842cd3 100644
> --- a/libavcodec/rscc.c
> +++ b/libavcodec/rscc.c
> @@ -64,7 +64,7 @@ typedef struct RsccContext {
> /* zlib interaction */
> uint8_t *inflated_buf;
> uLongf inflated_size;
> -int valid_pixels
> +int valid_pixels;
> } RsccContext;
>
> static av_cold int rscc_init(AVCodecContext *avctx)
>
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/ffv1: Simplify fold()
On Sun, Jan 27, 2019 at 01:44:13AM +0100, Michael Niedermayer wrote: > No speed difference, or slightly faster (the difference is too small so it > may be noise > that this appears faster) > > Signed-off-by: Michael Niedermayer > --- > libavcodec/ffv1.h | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) will apply patchset [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/rscc.c: add missing semicolon
On Thu, Jan 31, 2019 at 12:49:22PM -0300, James Almer wrote:
> On 1/31/2019 12:36 PM, Mateusz wrote:
> > Signed-off-by: Mateusz Brzostek
> > ---
> > libavcodec/rscc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/rscc.c b/libavcodec/rscc.c
> > index e4b51973d8..7d4e842cd3 100644
> > --- a/libavcodec/rscc.c
> > +++ b/libavcodec/rscc.c
> > @@ -64,7 +64,7 @@ typedef struct RsccContext {
> > /* zlib interaction */
> > uint8_t *inflated_buf;
> > uLongf inflated_size;
> > -int valid_pixels
> > +int valid_pixels;
> > } RsccContext;
> >
> > static av_cold int rscc_init(AVCodecContext *avctx)
> >
>
> LGTM
will apply unless someone else is faster
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] web/consulting: add myself
From a03e88da9deb21b800714b695b4d99edb54397ff Mon Sep 17 00:00:00 2001 From: Gyan Doshi Date: Thu, 31 Jan 2019 21:44:19 +0530 Subject: [PATCH] web/consulting: add myself Signed-off-by: Gyan Doshi --- src/consulting | 13 + 1 file changed, 13 insertions(+) diff --git a/src/consulting b/src/consulting index c04b7b4..7dbc61c 100644 --- a/src/consulting +++ b/src/consulting @@ -158,3 +158,16 @@ E.g.: + + + + Gyan Doshi + +Gyan is located in Mumbai, India and is available for consulting +work. He has been a maintainer since 2018, and has expertise in ff* tools usage +and troubleshooting. You can contact him by email at +mailto:ffmpeg%20at%20gyani%20dot%20pro";>ffmpeg at gyani dot pro. + + + + -- 2.19.2___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavcodec: vp8 neon optimizations for aarch64
Partial port of the ARM Neon for aarch64. Benchmarks from fate: benchmarking with Linux Perf Monitoring API nop: 58.6 checkasm: using random seed 1760970128 NEON: - vp8dsp.idct [OK] - vp8dsp.mc [OK] - vp8dsp.loopfilter [OK] checkasm: all 21 tests passed vp8_idct_add_c: 201.6 vp8_idct_add_neon: 83.1 vp8_idct_dc_add_c: 107.6 vp8_idct_dc_add_neon: 33.8 vp8_idct_dc_add4y_c: 426.4 vp8_idct_dc_add4y_neon: 59.4 vp8_loop_filter8uv_h_c: 688.1 vp8_loop_filter8uv_h_neon: 216.3 vp8_loop_filter8uv_inner_h_c: 649.3 vp8_loop_filter8uv_inner_h_neon: 195.3 vp8_loop_filter8uv_inner_v_c: 544.8 vp8_loop_filter8uv_inner_v_neon: 131.3 vp8_loop_filter8uv_v_c: 706.1 vp8_loop_filter8uv_v_neon: 141.1 vp8_loop_filter16y_h_c: 668.8 vp8_loop_filter16y_h_neon: 242.8 vp8_loop_filter16y_inner_h_c: 647.3 vp8_loop_filter16y_inner_h_neon: 224.6 vp8_loop_filter16y_inner_v_c: 647.8 vp8_loop_filter16y_inner_v_neon: 128.8 vp8_loop_filter16y_v_c: 721.8 vp8_loop_filter16y_v_neon: 154.3 vp8_loop_filter_simple_h_c: 387.8 vp8_loop_filter_simple_h_neon: 187.6 vp8_loop_filter_simple_v_c: 384.1 vp8_loop_filter_simple_v_neon: 78.6 vp8_put_epel8_h4v4_c: 3971.1 vp8_put_epel8_h4v4_neon: 855.1 vp8_put_epel8_h4v6_c: 5060.1 vp8_put_epel8_h4v6_neon: 989.6 vp8_put_epel8_h6v4_c: 4320.8 vp8_put_epel8_h6v4_neon: 1007.3 vp8_put_epel8_h6v6_c: 5449.3 vp8_put_epel8_h6v6_neon: 1158.1 vp8_put_epel16_h6_c: 6683.8 vp8_put_epel16_h6_neon: 831.8 vp8_put_epel16_h6v6_c: 0.8 vp8_put_epel16_h6v6_neon: 2214.8 vp8_put_epel16_v6_c: 7024.8 vp8_put_epel16_v6_neon: 799.6 vp8_put_pixels8_c: 112.8 vp8_put_pixels8_neon: 78.1 vp8_put_pixels16_c: 131.3 vp8_put_pixels16_neon: 129.8 Signed-off-by: Magnus Röös --- libavcodec/aarch64/Makefile |2 + libavcodec/aarch64/vp8dsp.h | 70 ++ libavcodec/aarch64/vp8dsp_init_aarch64.c | 81 +++ libavcodec/aarch64/vp8dsp_neon.S | 1031 ++ libavcodec/vp8dsp.c |4 + libavcodec/vp8dsp.h |2 + 6 files changed, 1190 insertions(+) create mode 100644 libavcodec/aarch64/vp8dsp.h create mode 100644 libavcodec/aarch64/vp8dsp_init_aarch64.c create mode 100644 libavcodec/aarch64/vp8dsp_neon.S diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile index 72080c2dbb..2f57bce55b 100644 --- a/libavcodec/aarch64/Makefile +++ b/libavcodec/aarch64/Makefile @@ -48,6 +48,8 @@ NEON-OBJS-$(CONFIG_MPEGAUDIODSP)+= aarch64/mpegaudiodsp_neon.o NEON-OBJS-$(CONFIG_AAC_DECODER) += aarch64/aacpsdsp_neon.o NEON-OBJS-$(CONFIG_DCA_DECODER) += aarch64/synth_filter_neon.o NEON-OBJS-$(CONFIG_VORBIS_DECODER) += aarch64/vorbisdsp_neon.o +NEON-OBJS-$(CONFIG_VP8DSP) += aarch64/vp8dsp_init_aarch64.o \ + aarch64/vp8dsp_neon.o NEON-OBJS-$(CONFIG_VP9_DECODER) += aarch64/vp9itxfm_16bpp_neon.o \ aarch64/vp9itxfm_neon.o \ aarch64/vp9lpf_16bpp_neon.o \ diff --git a/libavcodec/aarch64/vp8dsp.h b/libavcodec/aarch64/vp8dsp.h new file mode 100644 index 00..960dfa8124 --- /dev/null +++ b/libavcodec/aarch64/vp8dsp.h @@ -0,0 +1,70 @@ +/* + * 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 + */ + +#ifndef AVCODEC_ARM_VP8DSP_H +#define AVCODEC_ARM_VP8DSP_H + +#include "libavcodec/vp8dsp.h" + +#define VP8_LF_Y(hv, inner, opt) \ +void ff_vp8_##hv##_loop_filter16##inner##_##opt(uint8_t *dst,\ +ptrdiff_t stride,\ +int flim_E, int flim_I, \ +int hev_thresh) + +#define VP8_LF_UV(hv, inner, opt)\ +void ff_vp8_##hv##_loop_filter8uv##inner##_##opt(uint8_t *dstU, \ + uint8_t *dstV, \ + ptrdiff_t stride, \ + int flim_E, int flim_I, \ +
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add discard_sample_percentage
On Sat, Jan 19, 2019 at 12:00:48AM +0100, Michael Niedermayer wrote: > Suggested-by: BBB > Signed-off-by: Michael Niedermayer > --- > doc/APIchanges | 3 +++ > libavcodec/avcodec.h | 8 > libavcodec/options_table.h | 1 + > tests/ref/fate/api-mjpeg-codec-param | 2 ++ > tests/ref/fate/api-png-codec-param | 2 ++ > 5 files changed, 16 insertions(+) do people prefer i backport this user parameter to release branches or is it preferred to ommit fixes which depend on this option ? or some other solution ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_parse: no need check ref list1 for P slices.
On Thu, Jan 31, 2019 at 03:36:56PM +0800, Decai Lin wrote: > This is robust for some corner case there is incorrect list1 count > in pps header, but it's a P slice and can be decoded well. please provide a sample h264 video that needs this thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add discard_sample_percentage
On 1/31/2019 1:25 PM, Michael Niedermayer wrote: > On Sat, Jan 19, 2019 at 12:00:48AM +0100, Michael Niedermayer wrote: >> Suggested-by: BBB >> Signed-off-by: Michael Niedermayer >> --- >> doc/APIchanges | 3 +++ >> libavcodec/avcodec.h | 8 >> libavcodec/options_table.h | 1 + >> tests/ref/fate/api-mjpeg-codec-param | 2 ++ >> tests/ref/fate/api-png-codec-param | 2 ++ >> 5 files changed, 16 insertions(+) > > do people prefer i backport this user parameter to release branches or is > it preferred > to ommit fixes which depend on this option ? > or some other solution ? No, don't backport API like this. And unless it's security related, i would just not adapt and backport fixes that depend on it. > > thx > > [...] > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix sidx size being doubled in offset.
On Sun, Jan 27, 2019 at 11:08:29AM -0500, agrecascino...@gmail.com wrote:
> From: mptcultist
>
> fixes an issue where if the video size was very specific, ffmpeg would hang
> from not filling the sidx_pts for all streams, due to not reading the last
> sidx lump. for #7572
>
> ---
> libavformat/mov.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 9b9739f788..c222582886 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -4933,7 +4933,7 @@ static int mov_read_trun(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
>
> static int mov_read_sidx(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> {
> -int64_t offset = avio_tell(pb) + atom.size, pts, timestamp;
> +int64_t offset = avio_tell(pb), pts, timestamp;
> uint8_t version;
> unsigned i, j, track_id, item_count;
> AVStream *st = NULL;
this breaks fate-mov-frag-encrypted
TESTmov-frag-encrypted
--- ./tests/ref/fate/mov-frag-encrypted 2019-01-31 18:04:25.857528993 +0100
+++ tests/data/fate/mov-frag-encrypted 2019-01-31 19:44:38.301710624 +0100
@@ -1,57 +0,0 @@
-#format: frame checksums
-#version: 2
-#hash: MD5
-#tb 0: 1/24
-#media_type 0: video
-#codec_id 0: rawvideo
-#dimensions 0: 120x52
-#sar 0: 544/545
-#stream#, dts,pts, duration, size, hash
-0, 0, 0,1, 9360, 920bdc277a6a31c1daed9aca44b10caf
-0, 1, 1,1, 9360, f1c0b61fef593de57cb97be7fa846569
-0, 2, 2,1, 9360, 6ef32d9d4398355aebf6d3fb11d51d3f
...
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Fix Markdown formatting
--- INSTALL.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/INSTALL.md b/INSTALL.md index 5db912231c..3b220bc6ff 100644 --- a/INSTALL.md +++ b/INSTALL.md @@ -1,4 +1,4 @@ -#Installing FFmpeg: +## Installing FFmpeg 1. Type `./configure` to create the configuration. A list of configure options is printed by running `configure --help`. -- 2.19.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] web/consulting: add myself
On Thu, 31 Jan 2019 21:57:38 +0530 Gyan wrote: > From a03e88da9deb21b800714b695b4d99edb54397ff Mon Sep 17 00:00:00 2001 > From: Gyan Doshi > Date: Thu, 31 Jan 2019 21:44:19 +0530 > Subject: [PATCH] web/consulting: add myself > > Signed-off-by: Gyan Doshi > --- > src/consulting | 13 + > 1 file changed, 13 insertions(+) Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec: vp8 neon optimizations for aarch64
2019-01-31 17:04 GMT+01:00, Magnus Röös : > Partial port of the ARM Neon for aarch64. Reproduced a >20% speedup for fate-vp8 and applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fix Markdown formatting
On Thu, 31 Jan 2019 11:46:49 -0500 Justin Bull wrote: > --- > INSTALL.md | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/INSTALL.md b/INSTALL.md > index 5db912231c..3b220bc6ff 100644 > --- a/INSTALL.md > +++ b/INSTALL.md > @@ -1,4 +1,4 @@ > -#Installing FFmpeg: > +## Installing FFmpeg > > 1. Type `./configure` to create the configuration. A list of configure > options is printed by running `configure --help`. Applied, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi/vf_nlmeans: Improve the performance for nlmeans
2019-01-31 14:55 GMT+01:00, Jun Zhao : > Remove the pdiff_lut_scale in nlmeans, when search the weight_luttable > in nlmeans_slices(), the old way need to the float-point arithmetic > using pdiff_lut_scale. This change will avoid using pdiff_lut_scale > in the weight_lut table search, it's will improve the performance about > 12%. (1080P size picture). Please mention the change in heap memory requirement with numbers. Remove "old way need to the float-point arithmetic" because new way also needs (some) floating-point arithmetic. Feel free not to mention pdiff_lut_scale in the commit message. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavf:Constify AVInputFormat pointer
Hi!
Attached patch persistently uses "const" for AVInputFormat pointer
after the next version bump.
Please comment, Carl Eugen
From 95fc17cc1a82ea6d2e9e96932e145cc2b4c210b6 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 31 Jan 2019 21:40:58 +0100
Subject: [PATCH] lavf: Constify AVInputFormat pointer.
---
libavformat/allformats.c |6 +-
libavformat/avformat.h | 32 +++-
libavformat/dashdec.c|3 +++
libavformat/hls.c|3 +++
libavformat/img2dec.c|2 +-
libavformat/mpeg.c |3 +++
libavformat/rtpdec_asf.c |3 +++
libavformat/sapdec.c |3 +++
libavformat/utils.c | 11 ---
libavformat/version.h|3 +++
10 files changed, 63 insertions(+), 6 deletions(-)
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 0684498..01c4c14 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -583,7 +583,11 @@ AVInputFormat *av_iformat_next(const AVInputFormat *f)
ff_thread_once(&av_format_next_init, av_format_init_next);
if (f)
-return f->next;
+return
+#if !FF_API_AVINPUTFORMAT
+ (AVInputFormat *)
+#endif
+ f->next;
else {
void *opaque = NULL;
return (AVInputFormat *)av_demuxer_iterate(&opaque);
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index fdaffa5..7c4ec8f 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -676,7 +676,10 @@ typedef struct AVInputFormat {
* New public fields should be added right above.
*
*/
-struct AVInputFormat *next;
+#if !FF_API_AVINPUTFORMAT
+const
+#endif
+struct AVInputFormat *next;
/**
* Raw demuxers store their codec ID here.
@@ -1346,6 +1349,9 @@ typedef struct AVFormatContext {
*
* Demuxing only, set by avformat_open_input().
*/
+#if !FF_API_AVINPUTFORMAT
+const
+#endif
struct AVInputFormat *iformat;
/**
@@ -,6 +2228,9 @@ int avformat_alloc_output_context2(AVFormatContext **ctx, AVOutputFormat *oforma
/**
* Find AVInputFormat based on the short name of the input format.
*/
+#if !FF_API_AVINPUTFORMAT
+const
+#endif
AVInputFormat *av_find_input_format(const char *short_name);
/**
@@ -2231,6 +2240,9 @@ AVInputFormat *av_find_input_format(const char *short_name);
* @param is_opened Whether the file is already opened; determines whether
* demuxers with or without AVFMT_NOFILE are probed.
*/
+#if !FF_API_AVINPUTFORMAT
+const
+#endif
AVInputFormat *av_probe_input_format(AVProbeData *pd, int is_opened);
/**
@@ -2245,6 +2257,9 @@ AVInputFormat *av_probe_input_format(AVProbeData *pd, int is_opened);
* If the score is <= AVPROBE_SCORE_MAX / 4 it is recommended
* to retry with a larger probe buffer.
*/
+#if !FF_API_AVINPUTFORMAT
+const
+#endif
AVInputFormat *av_probe_input_format2(AVProbeData *pd, int is_opened, int *score_max);
/**
@@ -2254,6 +2269,9 @@ AVInputFormat *av_probe_input_format2(AVProbeData *pd, int is_opened, int *score
* demuxers with or without AVFMT_NOFILE are probed.
* @param score_ret The score of the best detection.
*/
+#if !FF_API_AVINPUTFORMAT
+const
+#endif
AVInputFormat *av_probe_input_format3(AVProbeData *pd, int is_opened, int *score_ret);
/**
@@ -2272,14 +2290,22 @@ AVInputFormat *av_probe_input_format3(AVProbeData *pd, int is_opened, int *score
* the maximal score is AVPROBE_SCORE_MAX
* AVERROR code otherwise
*/
+#if FF_API_AVINPUTFORMAT
int av_probe_input_buffer2(AVIOContext *pb, AVInputFormat **fmt,
+#else
+int av_probe_input_buffer2(AVIOContext *pb, const AVInputFormat **fmt,
+#endif
const char *url, void *logctx,
unsigned int offset, unsigned int max_probe_size);
/**
* Like av_probe_input_buffer2() but returns 0 on success
*/
+#if FF_API_AVINPUTFORMAT
int av_probe_input_buffer(AVIOContext *pb, AVInputFormat **fmt,
+#else
+int av_probe_input_buffer(AVIOContext *pb, const AVInputFormat **fmt,
+#endif
const char *url, void *logctx,
unsigned int offset, unsigned int max_probe_size);
@@ -2302,7 +2328,11 @@ int av_probe_input_buffer(AVIOContext *pb, AVInputFormat **fmt,
*
* @note If you want to use custom IO, preallocate the format context and set its pb field.
*/
+#if FF_API_AVINPUTFORMAT
int avformat_open_input(AVFormatContext **ps, const char *url, AVInputFormat *fmt, AVDictionary **options);
+#else
+int avformat_open_input(AVFormatContext **ps, const char *url, const AVInputFormat *fmt, AVDictionary **options);
+#endif
attribute_deprecated
int av_demuxer_open(AVFormatContext *ic);
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index f4f4e93..ad9cdb1 100644
--- a/libavformat/dashdec.c
+++ b/l
Re: [FFmpeg-devel] [PATCH]lavf:Constify AVInputFormat pointer
2019-01-31 21:43 GMT+01:00, Carl Eugen Hoyos :
> Hi!
>
> Attached patch persistently uses "const" for AVInputFormat pointer
> after the next version bump.
Now with an actually working version.
Please comment, Carl Eugen
From f383a7f914b2c7240378b404d529a7d73c68941b Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 31 Jan 2019 21:51:56 +0100
Subject: [PATCH] lavf: Constify AVInputFormat pointer.
---
libavformat/allformats.c |6 +-
libavformat/avformat.h | 32 +++-
libavformat/dashdec.c|3 +++
libavformat/format.c | 32 ++--
libavformat/hls.c|3 +++
libavformat/img2dec.c|2 +-
libavformat/mpeg.c |3 +++
libavformat/rtpdec_asf.c |3 +++
libavformat/sapdec.c |3 +++
libavformat/utils.c | 11 ---
libavformat/version.h|3 +++
11 files changed, 93 insertions(+), 8 deletions(-)
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 0684498..01c4c14 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -583,7 +583,11 @@ AVInputFormat *av_iformat_next(const AVInputFormat *f)
ff_thread_once(&av_format_next_init, av_format_init_next);
if (f)
-return f->next;
+return
+#if !FF_API_AVINPUTFORMAT
+ (AVInputFormat *)
+#endif
+ f->next;
else {
void *opaque = NULL;
return (AVInputFormat *)av_demuxer_iterate(&opaque);
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index fdaffa5..7c4ec8f 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -676,7 +676,10 @@ typedef struct AVInputFormat {
* New public fields should be added right above.
*
*/
-struct AVInputFormat *next;
+#if !FF_API_AVINPUTFORMAT
+const
+#endif
+struct AVInputFormat *next;
/**
* Raw demuxers store their codec ID here.
@@ -1346,6 +1349,9 @@ typedef struct AVFormatContext {
*
* Demuxing only, set by avformat_open_input().
*/
+#if !FF_API_AVINPUTFORMAT
+const
+#endif
struct AVInputFormat *iformat;
/**
@@ -,6 +2228,9 @@ int avformat_alloc_output_context2(AVFormatContext **ctx, AVOutputFormat *oforma
/**
* Find AVInputFormat based on the short name of the input format.
*/
+#if !FF_API_AVINPUTFORMAT
+const
+#endif
AVInputFormat *av_find_input_format(const char *short_name);
/**
@@ -2231,6 +2240,9 @@ AVInputFormat *av_find_input_format(const char *short_name);
* @param is_opened Whether the file is already opened; determines whether
* demuxers with or without AVFMT_NOFILE are probed.
*/
+#if !FF_API_AVINPUTFORMAT
+const
+#endif
AVInputFormat *av_probe_input_format(AVProbeData *pd, int is_opened);
/**
@@ -2245,6 +2257,9 @@ AVInputFormat *av_probe_input_format(AVProbeData *pd, int is_opened);
* If the score is <= AVPROBE_SCORE_MAX / 4 it is recommended
* to retry with a larger probe buffer.
*/
+#if !FF_API_AVINPUTFORMAT
+const
+#endif
AVInputFormat *av_probe_input_format2(AVProbeData *pd, int is_opened, int *score_max);
/**
@@ -2254,6 +2269,9 @@ AVInputFormat *av_probe_input_format2(AVProbeData *pd, int is_opened, int *score
* demuxers with or without AVFMT_NOFILE are probed.
* @param score_ret The score of the best detection.
*/
+#if !FF_API_AVINPUTFORMAT
+const
+#endif
AVInputFormat *av_probe_input_format3(AVProbeData *pd, int is_opened, int *score_ret);
/**
@@ -2272,14 +2290,22 @@ AVInputFormat *av_probe_input_format3(AVProbeData *pd, int is_opened, int *score
* the maximal score is AVPROBE_SCORE_MAX
* AVERROR code otherwise
*/
+#if FF_API_AVINPUTFORMAT
int av_probe_input_buffer2(AVIOContext *pb, AVInputFormat **fmt,
+#else
+int av_probe_input_buffer2(AVIOContext *pb, const AVInputFormat **fmt,
+#endif
const char *url, void *logctx,
unsigned int offset, unsigned int max_probe_size);
/**
* Like av_probe_input_buffer2() but returns 0 on success
*/
+#if FF_API_AVINPUTFORMAT
int av_probe_input_buffer(AVIOContext *pb, AVInputFormat **fmt,
+#else
+int av_probe_input_buffer(AVIOContext *pb, const AVInputFormat **fmt,
+#endif
const char *url, void *logctx,
unsigned int offset, unsigned int max_probe_size);
@@ -2302,7 +2328,11 @@ int av_probe_input_buffer(AVIOContext *pb, AVInputFormat **fmt,
*
* @note If you want to use custom IO, preallocate the format context and set its pb field.
*/
+#if FF_API_AVINPUTFORMAT
int avformat_open_input(AVFormatContext **ps, const char *url, AVInputFormat *fmt, AVDictionary **options);
+#else
+int avformat_open_input(AVFormatContext **ps, const char *url, const AVInputFormat *fmt, AVDictionary **options);
+#endif
attribute_deprecated
int av_
Re: [FFmpeg-devel] [PATCH]lavf:Constify AVInputFormat pointer
On 1/31/2019 5:54 PM, Carl Eugen Hoyos wrote:
> 2019-01-31 21:43 GMT+01:00, Carl Eugen Hoyos :
>> Hi!
>>
>> Attached patch persistently uses "const" for AVInputFormat pointer
>> after the next version bump.
> Now with an actually working version.
>
> Please comment, Carl Eugen
>
>
> 0001-lavf-Constify-AVInputFormat-pointer.patch
>
> From f383a7f914b2c7240378b404d529a7d73c68941b Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos
> Date: Thu, 31 Jan 2019 21:51:56 +0100
> Subject: [PATCH] lavf: Constify AVInputFormat pointer.
>
> ---
> libavformat/allformats.c |6 +-
> libavformat/avformat.h | 32 +++-
> libavformat/dashdec.c|3 +++
> libavformat/format.c | 32 ++--
> libavformat/hls.c|3 +++
> libavformat/img2dec.c|2 +-
> libavformat/mpeg.c |3 +++
> libavformat/rtpdec_asf.c |3 +++
> libavformat/sapdec.c |3 +++
> libavformat/utils.c | 11 ---
> libavformat/version.h|3 +++
> 11 files changed, 93 insertions(+), 8 deletions(-)
>
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 0684498..01c4c14 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -583,7 +583,11 @@ AVInputFormat *av_iformat_next(const AVInputFormat *f)
> ff_thread_once(&av_format_next_init, av_format_init_next);
>
> if (f)
> -return f->next;
> +return
> +#if !FF_API_AVINPUTFORMAT
> + (AVInputFormat *)
> +#endif
> + f->next;
> else {
> void *opaque = NULL;
> return (AVInputFormat *)av_demuxer_iterate(&opaque);
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index fdaffa5..7c4ec8f 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -676,7 +676,10 @@ typedef struct AVInputFormat {
> * New public fields should be added right above.
> *
> */
> -struct AVInputFormat *next;
> +#if !FF_API_AVINPUTFORMAT
> +const
> +#endif
> +struct AVInputFormat *next;
>
> /**
> * Raw demuxers store their codec ID here.
> @@ -1346,6 +1349,9 @@ typedef struct AVFormatContext {
> *
> * Demuxing only, set by avformat_open_input().
> */
> +#if !FF_API_AVINPUTFORMAT
> +const
> +#endif
> struct AVInputFormat *iformat;
>
> /**
> @@ -,6 +2228,9 @@ int avformat_alloc_output_context2(AVFormatContext
> **ctx, AVOutputFormat *oforma
> /**
> * Find AVInputFormat based on the short name of the input format.
> */
> +#if !FF_API_AVINPUTFORMAT
> +const
> +#endif
> AVInputFormat *av_find_input_format(const char *short_name);
I'd prefer if you instead do like with av_probe_input_buffer() so we can
simply remove the dead code after a major bump and end up with a single
line prototype without extra line changes.
>
> /**
> @@ -2231,6 +2240,9 @@ AVInputFormat *av_find_input_format(const char
> *short_name);
> * @param is_opened Whether the file is already opened; determines whether
> * demuxers with or without AVFMT_NOFILE are probed.
> */
> +#if !FF_API_AVINPUTFORMAT
> +const
> +#endif
> AVInputFormat *av_probe_input_format(AVProbeData *pd, int is_opened);
>
> /**
> @@ -2245,6 +2257,9 @@ AVInputFormat *av_probe_input_format(AVProbeData *pd,
> int is_opened);
> * If the score is <= AVPROBE_SCORE_MAX / 4 it is
> recommended
> * to retry with a larger probe buffer.
> */
> +#if !FF_API_AVINPUTFORMAT
> +const
> +#endif
> AVInputFormat *av_probe_input_format2(AVProbeData *pd, int is_opened, int
> *score_max);
>
> /**
> @@ -2254,6 +2269,9 @@ AVInputFormat *av_probe_input_format2(AVProbeData *pd,
> int is_opened, int *score
> * demuxers with or without AVFMT_NOFILE are probed.
> * @param score_ret The score of the best detection.
> */
> +#if !FF_API_AVINPUTFORMAT
> +const
> +#endif
> AVInputFormat *av_probe_input_format3(AVProbeData *pd, int is_opened, int
> *score_ret);
>
> /**
> @@ -2272,14 +2290,22 @@ AVInputFormat *av_probe_input_format3(AVProbeData
> *pd, int is_opened, int *score
> * the maximal score is AVPROBE_SCORE_MAX
> * AVERROR code otherwise
> */
> +#if FF_API_AVINPUTFORMAT
> int av_probe_input_buffer2(AVIOContext *pb, AVInputFormat **fmt,
> +#else
> +int av_probe_input_buffer2(AVIOContext *pb, const AVInputFormat **fmt,
> +#endif
> const char *url, void *logctx,
> unsigned int offset, unsigned int max_probe_size);
>
> /**
> * Like av_probe_input_buffer2() but returns 0 on success
> */
> +#if FF_API_AVINPUTFORMAT
> int av_probe_input_buffer(AVIOContext *pb, AVInputFormat **fmt,
> +#else
> +int av_probe_input_buffer(AVIOContext *pb, const AVInputFormat **fmt,
> +#endif
>const char *url, void
Re: [FFmpeg-devel] [PATCH] avcodec/gsm_parser: return -1 on parse error
On Wed, Jan 30, 2019 at 5:43 PM James Almer wrote: > On 1/30/2019 10:20 PM, Chris Cunningham wrote: > >> > And this definitely means there's a bug elsewhere. This parser should > have not been used for codecs ids other than GSM and GSM_MS. That's > precisely what this assert() is making sure of. > > >>> > >>> I'll take a closer look at how this parser was selected. > >> > > > > Ok, here are full details of how this happens: > > > >1. AV_CODEC_ID_GSM_MS is assigned to on st->codecpar->codec_id > >in ogm_header() (oggparseogm.c:75) > >2. The (deprecated) st->codec->codec_id is not assigned at that time > and > >remains 0 (UNKNOWN) > >3. AV_CODEC_ID_GSM_MS from st->codecpar is passed to av_parser_init, > >selecting the gsm parser (in read_frame_internal()) > >4. The fuzzer next (only) packet has a size of 0, so the first call to > >parse_packet() (still in read_frame_internal()) does nothing > >5. After this call we assign several members of st->internal->avctx to > >st->codecpar. This leaves codecpar->codec_id = UNKNOWN. > Interestingly, we > >do not reset the st->parser at this point (maybe we should?) > > Where does this happen? A call to avcodec_parameters_from_context() > should also copy codec_id. > Ignore #5 here - I'm not seeing that today - was likely confused. > > >6. Next iteration of the read_frame_internal() loop we get EOF from > >ff_read_packet. This triggers the "flush the parsers" call to > >parse_packet() which finally reaches gsm_parse() to trigger the abort > >(avctx->codec_id is still 0). > > > > Questions (guessing at the fix): > > > >- At what point should st->codec->codec_id be synchronized with > >st->codecpar->codec_id? It never is in this test. > > In avformat_find_stream_info(), i think. In any case, st->codec should > have no effect on parsers. What is used in parse_packet() however is > st->internal->avctx, so that context is the one that evidently contains > codec_id == UNKNOWN when it should be in sync with codecpar. > We do call avformat_find_stream_info, and avcodec_parameters_from_context is called during that process. Everything seems OK when avformat_find_stream_info is done. The codecpar->codec_id is in sync with internal->avctx->codec_id for all streams. But then we start calling av_read_frame as part of normal demuxing. avcodec_parameters_from_context() does not appear to be called during this process. Eventually we get this stack: ogm_header ogg_packet ogg_read_packet ff_read_packet read_frame_internal av_read_frame Inside ogm_header, st->codecpar->codec_id is assigned AV_CODEC_ID_GSM_MS (previous value was codec NONE). But *st->internal->avctx->codec_id is never updated. It remains NONE for the rest of this test. * When this unwinds back to read_frame_internal, st->parser is assigned using this new codec (GSM_MS) st->parser = av_parser_init(st->codecpar->codec_id); Later on, still inside read_frame_internal's loop, we get EOF and call, parse_packet (/* flush the parsers */) parse_packet() calls av_parser_parse2(), passing st->internal->avctx (codec_id still NONE, while codecpar still says GSM_MS). This ultimately gets passed to gsm_parse, which triggers the assert0. The underlined bit above seems like the root cause. Where should we be updating st->internal->avctx->codec_id? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] doc: fix various typos
Found with the help of codespell-1.14.0.
Signed-off-by: Moritz Barsnick
---
doc/bitstream_filters.texi | 2 +-
doc/codecs.texi| 2 +-
doc/filters.texi | 24
doc/formats.texi | 2 +-
doc/general.texi | 8
doc/muxers.texi| 2 +-
6 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index b779265f58..076b910e40 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -561,7 +561,7 @@ P3 D65
@end table
@item transfer_characteristics
-Set the color transfert.
+Set the color transfer.
Available values are:
@table @samp
diff --git a/doc/codecs.texi b/doc/codecs.texi
index 02d5a1b222..c1c6996dee 100644
--- a/doc/codecs.texi
+++ b/doc/codecs.texi
@@ -1230,7 +1230,7 @@ instead of alpha. Default is 0.
@item dump_separator @var{string} (@emph{input})
Separator used to separate the fields printed on the command line about the
Stream parameters.
-For example to separate the fields with newlines and indention:
+For example to separate the fields with newlines and indentation:
@example
ffprobe -dump_separator "
" -i ~/videos/matrixbench_mpeg2.mpg
diff --git a/doc/filters.texi b/doc/filters.texi
index fc98323af0..60d9bbd047 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -606,7 +606,7 @@ The lower value, the more samples will be detected as
impulsive noise.
Set burst fusion, in percentage of window size. Allowed range is @code{0} to
@code{10}. Default value is @code{2}.
If any two samples deteced as noise are spaced less than this value then any
-sample inbetween those two samples will be also detected as noise.
+sample between those two samples will be also detected as noise.
@item m
Set overlap method.
@@ -1220,7 +1220,7 @@ Set max allowed Impulse Response filter duration in
seconds. Default is 30 secon
Allowed range is 0.1 to 60 seconds.
@item response
-Show IR frequency reponse, magnitude(magenta) and phase(green) and group
delay(yellow) in additional video stream.
+Show IR frequency response, magnitude(magenta) and phase(green) and group
delay(yellow) in additional video stream.
By default it is disabled.
@item channel
@@ -1382,7 +1382,7 @@ Z-plane zeros/poles, polar degrees
@item r
Set kind of processing.
-Can be @code{d} - direct or @code{s} - serial cascading. Defauls is @code{s}.
+Can be @code{d} - direct or @code{s} - serial cascading. Default is @code{s}.
@item e
Set filtering precision.
@@ -1399,7 +1399,7 @@ single-precision floating-point
@end table
@item response
-Show IR frequency reponse, magnitude and phase in additional video stream.
+Show IR frequency response, magnitude and phase in additional video stream.
By default it is disabled.
@item channel
@@ -1425,7 +1425,7 @@ used for all remaining channels.
@itemize
@item
-Apply 2 pole elliptic notch at arround 5000Hz for 48000 Hz sample rate:
+Apply 2 pole elliptic notch at around 5000Hz for 48000 Hz sample rate:
@example
aiir=k=1:z=7.957584807809675810E-1 -2.575128568908332300 3.674839853930788710
-2.57512875289799137 7.957586296317130880E-1:p=1 -2.86950072432325953
3.63022088054647218 -2.28075678147272232 6.361362326477423500E-1:f=tf:r=d
@end example
@@ -5647,7 +5647,7 @@ For example radius of 3 will instruct filter to calculate
average of 7 frames.
Set factor to amplify difference. Default is 2. Allowed range is from 0 to
65535.
@item threshold
-Set threshold for difference amplification. Any differrence greater or equal to
+Set threshold for difference amplification. Any difference greater or equal to
this value will not alter source pixel. Default is 10.
Allowed range is from 0 to 65535.
@@ -6032,7 +6032,7 @@ The filter accepts the following options.
@item sigma
Set denoising strength. Default value is 1.
Allowed range is from 0 to 999.9.
-The denoising algorith is very sensitive to sigma, so adjust it
+The denoising algorithm is very sensitive to sigma, so adjust it
according to the source.
@item block
@@ -10264,7 +10264,7 @@ The filter accepts the following options:
Set horizontal sigma, standard deviation of Gaussian blur. Default is
@code{0.5}.
@item steps
-Set number of steps for Gaussian approximation. Defauls is @code{1}.
+Set number of steps for Gaussian approximation. Default is @code{1}.
@item planes
Set which planes to filter. By default all planes are filtered.
@@ -15335,7 +15335,7 @@ Keep the same color primaries property (default).
@end table
@item color_trc
-Set the color transfert.
+Set the color transfer.
Available values are:
@table @samp
@@ -19135,7 +19135,7 @@ the cpu version tonemap currently. A setting of 0.0
disables this option.
@item threshold
The tonemapping algorithm parameters is fine-tuned per each scene. And a
threshold
-is used to detect whether the scene has changed or not. If the distance beween
+is used to dete
Re: [FFmpeg-devel] [PATCH] doc: fix various typos
On Thu, Jan 31, 2019, at 2:23 PM, Moritz Barsnick wrote: > Found with the help of codespell-1.14.0. > > Signed-off-by: Moritz Barsnick > --- > doc/bitstream_filters.texi | 2 +- > doc/codecs.texi| 2 +- > doc/filters.texi | 24 > doc/formats.texi | 2 +- > doc/general.texi | 8 > doc/muxers.texi| 2 +- > 6 files changed, 20 insertions(+), 20 deletions(-) LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf:Constify AVInputFormat pointer
On Thu, Jan 31, 2019 at 09:54:14PM +0100, Carl Eugen Hoyos wrote:
> 2019-01-31 21:43 GMT+01:00, Carl Eugen Hoyos :
> > Hi!
> >
> > Attached patch persistently uses "const" for AVInputFormat pointer
> > after the next version bump.
>
> Now with an actually working version.
>
> Please comment, Carl Eugen
> allformats.c |6 +-
> avformat.h | 32 +++-
> dashdec.c|3 +++
> format.c | 32 ++--
> hls.c|3 +++
> img2dec.c|2 +-
> mpeg.c |3 +++
> rtpdec_asf.c |3 +++
> sapdec.c |3 +++
> utils.c | 11 ---
> version.h|3 +++
> 11 files changed, 93 insertions(+), 8 deletions(-)
> d3aece2f0b9a9c3ff8b2a187ceccdc744ea40de2
> 0001-lavf-Constify-AVInputFormat-pointer.patch
> From f383a7f914b2c7240378b404d529a7d73c68941b Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos
> Date: Thu, 31 Jan 2019 21:51:56 +0100
> Subject: [PATCH] lavf: Constify AVInputFormat pointer.
>
> ---
> libavformat/allformats.c |6 +-
> libavformat/avformat.h | 32 +++-
> libavformat/dashdec.c|3 +++
> libavformat/format.c | 32 ++--
> libavformat/hls.c|3 +++
> libavformat/img2dec.c|2 +-
> libavformat/mpeg.c |3 +++
> libavformat/rtpdec_asf.c |3 +++
> libavformat/sapdec.c |3 +++
> libavformat/utils.c | 11 ---
> libavformat/version.h|3 +++
> 11 files changed, 93 insertions(+), 8 deletions(-)
>
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 0684498..01c4c14 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -583,7 +583,11 @@ AVInputFormat *av_iformat_next(const AVInputFormat *f)
> ff_thread_once(&av_format_next_init, av_format_init_next);
>
> if (f)
> -return f->next;
> +return
> +#if !FF_API_AVINPUTFORMAT
> + (AVInputFormat *)
> +#endif
> + f->next;
> else {
> void *opaque = NULL;
> return (AVInputFormat *)av_demuxer_iterate(&opaque);
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index fdaffa5..7c4ec8f 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -676,7 +676,10 @@ typedef struct AVInputFormat {
> * New public fields should be added right above.
> *
> */
> -struct AVInputFormat *next;
> +#if !FF_API_AVINPUTFORMAT
> +const
> +#endif
> +struct AVInputFormat *next;
some av_const59 which is defined to nothing until version 59
should avoid the repeated #if/endif
it would require an eventual update to change it to const at some
point but it would avoid most preprocessor comands
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] movenc: Fix VPCC bitdepth for hardware pixel formats
If a hardware encoder is used, the pixel format may be a hardware pixel format.
This leads to invalid VPCC atom being written, due to depth of hardware pixel
formats being 0.
To work around this, fallback on bits_per_raw_sample.
Signed-off-by: Nikolas Bowe
---
libavcodec/vaapi_encode.c | 2 +-
libavformat/vpcc.c| 13 +
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index b4e9fadaee..cfd9413f0f 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1116,7 +1116,7 @@ static av_cold int
vaapi_encode_profile_entrypoint(AVCodecContext *avctx)
ctx->input_frames->sw_format);
return AVERROR(EINVAL);
}
-depth = desc->comp[0].depth;
+avctx->bits_per_raw_sample = depth = desc->comp[0].depth;
for (i = 1; i < desc->nb_components; i++) {
if (desc->comp[i].depth != depth) {
av_log(avctx, AV_LOG_ERROR, "Invalid input pixfmt (%s).\n",
diff --git a/libavformat/vpcc.c b/libavformat/vpcc.c
index e0b7f288a6..f667ca9c00 100644
--- a/libavformat/vpcc.c
+++ b/libavformat/vpcc.c
@@ -51,15 +51,20 @@ static int get_vpx_chroma_subsampling(AVFormatContext *s,
return -1;
}
-static int get_bit_depth(AVFormatContext *s, enum AVPixelFormat pixel_format)
+static int get_bit_depth(AVFormatContext *s, AVCodecParameters *par)
{
+enum AVPixelFormat pixel_format = par->format;
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pixel_format);
if (desc == NULL) {
av_log(s, AV_LOG_ERROR, "Unsupported pixel format (%d)\n",
pixel_format);
return -1;
}
-return desc->comp[0].depth;
+if (desc->comp[0].depth) {
+return desc->comp[0].depth;
+}
+// Fallback on bits_per_raw_sample if pix_fmt is a hw format.
+return par->bits_per_raw_sample;
}
static int get_vpx_video_full_range_flag(enum AVColorRange color_range)
@@ -119,13 +124,13 @@ int ff_isom_get_vpcc_features(AVFormatContext *s,
AVCodecParameters *par,
int profile = par->profile;
int level = par->level == FF_LEVEL_UNKNOWN ?
get_vp9_level(par, frame_rate) : par->level;
-int bit_depth = get_bit_depth(s, par->format);
+int bit_depth = get_bit_depth(s, par);
int vpx_chroma_subsampling =
get_vpx_chroma_subsampling(s, par->format, par->chroma_location);
int vpx_video_full_range_flag =
get_vpx_video_full_range_flag(par->color_range);
-if (bit_depth < 0 || vpx_chroma_subsampling < 0)
+if (bit_depth <= 0 || vpx_chroma_subsampling < 0)
return AVERROR_INVALIDDATA;
if (profile == FF_PROFILE_UNKNOWN) {
--
2.20.1.611.gfbb209baf1-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/mov: validate chunk_count vs stsc_data
Bad content may contain stsc boxes with a first_chunk index that
exceeds stco.entries (chunk_count).
mov_get_stsc_samples now checks for this and returns 0 when
values are invalid.
Also updates MOVStsc to use unsigned ints, per spec.
---
libavformat/isom.h | 6 +++---
libavformat/mov.c | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index e629663949..8e0d8355b3 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -59,9 +59,9 @@ typedef struct MOVStts {
} MOVStts;
typedef struct MOVStsc {
-int first;
-int count;
-int id;
+unsigned int first;
+unsigned int count;
+unsigned int id;
} MOVStsc;
typedef struct MOVElst {
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9b9739f788..dcf4ee8dc1 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2690,11 +2690,11 @@ static inline int mov_stsc_index_valid(unsigned int
index, unsigned int count)
/* Compute the samples value for the stsc entry at the given index. */
static inline int64_t mov_get_stsc_samples(MOVStreamContext *sc, unsigned int
index)
{
-int chunk_count;
+unsigned int chunk_count = 0;
if (mov_stsc_index_valid(index, sc->stsc_count))
chunk_count = sc->stsc_data[index + 1].first -
sc->stsc_data[index].first;
-else
+else if (sc->chunk_count >= sc->stsc_data[index].first)
chunk_count = sc->chunk_count - (sc->stsc_data[index].first - 1);
return sc->stsc_data[index].count * (int64_t)chunk_count;
--
2.20.1.611.gfbb209baf1-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: validate chunk_count vs stsc_data
Some extra context: this remedies some bad math that otherwise triggers an
abort near the bottom of mov_seek_stream().
My first thought on seeing this was we should probably be
returning AVERROR_INVALIDDATA somewhere. The stsc and stco boxes aren't
agreeing (stco says no chunks, stsc.first points to chunk 135). stsc and
stco aren't gauranteed to come in a particular order, but we could try to
validate that they agree whenever both arrive. One challenge is
that mov_read_stco is already pretty relaxed about setting sc->chunk_count
(it sets to some lower number if we hit EOF during parsing).
Feedback welcome.
On Thu, Jan 31, 2019 at 5:26 PM chcunningham
wrote:
> Bad content may contain stsc boxes with a first_chunk index that
> exceeds stco.entries (chunk_count).
>
> mov_get_stsc_samples now checks for this and returns 0 when
> values are invalid.
>
> Also updates MOVStsc to use unsigned ints, per spec.
> ---
> libavformat/isom.h | 6 +++---
> libavformat/mov.c | 4 ++--
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/isom.h b/libavformat/isom.h
> index e629663949..8e0d8355b3 100644
> --- a/libavformat/isom.h
> +++ b/libavformat/isom.h
> @@ -59,9 +59,9 @@ typedef struct MOVStts {
> } MOVStts;
>
> typedef struct MOVStsc {
> -int first;
> -int count;
> -int id;
> +unsigned int first;
> +unsigned int count;
> +unsigned int id;
> } MOVStsc;
>
> typedef struct MOVElst {
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 9b9739f788..dcf4ee8dc1 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -2690,11 +2690,11 @@ static inline int mov_stsc_index_valid(unsigned
> int index, unsigned int count)
> /* Compute the samples value for the stsc entry at the given index. */
> static inline int64_t mov_get_stsc_samples(MOVStreamContext *sc, unsigned
> int index)
> {
> -int chunk_count;
> +unsigned int chunk_count = 0;
>
> if (mov_stsc_index_valid(index, sc->stsc_count))
> chunk_count = sc->stsc_data[index + 1].first -
> sc->stsc_data[index].first;
> -else
> +else if (sc->chunk_count >= sc->stsc_data[index].first)
> chunk_count = sc->chunk_count - (sc->stsc_data[index].first - 1);
>
> return sc->stsc_data[index].count * (int64_t)chunk_count;
> --
> 2.20.1.611.gfbb209baf1-goog
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi/vf_nlmeans: Improve the performance for nlmeans
On Fri, Feb 1, 2019 at 3:57 AM Carl Eugen Hoyos wrote: > > 2019-01-31 14:55 GMT+01:00, Jun Zhao : > > Remove the pdiff_lut_scale in nlmeans, when search the weight_luttable > > in nlmeans_slices(), the old way need to the float-point arithmetic > > using pdiff_lut_scale. This change will avoid using pdiff_lut_scale > > in the weight_lut table search, it's will improve the performance about > > 12%. (1080P size picture). > > Please mention the change in heap memory requirement with numbers. > Remove "old way need to the float-point arithmetic" because new way > also needs (some) floating-point arithmetic. > Feel free not to mention pdiff_lut_scale in the commit message. > Will update the commit message again, Tks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH V2] lavfi/vf_nlmeans: Improve the performance for nlmeans
Remove the pdiff_lut_scale in nlmeans and increase weight_lut table size
from 2^9 to 80, this change will avoid using pdiff_lut_scale in
nlmeans_slice() for weight_lut table search, it's will improve the
performance about 12%. (in 1080P size picture case).
Use the profiling command like:
perf stat -a -d -r 5 ./ffmpeg -i input -an -vf nlmeans=s=30 -vframes 10 \
-f null /dev/null
without this change:
when s=1.0(default value) 63s
s=30.0 72s
after this change:
s=1.0(default value) 56s
s=30.0 63s
Reviewed-by: Carl Eugen Hoyos
Signed-off-by: Jun Zhao
---
libavfilter/vf_nlmeans.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/libavfilter/vf_nlmeans.c b/libavfilter/vf_nlmeans.c
index 82e779c..72eb819 100644
--- a/libavfilter/vf_nlmeans.c
+++ b/libavfilter/vf_nlmeans.c
@@ -43,8 +43,7 @@ struct weighted_avg {
float sum;
};
-#define WEIGHT_LUT_NBITS 9
-#define WEIGHT_LUT_SIZE (1< 300 * 300 * log(255)
typedef struct NLMeansContext {
const AVClass *class;
@@ -63,7 +62,6 @@ typedef struct NLMeansContext {
struct weighted_avg *wa;// weighted average of every
pixel
ptrdiff_t wa_linesize; // linesize for wa in struct
size unit
float weight_lut[WEIGHT_LUT_SIZE]; // lookup table mapping
(scaled) patch differences to their associated weights
-float pdiff_lut_scale; // scale factor for patch
differences before looking into the LUT
uint32_t max_meaningful_diff; // maximum difference
considered (if the patch difference is too high we ignore the pixel)
NLMeansDSPContext dsp;
} NLMeansContext;
@@ -401,8 +399,7 @@ static int nlmeans_slice(AVFilterContext *ctx, void *arg,
int jobnr, int nb_jobs
const uint32_t patch_diff_sq = e - d - b + a;
if (patch_diff_sq < s->max_meaningful_diff) {
-const unsigned weight_lut_idx = patch_diff_sq *
s->pdiff_lut_scale;
-const float weight = s->weight_lut[weight_lut_idx]; //
exp(-patch_diff_sq * s->pdiff_scale)
+const float weight = s->weight_lut[patch_diff_sq]; //
exp(-patch_diff_sq * s->pdiff_scale)
wa[x].total_weight += weight;
wa[x].sum += weight * src[x];
}
@@ -527,10 +524,9 @@ static av_cold int init(AVFilterContext *ctx)
s->pdiff_scale = 1. / (h * h);
s->max_meaningful_diff = -log(1/255.) / s->pdiff_scale;
-s->pdiff_lut_scale = 1./s->max_meaningful_diff * WEIGHT_LUT_SIZE;
-av_assert0((s->max_meaningful_diff - 1) * s->pdiff_lut_scale <
FF_ARRAY_ELEMS(s->weight_lut));
+av_assert0((s->max_meaningful_diff - 1) < FF_ARRAY_ELEMS(s->weight_lut));
for (i = 0; i < WEIGHT_LUT_SIZE; i++)
-s->weight_lut[i] = exp(-i / s->pdiff_lut_scale * s->pdiff_scale);
+s->weight_lut[i] = exp(-i * s->pdiff_scale);
CHECK_ODD_FIELD(research_size, "Luma research window");
CHECK_ODD_FIELD(patch_size, "Luma patch");
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_parse: no need check ref list1 for P slices.
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > Michael Niedermayer > Sent: 2019年2月1日 1:12 > To: FFmpeg development discussions and patches > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/h264_parse: no need check ref > list1 for P slices. > > On Thu, Jan 31, 2019 at 03:36:56PM +0800, Decai Lin wrote: > > This is robust for some corner case there is incorrect list1 count in > > pps header, but it's a P slice and can be decoded well. > > please provide a sample h264 video that needs this > Attached the test clip for this patch. Thanks IP_with invalid_reflist1_cnt.264 Description: IP_with invalid_reflist1_cnt.264 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] avcodec/mips: [loongson] optimize put_hevc_qpel_bi_h_8 with mmi.
Optimize put_hevc_qpel_bi_h_8 with mmi in the case width=4/8/12/16/24/32/48/64.
This optimization improved HEVC decoding performance 2.1%(2.34x to 2.39x,
tested on loongson 3A3000).
---
libavcodec/mips/hevcdsp_init_mips.c | 9 +++
libavcodec/mips/hevcdsp_mips.h | 9 +++
libavcodec/mips/hevcdsp_mmi.c | 132
3 files changed, 150 insertions(+)
diff --git a/libavcodec/mips/hevcdsp_init_mips.c
b/libavcodec/mips/hevcdsp_init_mips.c
index bf7d823..6c0533c 100644
--- a/libavcodec/mips/hevcdsp_init_mips.c
+++ b/libavcodec/mips/hevcdsp_init_mips.c
@@ -34,6 +34,15 @@ static av_cold void hevc_dsp_init_mmi(HEVCDSPContext *c,
c->put_hevc_qpel[8][1][1] = ff_hevc_put_hevc_qpel_hv48_8_mmi;
c->put_hevc_qpel[9][1][1] = ff_hevc_put_hevc_qpel_hv64_8_mmi;
+c->put_hevc_qpel_bi[1][0][1] = ff_hevc_put_hevc_qpel_bi_h4_8_mmi;
+c->put_hevc_qpel_bi[3][0][1] = ff_hevc_put_hevc_qpel_bi_h8_8_mmi;
+c->put_hevc_qpel_bi[4][0][1] = ff_hevc_put_hevc_qpel_bi_h12_8_mmi;
+c->put_hevc_qpel_bi[5][0][1] = ff_hevc_put_hevc_qpel_bi_h16_8_mmi;
+c->put_hevc_qpel_bi[6][0][1] = ff_hevc_put_hevc_qpel_bi_h24_8_mmi;
+c->put_hevc_qpel_bi[7][0][1] = ff_hevc_put_hevc_qpel_bi_h32_8_mmi;
+c->put_hevc_qpel_bi[8][0][1] = ff_hevc_put_hevc_qpel_bi_h48_8_mmi;
+c->put_hevc_qpel_bi[9][0][1] = ff_hevc_put_hevc_qpel_bi_h64_8_mmi;
+
c->put_hevc_qpel_bi[1][1][1] = ff_hevc_put_hevc_qpel_bi_hv4_8_mmi;
c->put_hevc_qpel_bi[3][1][1] = ff_hevc_put_hevc_qpel_bi_hv8_8_mmi;
c->put_hevc_qpel_bi[4][1][1] = ff_hevc_put_hevc_qpel_bi_hv12_8_mmi;
diff --git a/libavcodec/mips/hevcdsp_mips.h b/libavcodec/mips/hevcdsp_mips.h
index fe4faae..41f56c8 100644
--- a/libavcodec/mips/hevcdsp_mips.h
+++ b/libavcodec/mips/hevcdsp_mips.h
@@ -524,6 +524,15 @@ L_BI_MC(qpel, hv, 32, mmi);
L_BI_MC(qpel, hv, 48, mmi);
L_BI_MC(qpel, hv, 64, mmi);
+L_BI_MC(qpel, h, 4, mmi);
+L_BI_MC(qpel, h, 8, mmi);
+L_BI_MC(qpel, h, 12, mmi);
+L_BI_MC(qpel, h, 16, mmi);
+L_BI_MC(qpel, h, 24, mmi);
+L_BI_MC(qpel, h, 32, mmi);
+L_BI_MC(qpel, h, 48, mmi);
+L_BI_MC(qpel, h, 64, mmi);
+
L_BI_MC(epel, hv, 4, mmi);
L_BI_MC(epel, hv, 8, mmi);
L_BI_MC(epel, hv, 12, mmi);
diff --git a/libavcodec/mips/hevcdsp_mmi.c b/libavcodec/mips/hevcdsp_mmi.c
index f0e4aa9..97d0ff7 100644
--- a/libavcodec/mips/hevcdsp_mmi.c
+++ b/libavcodec/mips/hevcdsp_mmi.c
@@ -217,6 +217,138 @@ PUT_HEVC_QPEL_HV(32, 8, -32, -64);
PUT_HEVC_QPEL_HV(48, 12, -48, -96);
PUT_HEVC_QPEL_HV(64, 16, -64, -128);
+#define PUT_HEVC_QPEL_BI_H(w, x_step, src_step, src2_step, dst_step)\
+void ff_hevc_put_hevc_qpel_bi_h##w##_8_mmi(uint8_t *_dst, \
+ ptrdiff_t _dststride,\
+ uint8_t *_src, \
+ ptrdiff_t _srcstride,\
+ int16_t *src2, int height, \
+ intptr_t mx, intptr_t my,\
+ int width) \
+{ \
+int x, y; \
+pixel*src = (pixel*)_src - 3; \
+ptrdiff_t srcstride = _srcstride / sizeof(pixel); \
+pixel *dst = (pixel *)_dst;\
+ptrdiff_t dststride = _dststride / sizeof(pixel); \
+const int8_t *filter= ff_hevc_qpel_filters[mx - 1]; \
+uint64_t ftmp[20]; \
+uint64_t rtmp[1]; \
+int shift = 7; \
+int offset = 64;\
+\
+x = width >> 2; \
+y = height; \
+__asm__ volatile( \
+MMI_LDC1(%[ftmp1], %[filter], 0x00) \
+"li %[rtmp0], 0x08 \n\t" \
+"dmtc1%[rtmp0], %[ftmp0] \n\t" \
+"punpckhbh%[ftmp2], %[ftmp0], %[ftmp1]\n\t" \
+"punpcklbh%[ftmp1], %[ftmp0], %[ftmp1]\n\t" \
+"psrah%[ftmp1], %[ftmp1], %[ftmp0]\n\t" \
+"psrah%[ftmp2], %[ftmp2], %[ftmp0]\n\t" \
+"xor %[ftmp0], %[ftmp0], %[ftmp0]\n\t" \
+"punpcklhw%[offset], %[offset], %[offset] \n\t" \
+"punpcklwd%[offset]
[FFmpeg-devel] [PATCH 1/4] avcodec/mips: [loongson] optimize put_hevc_qpel_uni_hv_8 with mmi.
Optimize put_hevc_qpel_uni_hv_8 with mmi in the case
width=4/8/12/16/24/32/48/64.
This optimization improved HEVC decoding performance 2.7%(2.24x to 2.30x,
tested on loongson 3A3000).
---
libavcodec/mips/hevcdsp_init_mips.c | 9 ++
libavcodec/mips/hevcdsp_mips.h | 21
libavcodec/mips/hevcdsp_mmi.c | 211
3 files changed, 241 insertions(+)
diff --git a/libavcodec/mips/hevcdsp_init_mips.c
b/libavcodec/mips/hevcdsp_init_mips.c
index 18d97d9..9e08c0e 100644
--- a/libavcodec/mips/hevcdsp_init_mips.c
+++ b/libavcodec/mips/hevcdsp_init_mips.c
@@ -54,6 +54,15 @@ static av_cold void hevc_dsp_init_mmi(HEVCDSPContext *c,
c->put_hevc_epel_bi[5][0][0] = ff_hevc_put_hevc_pel_bi_pixels16_8_mmi;
c->put_hevc_epel_bi[6][0][0] = ff_hevc_put_hevc_pel_bi_pixels24_8_mmi;
c->put_hevc_epel_bi[7][0][0] = ff_hevc_put_hevc_pel_bi_pixels32_8_mmi;
+
+c->put_hevc_qpel_uni[1][1][1] = ff_hevc_put_hevc_qpel_uni_hv4_8_mmi;
+c->put_hevc_qpel_uni[3][1][1] = ff_hevc_put_hevc_qpel_uni_hv8_8_mmi;
+c->put_hevc_qpel_uni[4][1][1] = ff_hevc_put_hevc_qpel_uni_hv12_8_mmi;
+c->put_hevc_qpel_uni[5][1][1] = ff_hevc_put_hevc_qpel_uni_hv16_8_mmi;
+c->put_hevc_qpel_uni[6][1][1] = ff_hevc_put_hevc_qpel_uni_hv24_8_mmi;
+c->put_hevc_qpel_uni[7][1][1] = ff_hevc_put_hevc_qpel_uni_hv32_8_mmi;
+c->put_hevc_qpel_uni[8][1][1] = ff_hevc_put_hevc_qpel_uni_hv48_8_mmi;
+c->put_hevc_qpel_uni[9][1][1] = ff_hevc_put_hevc_qpel_uni_hv64_8_mmi;
}
}
#endif // #if HAVE_MMI
diff --git a/libavcodec/mips/hevcdsp_mips.h b/libavcodec/mips/hevcdsp_mips.h
index 9f1e447..ebd5f32 100644
--- a/libavcodec/mips/hevcdsp_mips.h
+++ b/libavcodec/mips/hevcdsp_mips.h
@@ -525,4 +525,25 @@ L_BI_MC(qpel, hv, 48, mmi);
L_BI_MC(qpel, hv, 64, mmi);
#undef L_BI_MC
+
+#define L_UNI_MC(PEL, DIR, WIDTH, TYPE)
\
+void ff_hevc_put_hevc_##PEL##_uni_##DIR##WIDTH##_8_##TYPE(uint8_t *dst,
\
+ ptrdiff_t
dst_stride, \
+ uint8_t *src,
\
+ ptrdiff_t
src_stride, \
+ int height,
\
+ intptr_t mx,
\
+ intptr_t my,
\
+ int width)
+
+L_UNI_MC(qpel, hv, 4, mmi);
+L_UNI_MC(qpel, hv, 8, mmi);
+L_UNI_MC(qpel, hv, 12, mmi);
+L_UNI_MC(qpel, hv, 16, mmi);
+L_UNI_MC(qpel, hv, 24, mmi);
+L_UNI_MC(qpel, hv, 32, mmi);
+L_UNI_MC(qpel, hv, 48, mmi);
+L_UNI_MC(qpel, hv, 64, mmi);
+#undef L_UNI_MC
+
#endif // #ifndef AVCODEC_MIPS_HEVCDSP_MIPS_H
diff --git a/libavcodec/mips/hevcdsp_mmi.c b/libavcodec/mips/hevcdsp_mmi.c
index 727a718..aced846 100644
--- a/libavcodec/mips/hevcdsp_mmi.c
+++ b/libavcodec/mips/hevcdsp_mmi.c
@@ -556,3 +556,214 @@ PUT_HEVC_PEL_BI_PIXELS(24, 3, -24, -24, -48);
PUT_HEVC_PEL_BI_PIXELS(32, 4, -32, -32, -64);
PUT_HEVC_PEL_BI_PIXELS(48, 6, -48, -48, -96);
PUT_HEVC_PEL_BI_PIXELS(64, 8, -64, -64, -128);
+
+#define PUT_HEVC_QPEL_UNI_HV(w, x_step, src_step, dst_step, tmp_step) \
+void ff_hevc_put_hevc_qpel_uni_hv##w##_8_mmi(uint8_t *_dst, \
+ ptrdiff_t _dststride, \
+ uint8_t *_src, \
+ ptrdiff_t _srcstride, \
+ int height,\
+ intptr_t mx, intptr_t my, \
+ int width) \
+{ \
+int x, y; \
+const int8_t *filter; \
+pixel *src = (pixel*)_src; \
+ptrdiff_t srcstride = _srcstride / sizeof(pixel); \
+pixel *dst = (pixel *)_dst;\
+ptrdiff_t dststride = _dststride / sizeof(pixel); \
+int16_t tmp_array[(MAX_PB_SIZE + QPEL_EXTRA) * MAX_PB_SIZE];\
+int16_t *tmp = tmp_array; \
+uint64_t ftmp[20]; \
+uint64_t rtmp[1]; \
+int shift = 6; \
+int offset = 32;\
+\
+src -= (QPEL_EXTRA_BEFORE * srcstride +
[FFmpeg-devel] [PATCH 2/4] avcodec/mips: [loongson] optimize put_hevc_epel_bi_hv_8 with mmi.
Optimize put_hevc_epel_bi_hv_8 with mmi in the case width=4/8/12/16/24/32.
This optimization improved HEVC decoding performance 1.7%(2.30x to 2.34x,
tested on loongson 3A3000).
---
libavcodec/mips/hevcdsp_init_mips.c | 7 ++
libavcodec/mips/hevcdsp_mips.h | 6 ++
libavcodec/mips/hevcdsp_mmi.c | 186
3 files changed, 199 insertions(+)
diff --git a/libavcodec/mips/hevcdsp_init_mips.c
b/libavcodec/mips/hevcdsp_init_mips.c
index 9e08c0e..bf7d823 100644
--- a/libavcodec/mips/hevcdsp_init_mips.c
+++ b/libavcodec/mips/hevcdsp_init_mips.c
@@ -55,6 +55,13 @@ static av_cold void hevc_dsp_init_mmi(HEVCDSPContext *c,
c->put_hevc_epel_bi[6][0][0] = ff_hevc_put_hevc_pel_bi_pixels24_8_mmi;
c->put_hevc_epel_bi[7][0][0] = ff_hevc_put_hevc_pel_bi_pixels32_8_mmi;
+c->put_hevc_epel_bi[1][1][1] = ff_hevc_put_hevc_epel_bi_hv4_8_mmi;
+c->put_hevc_epel_bi[3][1][1] = ff_hevc_put_hevc_epel_bi_hv8_8_mmi;
+c->put_hevc_epel_bi[4][1][1] = ff_hevc_put_hevc_epel_bi_hv12_8_mmi;
+c->put_hevc_epel_bi[5][1][1] = ff_hevc_put_hevc_epel_bi_hv16_8_mmi;
+c->put_hevc_epel_bi[6][1][1] = ff_hevc_put_hevc_epel_bi_hv24_8_mmi;
+c->put_hevc_epel_bi[7][1][1] = ff_hevc_put_hevc_epel_bi_hv32_8_mmi;
+
c->put_hevc_qpel_uni[1][1][1] = ff_hevc_put_hevc_qpel_uni_hv4_8_mmi;
c->put_hevc_qpel_uni[3][1][1] = ff_hevc_put_hevc_qpel_uni_hv8_8_mmi;
c->put_hevc_qpel_uni[4][1][1] = ff_hevc_put_hevc_qpel_uni_hv12_8_mmi;
diff --git a/libavcodec/mips/hevcdsp_mips.h b/libavcodec/mips/hevcdsp_mips.h
index ebd5f32..fe4faae 100644
--- a/libavcodec/mips/hevcdsp_mips.h
+++ b/libavcodec/mips/hevcdsp_mips.h
@@ -524,6 +524,12 @@ L_BI_MC(qpel, hv, 32, mmi);
L_BI_MC(qpel, hv, 48, mmi);
L_BI_MC(qpel, hv, 64, mmi);
+L_BI_MC(epel, hv, 4, mmi);
+L_BI_MC(epel, hv, 8, mmi);
+L_BI_MC(epel, hv, 12, mmi);
+L_BI_MC(epel, hv, 16, mmi);
+L_BI_MC(epel, hv, 24, mmi);
+L_BI_MC(epel, hv, 32, mmi);
#undef L_BI_MC
#define L_UNI_MC(PEL, DIR, WIDTH, TYPE)
\
diff --git a/libavcodec/mips/hevcdsp_mmi.c b/libavcodec/mips/hevcdsp_mmi.c
index aced846..f0e4aa9 100644
--- a/libavcodec/mips/hevcdsp_mmi.c
+++ b/libavcodec/mips/hevcdsp_mmi.c
@@ -446,6 +446,192 @@ PUT_HEVC_QPEL_BI_HV(32, 8, -32, -64, -32);
PUT_HEVC_QPEL_BI_HV(48, 12, -48, -96, -48);
PUT_HEVC_QPEL_BI_HV(64, 16, -64, -128, -64);
+#define PUT_HEVC_EPEL_BI_HV(w, x_step, src_step, src2_step, dst_step) \
+void ff_hevc_put_hevc_epel_bi_hv##w##_8_mmi(uint8_t *_dst, \
+ptrdiff_t _dststride, \
+uint8_t *_src, \
+ptrdiff_t _srcstride, \
+int16_t *src2, int height, \
+intptr_t mx, intptr_t my, \
+int width) \
+{ \
+int x, y; \
+pixel *src = (pixel *)_src; \
+ptrdiff_t srcstride = _srcstride / sizeof(pixel); \
+pixel *dst = (pixel *)_dst;\
+ptrdiff_t dststride = _dststride / sizeof(pixel); \
+const int8_t *filter = ff_hevc_epel_filters[mx - 1];\
+int16_t tmp_array[(MAX_PB_SIZE + EPEL_EXTRA) * MAX_PB_SIZE];\
+int16_t *tmp = tmp_array; \
+uint64_t ftmp[12]; \
+uint64_t rtmp[1]; \
+int shift = 7; \
+int offset = 64;\
+\
+src -= (EPEL_EXTRA_BEFORE * srcstride + 1); \
+x = width >> 2; \
+y = height + EPEL_EXTRA;\
+__asm__ volatile( \
+MMI_LWC1(%[ftmp1], %[filter], 0x00) \
+"li %[rtmp0], 0x08 \n\t" \
+"dmtc1%[rtmp0], %[ftmp0] \n\t" \
+"punpcklbh%[ftmp1], %[ftmp0], %[ftmp1]\n\t" \
+"psrah%[ftmp1], %[ftmp1], %[ftmp0]\n\t" \
+"xor %[ftmp0], %[ftmp0], %[ftmp0]\n\t" \
+\
+"1: \n\t" \
+"2:
[FFmpeg-devel] [PATCH] doc/filters: document ranges and defaults for nlmeans options
document ranges and defaults for nlmeans options
Signed-off-by: Jun Zhao
---
doc/filters.texi |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index fc98323..d588315 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -12296,10 +12296,10 @@ The filter accepts the following options.
@table @option
@item s
-Set denoising strength.
+Set denoising strength. Default is 1.0. Must be in range [1.0, 30.0].
@item p
-Set patch size.
+Set patch size. Default is 7. Must be odd number in range [0, 99].
@item pc
Same as @option{p} but for chroma planes.
@@ -12307,7 +12307,7 @@ Same as @option{p} but for chroma planes.
The default value is @var{0} and means automatic.
@item r
-Set research size.
+Set research size. Default is 15. Must be odd number in range [0, 99].
@item rc
Same as @option{r} but for chroma planes.
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] avcodec/mips: [loongson] optimize put_hevc_qpel_h_8 with mmi.
Optimize put_hevc_qpel_h_8 with mmi in the case width=4/8/12/16/24/32/48/64.
This optimization improved HEVC decoding performance 2%(2.39x to 2.44x, tested
on loongson 3A3000).
---
libavcodec/mips/hevcdsp_init_mips.c | 9
libavcodec/mips/hevcdsp_mips.h | 9
libavcodec/mips/hevcdsp_mmi.c | 97 +
3 files changed, 115 insertions(+)
diff --git a/libavcodec/mips/hevcdsp_init_mips.c
b/libavcodec/mips/hevcdsp_init_mips.c
index 6c0533c..88337f4 100644
--- a/libavcodec/mips/hevcdsp_init_mips.c
+++ b/libavcodec/mips/hevcdsp_init_mips.c
@@ -25,6 +25,15 @@ static av_cold void hevc_dsp_init_mmi(HEVCDSPContext *c,
const int bit_depth)
{
if (8 == bit_depth) {
+c->put_hevc_qpel[1][0][1] = ff_hevc_put_hevc_qpel_h4_8_mmi;
+c->put_hevc_qpel[3][0][1] = ff_hevc_put_hevc_qpel_h8_8_mmi;
+c->put_hevc_qpel[4][0][1] = ff_hevc_put_hevc_qpel_h12_8_mmi;
+c->put_hevc_qpel[5][0][1] = ff_hevc_put_hevc_qpel_h16_8_mmi;
+c->put_hevc_qpel[6][0][1] = ff_hevc_put_hevc_qpel_h24_8_mmi;
+c->put_hevc_qpel[7][0][1] = ff_hevc_put_hevc_qpel_h32_8_mmi;
+c->put_hevc_qpel[8][0][1] = ff_hevc_put_hevc_qpel_h48_8_mmi;
+c->put_hevc_qpel[9][0][1] = ff_hevc_put_hevc_qpel_h64_8_mmi;
+
c->put_hevc_qpel[1][1][1] = ff_hevc_put_hevc_qpel_hv4_8_mmi;
c->put_hevc_qpel[3][1][1] = ff_hevc_put_hevc_qpel_hv8_8_mmi;
c->put_hevc_qpel[4][1][1] = ff_hevc_put_hevc_qpel_hv12_8_mmi;
diff --git a/libavcodec/mips/hevcdsp_mips.h b/libavcodec/mips/hevcdsp_mips.h
index 41f56c8..c84e08d 100644
--- a/libavcodec/mips/hevcdsp_mips.h
+++ b/libavcodec/mips/hevcdsp_mips.h
@@ -488,6 +488,15 @@ void
ff_hevc_put_hevc_##PEL##_##DIR##WIDTH##_8_##TYPE(int16_t *dst, \
intptr_t mx, \
intptr_t my, \
int width)
+L_MC(qpel, h, 4, mmi);
+L_MC(qpel, h, 8, mmi);
+L_MC(qpel, h, 12, mmi);
+L_MC(qpel, h, 16, mmi);
+L_MC(qpel, h, 24, mmi);
+L_MC(qpel, h, 32, mmi);
+L_MC(qpel, h, 48, mmi);
+L_MC(qpel, h, 64, mmi);
+
L_MC(qpel, hv, 4, mmi);
L_MC(qpel, hv, 8, mmi);
L_MC(qpel, hv, 12, mmi);
diff --git a/libavcodec/mips/hevcdsp_mmi.c b/libavcodec/mips/hevcdsp_mmi.c
index 97d0ff7..f7b3f2a 100644
--- a/libavcodec/mips/hevcdsp_mmi.c
+++ b/libavcodec/mips/hevcdsp_mmi.c
@@ -23,6 +23,103 @@
#include "libavcodec/mips/hevcdsp_mips.h"
#include "libavutil/mips/mmiutils.h"
+#define PUT_HEVC_QPEL_H(w, x_step, src_step, dst_step) \
+void ff_hevc_put_hevc_qpel_h##w##_8_mmi(int16_t *dst, uint8_t *_src, \
+ptrdiff_t _srcstride,\
+int height, intptr_t mx, \
+intptr_t my, int width) \
+{\
+int x, y;\
+pixel *src = (pixel*)_src - 3; \
+ptrdiff_t srcstride = _srcstride / sizeof(pixel);\
+uint64_t ftmp[15]; \
+uint64_t rtmp[1];\
+const int8_t *filter = ff_hevc_qpel_filters[mx - 1]; \
+ \
+x = x_step; \
+y = height; \
+__asm__ volatile(\
+MMI_LDC1(%[ftmp1], %[filter], 0x00) \
+"li %[rtmp0], 0x08 \n\t"\
+"dmtc1%[rtmp0], %[ftmp0] \n\t"\
+"punpckhbh%[ftmp2], %[ftmp0], %[ftmp1]\n\t"\
+"punpcklbh%[ftmp1], %[ftmp0], %[ftmp1]\n\t"\
+"psrah%[ftmp1], %[ftmp1], %[ftmp0]\n\t"\
+"psrah%[ftmp2], %[ftmp2], %[ftmp0]\n\t"\
+"xor %[ftmp0], %[ftmp0], %[ftmp0]\n\t"\
+ \
+"1: \n\t"\
+"2: \n\t"\
+"gsldlc1 %[ftmp3], 0x07(%[src]) \n\t"\
+"gsldrc1 %[ftmp3], 0x00(%[src]) \n\t"\
+"gsldlc1 %[ftmp4], 0x08(%[src]) \n\t"\
+"gsldrc1 %[ftmp4], 0x01(%[src]) \n\t"\
+"gsldlc1 %[ftmp5], 0x09(%[sr
Re: [FFmpeg-devel] [PATCH] avcodec/h264_parse: no need check ref list1 for P slices.
On Fri, Feb 1, 2019 at 1:28 PM Lin, Decai wrote: > > > > > -Original Message- > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > > Michael Niedermayer > > Sent: 2019年2月1日 1:12 > > To: FFmpeg development discussions and patches > > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/h264_parse: no need check ref > > list1 for P slices. > > > > On Thu, Jan 31, 2019 at 03:36:56PM +0800, Decai Lin wrote: > > > This is robust for some corner case there is incorrect list1 count in > > > pps header, but it's a P slice and can be decoded well. > > > > please provide a sample h264 video that needs this > > > > Attached the test clip for this patch. > I think the better way is to add a new fate test case with the test clip for h264dec, isn't it? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
