Re: [FFmpeg-devel] [PATCH v1] avcodec/v210enc: add yuv420p/yuv420p10 input pixel format support
On 9/20/19, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/v210_template.c | 20
> libavcodec/v210enc.c | 8 +---
> 2 files changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/v210_template.c b/libavcodec/v210_template.c
> index 9e1d9f9..083a9f1 100644
> --- a/libavcodec/v210_template.c
> +++ b/libavcodec/v210_template.c
> @@ -43,11 +43,31 @@ static void RENAME(v210_enc)(AVCodecContext *avctx,
> const TYPE *y = (const TYPE *)pic->data[0];
> const TYPE *u = (const TYPE *)pic->data[1];
> const TYPE *v = (const TYPE *)pic->data[2];
> +const TYPE *u_even = u;
> +const TYPE *v_even = v;
> const int sample_size = 6 * s->RENAME(sample_factor);
> const int sample_w= avctx->width / sample_size;
>
> for (h = 0; h < avctx->height; h++) {
> uint32_t val;
> +
> +if (pic->format == AV_PIX_FMT_YUV420P10 ||
> +pic->format == AV_PIX_FMT_YUV420P) {
> +int mod = pic->interlaced_frame == 1 ? 4 : 2;
> +if (h % mod == 0) {
> +u_even = u;
> +v_even = v;
> +} else {
> +/* progressive chroma */
> +if (mod == 2) {
> +u = u_even;
> +v = v_even;
> +} else if (h % 4 == 2) {
> +u = u_even;
> +v = v_even;
> +}
> +}
> +}
> w = sample_w * sample_size;
> s->RENAME(pack_line)(y, u, v, dst, w);
>
> diff --git a/libavcodec/v210enc.c b/libavcodec/v210enc.c
> index 16e8810..2180737 100644
> --- a/libavcodec/v210enc.c
> +++ b/libavcodec/v210enc.c
> @@ -131,9 +131,9 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
> *pkt,
> }
> dst = pkt->data;
>
> -if (pic->format == AV_PIX_FMT_YUV422P10)
> +if (pic->format == AV_PIX_FMT_YUV422P10 || pic->format ==
> AV_PIX_FMT_YUV420P10)
> v210_enc_10(avctx, dst, pic);
> -else if(pic->format == AV_PIX_FMT_YUV422P)
> +else if(pic->format == AV_PIX_FMT_YUV422P || pic->format ==
> AV_PIX_FMT_YUV420P)
> v210_enc_8(avctx, dst, pic);
>
> side_data = av_frame_get_side_data(pic, AV_FRAME_DATA_A53_CC);
> @@ -165,5 +165,7 @@ AVCodec ff_v210_encoder = {
> .priv_data_size = sizeof(V210EncContext),
> .init = encode_init,
> .encode2= encode_frame,
> -.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV422P10,
> AV_PIX_FMT_YUV422P, AV_PIX_FMT_NONE },
> +.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV422P10,
> AV_PIX_FMT_YUV422P,
> +AV_PIX_FMT_YUV420P10,
> AV_PIX_FMT_YUV420P,
> +AV_PIX_FMT_NONE },
> };
> --
> 2.6.4
>
> ___
> 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".
Why people constantly try to do this? First cinepak, now this?
Obviously not accepted.
___
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] lavf/movdec: add position_order option
Rodger Combs: > This allows reading packets linearly, which prevents large numbers of > unnecessary seeks in poorly-interleaved files with consumer software that > handles those cases well on its own. > --- Did you test whether this fixes tickets #7592 and #7891? - Andreas ___ 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] lavf/movdec: add position_order option
> On Sep 22, 2019, at 03:19, Andreas Rheinhardt > wrote: > > Rodger Combs: >> This allows reading packets linearly, which prevents large numbers of >> unnecessary seeks in poorly-interleaved files with consumer software that >> handles those cases well on its own. >> --- > > Did you test whether this fixes tickets #7592 and #7891? > > - Andreas Tested just now; I can't validate 7592 as the sample link is dead, but playback of the files in 7891 over network (in either mpv or ffplay) improves dramatically with this option set. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/utils: unref packet on AVInputFormat.read_packet() failure
James Almer:
> Demuxers may have allocated a packet before encountering an error and
> aborting.
>
> Fixes ticket #8150
>
> Signed-off-by: James Almer
> ---
> It may also fix other tickets as well, since i recall seeing other reports
> about
> leaks in ff_read_packet() on malformed input in the past, but i can't remember
> which.
>
> libavformat/utils.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 3983a3f4ce..215cbe6df8 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -854,6 +854,8 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
> av_init_packet(pkt);
> ret = s->iformat->read_packet(s, pkt);
> if (ret < 0) {
> +av_packet_unref(pkt);
> +
> /* Some demuxers return FFERROR_REDO when they consume
> data and discard it (ignored streams, junk, extradata).
> We must re-call the demuxer to get the real packet. */
>
Hello,
you should take a look at this patchset [1]. The first patch of it
deals with other potential memleaks in ff_read_packet. I have
incorporated your patch as second patch. The rest of the patchset
mainly deals with resetting the packet when putting it on a packet
list (i.e. with your TODO in ff_packet_list_put).
- Andreas
[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-September/250229.html
___
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/truespeech: Eliminate some left shifts
Michael Niedermayer:
> This avoids some invalid shifts
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/truespeech.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/truespeech.c b/libavcodec/truespeech.c
> index d4ddfcbf9c..54352851b3 100644
> --- a/libavcodec/truespeech.c
> +++ b/libavcodec/truespeech.c
> @@ -132,8 +132,7 @@ static void truespeech_correlate_filter(TSContext *dec)
> if(i > 0){
> memcpy(tmp, dec->cvector, i * sizeof(*tmp));
> for(j = 0; j < i; j++)
> -dec->cvector[j] = ((tmp[i - j - 1] * dec->vector[i]) +
> - (dec->cvector[j] << 15) + 0x4000) >> 15;
> +dec->cvector[j] += (tmp[i - j - 1] * dec->vector[i] +
> 0x4000) >> 15;
> }
> dec->cvector[i] = (8 - dec->vector[i]) >> 3;
> }
> @@ -256,7 +255,7 @@ static void truespeech_synth(TSContext *dec, int16_t
> *out, int quart)
> int sum = 0;
> for(k = 0; k < 8; k++)
> sum += ptr0[k] * ptr1[k];
> -sum = (sum + (out[i] << 12) + 0x800) >> 12;
> +sum = out[i] + ((sum + 0x800) >> 12);
> out[i] = av_clip(sum, -0x7FFE, 0x7FFE);
> for(k = 7; k > 0; k--)
> ptr0[k] = ptr0[k - 1];
> @@ -274,7 +273,7 @@ static void truespeech_synth(TSContext *dec, int16_t
> *out, int quart)
> for(k = 7; k > 0; k--)
> ptr0[k] = ptr0[k - 1];
> ptr0[0] = out[i];
> -out[i] = ((out[i] << 12) - sum) >> 12;
> +out[i] += (- sum) >> 12;
> }
>
> for(i = 0; i < 8; i++)
>
LGTM.
- Andreas
PS: My first patch for this (never sent to the ML) was exactly as
yours until I dropped this approach because (x << shift) >> shift is
not the identity, but may change the high bits. Then I switched to
using multiplications and checked that they don't overflow, because
one factor is always an int16_t. At this point I should have realized
that my first approach was viable, but somehow didn't.
___
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 V1 1/6] lavf/4xm: fix memory leak in error handing path
On Sat, Sep 21, 2019 at 10:12:10AM +0800, Jun Zhao wrote:
> From: Jun Zhao
>
> need to free the header in error path
>
> Signed-off-by: Jun Zhao
> ---
> libavformat/4xm.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/libavformat/4xm.c b/libavformat/4xm.c
> index a984fc9..8054980 100644
> --- a/libavformat/4xm.c
> +++ b/libavformat/4xm.c
> @@ -241,6 +241,7 @@ static int fourxm_read_header(AVFormatContext *s)
> size = AV_RL32(&header[i + 4]);
> if (size > header_size - i - 8 && (fourcc_tag == vtrk_TAG ||
> fourcc_tag == strk_TAG)) {
> av_log(s, AV_LOG_ERROR, "chunk larger than array %d>%d\n", size,
> header_size - i - 8);
> +av_free(header);
> return AVERROR_INVALIDDATA;
this doesnt free everything, a goto fail is probably better
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
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] avformat/hashenc: fix incorrect use of av_mallocz_array()
Fixes CID 1453867, CID 1453866, CID 1453865.
Signed-off-by: Moritz Barsnick
---
libavformat/hashenc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/hashenc.c b/libavformat/hashenc.c
index 8e090731ae..34a8fd1f50 100644
--- a/libavformat/hashenc.c
+++ b/libavformat/hashenc.c
@@ -85,7 +85,7 @@ static int hash_init(struct AVFormatContext *s)
int res;
struct HashContext *c = s->priv_data;
c->per_stream = 0;
-c->hashes = av_mallocz_array(1, sizeof(c->hashes));
+c->hashes = av_mallocz_array(1, sizeof(*c->hashes));
if (!c->hashes)
return AVERROR(ENOMEM);
res = av_hash_alloc(&c->hashes[0], c->hash_name);
@@ -102,7 +102,7 @@ static int streamhash_init(struct AVFormatContext *s)
int res, i;
struct HashContext *c = s->priv_data;
c->per_stream = 1;
-c->hashes = av_mallocz_array(s->nb_streams, sizeof(c->hashes));
+c->hashes = av_mallocz_array(s->nb_streams, sizeof(*c->hashes));
if (!c->hashes)
return AVERROR(ENOMEM);
for (i = 0; i < s->nb_streams; i++) {
@@ -270,7 +270,7 @@ static int framehash_init(struct AVFormatContext *s)
int res;
struct HashContext *c = s->priv_data;
c->per_stream = 0;
-c->hashes = av_mallocz_array(1, sizeof(c->hashes));
+c->hashes = av_mallocz_array(1, sizeof(*c->hashes));
if (!c->hashes)
return AVERROR(ENOMEM);
res = av_hash_alloc(&c->hashes[0], c->hash_name);
--
2.20.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 v3 0/3] avformat/hashenc: add streamhash muxer
On Sat, Sep 21, 2019 at 10:07:25 +0530, Gyan wrote: [...] > Coverity reports three issues arising from this patchset, actually one > issue, having an instance in each of the three init () functions. [...] > c->hashes = av_mallocz_array(1, sizeof(c->hashes)); [...] > "Passing argument "8UL /* sizeof (c->hashes) */" to function > "av_mallocz_array" and then casting the return value to "struct > AVHashContext **" is suspicious. In this particular case "sizeof (struct > AVHashContext **)" happens to be equal to "sizeof (struct AVHashContext > *)", but this is not a portable assumption." Now that you point it out, it's obvious. Shame on me, it wasn't before. (For the record, for those who want to learn what I learned: c->hashes = av_mallocz_array(1, sizeof(*c->hashes)); would have been correct.) Too bad we don't have other static analysis tools to catch this. (Or would cppcheck have caught this?) I'm aware that Coverity only operates on the actual repo, not on submitted patches. Anyway, a patch to fix this is posted. Thanks, Moritz ___ 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 v1] avcodec/v210enc: add yuv420p/yuv420p10 input pixel format support
On Sun, Sep 22, 2019 at 10:05:10AM +0200, Paul B Mahol wrote:
> On 9/20/19, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavcodec/v210_template.c | 20
> > libavcodec/v210enc.c | 8 +---
> > 2 files changed, 25 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavcodec/v210_template.c b/libavcodec/v210_template.c
> > index 9e1d9f9..083a9f1 100644
> > --- a/libavcodec/v210_template.c
> > +++ b/libavcodec/v210_template.c
> > @@ -43,11 +43,31 @@ static void RENAME(v210_enc)(AVCodecContext *avctx,
> > const TYPE *y = (const TYPE *)pic->data[0];
> > const TYPE *u = (const TYPE *)pic->data[1];
> > const TYPE *v = (const TYPE *)pic->data[2];
> > +const TYPE *u_even = u;
> > +const TYPE *v_even = v;
> > const int sample_size = 6 * s->RENAME(sample_factor);
> > const int sample_w= avctx->width / sample_size;
> >
> > for (h = 0; h < avctx->height; h++) {
> > uint32_t val;
> > +
> > +if (pic->format == AV_PIX_FMT_YUV420P10 ||
> > +pic->format == AV_PIX_FMT_YUV420P) {
> > +int mod = pic->interlaced_frame == 1 ? 4 : 2;
> > +if (h % mod == 0) {
> > +u_even = u;
> > +v_even = v;
> > +} else {
> > +/* progressive chroma */
> > +if (mod == 2) {
> > +u = u_even;
> > +v = v_even;
> > +} else if (h % 4 == 2) {
> > +u = u_even;
> > +v = v_even;
> > +}
> > +}
> > +}
> > w = sample_w * sample_size;
> > s->RENAME(pack_line)(y, u, v, dst, w);
> >
> > diff --git a/libavcodec/v210enc.c b/libavcodec/v210enc.c
> > index 16e8810..2180737 100644
> > --- a/libavcodec/v210enc.c
> > +++ b/libavcodec/v210enc.c
> > @@ -131,9 +131,9 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
> > *pkt,
> > }
> > dst = pkt->data;
> >
> > -if (pic->format == AV_PIX_FMT_YUV422P10)
> > +if (pic->format == AV_PIX_FMT_YUV422P10 || pic->format ==
> > AV_PIX_FMT_YUV420P10)
> > v210_enc_10(avctx, dst, pic);
> > -else if(pic->format == AV_PIX_FMT_YUV422P)
> > +else if(pic->format == AV_PIX_FMT_YUV422P || pic->format ==
> > AV_PIX_FMT_YUV420P)
> > v210_enc_8(avctx, dst, pic);
> >
> > side_data = av_frame_get_side_data(pic, AV_FRAME_DATA_A53_CC);
> > @@ -165,5 +165,7 @@ AVCodec ff_v210_encoder = {
> > .priv_data_size = sizeof(V210EncContext),
> > .init = encode_init,
> > .encode2= encode_frame,
> > -.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV422P10,
> > AV_PIX_FMT_YUV422P, AV_PIX_FMT_NONE },
> > +.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV422P10,
> > AV_PIX_FMT_YUV422P,
> > +AV_PIX_FMT_YUV420P10,
> > AV_PIX_FMT_YUV420P,
> > +AV_PIX_FMT_NONE },
> > };
> > --
> > 2.6.4
> >
> > ___
> > 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".
>
>
> Why people constantly try to do this? First cinepak, now this?
>
> Obviously not accepted.
This means that several of your big-name experts should consider the global
design,
improve the current system framework, and solve the actual needs, rather than
simply
rejecting the performance improvement of different modules. I believe that the
kernel
zero copy technology is also forced to come out like this. Technology is to
change
the world, not to be perfect.
___
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 2/2] avcodec/v210dec: add the frame and slice threading support
On Sat, Sep 21, 2019 at 11:04:27PM +0200, Michael Niedermayer wrote:
> On Sat, Sep 21, 2019 at 07:45:58AM +0800, Limin Wang wrote:
> > On Fri, Sep 20, 2019 at 07:57:10PM +0200, Michael Niedermayer wrote:
> > > On Fri, Sep 06, 2019 at 11:28:29PM +0800, lance.lmw...@gmail.com wrote:
> > > > From: Limin Wang
> > > >
> > > > The multithread is avoid one core cpu is full with other filter like
> > > > scale etc.
> > > > About the performance, the gain is very small, below is my testing for
> > > > performance.
> > > > In order to avoid the disk bottleneck, I'll use stream_loop mode for 10
> > > > frame
> > > > only.
> > > >
> > > > ./ffmpeg -y -i ~/Movies/4k_Rec709_ProResHQ.mov -c:v v210 -f rawvideo
> > > > -frames 10
> > > > ~/Movies/1.v210
> > > >
> > > > master:
> > > > ./ffmpeg -threads 1 -s 4096x3072 -stream_loop 100 -i ~/Movies/1.v210
> > > > -benchmark
> > > > -f null -
> > > > frame= 1010 fps= 42 q=-0.0 Lsize=N/A time=00:00:40.40 bitrate=N/A
> > > > speed=1.69x
> > > > video:529kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
> > > > muxing
> > > > overhead: unknown
> > > > bench: utime=10.082s stime=13.784s rtime=23.889s
> > > > bench: maxrss=147836928kB
> > > >
> > > > patch applied:
> > > > ./ffmpeg -threads 4 -thread_type frame+slice -s 4096x3072 -stream_loop
> > > > 100 -i
> > > > ~/Movies/1.v210 -benchmark -f null -
> > > >
> > > > frame= 1010 fps= 55 q=-0.0 Lsize=N/A time=00:00:40.40 bitrate=N/A
> > > > speed=2.22x
> > > > video:529kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
> > > > muxing
> > > > overhead: unknown
> > > > bench: utime=11.407s stime=17.258s rtime=18.279s
> > > > bench: maxrss=442884096kB
> > > >
> > > > Signed-off-by: Limin Wang
> > > > ---
> > > > libavcodec/v210dec.c | 135
> > > > +--
> > > > libavcodec/v210dec.h | 1 +
> > > > 2 files changed, 88 insertions(+), 48 deletions(-)
> > > >
> > > > diff --git a/libavcodec/v210dec.c b/libavcodec/v210dec.c
> > > > index 6ce18aa..2cdb99e 100644
> > > > --- a/libavcodec/v210dec.c
> > > > +++ b/libavcodec/v210dec.c
> > > > @@ -28,6 +28,7 @@
> > > > #include "libavutil/internal.h"
> > > > #include "libavutil/mem.h"
> > > > #include "libavutil/intreadwrite.h"
> > > > +#include "thread.h"
> > > >
> > > > #define READ_PIXELS(a, b, c) \
> > > > do { \
> > > > @@ -37,6 +38,13 @@
> > > > *c++ = (val >> 20) & 0x3FF; \
> > > > } while (0)
> > > >
> > > > +#define MAX_SLICES 32
> > > > +typedef struct ThreadData {
> > > > +AVFrame *frame;
> > > > +uint8_t *buf;
> > > > +int stride;
> > > > +} ThreadData;
> > > > +
> > > > static void v210_planar_unpack_c(const uint32_t *src, uint16_t *y,
> > > > uint16_t *u, uint16_t *v, int width)
> > > > {
> > > > uint32_t val;
> > > > @@ -67,58 +75,32 @@ static av_cold int decode_init(AVCodecContext
> > > > *avctx)
> > > > s->aligned_input = 0;
> > > > ff_v210dec_init(s);
> > > >
> > > > +s->slice_count = av_clip(avctx->thread_count, 1, MAX_SLICES);
> > >
> > > why is there a MAX_SLICES ?
> >
> > It's limit the slice thread count, if it's not OK, I can use
> > MAX_AUTO_THREADS for max.
>
> why is a limit needed here ?
> where does avctx->thread_count get a bad value ?
>
> This feels a bit arbitrary to limit it to 32 (or any number)
> will that be still correct in 10 years ? if not then this is
> not a good way to limit it
Michael, I have fixed and update the patch, please review it.
Can I remove similar thread restrictions for other modules that support
threads?
When we refer to multi-threaded code, they also cause misleading.
>
> thx
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The misfortune of the wise is better than the prosperity of the fool.
> -- Epicurus
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 1/9] avformat/utils: Fix memleaks
On Fri, Sep 20, 2019 at 10:39:08PM +0200, Andreas Rheinhardt wrote:
> ff_read_packet had several potential memleaks:
> 1. If av_packet_make_refcounted fails, it means that the packet is not
> refcounted, but it could nevertheless carry side data and therefore
> needs to be unreferenced.
> 2. If a packet happens to have an illegal stream index (i.e. one that
> does not correspond to a stream), it should nevertheless be
> unreferenced.
> 3. If putting a packet on a packet list fails, it wasn't unreferenced.
>
> Furthermore, read_frame_internal leaked a packet's (side) data if a
> context update was required and failed.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/utils.c | 17 +
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 3983a3f4ce..652642a71b 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -872,8 +872,10 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
> }
>
> err = av_packet_make_refcounted(pkt);
> -if (err < 0)
> +if (err < 0) {
> +av_packet_unref(pkt);
> return err;
> +}
>
> if ((s->flags & AVFMT_FLAG_DISCARD_CORRUPT) &&
> (pkt->flags & AV_PKT_FLAG_CORRUPT)) {
> @@ -886,6 +888,7 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
>
> if (pkt->stream_index >= (unsigned)s->nb_streams) {
> av_log(s, AV_LOG_ERROR, "Invalid stream index %d\n",
> pkt->stream_index);
> +av_packet_unref(pkt);
> continue;
> }
>
What does generate invalid stream indexes ?
if nothing then this should probably be an av_assert*()
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott
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 v3] lavfi/vf_colorconstancy: add weighted_greyedge
Is this gonna be applied at all? On 12/3/18, Mina wrote: > Hi, > >This patch was part of GSoC Color Constancy filter. It introduces an > improved color constancy filter(weighted_greyedge) based on the already > pushed greyedge. I'm sending it again after updating it against latest > version of master. > > V3 changes: > - fixed inconsistency in filters.texi > > > Regards, > Mina Sami > > ___ 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 v1] avcodec/dnxhdenc: return error if av_malloc failed
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/dnxhdenc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/dnxhdenc.c b/libavcodec/dnxhdenc.c
index 41b8079..f144406 100644
--- a/libavcodec/dnxhdenc.c
+++ b/libavcodec/dnxhdenc.c
@@ -365,7 +365,7 @@ fail:
static av_cold int dnxhd_encode_init(AVCodecContext *avctx)
{
DNXHDEncContext *ctx = avctx->priv_data;
-int i, index, ret;
+int i = 1, index, ret;
switch (avctx->pix_fmt) {
case AV_PIX_FMT_YUV422P:
@@ -542,12 +542,15 @@ FF_ENABLE_DEPRECATION_WARNINGS
if (avctx->active_thread_type == FF_THREAD_SLICE) {
for (i = 1; i < avctx->thread_count; i++) {
ctx->thread[i] = av_malloc(sizeof(DNXHDEncContext));
+if(!ctx->thread[i])
+goto fail;
memcpy(ctx->thread[i], ctx, sizeof(DNXHDEncContext));
}
}
return 0;
fail: // for FF_ALLOCZ_OR_GOTO
+avctx->thread_count = i;
return AVERROR(ENOMEM);
}
--
2.6.4
___
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 v1] avcodec/dnxhdenc: return error if av_malloc failed
On 9/22/2019 11:06 AM, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/dnxhdenc.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/dnxhdenc.c b/libavcodec/dnxhdenc.c
> index 41b8079..f144406 100644
> --- a/libavcodec/dnxhdenc.c
> +++ b/libavcodec/dnxhdenc.c
> @@ -365,7 +365,7 @@ fail:
> static av_cold int dnxhd_encode_init(AVCodecContext *avctx)
> {
> DNXHDEncContext *ctx = avctx->priv_data;
> -int i, index, ret;
> +int i = 1, index, ret;
>
> switch (avctx->pix_fmt) {
> case AV_PIX_FMT_YUV422P:
> @@ -542,12 +542,15 @@ FF_ENABLE_DEPRECATION_WARNINGS
> if (avctx->active_thread_type == FF_THREAD_SLICE) {
> for (i = 1; i < avctx->thread_count; i++) {
> ctx->thread[i] = av_malloc(sizeof(DNXHDEncContext));
> +if(!ctx->thread[i])
> +goto fail;
> memcpy(ctx->thread[i], ctx, sizeof(DNXHDEncContext));
> }
> }
>
> return 0;
> fail: // for FF_ALLOCZ_OR_GOTO
> +avctx->thread_count = i;
This is unnecessary. All ctx->thread[] array elements are zero
initialized, so the av_freep() calls in dnxhd_encode_end() are safe for
those that were never allocated.
> return AVERROR(ENOMEM);
> }
>
>
___
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] avcodec/dnxhdenc: remove the unneed *thread[MAX_THREADS]
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/dnxhdenc.c | 47 ++-
libavcodec/dnxhdenc.h | 2 --
2 files changed, 10 insertions(+), 39 deletions(-)
diff --git a/libavcodec/dnxhdenc.c b/libavcodec/dnxhdenc.c
index 41b8079..6be3c43 100644
--- a/libavcodec/dnxhdenc.c
+++ b/libavcodec/dnxhdenc.c
@@ -365,7 +365,7 @@ fail:
static av_cold int dnxhd_encode_init(AVCodecContext *avctx)
{
DNXHDEncContext *ctx = avctx->priv_data;
-int i, index, ret;
+int index, ret;
switch (avctx->pix_fmt) {
case AV_PIX_FMT_YUV422P:
@@ -526,26 +526,11 @@ FF_DISABLE_DEPRECATION_WARNINGS
FF_ENABLE_DEPRECATION_WARNINGS
#endif
-if (avctx->active_thread_type == FF_THREAD_SLICE) {
-if (avctx->thread_count > MAX_THREADS) {
-av_log(avctx, AV_LOG_ERROR, "too many threads\n");
-return AVERROR(EINVAL);
-}
-}
-
if (avctx->qmax <= 1) {
av_log(avctx, AV_LOG_ERROR, "qmax must be at least 2\n");
return AVERROR(EINVAL);
}
-ctx->thread[0] = ctx;
-if (avctx->active_thread_type == FF_THREAD_SLICE) {
-for (i = 1; i < avctx->thread_count; i++) {
-ctx->thread[i] = av_malloc(sizeof(DNXHDEncContext));
-memcpy(ctx->thread[i], ctx, sizeof(DNXHDEncContext));
-}
-}
-
return 0;
fail: // for FF_ALLOCZ_OR_GOTO
return AVERROR(ENOMEM);
@@ -713,11 +698,11 @@ void dnxhd_get_blocks(DNXHDEncContext *ctx, int mb_x, int
mb_y)
int dct_uv_offset = ctx->dct_uv_offset;
int linesize = ctx->m.linesize;
int uvlinesize = ctx->m.uvlinesize;
-const uint8_t *ptr_y = ctx->thread[0]->src[0] +
+const uint8_t *ptr_y = ctx->src[0] +
((mb_y << 4) * ctx->m.linesize) + (mb_x << bs + 1);
-const uint8_t *ptr_u = ctx->thread[0]->src[1] +
+const uint8_t *ptr_u = ctx->src[1] +
((mb_y << 4) * ctx->m.uvlinesize) + (mb_x << bs +
ctx->is_444);
-const uint8_t *ptr_v = ctx->thread[0]->src[2] +
+const uint8_t *ptr_v = ctx->src[2] +
((mb_y << 4) * ctx->m.uvlinesize) + (mb_x << bs +
ctx->is_444);
PixblockDSPContext *pdsp = &ctx->m.pdsp;
VideoDSPContext *vdsp = &ctx->m.vdsp;
@@ -853,7 +838,6 @@ static int dnxhd_calc_bits_thread(AVCodecContext *avctx,
void *arg,
int mb_y = jobnr, mb_x;
int qscale = ctx->qscale;
LOCAL_ALIGNED_16(int16_t, block, [64]);
-ctx = ctx->thread[threadnr];
ctx->m.last_dc[0] =
ctx->m.last_dc[1] =
@@ -908,7 +892,6 @@ static int dnxhd_encode_thread(AVCodecContext *avctx, void
*arg,
{
DNXHDEncContext *ctx = avctx->priv_data;
int mb_y = jobnr, mb_x;
-ctx = ctx->thread[threadnr];
init_put_bits(&ctx->m.pb, (uint8_t *)arg + ctx->data_offset +
ctx->slice_offs[jobnr],
ctx->slice_size[jobnr]);
@@ -969,9 +952,8 @@ static int dnxhd_mb_var_thread(AVCodecContext *avctx, void
*arg,
int partial_last_row = (mb_y == ctx->m.mb_height - 1) &&
((avctx->height >> ctx->interlaced) & 0xF);
-ctx = ctx->thread[threadnr];
if (ctx->bit_depth == 8) {
-uint8_t *pix = ctx->thread[0]->src[0] + ((mb_y << 4) *
ctx->m.linesize);
+uint8_t *pix = ctx->src[0] + ((mb_y << 4) * ctx->m.linesize);
for (mb_x = 0; mb_x < ctx->m.mb_width; ++mb_x, pix += 16) {
unsigned mb = mb_y * ctx->m.mb_width + mb_x;
int sum;
@@ -1000,7 +982,7 @@ static int dnxhd_mb_var_thread(AVCodecContext *avctx, void
*arg,
} else { // 10-bit
const int linesize = ctx->m.linesize >> 1;
for (mb_x = 0; mb_x < ctx->m.mb_width; ++mb_x) {
-uint16_t *pix = (uint16_t *)ctx->thread[0]->src[0] +
+uint16_t *pix = (uint16_t *)ctx->src[0] +
((mb_y << 4) * linesize) + (mb_x << 4);
unsigned mb = mb_y * ctx->m.mb_width + mb_x;
int sum = 0;
@@ -1264,14 +1246,11 @@ static int dnxhd_encode_fast(AVCodecContext *avctx,
DNXHDEncContext *ctx)
static void dnxhd_load_picture(DNXHDEncContext *ctx, const AVFrame *frame)
{
-int i;
-for (i = 0; i < ctx->m.avctx->thread_count; i++) {
-ctx->thread[i]->m.linesize= frame->linesize[0] << ctx->interlaced;
-ctx->thread[i]->m.uvlinesize = frame->linesize[1] << ctx->interlaced;
-ctx->thread[i]->dct_y_offset = ctx->m.linesize *8;
-ctx->thread[i]->dct_uv_offset = ctx->m.uvlinesize*8;
-}
+ctx->m.linesize= frame->linesize[0] << ctx->interlaced;
+ctx->m.uvlinesize = frame->linesize[1] << ctx->interlaced;
+ctx->dct_y_offset = ctx->m.linesize *8;
+ctx->dct_uv_offset = ctx->m.uvlinesize*8;
#if FF_API_CODED_FRAME
FF_DISABLE_DEPRECATION_WARNINGS
@@ -1354,7 +1333,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
static av_cold int dnxhd_encode_end(AVCodecContext *avctx)
{
DNXHDEncContext *ctx = avctx->priv_data;
-int i;
av_freep(&ctx
Re: [FFmpeg-devel] [PATCH v2] avcodec/dnxhdenc: remove the unneed *thread[MAX_THREADS]
On 9/22/2019 12:43 PM, lance.lmw...@gmail.com wrote: > From: Limin Wang > > Signed-off-by: Limin Wang > --- > libavcodec/dnxhdenc.c | 47 ++- > libavcodec/dnxhdenc.h | 2 -- > 2 files changed, 10 insertions(+), 39 deletions(-) Err, what? I think you misunderstood what i called unnecessary in my last email... ___ 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 v1] avcodec/dnxhdenc: return error if av_malloc failed
On Sun, Sep 22, 2019 at 11:15:51AM -0300, James Almer wrote:
> On 9/22/2019 11:06 AM, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavcodec/dnxhdenc.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/dnxhdenc.c b/libavcodec/dnxhdenc.c
> > index 41b8079..f144406 100644
> > --- a/libavcodec/dnxhdenc.c
> > +++ b/libavcodec/dnxhdenc.c
> > @@ -365,7 +365,7 @@ fail:
> > static av_cold int dnxhd_encode_init(AVCodecContext *avctx)
> > {
> > DNXHDEncContext *ctx = avctx->priv_data;
> > -int i, index, ret;
> > +int i = 1, index, ret;
> >
> > switch (avctx->pix_fmt) {
> > case AV_PIX_FMT_YUV422P:
> > @@ -542,12 +542,15 @@ FF_ENABLE_DEPRECATION_WARNINGS
> > if (avctx->active_thread_type == FF_THREAD_SLICE) {
> > for (i = 1; i < avctx->thread_count; i++) {
> > ctx->thread[i] = av_malloc(sizeof(DNXHDEncContext));
> > +if(!ctx->thread[i])
> > +goto fail;
> > memcpy(ctx->thread[i], ctx, sizeof(DNXHDEncContext));
> > }
> > }
> >
> > return 0;
> > fail: // for FF_ALLOCZ_OR_GOTO
> > +avctx->thread_count = i;
>
> This is unnecessary. All ctx->thread[] array elements are zero
> initialized, so the av_freep() calls in dnxhd_encode_end() are safe for
> those that were never allocated.
After more review for the code, I think it's unneed to define the thread[i]
totally by my study for the thread code. I have post the update patch,
please point out if I'm misunderstand as I'm lacking the background for
it.
>
> > return AVERROR(ENOMEM);
> > }
> >
> >
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avcodec/dnxhdenc: remove the unneed *thread[MAX_THREADS]
On Sun, Sep 22, 2019 at 12:45:48PM -0300, James Almer wrote: > On 9/22/2019 12:43 PM, lance.lmw...@gmail.com wrote: > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > libavcodec/dnxhdenc.c | 47 ++- > > libavcodec/dnxhdenc.h | 2 -- > > 2 files changed, 10 insertions(+), 39 deletions(-) > > Err, what? I think you misunderstood what i called unnecessary in my > last email... No, I'm not familar with dnxhdenc too much, so I have pass "make fate" to testing the function(with THREAD=0 and THREAD=2) For the performance, by my quick testing, the results are same as before. I hope it's my misunderstanding, but the results are OK. Thanks, Limin > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avcodec/dnxhdenc: remove the unneed *thread[MAX_THREADS]
On 9/22/2019 1:01 PM, Limin Wang wrote: > On Sun, Sep 22, 2019 at 12:45:48PM -0300, James Almer wrote: >> On 9/22/2019 12:43 PM, lance.lmw...@gmail.com wrote: >>> From: Limin Wang >>> >>> Signed-off-by: Limin Wang >>> --- >>> libavcodec/dnxhdenc.c | 47 ++- >>> libavcodec/dnxhdenc.h | 2 -- >>> 2 files changed, 10 insertions(+), 39 deletions(-) >> >> Err, what? I think you misunderstood what i called unnecessary in my >> last email... > No, I'm not familar with dnxhdenc too much, so I have pass "make fate" to > testing > the function(with THREAD=0 and THREAD=2) > > For the performance, by my quick testing, the results are same as before. > > I hope it's my misunderstanding, but the results are OK. Try with THREAD_TYPE=slice, otherwise you'll be testing frame threading. > > > Thanks, > Limin > > >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/opt: Fix type specifier
On Sat, Sep 21, 2019 at 05:11:57PM +0200, Paul B Mahol wrote: > lgtm will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/5] avcodec/sunrast: Fix return type for "unsupported (compression) type"
On Sat, Sep 21, 2019 at 07:00:41PM +0200, Paul B Mahol wrote: > LGTM will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/5] avcodec/sunrast: Fix indention
On Sat, Sep 21, 2019 at 06:57:26PM +0200, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavcodec/sunrast.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1] avcodec/v210enc: add yuv420p/yuv420p10 input pixel format support
> > This means that several of your big-name experts should consider the > global design, > improve the current system framework, and solve the actual needs, rather > than simply > rejecting the performance improvement of different modules. I believe that > the kernel > zero copy technology is also forced to come out like this. Technology is > to change > the world, not to be perfect. > And just like in the kernel, zero copy technology is maintained outside. Good design is separation of different functionality, otherwise the combinations of codepaths is exponentiated. Patch rejected Regards, Kieran Kunhya ___ 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 v1] avcodec/v210enc: add yuv420p/yuv420p10 input pixel format support
On Sat, Sep 21, 2019 at 10:49:21PM -0400, Devin Heitmueller wrote: > > > On Sep 21, 2019, at 4:44 PM, Michael Niedermayer > > wrote: > > > >> The patch just expands 4:2:0 to 4:2:2 while properly supporting interlaced > >> chroma. > > > > 4:2:0 and 4:2:2 have a chroma plane with different resolution. > > converting between planes of different resolution is what i called scaling. > > > > > >> It avoids having to auto insert the swscale filter in the case where there > >> is no scaling required (e.g. H.264 4:2:0 video being output to decklink in > >> its original resolution). > > > > yes, doing an operation in the encoder avoids a filter being inserted which > > does that operation. > > Thats true for every encoder and every filter. > > The key thing here is the encoder is already touching every pixel, so > avoiding having the need for the filter essentially allows the conversion to > happen at essentially zero cost (as we repack the pixels into the requisite > v210 layout). > > > Also replacing interpolation by a nearest neighbor implementation > > is quite expectedly faster. > > Yes, and we can certainly argue about whether doing interpolation of chroma > when doing 4:2:0 to 4:2:2 actually has any visible benefit. I can however > say the cost of having swscaler in the pipeline is considerable. In fact I > didn’t appreciate it myself until I was trying to deliver 1080p60 in realtime > to four decklink outputs and couldn’t keep up on my target platform. And > because filters generally aren’t threaded, I got hit with one of those cases > where I had to break out the profiler and ask “why on Earth is the main > ffmpeg thread so busy?" > > > > one problem is > > the user can setup the scale filter with high quality in mind or with > > low quality and speed in mind. > > But after this patch she always gets low quality because the low quality > > convertion code is hardcoded in the encoder which pretends to support 420. > > The outside code has no chance to know it shouldnt feed 420 if high quality > > is wanted. > > The user can still insert a scaler explicitly or use the pix_fmt argument so > the format filter gets put into the pipeline. The problem is the user first has to know about the "in encoder convert" and fully understand the implications. Only then can she insert a scaler and format filter manually (unless she is copy and pasting this from somewhere). That is alot of knowledge for the average user > > > > > Also why should this be in one encoder and not be available to other > > encoders supporting 4:2:2 input ? > > A solution should work for all of them > > I would assume this would really only be helpful in encoders which only > support 4:2:2 and not 4:2:0, since typical encoders that accept 4:2:0 would > preserve that in their resulting encoding (i.e. they wouldn’t blindly upscale > 4:2:0 to 4:2:2 for no good reason). Maybe. But then there are specifications that demand 4:2:2 in cases where the underlaying encoder supports 4:2:0. In these cases 4:2:2 would need to be delivered and delivering 4:2:0 directly to the encoder would not produce a compliant result (with current encoders) > > I did actually consider doing a separate filter which just does packed/planer > conversion and 4:2:0 to 4:2:2 (as opposed to swscaler). In this case though > the additional modularity in such a filter was outweighed by my goal to > minimize the number of times I’m copying the frame data. Combining it with > the v210 encoding meant only a single pass over the data. > > > > > Iam not sure what is the best solution but simply hardcoding this in > > one encoder feels rather wrong > > The scale filter performs three basic roles: > 1. Scaling > 2. Packed to planer conversion (or vice versa) > 3. Colorspace conversion > > I supposed potentially someone could redesign swscale to include the option > to not take the slow path for cases where scaling isn’t actually required > (i.e. cases where only 2 and 3 are needed). For this look at ff_get_unscaled_swscale() a new 420->422 scaler can easily be added in there, it would not be 0 copy though. But it certainly would make sense for the cases where this codepath i used > > Just so we’re all on the same page - this wasn’t a case of random or > premature optimization. I have a specific use case where I’m decoding four > instances of 1080p60 video and the platform can’t keep up without this > change. It’s the result of actually profiling the entire pipeline as opposed > to some unit test with a benchmark. In fact I don’t particularly agree with > Limin's numbers where he used the benchmark option, since that fails to take > into account caching behavior or memory bandwidth on a platform which is > constrained (a problem which is exacerbated when running multiple instances). > In a perfect world we would have very small operations which each perform > some discrete function, and we can combine all of those
Re: [FFmpeg-devel] [PATCH v1] avcodec/v210enc: add yuv420p/yuv420p10 input pixel format support
On 22/09/2019 17:18, Kieran Kunhya wrote: > And just like in the kernel, zero copy technology is maintained outside. > Good design is separation of different functionality, otherwise the > combinations of codepaths is exponentiated. Agreed with everyone else here, this code doesn't belong in an encoder. libavcodec is a general use codec library, and this doesn't fit that design or philosophy at all. It's hideous. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1 1/4] avfilter/vf_framerate: add flags none to disable scene change detection if necessary
On Sat, 21 Sep 2019, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/filters.texi | 2 ++
libavfilter/vf_framerate.c | 17 +++--
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index bbfdad4..fce4ef4 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10637,6 +10637,8 @@ Specify flags influencing the filter process.
Available value for @var{flags} is:
@table @option
+@item none
+Disable scene change detection
This is only true if no additional flags are added later. The reason of
using a flags option is future extensibility, so adding such a constant
kind of defeats that purpose. It is also uneeded, "none" is a a named
constant which you can always use to explicitly set no flags.
So this patch seems uneeded.
Regards,
Marton
@item scene_change_detect, scd
Enable scene change detection using the value of the option @var{scene}.
This flag is enabled by default.
diff --git a/libavfilter/vf_framerate.c b/libavfilter/vf_framerate.c
index 06e463e..99faf75 100644
--- a/libavfilter/vf_framerate.c
+++ b/libavfilter/vf_framerate.c
@@ -44,7 +44,9 @@
#define OFFSET(x) offsetof(FrameRateContext, x)
#define V AV_OPT_FLAG_VIDEO_PARAM
#define F AV_OPT_FLAG_FILTERING_PARAM
+#define FRAMERATE_FLAG_NONE 00
#define FRAMERATE_FLAG_SCD 01
+#define CONST(name, help, val, unit) { name, help, 0, AV_OPT_TYPE_CONST,
{.i64=val}, 0, 0, V|F, unit }
static const AVOption framerate_options[] = {
{"fps", "required output frames per second rate",
OFFSET(dest_frame_rate), AV_OPT_TYPE_VIDEO_RATE, {.str="50"}, 0, INT_MAX, V|F },
@@ -53,9 +55,10 @@ static const AVOption framerate_options[] = {
{"interp_end", "point to end linear interpolation",
OFFSET(interp_end), AV_OPT_TYPE_INT, {.i64=240},0, 255, V|F },
{"scene", "scene change level",
OFFSET(scene_score), AV_OPT_TYPE_DOUBLE, {.dbl=8.2},0, INT_MAX, V|F },
-{"flags", "set flags", OFFSET(flags),
AV_OPT_TYPE_FLAGS,{.i64=1}, 0, INT_MAX, V|F, "flags" },
-{"scene_change_detect", "enable scene change detection", 0,
AV_OPT_TYPE_CONST,{.i64=FRAMERATE_FLAG_SCD}, INT_MIN, INT_MAX, V|F, "flags" },
-{"scd", "enable scene change detection", 0,
AV_OPT_TYPE_CONST,{.i64=FRAMERATE_FLAG_SCD}, INT_MIN, INT_MAX, V|F, "flags" },
+{"flags", "set flags", OFFSET(flags), AV_OPT_TYPE_FLAGS,
{.i64=FRAMERATE_FLAG_SCD}, FRAMERATE_FLAG_NONE, FRAMERATE_FLAG_SCD, V|F, "flags" },
+CONST("none", "disable scene change detection",
FRAMERATE_FLAG_NONE,"flags"),
+CONST("scene_change_detect", "enable scene change detection",
FRAMERATE_FLAG_SCD, "flags"),
+CONST("scd", "enable scene change detection",
FRAMERATE_FLAG_SCD, "flags"),
{NULL}
};
@@ -301,9 +304,11 @@ static int config_input(AVFilterLink *inlink)
s->bitdepth = pix_desc->comp[0].depth;
s->vsub = pix_desc->log2_chroma_h;
-s->sad = ff_scene_sad_get_fn(s->bitdepth == 8 ? 8 : 16);
-if (!s->sad)
-return AVERROR(EINVAL);
+if ((s->flags & FRAMERATE_FLAG_SCD)) {
+s->sad = ff_scene_sad_get_fn(s->bitdepth == 8 ? 8 : 16);
+if (!s->sad)
+return AVERROR(EINVAL);
+}
s->srce_time_base = inlink->time_base;
--
2.6.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/3] avformat: use avpriv_mpeg4audio_get_config2()
WwawwewzA XX,$_2*#$5$2
On Sat, Sep 21, 2019, 7:28 PM James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavformat/adtsenc.c | 2 +-
> libavformat/isom.c| 4 ++--
> libavformat/latmenc.c | 2 +-
> libavformat/matroskaenc.c | 3 +--
> 4 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/libavformat/adtsenc.c b/libavformat/adtsenc.c
> index 3c2840c6ab..d937e2bea9 100644
> --- a/libavformat/adtsenc.c
> +++ b/libavformat/adtsenc.c
> @@ -53,7 +53,7 @@ static int adts_decode_extradata(AVFormatContext *s,
> ADTSContext *adts, const ui
> int off;
>
> init_get_bits(&gb, buf, size * 8);
> -off = avpriv_mpeg4audio_get_config(&m4ac, buf, size * 8, 1);
> +off = avpriv_mpeg4audio_get_config2(&m4ac, buf, size, 1, s);
> if (off < 0)
> return off;
> skip_bits_long(&gb, off);
> diff --git a/libavformat/isom.c b/libavformat/isom.c
> index fa2e318099..edd0d81063 100644
> --- a/libavformat/isom.c
> +++ b/libavformat/isom.c
> @@ -547,8 +547,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
> return ret;
> if (st->codecpar->codec_id == AV_CODEC_ID_AAC) {
> MPEG4AudioConfig cfg = {0};
> -ret = avpriv_mpeg4audio_get_config(&cfg,
> st->codecpar->extradata,
> -
> st->codecpar->extradata_size * 8, 1);
> +ret = avpriv_mpeg4audio_get_config2(&cfg,
> st->codecpar->extradata,
> +
> st->codecpar->extradata_size, 1, fc);
> if (ret < 0)
> return ret;
> st->codecpar->channels = cfg.channels;
> diff --git a/libavformat/latmenc.c b/libavformat/latmenc.c
> index 1b16d752b6..db867ebf1a 100644
> --- a/libavformat/latmenc.c
> +++ b/libavformat/latmenc.c
> @@ -62,7 +62,7 @@ static int latm_decode_extradata(AVFormatContext *s,
> uint8_t *buf, int size)
> av_log(s, AV_LOG_ERROR, "Extradata is larger than currently
> supported.\n");
> return AVERROR_INVALIDDATA;
> }
> -ctx->off = avpriv_mpeg4audio_get_config(&m4ac, buf, size * 8, 1);
> +ctx->off = avpriv_mpeg4audio_get_config2(&m4ac, buf, size, 1, s);
> if (ctx->off < 0)
> return ctx->off;
>
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index cef504fa05..a64ffdb690 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -717,8 +717,7 @@ static int get_aac_sample_rates(AVFormatContext *s,
> uint8_t *extradata, int extr
> MPEG4AudioConfig mp4ac;
> int ret;
>
> -ret = avpriv_mpeg4audio_get_config(&mp4ac, extradata,
> - extradata_size * 8, 1);
> +ret = avpriv_mpeg4audio_get_config2(&mp4ac, extradata,
> extradata_size, 1, s);
> /* Don't abort if the failure is because of missing extradata. Assume
> in that
> * case a bitstream filter will provide the muxer with the extradata
> in the
> * first packet.
> --
> 2.22.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] lavfi/vf_colorconstancy: add weighted_greyedge
Hi, I have been very busy last year but recently things are settling down and I would be glad to resume contributing. FYI, a contest was held earlier this year that resulted in some great papers/variations, so I can either resend an updated patch or refactor the filter to accommodate for those possible new variations. Cheers, Mina Sami On 9/22/19 3:13 PM, Paul B Mahol wrote: Is this gonna be applied at all? On 12/3/18, Mina wrote: Hi, This patch was part of GSoC Color Constancy filter. It introduces an improved color constancy filter(weighted_greyedge) based on the already pushed greyedge. I'm sending it again after updating it against latest version of master. V3 changes: - fixed inconsistency in filters.texi Regards, Mina Sami ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avcodec/dnxhdenc: remove the unneed *thread[MAX_THREADS]
On Sun, Sep 22, 2019 at 01:04:01PM -0300, James Almer wrote: > On 9/22/2019 1:01 PM, Limin Wang wrote: > > On Sun, Sep 22, 2019 at 12:45:48PM -0300, James Almer wrote: > >> On 9/22/2019 12:43 PM, lance.lmw...@gmail.com wrote: > >>> From: Limin Wang > >>> > >>> Signed-off-by: Limin Wang > >>> --- > >>> libavcodec/dnxhdenc.c | 47 > >>> ++- > >>> libavcodec/dnxhdenc.h | 2 -- > >>> 2 files changed, 10 insertions(+), 39 deletions(-) > >> > >> Err, what? I think you misunderstood what i called unnecessary in my > >> last email... > > No, I'm not familar with dnxhdenc too much, so I have pass "make fate" to > > testing > > the function(with THREAD=0 and THREAD=2) > > > > For the performance, by my quick testing, the results are same as before. > > > > I hope it's my misunderstanding, but the results are OK. > > Try with THREAD_TYPE=slice, otherwise you'll be testing frame threading. OK, got it. I believe I haven't tested the code without it. > > > > > > > Thanks, > > Limin > > > > > >> ___ > >> ffmpeg-devel mailing list > >> ffmpeg-devel@ffmpeg.org > >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> > >> To unsubscribe, visit link above, or email > >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1] avcodec/v210enc: add yuv420p/yuv420p10 input pixel format support
On Sun, Sep 22, 2019 at 07:15:53PM +0100, Derek Buitenhuis wrote: > On 22/09/2019 17:18, Kieran Kunhya wrote: > > And just like in the kernel, zero copy technology is maintained outside. > > Good design is separation of different functionality, otherwise the > > combinations of codepaths is exponentiated. > > Agreed with everyone else here, this code doesn't belong in an encoder. > > libavcodec is a general use codec library, and this doesn't fit that > design or philosophy at all. It's hideous. I agree with your guys. Can I submit a patch to remove AV_PIX_FMT_YUV422P, it's not belong to v210 encoder also? It make me misunderstanding it's acceptable to add other format. > > - Derek > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ 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 v1 1/4] avfilter/vf_framerate: add flags none to disable scene change detection if necessary
On Sun, Sep 22, 2019 at 08:54:36PM +0200, Marton Balint wrote:
>
>
> On Sat, 21 Sep 2019, lance.lmw...@gmail.com wrote:
>
> >From: Limin Wang
> >
> >Signed-off-by: Limin Wang
> >---
> >doc/filters.texi | 2 ++
> >libavfilter/vf_framerate.c | 17 +++--
> >2 files changed, 13 insertions(+), 6 deletions(-)
> >
> >diff --git a/doc/filters.texi b/doc/filters.texi
> >index bbfdad4..fce4ef4 100644
> >--- a/doc/filters.texi
> >+++ b/doc/filters.texi
> >@@ -10637,6 +10637,8 @@ Specify flags influencing the filter process.
> >Available value for @var{flags} is:
> >
> >@table @option
> >+@item none
> >+Disable scene change detection
>
> This is only true if no additional flags are added later. The reason
> of using a flags option is future extensibility, so adding such a
> constant kind of defeats that purpose. It is also uneeded, "none" is
> a a named constant which you can always use to explicitly set no
> flags.
>
> So this patch seems uneeded.
Marton, thanks for your review, the none flags is for debug purpose,
without sceencut detection, the result will consistent. So it's
necessary to have none flags to turn it off.
>
> Regards,
> Marton
>
> >@item scene_change_detect, scd
> >Enable scene change detection using the value of the option @var{scene}.
> >This flag is enabled by default.
> >diff --git a/libavfilter/vf_framerate.c b/libavfilter/vf_framerate.c
> >index 06e463e..99faf75 100644
> >--- a/libavfilter/vf_framerate.c
> >+++ b/libavfilter/vf_framerate.c
> >@@ -44,7 +44,9 @@
> >#define OFFSET(x) offsetof(FrameRateContext, x)
> >#define V AV_OPT_FLAG_VIDEO_PARAM
> >#define F AV_OPT_FLAG_FILTERING_PARAM
> >+#define FRAMERATE_FLAG_NONE 00
> >#define FRAMERATE_FLAG_SCD 01
> >+#define CONST(name, help, val, unit) { name, help, 0, AV_OPT_TYPE_CONST,
> >{.i64=val}, 0, 0, V|F, unit }
> >
> >static const AVOption framerate_options[] = {
> >{"fps", "required output frames per second rate",
> > OFFSET(dest_frame_rate), AV_OPT_TYPE_VIDEO_RATE, {.str="50"},
> > 0, INT_MAX, V|F },
> >@@ -53,9 +55,10 @@ static const AVOption framerate_options[] = {
> >{"interp_end", "point to end linear interpolation",
> > OFFSET(interp_end), AV_OPT_TYPE_INT, {.i64=240},
> > 0, 255, V|F },
> >{"scene", "scene change level",
> > OFFSET(scene_score), AV_OPT_TYPE_DOUBLE, {.dbl=8.2},
> > 0, INT_MAX, V|F },
> >
> >-{"flags", "set flags",
> >OFFSET(flags), AV_OPT_TYPE_FLAGS,{.i64=1}, 0,
> > INT_MAX, V|F, "flags" },
> >-{"scene_change_detect", "enable scene change detection", 0,
> > AV_OPT_TYPE_CONST,{.i64=FRAMERATE_FLAG_SCD}, INT_MIN,
> >INT_MAX, V|F, "flags" },
> >-{"scd", "enable scene change detection", 0,
> > AV_OPT_TYPE_CONST,{.i64=FRAMERATE_FLAG_SCD}, INT_MIN,
> >INT_MAX, V|F, "flags" },
> >+{"flags", "set flags", OFFSET(flags), AV_OPT_TYPE_FLAGS,
> >{.i64=FRAMERATE_FLAG_SCD}, FRAMERATE_FLAG_NONE, FRAMERATE_FLAG_SCD, V|F,
> >"flags" },
> >+CONST("none", "disable scene change detection",
> > FRAMERATE_FLAG_NONE,"flags"),
> >+CONST("scene_change_detect", "enable scene change detection",
> > FRAMERATE_FLAG_SCD, "flags"),
> >+CONST("scd", "enable scene change detection",
> > FRAMERATE_FLAG_SCD, "flags"),
> >
> >{NULL}
> >};
> >@@ -301,9 +304,11 @@ static int config_input(AVFilterLink *inlink)
> >s->bitdepth = pix_desc->comp[0].depth;
> >s->vsub = pix_desc->log2_chroma_h;
> >
> >-s->sad = ff_scene_sad_get_fn(s->bitdepth == 8 ? 8 : 16);
> >-if (!s->sad)
> >-return AVERROR(EINVAL);
> >+if ((s->flags & FRAMERATE_FLAG_SCD)) {
> >+s->sad = ff_scene_sad_get_fn(s->bitdepth == 8 ? 8 : 16);
> >+if (!s->sad)
> >+return AVERROR(EINVAL);
> >+}
> >
> >s->srce_time_base = inlink->time_base;
> >
> >--
> >2.6.4
> >
> >___
> >ffmpeg-devel mailing list
> >ffmpeg-devel@ffmpeg.org
> >https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >To unsubscribe, visit link above, or email
> >ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH V2] libavcodec/libx264 and libx265: add a flag to output ROI warnings only once.
Signed-off-by: Guo, Yejun
---
libavcodec/libx264.c | 16 ++--
libavcodec/libx265.c | 11 ++-
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 86e3530..8788286 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -99,6 +99,12 @@ typedef struct X264Context {
int nb_reordered_opaque, next_reordered_opaque;
int64_t *reordered_opaque;
+
+/**
+ * If the encoder does not support ROI then warn the first time we
+ * encounter a frame with ROI side data.
+ */
+int roi_warned;
} X264Context;
static void X264_log(void *p, int level, const char *fmt, va_list args)
@@ -356,7 +362,10 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt,
const AVFrame *frame,
sd = av_frame_get_side_data(frame, AV_FRAME_DATA_REGIONS_OF_INTEREST);
if (sd) {
if (x4->params.rc.i_aq_mode == X264_AQ_NONE) {
-av_log(ctx, AV_LOG_WARNING, "Adaptive quantization must be
enabled to use ROI encoding, skipping ROI.\n");
+if (!x4->roi_warned) {
+x4->roi_warned = 1;
+av_log(ctx, AV_LOG_WARNING, "Adaptive quantization must be
enabled to use ROI encoding, skipping ROI.\n");
+}
} else {
if (frame->interlaced_frame == 0) {
int mbx = (frame->width + MB_SIZE - 1) / MB_SIZE;
@@ -410,7 +419,10 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt,
const AVFrame *frame,
x4->pic.prop.quant_offsets = qoffsets;
x4->pic.prop.quant_offsets_free = av_free;
} else {
-av_log(ctx, AV_LOG_WARNING, "interlaced_frame not
supported for ROI encoding yet, skipping ROI.\n");
+if (!x4->roi_warned) {
+x4->roi_warned = 1;
+av_log(ctx, AV_LOG_WARNING, "interlaced_frame not
supported for ROI encoding yet, skipping ROI.\n");
+}
}
}
}
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 665b780..4e75077 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -47,6 +47,12 @@ typedef struct libx265Context {
char *tune;
char *profile;
char *x265_opts;
+
+/**
+ * If the encoder does not support ROI then warn the first time we
+ * encounter a frame with ROI side data.
+ */
+int roi_warned;
} libx265Context;
static int is_keyframe(NalUnitType naltype)
@@ -310,7 +316,10 @@ static av_cold int libx265_encode_set_roi(libx265Context
*ctx, const AVFrame *fr
AVFrameSideData *sd = av_frame_get_side_data(frame,
AV_FRAME_DATA_REGIONS_OF_INTEREST);
if (sd) {
if (ctx->params->rc.aqMode == X265_AQ_NONE) {
-av_log(ctx, AV_LOG_WARNING, "Adaptive quantization must be enabled
to use ROI encoding, skipping ROI.\n");
+if (!ctx->roi_warned) {
+ctx->roi_warned = 1;
+av_log(ctx, AV_LOG_WARNING, "Adaptive quantization must be
enabled to use ROI encoding, skipping ROI.\n");
+}
} else {
/* 8x8 block when qg-size is 8, 16*16 block otherwise. */
int mb_size = (ctx->params->rc.qgSize == 8) ? 8 : 16;
--
2.7.4
___
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/qsv: Fix MSDK initialization failure in system memory mode
> From: Li, Zhong
> Sent: Friday, September 20, 2019 4:45 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Li, Zhong
> Subject: [PATCH 2/3] lavc/qsv: Fix MSDK initialization failure in system
> memory
> mode
>
> MSDK does not create internal acceleration device on Linux, So
> MFXVideoCORE_SetHandle() is necessary.
> It has been added for ff_qsv_init_session_device().
> But missed for ff_qsv_init_internal_session() due to commit
> 1f26a23 overwrited commit db89f45
>
> Fix #7030
>
> Signed-off-by: Zhong Li
> ---
> libavcodec/qsv.c | 62 ---
> libavcodec/qsv_internal.h | 28 +-
> libavcodec/qsvdec.c | 29 +-
> libavcodec/qsvdec.h | 2 +-
> libavcodec/qsvenc.c | 17 +--
> libavcodec/qsvenc.h | 2 +-
> 6 files changed, 109 insertions(+), 31 deletions(-)
>
> diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c index 65ad070e1f..87ff694030
> 100644
> --- a/libavcodec/qsv.c
> +++ b/libavcodec/qsv.c
> @@ -348,7 +348,41 @@ load_plugin_fail:
>
> }
>
> -int ff_qsv_init_internal_session(AVCodecContext *avctx, mfxSession *session,
> +//This code is only required for Linux since a display handle is required.
> +//For Windows the session is complete and ready to use.
> +
> +#ifdef AVCODEC_QSV_LINUX_SESSION_HANDLE static int
> +ff_qsv_set_display_handle(AVCodecContext *avctx, QSVSession *qs) {
> +AVDictionary *child_device_opts = NULL;
> +AVVAAPIDeviceContext *hwctx;
> +int ret;
> +
> +av_dict_set(&child_device_opts, "kernel_driver", "i915", 0);
> +av_dict_set(&child_device_opts, "driver","iHD", 0);
> +
> +ret = av_hwdevice_ctx_create(&qs->va_device_ref,
> AV_HWDEVICE_TYPE_VAAPI, NULL, child_device_opts, 0);
> +if (ret < 0) {
> + av_log(avctx, AV_LOG_ERROR, "Failed to create a VAAPI device.\n");
> +return ret;
> +} else {
> +qs->va_device_ctx = (AVHWDeviceContext*)qs->va_device_ref->data;
> +hwctx = qs->va_device_ctx->hwctx;
> +
> + ret = MFXVideoCORE_SetHandle(qs->session,
> + (mfxHandleType)MFX_HANDLE_VA_DISPLAY, (mfxHDL)hwctx-
> >display);
> + if (ret < 0) {
> + return ff_qsv_print_error(avctx, ret, "Error during set display
> handle\n");
> + }
> +}
> +
> +av_dict_free(&child_device_opts);
> +
> +return 0;
> +}
> +#endif //AVCODEC_QSV_LINUX_SESSION_HANDLE
> +
> +int ff_qsv_init_internal_session(AVCodecContext *avctx, QSVSession *qs,
> const char *load_plugins) {
> mfxIMPL impl = MFX_IMPL_AUTO_ANY;
> @@ -357,18 +391,24 @@ int ff_qsv_init_internal_session(AVCodecContext
> *avctx, mfxSession *session,
> const char *desc;
> int ret;
>
> -ret = MFXInit(impl, &ver, session);
> +ret = MFXInit(impl, &ver, &qs->session);
> if (ret < 0)
> return ff_qsv_print_error(avctx, ret,
>"Error initializing an internal MFX
> session");
>
> -ret = qsv_load_plugins(*session, load_plugins, avctx);
> +#ifdef AVCODEC_QSV_LINUX_SESSION_HANDLE
> +ret = ff_qsv_set_display_handle(avctx, qs);
> +if (ret < 0)
> +return ret;
> +#endif
> +
> +ret = qsv_load_plugins(qs->session, load_plugins, avctx);
> if (ret < 0) {
> av_log(avctx, AV_LOG_ERROR, "Error loading plugins\n");
> return ret;
> }
>
> -MFXQueryIMPL(*session, &impl);
> +MFXQueryIMPL(qs->session, &impl);
>
> switch (MFX_IMPL_BASETYPE(impl)) {
> case MFX_IMPL_SOFTWARE:
> @@ -758,3 +798,17 @@ int ff_qsv_init_session_frames(AVCodecContext *avctx,
> mfxSession *psession,
> *psession = session;
> return 0;
> }
> +
> +int ff_qsv_close_internal_session(QSVSession *qs) {
> +if (qs->session) {
> +MFXClose(qs->session);
> +qs->session = NULL;
> +}
> +#ifdef AVCODEC_QSV_LINUX_SESSION_HANDLE
> +if (qs->va_device_ctx) {
> +qs->va_device_ctx->free(qs->va_device_ctx);
> +}
> +#endif
> +return 0;
> +}
> diff --git a/libavcodec/qsv_internal.h b/libavcodec/qsv_internal.h index
> c50e9c792c..62885134b1 100644
> --- a/libavcodec/qsv_internal.h
> +++ b/libavcodec/qsv_internal.h
> @@ -21,6 +21,22 @@
> #ifndef AVCODEC_QSV_INTERNAL_H
> #define AVCODEC_QSV_INTERNAL_H
>
> +#if CONFIG_VAAPI
> +#define AVCODEC_QSV_LINUX_SESSION_HANDLE #endif //CONFIG_VAAPI
> +
> +#ifdef AVCODEC_QSV_LINUX_SESSION_HANDLE #include #include
> + #if HAVE_UNISTD_H #include #endif #include
> + #include #include #include
> +"libavutil/hwcontext_vaapi.h"
> +#endif
> +
> #include
>
> #include "libavutil/frame.h"
> @@ -64,6 +80,14 @@ typedef struct QSVFrame {
> struct QSVFrame *next;
> } QSVFrame;
>
> +typedef struct QSVSession {
> +mfxSession session;
> +#ifdef AVCODEC_QSV_LINUX_SESSION_HANDLE
> +AVBufferRef *va_device_ref;
> +AVHWDeviceContext *va_device_ctx;
> +#endif
> +} QSVSession;
> +
> typedef struct QSVFramesContext {
> AVBufferRef *hw_frames_ctx;
>
[FFmpeg-devel] [PATCH] avcodec/bsf: check that AVBSFInternal was allocated before dereferencing it
This can happen when av_bsf_free() is called on av_bsf_alloc() failure. Signed-off-by: James Almer --- libavcodec/bsf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavcodec/bsf.c b/libavcodec/bsf.c index 71915dea85..c1653cddb0 100644 --- a/libavcodec/bsf.c +++ b/libavcodec/bsf.c @@ -47,7 +47,8 @@ void av_bsf_free(AVBSFContext **pctx) av_opt_free(ctx); -av_packet_free(&ctx->internal->buffer_pkt); +if (ctx->internal) +av_packet_free(&ctx->internal->buffer_pkt); av_freep(&ctx->internal); av_freep(&ctx->priv_data); -- 2.22.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V3 1/2] avformat/dashdec: fix pointer being freed was not allocated
> 在 2019年9月20日，下午8:20，vectronic 写道： > > > >> On 16 Sep 2019, at 11:55, Liu Steven wrote: >> >> >> >>> 在 2019年9月16日，下午6:44，vectronic 写道： >>> >>> prevent attempt to call xmlFree if val was not allocated >>> >>> fixes: 8135 >>> Signed-off-by: vectronic >>> --- >>> libavformat/dashdec.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c >>> index 8c0a9b0102..738bfeaefb 100644 >>> --- a/libavformat/dashdec.c >>> +++ b/libavformat/dashdec.c >>> @@ -1203,6 +1203,7 @@ static int parse_programinformation(AVFormatContext >>> *s, xmlNodePtr node) >>> } >>> node = xmlNextElementSibling(node); >>> xmlFree(val); >>> +val = NULL; >>> } >>> return 0; >>> } >>> -- >>> 2.20.1 (Apple Git-117) >>> >>> ___ >>> 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". >> >> patchset LGTM >> Applied Thanks Steven ___ 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 v3] avcodec/dnxhdenc: return error if av_malloc failed
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/dnxhdenc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/dnxhdenc.c b/libavcodec/dnxhdenc.c
index 41b8079a09..c82c5d5140 100644
--- a/libavcodec/dnxhdenc.c
+++ b/libavcodec/dnxhdenc.c
@@ -542,6 +542,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
if (avctx->active_thread_type == FF_THREAD_SLICE) {
for (i = 1; i < avctx->thread_count; i++) {
ctx->thread[i] = av_malloc(sizeof(DNXHDEncContext));
+if (!ctx->thread[i])
+goto fail;
memcpy(ctx->thread[i], ctx, sizeof(DNXHDEncContext));
}
}
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] mp4 demuxer only set video stream start_time
Hi, Recently, I met a case of wrong audio duration when ffprobe a mp4 file use FFmpeg 4.0, but right in FFmpeg 4.1.3. In moov, the audio duration was right, the format duration (in mvhd) was wrong. But the probe output showed that the audio duration was set to the wrong format duration. I root cause this case and found out two patches can fix the problem: commit 28503c5aea5f5ecaab95e9d0c56064132e4796d3, This fix the problem of wrong duration caculation. [https://github.com/FFmpeg/FFmpeg/commit/28503c5aea5f5ecaab95e9d0c56064132e4796d3] commit 12673bb25342c772e1bf5fd2adebd85f97dc616e, This fix the problem of audio stream start_time not set. [https://github.com/FFmpeg/FFmpeg/commit/12673bb25342c772e1bf5fd2adebd85f97dc616e] The first patch was resonable while the second patch puzzed me a lot. Why I need this one? Because if the stream start_time is not set, it will be filled in avformat_find_stream_info() -> estimate_timings() -> fill_all_stream_timings() [libavformat/utils.c], AND at the same time, this function will replace the stream duration with the Format Duration, so stream start_time must be set so that I can get the right audio duration. I have two questions now: Why should fill_all_stream_timings() update stream duration when stream start_time is not set? In mp4 demuxer, codes related to stream start_time setting only used by video stream before patch 12673bb25342c772e1bf5fd2adebd85f97dc616e. Now in mov_build_index() still as it is, should this be fixed too? vacingf...@qq.com ___ 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 2/3] avfilter/x86/vf_eq: Change inline assembly into nasm code
> -Original Message- > From: ffmpeg-devel On Behalf Of Ting Fu > Sent: Wednesday, September 18, 2019 03:06 PM > To: ffmpeg-devel@ffmpeg.org > Subject: [FFmpeg-devel] [PATCH V2 2/3] avfilter/x86/vf_eq: Change inline > assembly into nasm code Ping? > > Signed-off-by: Ting Fu > --- > libavfilter/x86/Makefile | 3 +- > libavfilter/x86/vf_eq.asm| 82 ++ > libavfilter/x86/vf_eq.c | 96 > libavfilter/x86/vf_eq_init.c | 55 + > 4 files changed, 139 insertions(+), 97 deletions(-) create mode 100644 > libavfilter/x86/vf_eq.asm delete mode 100644 libavfilter/x86/vf_eq.c create > mode 100644 libavfilter/x86/vf_eq_init.c > [...] ___ 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 V1 1/6] lavf/4xm: fix memory leak in error handing path
On Sun, Sep 22, 2019 at 7:45 PM Michael Niedermayer
wrote:
>
> On Sat, Sep 21, 2019 at 10:12:10AM +0800, Jun Zhao wrote:
> > From: Jun Zhao
> >
> > need to free the header in error path
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavformat/4xm.c |1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/libavformat/4xm.c b/libavformat/4xm.c
> > index a984fc9..8054980 100644
> > --- a/libavformat/4xm.c
> > +++ b/libavformat/4xm.c
> > @@ -241,6 +241,7 @@ static int fourxm_read_header(AVFormatContext *s)
> > size = AV_RL32(&header[i + 4]);
> > if (size > header_size - i - 8 && (fourcc_tag == vtrk_TAG ||
> > fourcc_tag == strk_TAG)) {
> > av_log(s, AV_LOG_ERROR, "chunk larger than array %d>%d\n",
> > size, header_size - i - 8);
> > +av_free(header);
> > return AVERROR_INVALIDDATA;
>
> this doesnt free everything, a goto fail is probably better
>
> thx
Will update the patch as the review, Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
