Re: [FFmpeg-devel] [PATCH 1/2] avdevice/decklink_dec: mark the field flag if framerate > 30FPS
On Sat, Jul 18, 2020 at 08:38:16PM +0200, Marton Balint wrote:
>
>
> On Sat, 18 Jul 2020, lance.lmw...@gmail.com wrote:
>
> > On Sat, Jul 18, 2020 at 09:44:03AM +0200, Marton Balint wrote:
> > >
> > >
> > > On Sat, 18 Jul 2020, lance.lmw...@gmail.com wrote:
> > >
> > > > On Fri, Jul 17, 2020 at 07:13:28PM +0200, Marton Balint wrote:
> > > > > > > > > On Fri, 17 Jul 2020, lance.lmw...@gmail.com wrote:
> > > > > > > > From: Limin Wang
> > > > > > > In SMPTE ST 12-1: 2014 Sec 12.2, we need to mark the frame flag
> > > > > if the frame rate > 30FPS to
> > > > > > avoid interoperability issues. It will be used by the encoder to
> > > > > > identify even or odd frames
> > > > > > and correctly calculate the frame number of the SEI TC.
> > > > > > > This feature looks like it belongs to
> > > av_timecode_get_smpte_from_framenum
> > > > > and not into decklink. Also checking previous timecode and guessing
> > > > > something is a hack, especially since you have the exact source
> > > > > timecode.
> > > > If I understand correctly, it's not hacky, for the framerate > 30, the
> > > > source timecode will be
> > > > frame pair(it's limited by 2bits limit of frame number ten digital.
> > > > Below is one exmaple for 50fps
> > > > if you tested with SDI with TC.
> > > > 00:00:00:24
> > > > 00:00:00:24
> > > > 00:00:00:25
> > > > 00:00:00:25
> > > > 00:00:00:00
> > > > 00:00:00:00
> > >
> > > Have you actually tested this with a real SDI signal containing timecode?
> >
> > Yes, have tested with SDI playback by decklink UltraStudio 4K mini with TC
> > enabled.
>
> I still don't understand how this works. Isn't timecode in the SDI signal
> also contain the so called "field bit" flag to support 50fps timecode? And
> if it does, then why can't you query it from decklink? Timecode in SDI
> signal is also supposed to be an SMPTE 12M timecode, so all the bits you
> need should be in it, you should not need to guess anything. Therefore it
> makes little sense to me that the DeckLink API does not provide a proper
> timecode as string, unless the original capture you made with your
> UltraStudio and which you played back also has a faulty timecode.
> What generated the signal which you captured with UltraStudio? Not ffmpeg I
> hope...
It's auto-generated by configure of UltraStudio. I have tested with
bmdTimecodeFieldMark
flag, it's not set as expected for testing. I have no clue how to get the flag
as the API
provide the TC string is same for the frame pair. Maybe I miss something.
>
> Regards,
> Marton
>
>
> >
> > >
> > > Thanks,
> > > Marton
> > >
> > > > > That's why I check the last TC to get the frame is even or odd.
> > > > > Why not use av_timecode_get_smpte_from_framenum(), for it's
> > > calculated by the string TC by one time,
> > > > so it lacks the information whether it's odd or even frame.
> > > > > > > > Regards,
> > > > > Marton
> > > > > > > > > ---
> > > > > > libavdevice/decklink_common.h | 1 +
> > > > > > libavdevice/decklink_dec.cpp | 14 ++
> > > > > > 2 files changed, 15 insertions(+)
> > > > > > > diff --git a/libavdevice/decklink_common.h
> > > > > b/libavdevice/decklink_common.h
> > > > > > index bd68c7b..8ddc411 100644
> > > > > > --- a/libavdevice/decklink_common.h
> > > > > > +++ b/libavdevice/decklink_common.h
> > > > > > @@ -151,6 +151,7 @@ struct decklink_ctx {
> > > > > > int channels;
> > > > > > int audio_depth;
> > > > > > unsigned long tc_seen;// used with option wait_for_tc
> > > > > > +uint32_t last_tc;
> > > > > > };
> > > > > > > typedef enum { DIRECTION_IN, DIRECTION_OUT}
> > > > > decklink_direction_t;
> > > > > > diff --git a/libavdevice/decklink_dec.cpp
> > > > > > b/libavdevice/decklink_dec.cpp
> > > > > > index dde68ff..a60c01b 100644
> > > > > > --- a/libavdevice/decklink_dec.cpp
> > > > > > +++ b/libavdevice/decklink_dec.cpp
> > > > > > @@ -884,12 +884,26 @@ HRESULT
> > > > > > decklink_input_callback::VideoInputFrameArrived(
> > > > > > int metadata_len;
> > > > > > uint8_t* packed_metadata;
> > > > > > AVTimecode tcr;
> > > > > > +AVRational rate =
> > > > > > ctx->video_st->r_frame_rate;
> > > > > > > if (av_timecode_init_from_string(,
> > > > > ctx->video_st->r_frame_rate, tc, ctx) >= 0) {
> > > > > > uint32_t tc_data =
> > > > > > av_timecode_get_smpte_from_framenum(, 0);
> > > > > > int size = sizeof(uint32_t) * 4;
> > > > > > uint32_t *sd = (uint32_t
> > > > > > *)av_packet_new_side_data(, AV_PKT_DATA_S12M_TIMECODE, size);
> > > > > > > +/* set the field flag if frame rate
> > > > > > 30FPS */
> > > > > > +/* Refer to SMPTE ST 12-1:2014 Sec
> > > > > > 12.2 */
> > > > > > +if (av_cmp_q(rate, (AVRational) {30,
> > > > > > 1})
[FFmpeg-devel] [PATCH] avformat/hlsenc: increase initial program date time precision
Also query time only once, not for every variant stream, otherwise variant
streams might get a slightly different initial program date time. And we can
set this unconditionally because HLS_PROGRAM_DATE_TIME flag is checked
elsewhere.
Signed-off-by: Marton Balint
---
libavformat/hlsenc.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index df84e6487d..39ff1fa1e7 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2704,6 +2704,7 @@ static int hls_init(AVFormatContext *s)
char *p = NULL;
int http_base_proto = ff_is_http_proto(s->url);
int fmp4_init_filename_len = strlen(hls->fmp4_init_filename) + 1;
+double initial_program_date_time = av_gettime() / 100.0;
if (hls->use_localtime) {
pattern = get_default_pattern_localtime_fmt(s);
@@ -2798,12 +2799,7 @@ static int hls_init(AVFormatContext *s)
vs->start_pts = AV_NOPTS_VALUE;
vs->end_pts = AV_NOPTS_VALUE;
vs->current_segment_final_filename_fmt[0] = '\0';
-
-if (hls->flags & HLS_PROGRAM_DATE_TIME) {
-time_t now0;
-time();
-vs->initial_prog_date_time = now0;
-}
+vs->initial_prog_date_time = initial_program_date_time;
for (j = 0; j < vs->nb_streams; j++) {
vs->has_video += vs->streams[j]->codecpar->codec_type ==
AVMEDIA_TYPE_VIDEO;
--
2.26.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avcodec/diracdsp: Fix integer anomaly in dequant_subband_*
Fixes: negation of -2147483648 cannot be represented in type 'int32_t' (aka
'int'); cast to an unsigned type to negate this value to itself
Fixes:
23760/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-604209011412172
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/diracdsp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/diracdsp.c b/libavcodec/diracdsp.c
index 2dd56f83f3..4e08d3817e 100644
--- a/libavcodec/diracdsp.c
+++ b/libavcodec/diracdsp.c
@@ -198,9 +198,9 @@ static void dequant_subband_ ## PX ## _c(uint8_t *src,
uint8_t *dst, ptrdiff_t s
PX c, sign, *src_r = (PX *)src, *dst_r = (PX *)dst;
\
for (i = 0; i < tot_h; i++) {
\
c = *src_r++;
\
-sign = FFSIGN(c)*(!!c);
\
-c = (FFABS(c)*(unsigned)qf + qs) >> 2;
\
-*dst_r++ = c*sign;
\
+if (c < 0) c = -((-(unsigned)c*qf + qs) >> 2);
\
+else if(c > 0) c = (( (unsigned)c*qf + qs) >> 2);
\
+*dst_r++ = c;
\
}
\
src += tot_h << (sizeof(PX) >> 1);
\
dst += stride;
\
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] tools/target_dec_fuzzer: Adjust VQA threshold
Fixes: Timeout (169sec -> 9sec)
Fixes:
23745/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VQA_fuzzer-5638172179693568
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index 1ecafb9c0c..8bc1b9b87b 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -179,6 +179,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
case AV_CODEC_ID_TRUEMOTION2: maxpixels /= 1024; break;
case AV_CODEC_ID_VP7: maxpixels /= 256; break;
case AV_CODEC_ID_VP9: maxpixels /= 4096; break;
+case AV_CODEC_ID_WS_VQA: maxpixels /= 16384; break;
case AV_CODEC_ID_ZEROCODEC: maxpixels /= 128; break;
}
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] fftools/ffmpeg: make specifying thread_queue_size turn on threaded input
Threaded input can increase smoothness of e.g. x11grab significantly. Before
this patch, in order to activate threaded input the user had to specify a
"dummy" additional input, with this change it is no longer required.
Signed-off-by: Marton Balint
---
doc/ffmpeg.texi | 5 +++--
fftools/ffmpeg.c | 6 --
fftools/ffmpeg_opt.c | 3 ++-
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 70b8965d7f..267ddfe8b5 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1689,8 +1689,9 @@ not start from timestamp 0, such as transport streams.
@item -thread_queue_size @var{size} (@emph{input})
This option sets the maximum number of queued packets when reading from the
file or device. With low latency / high rate live streams, packets may be
-discarded if they are not read in a timely manner; raising this value can
-avoid it.
+discarded if they are not read in a timely manner; setting this value can
+force ffmpeg to use a separate input thread and read packets as soon as they
+arrive. By default ffmpeg only do this if multiple inputs are specified.
@item -sdp_file @var{file} (@emph{global})
Print sdp information for an output stream to @var{file}.
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 2e9448ea2b..173ac3c9a0 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -4051,7 +4051,9 @@ static int init_input_thread(int i)
int ret;
InputFile *f = input_files[i];
-if (nb_input_files == 1)
+if (f->thread_queue_size < 0)
+f->thread_queue_size = (nb_input_files > 1 ? 8 : 0);
+if (!f->thread_queue_size)
return 0;
if (f->ctx->pb ? !f->ctx->pb->seekable :
@@ -4105,7 +4107,7 @@ static int get_input_packet(InputFile *f, AVPacket *pkt)
}
#if HAVE_THREADS
-if (nb_input_files > 1)
+if (f->thread_queue_size)
return get_input_packet_mt(f, pkt);
#endif
return av_read_frame(f->ctx, pkt);
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 9d1489ce01..853550a142 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -228,6 +228,7 @@ static void init_options(OptionsContext *o)
o->limit_filesize = UINT64_MAX;
o->chapters_input_file = INT_MAX;
o->accurate_seek = 1;
+o->thread_queue_size = -1;
}
static int show_hwaccels(void *optctx, const char *opt, const char *arg)
@@ -1270,7 +1271,7 @@ static int open_input_file(OptionsContext *o, const char
*filename)
f->duration = 0;
f->time_base = (AVRational){ 1, 1 };
#if HAVE_THREADS
-f->thread_queue_size = o->thread_queue_size > 0 ? o->thread_queue_size : 8;
+f->thread_queue_size = o->thread_queue_size;
#endif
/* check if all codec options have been used */
--
2.26.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC PATCH] libavcodec/libopenjpeg: pix fmt selection change
Am Di., 9. Juni 2020 um 20:25 Uhr schrieb Carl Eugen Hoyos : > > Am Di., 9. Juni 2020 um 19:12 Uhr schrieb Gautam Ramakrishnan > : > > > > On Tue, Jun 9, 2020 at 10:24 PM Carl Eugen Hoyos wrote: > > > > > > Am Di., 9. Juni 2020 um 14:07 Uhr schrieb : > > > > > > > > From: Gautam Ramakrishnan > > > > > > > > This patch makes selection of pix_fmt similar to > > > > that in the native decoder. This makes samples such > > > > as p0_05.j2k and p1_03.j2k decodable by libopenjpeg. > > > > > > Since both files are not YUVA420P, I am not sure if this > > > patch is a good idea, in any case, the commit message > > > mentioning the two files as reasons for this patch is wrong. > > > > > I am not sure what file format this is then. > > I failed to find out so far, possibly Bayer, CMYK seems less > likely to me. I believe it is YCCK, two components (CC, if I am right) are subsampled. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avdevice/decklink_dec: mark the field flag if framerate > 30FPS
On Sat, 18 Jul 2020, lance.lmw...@gmail.com wrote:
On Sat, Jul 18, 2020 at 09:44:03AM +0200, Marton Balint wrote:
On Sat, 18 Jul 2020, lance.lmw...@gmail.com wrote:
> On Fri, Jul 17, 2020 at 07:13:28PM +0200, Marton Balint wrote:
> >
> >
> > On Fri, 17 Jul 2020, lance.lmw...@gmail.com wrote:
> >
> > > From: Limin Wang
> > > > In SMPTE ST 12-1: 2014 Sec 12.2, we need to mark the frame flag
> > if the frame rate > 30FPS to
> > > avoid interoperability issues. It will be used by the encoder to identify
even or odd frames
> > > and correctly calculate the frame number of the SEI TC.
> >
> > This feature looks like it belongs to av_timecode_get_smpte_from_framenum
> > and not into decklink. Also checking previous timecode and guessing
> > something is a hack, especially since you have the exact source timecode.
> If I understand correctly, it's not hacky, for the framerate > 30, the source
timecode will be
> frame pair(it's limited by 2bits limit of frame number ten digital. Below is
one exmaple for 50fps
> if you tested with SDI with TC.
> 00:00:00:24
> 00:00:00:24
> 00:00:00:25
> 00:00:00:25
> 00:00:00:00
> 00:00:00:00
Have you actually tested this with a real SDI signal containing timecode?
Yes, have tested with SDI playback by decklink UltraStudio 4K mini with TC
enabled.
I still don't understand how this works. Isn't timecode in the SDI signal
also contain the so called "field bit" flag to support 50fps timecode? And
if it does, then why can't you query it from decklink? Timecode in SDI
signal is also supposed to be an SMPTE 12M timecode, so all the bits you
need should be in it, you should not need to guess anything. Therefore it
makes little sense to me that the DeckLink API does not provide a proper
timecode as string, unless the original capture you made with your
UltraStudio and which you played back also has a faulty timecode.
What generated the signal which you captured with UltraStudio? Not ffmpeg
I hope...
Regards,
Marton
Thanks,
Marton
>
> That's why I check the last TC to get the frame is even or odd.
>
> Why not use av_timecode_get_smpte_from_framenum(), for it's calculated by the string TC by one time,
> so it lacks the information whether it's odd or even frame.
>
> >
> > Regards,
> > Marton
> >
> > > > ---
> > > libavdevice/decklink_common.h | 1 +
> > > libavdevice/decklink_dec.cpp | 14 ++
> > > 2 files changed, 15 insertions(+)
> > > > diff --git a/libavdevice/decklink_common.h
> > b/libavdevice/decklink_common.h
> > > index bd68c7b..8ddc411 100644
> > > --- a/libavdevice/decklink_common.h
> > > +++ b/libavdevice/decklink_common.h
> > > @@ -151,6 +151,7 @@ struct decklink_ctx {
> > > int channels;
> > > int audio_depth;
> > > unsigned long tc_seen;// used with option wait_for_tc
> > > +uint32_t last_tc;
> > > };
> > > > typedef enum { DIRECTION_IN, DIRECTION_OUT}
> > decklink_direction_t;
> > > diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
> > > index dde68ff..a60c01b 100644
> > > --- a/libavdevice/decklink_dec.cpp
> > > +++ b/libavdevice/decklink_dec.cpp
> > > @@ -884,12 +884,26 @@ HRESULT
decklink_input_callback::VideoInputFrameArrived(
> > > int metadata_len;
> > > uint8_t* packed_metadata;
> > > AVTimecode tcr;
> > > +AVRational rate = ctx->video_st->r_frame_rate;
> > > > if (av_timecode_init_from_string(,
> > ctx->video_st->r_frame_rate, tc, ctx) >= 0) {
> > > uint32_t tc_data =
av_timecode_get_smpte_from_framenum(, 0);
> > > int size = sizeof(uint32_t) * 4;
> > > uint32_t *sd = (uint32_t
*)av_packet_new_side_data(, AV_PKT_DATA_S12M_TIMECODE, size);
> > > > +/* set the field flag if frame rate
> > > 30FPS */
> > > +/* Refer to SMPTE ST 12-1:2014 Sec 12.2 */
> > > +if (av_cmp_q(rate, (AVRational) {30, 1}) ==
1) {
> > > +/* Odd frame */
> > > +if (ctx->last_tc == tc_data) {
> > > +if (av_cmp_q(rate, (AVRational) {50,
1}) == 0)
> > > +tc_data |= (1 << 7);
> > > +else
> > > +tc_data |= (1 << 23);
> > > +}
> > > +}
> > > +ctx->last_tc = tc_data;
> > > +
> > > if (sd) {
> > > *sd = 1; // one TC
> > > *(sd + 1) = tc_data; // TC
> > > -- > 2.9.4
> > > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > >
Re: [FFmpeg-devel] [PATCH] avformat/hls: add supporting EXT-X-DISCONTINUITY tag
Greetings!
unconditional AVFMT_TS_DISCONT also helps to survive when pts rollover in
mpegts occurs.
seems like this patch will break again reading long-lasting hls.
--
Aleksey Skripka
> On 17 Jul 2020, at 04:09, Dongwon Kim wrote:
>
> I modified setting AVFMT_TS_DISCONT flag on HLS input format depending on
> whether "EXT-X-DISCONTINUITY" existed or not in M3U8.
> previous, commits are set "AVFMT_TS_DISCONT" flag unconditionally, whether
> "EXT-X-DISCONTINUITY" existed or not, as below
> https://github.com/FFmpeg/FFmpeg/commit/d6ac6650b911f0957e69545d7fc25be6b7728705#diff-0e876d29bdcae30d9d256f04bc8795db
>
> So, I added checking and parsing "EXT-X-DISCONTINUITY" syntax, and if only it
> exists then set AVFMT_TS_DISCONT flag.
>
>
> On Fri, Jul 17, 2020 at 12:43:05AM +, Dongwon Kim wrote:
>> Signed-off-by: Dongwon Kim
>> ---
>> libavformat/hls.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavformat/hls.c b/libavformat/hls.c index
>> ba17c4ed96..5e331ab68f 100644
>> --- a/libavformat/hls.c
>> +++ b/libavformat/hls.c
>> @@ -810,6 +810,8 @@ static int parse_playlist(HLSContext *c, const char *url,
>> ff_parse_key_value(ptr, (ff_parse_key_val_cb)
>> handle_rendition_args,
>>);
>> new_rendition(c, , url);
>> +} else if (av_strstart(line, "#EXT-X-DISCONTINUITY", )) {
>> +c->ctx->iformat->flags |= AVFMT_TS_DISCONT;
>> } else if (av_strstart(line, "#EXT-X-TARGETDURATION:", )) {
>> ret = ensure_playlist(c, , url);
>> if (ret < 0)
>> @@ -2406,7 +2408,7 @@ AVInputFormat ff_hls_demuxer = {
>> .long_name = NULL_IF_CONFIG_SMALL("Apple HTTP Live Streaming"),
>> .priv_class = _class,
>> .priv_data_size = sizeof(HLSContext),
>> -.flags = AVFMT_NOGENSEARCH | AVFMT_TS_DISCONT,
>> +.flags = AVFMT_NOGENSEARCH,
>> .read_probe = hls_probe,
>> .read_header= hls_read_header,
>> .read_packet= hls_read_packet,
>> --
>> 2.25.1
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avfilter: add radial and circular blur video filter
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 46
libavfilter/Makefile | 2 +
libavfilter/allfilters.c | 2 +
libavfilter/vf_rblur.c | 560 +++
4 files changed, 610 insertions(+)
create mode 100644 libavfilter/vf_rblur.c
diff --git a/doc/filters.texi b/doc/filters.texi
index a2c31ff610..62705db984 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -7231,6 +7231,29 @@ Set planes to filter. Default value is to filter all
planes except alpha plane.
@end table
+@section cblur
+Apply a circular blur filter.
+
+The filter accepts the following options:
+
+@table @option
+@item centerx, centery
+Set central point position of circular blur. Default is @code{0.5}.
+
+@item amount
+Set amount of circular blur. Default is @code{0.03}.
+
+@item planes
+Set which planes to filter. By default all planes are filtered.
+@end table
+
+@subsection Commands
+This filter supports same @ref{commands} as options.
+The command accepts the same syntax of the corresponding option.
+
+If the specified expression is not valid, it is kept at its current
+value.
+
@section chromahold
Remove all color information for all colors except for certain one.
@@ -15768,6 +15791,29 @@ less than @code{0}, the filter will try to use a good
random seed on a
best effort basis.
@end table
+@section rblur
+Apply a radial blur filter.
+
+The filter accepts the following options:
+
+@table @option
+@item centerx, centery
+Set central point position of radial blur. Default is @code{0.5}.
+
+@item amount
+Set amount of radial blur. Default is @code{0.03}.
+
+@item planes
+Set which planes to filter. By default all planes are filtered.
+@end table
+
+@subsection Commands
+This filter supports same @ref{commands} as options.
+The command accepts the same syntax of the corresponding option.
+
+If the specified expression is not valid, it is kept at its current
+value.
+
@section readeia608
Read closed captioning (EIA-608) information from the top lines of a video
frame.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 33dcc69392..30f2abf9e2 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -180,6 +180,7 @@ OBJS-$(CONFIG_BOXBLUR_OPENCL_FILTER) +=
vf_avgblur_opencl.o opencl.o \
opencl/avgblur.o boxblur.o
OBJS-$(CONFIG_BWDIF_FILTER) += vf_bwdif.o yadif_common.o
OBJS-$(CONFIG_CAS_FILTER)+= vf_cas.o
+OBJS-$(CONFIG_CBLUR_FILTER) += vf_rblur.o
OBJS-$(CONFIG_CHROMABER_VULKAN_FILTER) += vf_chromaber_vulkan.o vulkan.o
OBJS-$(CONFIG_CHROMAHOLD_FILTER) += vf_chromakey.o
OBJS-$(CONFIG_CHROMAKEY_FILTER) += vf_chromakey.o
@@ -358,6 +359,7 @@ OBJS-$(CONFIG_PSNR_FILTER) += vf_psnr.o
framesync.o
OBJS-$(CONFIG_PULLUP_FILTER) += vf_pullup.o
OBJS-$(CONFIG_QP_FILTER) += vf_qp.o
OBJS-$(CONFIG_RANDOM_FILTER) += vf_random.o
+OBJS-$(CONFIG_RBLUR_FILTER) += vf_rblur.o
OBJS-$(CONFIG_READEIA608_FILTER) += vf_readeia608.o
OBJS-$(CONFIG_READVITC_FILTER) += vf_readvitc.o
OBJS-$(CONFIG_REALTIME_FILTER) += f_realtime.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index b896a76c9e..38279a44eb 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -171,6 +171,7 @@ extern AVFilter ff_vf_boxblur;
extern AVFilter ff_vf_boxblur_opencl;
extern AVFilter ff_vf_bwdif;
extern AVFilter ff_vf_cas;
+extern AVFilter ff_vf_cblur;
extern AVFilter ff_vf_chromahold;
extern AVFilter ff_vf_chromakey;
extern AVFilter ff_vf_chromanr;
@@ -341,6 +342,7 @@ extern AVFilter ff_vf_psnr;
extern AVFilter ff_vf_pullup;
extern AVFilter ff_vf_qp;
extern AVFilter ff_vf_random;
+extern AVFilter ff_vf_rblur;
extern AVFilter ff_vf_readeia608;
extern AVFilter ff_vf_readvitc;
extern AVFilter ff_vf_realtime;
diff --git a/libavfilter/vf_rblur.c b/libavfilter/vf_rblur.c
new file mode 100644
index 00..080224bcf7
--- /dev/null
+++ b/libavfilter/vf_rblur.c
@@ -0,0 +1,560 @@
+/*
+ * Copyright (c) 2020 Paul B Mahol
+ *
+ * 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
+ */
+
[FFmpeg-devel] [PATCH v6 2/6] libavutils: Add parse_r helper for MIPS
That helper grab from kernel code can allow us to inline
newer instructions (not implemented by the assembler) in
a elegant manner.
Signed-off-by: Jiaxun Yang
---
libavutil/mips/asmdefs.h | 42
1 file changed, 42 insertions(+)
diff --git a/libavutil/mips/asmdefs.h b/libavutil/mips/asmdefs.h
index 748119918a..7e0e4cf575 100644
--- a/libavutil/mips/asmdefs.h
+++ b/libavutil/mips/asmdefs.h
@@ -55,4 +55,46 @@
# define PTR_SLL"sll "
#endif
+/*
+ * parse_r var, r - Helper assembler macro for parsing register names.
+ *
+ * This converts the register name in $n form provided in \r to the
+ * corresponding register number, which is assigned to the variable \var. It is
+ * needed to allow explicit encoding of instructions in inline assembly where
+ * registers are chosen by the compiler in $n form, allowing us to avoid using
+ * fixed register numbers.
+ *
+ * It also allows newer instructions (not implemented by the assembler) to be
+ * transparently implemented using assembler macros, instead of needing
separate
+ * cases depending on toolchain support.
+ *
+ * Simple usage example:
+ * __asm__ __volatile__("parse_r __rt, %0\n\t"
+ * ".insn\n\t"
+ * "# di%0\n\t"
+ * ".word (0x41606000 | (__rt << 16))"
+ * : "=r" (status);
+ */
+
+/* Match an individual register number and assign to \var */
+#define _IFC_REG(n)\
+ ".ifc \\r, $" #n "\n\t" \
+ "\\var = " #n "\n\t" \
+ ".endif\n\t"
+
+__asm__(".macroparse_r var r\n\t"
+ "\\var = -1\n\t"
+ _IFC_REG(0) _IFC_REG(1) _IFC_REG(2) _IFC_REG(3)
+ _IFC_REG(4) _IFC_REG(5) _IFC_REG(6) _IFC_REG(7)
+ _IFC_REG(8) _IFC_REG(9) _IFC_REG(10) _IFC_REG(11)
+ _IFC_REG(12) _IFC_REG(13) _IFC_REG(14) _IFC_REG(15)
+ _IFC_REG(16) _IFC_REG(17) _IFC_REG(18) _IFC_REG(19)
+ _IFC_REG(20) _IFC_REG(21) _IFC_REG(22) _IFC_REG(23)
+ _IFC_REG(24) _IFC_REG(25) _IFC_REG(26) _IFC_REG(27)
+ _IFC_REG(28) _IFC_REG(29) _IFC_REG(30) _IFC_REG(31)
+ ".iflt \\var\n\t"
+ ".error \"Unable to parse register name \\r\"\n\t"
+ ".endif\n\t"
+ ".endm");
+
#endif /* AVCODEC_MIPS_ASMDEFS_H */
--
2.27.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] [PATCH v6 5/6] libavcodec: MIPS: MMI: Fix type mismatches
GCC complains about them.
Signed-off-by: Jiaxun Yang
---
libavcodec/mips/h264dsp_mips.h | 18 +-
libavcodec/mips/h264dsp_mmi.c | 18 +-
libavcodec/mips/xvid_idct_mmi.c | 4 ++--
libavcodec/mips/xvididct_mips.h | 4 ++--
4 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/libavcodec/mips/h264dsp_mips.h b/libavcodec/mips/h264dsp_mips.h
index 21b7de06f0..7b2a9fabe5 100644
--- a/libavcodec/mips/h264dsp_mips.h
+++ b/libavcodec/mips/h264dsp_mips.h
@@ -357,23 +357,23 @@ void ff_h264_biweight_pixels4_8_mmi(uint8_t *dst, uint8_t
*src,
void ff_deblock_v_chroma_8_mmi(uint8_t *pix, ptrdiff_t stride, int alpha, int
beta,
int8_t *tc0);
-void ff_deblock_v_chroma_intra_8_mmi(uint8_t *pix, int stride, int alpha,
+void ff_deblock_v_chroma_intra_8_mmi(uint8_t *pix, ptrdiff_t stride, int alpha,
int beta);
-void ff_deblock_h_chroma_8_mmi(uint8_t *pix, int stride, int alpha, int beta,
+void ff_deblock_h_chroma_8_mmi(uint8_t *pix, ptrdiff_t stride, int alpha, int
beta,
int8_t *tc0);
-void ff_deblock_h_chroma_intra_8_mmi(uint8_t *pix, int stride, int alpha,
+void ff_deblock_h_chroma_intra_8_mmi(uint8_t *pix, ptrdiff_t stride, int alpha,
int beta);
-void ff_deblock_v_luma_8_mmi(uint8_t *pix, int stride, int alpha, int beta,
+void ff_deblock_v_luma_8_mmi(uint8_t *pix, ptrdiff_t stride, int alpha, int
beta,
int8_t *tc0);
-void ff_deblock_v_luma_intra_8_mmi(uint8_t *pix, int stride, int alpha,
+void ff_deblock_v_luma_intra_8_mmi(uint8_t *pix, ptrdiff_t stride, int alpha,
int beta);
-void ff_deblock_h_luma_8_mmi(uint8_t *pix, int stride, int alpha, int beta,
+void ff_deblock_h_luma_8_mmi(uint8_t *pix, ptrdiff_t stride, int alpha, int
beta,
int8_t *tc0);
-void ff_deblock_h_luma_intra_8_mmi(uint8_t *pix, int stride, int alpha,
+void ff_deblock_h_luma_intra_8_mmi(uint8_t *pix, ptrdiff_t stride, int alpha,
int beta);
-void ff_deblock_v8_luma_8_mmi(uint8_t *pix, int stride, int alpha, int beta,
+void ff_deblock_v8_luma_8_mmi(uint8_t *pix, ptrdiff_t stride, int alpha, int
beta,
int8_t *tc0);
-void ff_deblock_v8_luma_intra_8_mmi(uint8_t *pix, int stride, int alpha,
+void ff_deblock_v8_luma_intra_8_mmi(uint8_t *pix, ptrdiff_t stride, int alpha,
int beta);
void ff_put_h264_qpel16_mc00_mmi(uint8_t *dst, const uint8_t *src,
diff --git a/libavcodec/mips/h264dsp_mmi.c b/libavcodec/mips/h264dsp_mmi.c
index 0459711b82..d3bd472599 100644
--- a/libavcodec/mips/h264dsp_mmi.c
+++ b/libavcodec/mips/h264dsp_mmi.c
@@ -1433,7 +1433,7 @@ void ff_h264_biweight_pixels4_8_mmi(uint8_t *dst, uint8_t
*src,
}
}
-void ff_deblock_v8_luma_8_mmi(uint8_t *pix, int stride, int alpha, int beta,
+void ff_deblock_v8_luma_8_mmi(uint8_t *pix, ptrdiff_t stride, int alpha, int
beta,
int8_t *tc0)
{
double ftmp[12];
@@ -1561,7 +1561,7 @@ void ff_deblock_v8_luma_8_mmi(uint8_t *pix, int stride,
int alpha, int beta,
);
}
-static void deblock_v8_luma_intra_8_mmi(uint8_t *pix, int stride, int alpha,
+static void deblock_v8_luma_intra_8_mmi(uint8_t *pix, ptrdiff_t stride, int
alpha,
int beta)
{
DECLARE_ALIGNED(8, const uint64_t, stack[0x0a]);
@@ -1871,7 +1871,7 @@ void ff_deblock_v_chroma_8_mmi(uint8_t *pix, ptrdiff_t
stride, int alpha,
);
}
-void ff_deblock_v_chroma_intra_8_mmi(uint8_t *pix, int stride, int alpha,
+void ff_deblock_v_chroma_intra_8_mmi(uint8_t *pix, ptrdiff_t stride, int alpha,
int beta)
{
double ftmp[9];
@@ -1949,7 +1949,7 @@ void ff_deblock_v_chroma_intra_8_mmi(uint8_t *pix, int
stride, int alpha,
);
}
-void ff_deblock_h_chroma_8_mmi(uint8_t *pix, int stride, int alpha, int beta,
+void ff_deblock_h_chroma_8_mmi(uint8_t *pix, ptrdiff_t stride, int alpha, int
beta,
int8_t *tc0)
{
double ftmp[11];
@@ -2089,7 +2089,7 @@ void ff_deblock_h_chroma_8_mmi(uint8_t *pix, int stride,
int alpha, int beta,
);
}
-void ff_deblock_h_chroma_intra_8_mmi(uint8_t *pix, int stride, int alpha,
+void ff_deblock_h_chroma_intra_8_mmi(uint8_t *pix, ptrdiff_t stride, int alpha,
int beta)
{
double ftmp[11];
@@ -,7 +,7 @@ void ff_deblock_h_chroma_intra_8_mmi(uint8_t *pix, int
stride, int alpha,
);
}
-void ff_deblock_v_luma_8_mmi(uint8_t *pix, int stride, int alpha, int beta,
+void ff_deblock_v_luma_8_mmi(uint8_t *pix, ptrdiff_t stride, int alpha, int
beta,
int8_t *tc0)
{
if ((tc0[0] & tc0[1]) >= 0)
@@ -2231,14 +2231,14 @@ void ff_deblock_v_luma_8_mmi(uint8_t *pix, int stride,
int alpha, int beta,
ff_deblock_v8_luma_8_mmi(pix + 8, stride, alpha, beta, tc0 + 2);
}
-void ff_deblock_v_luma_intra_8_mmi(uint8_t *pix, int stride, int alpha,
+void ff_deblock_v_luma_intra_8_mmi(uint8_t *pix, ptrdiff_t stride, int alpha,
int beta)
{
deblock_v8_luma_intra_8_mmi(pix + 0, stride, alpha, beta);
deblock_v8_luma_intra_8_mmi(pix + 8, stride, alpha, beta);
}
-void
[FFmpeg-devel] [PATCH v6 6/6] libavcodec: MIPS: MMI: Move sp out of the clobber list
GCC complains: warning: listing the stack pointer register ‘$29’ in a clobber list is deprecated [-Wdeprecated] Actually stack pointer was restored at the end of the inline assembly so there is no reason to add it to the clobber list. Also use $sp insted of $29 to make our intention much more clear. Signed-off-by: Jiaxun Yang --- libavcodec/mips/h264dsp_mmi.c | 38 +-- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/libavcodec/mips/h264dsp_mmi.c b/libavcodec/mips/h264dsp_mmi.c index d3bd472599..173e191c77 100644 --- a/libavcodec/mips/h264dsp_mmi.c +++ b/libavcodec/mips/h264dsp_mmi.c @@ -177,7 +177,7 @@ void ff_h264_idct8_add_8_mmi(uint8_t *dst, int16_t *block, int stride) __asm__ volatile ( "lhu%[tmp0],0x00(%[block]) \n\t" -PTR_ADDI "$29,$29,-0x20 \n\t" +PTR_ADDI "$sp,$sp,-0x20 \n\t" PTR_ADDIU "%[tmp0],%[tmp0],0x20\n\t" MMI_LDC1(%[ftmp1], %[block], 0x10) "sh %[tmp0],0x00(%[block]) \n\t" @@ -254,8 +254,8 @@ void ff_h264_idct8_add_8_mmi(uint8_t *dst, int16_t *block, int stride) "punpckhwd %[ftmp3], %[ftmp6], %[ftmp0]\n\t" "punpcklwd %[ftmp6], %[ftmp6], %[ftmp0]\n\t" MMI_LDC1(%[ftmp0], %[block], 0x00) -MMI_SDC1(%[ftmp7], $29, 0x00) -MMI_SDC1(%[ftmp1], $29, 0x10) +MMI_SDC1(%[ftmp7], $sp, 0x00) +MMI_SDC1(%[ftmp1], $sp, 0x10) "dmfc1 %[tmp1],%[ftmp6]\n\t" "dmfc1 %[tmp3],%[ftmp3]\n\t" "punpckhhw %[ftmp3], %[ftmp5], %[ftmp2]\n\t" @@ -266,8 +266,8 @@ void ff_h264_idct8_add_8_mmi(uint8_t *dst, int16_t *block, int stride) "punpcklwd %[ftmp5], %[ftmp5], %[ftmp4]\n\t" "punpckhwd %[ftmp4], %[ftmp3], %[ftmp2]\n\t" "punpcklwd %[ftmp3], %[ftmp3], %[ftmp2]\n\t" -MMI_SDC1(%[ftmp5], $29, 0x08) -MMI_SDC1(%[ftmp0], $29, 0x18) +MMI_SDC1(%[ftmp5], $sp, 0x08) +MMI_SDC1(%[ftmp0], $sp, 0x18) "dmfc1 %[tmp2],%[ftmp3]\n\t" "dmfc1 %[tmp4],%[ftmp4]\n\t" MMI_LDC1(%[ftmp1], %[block], 0x18) @@ -359,7 +359,7 @@ void ff_h264_idct8_add_8_mmi(uint8_t *dst, int16_t *block, int stride) PTR_ADDIU "%[addr0], %[dst], 0x04\n\t" "mov.d %[ftmp7], %[ftmp10] \n\t" "dmtc1 %[tmp3],%[ftmp6]\n\t" -MMI_LDC1(%[ftmp1], $29, 0x10) +MMI_LDC1(%[ftmp1], $sp, 0x10) "dmtc1 %[tmp1],%[ftmp3]\n\t" "mov.d %[ftmp4], %[ftmp1]\n\t" "psrah %[ftmp1], %[ftmp1], %[ftmp8]\n\t" @@ -392,7 +392,7 @@ void ff_h264_idct8_add_8_mmi(uint8_t *dst, int16_t *block, int stride) "psrah %[ftmp0], %[ftmp3], %[ftmp8]\n\t" "paddh %[ftmp2], %[ftmp2], %[ftmp3]\n\t" "psubh %[ftmp0], %[ftmp0], %[ftmp7]\n\t" -MMI_LDC1(%[ftmp3], $29, 0x00) +MMI_LDC1(%[ftmp3], $sp, 0x00) "dmtc1 %[tmp5],%[ftmp7]\n\t" "paddh %[ftmp7], %[ftmp7], %[ftmp3]\n\t" "paddh %[ftmp3], %[ftmp3], %[ftmp3]\n\t" @@ -414,9 +414,9 @@ void ff_h264_idct8_add_8_mmi(uint8_t *dst, int16_t *block, int stride) "paddh %[ftmp1], %[ftmp1], %[ftmp7]\n\t" "psubh %[ftmp3], %[ftmp3], %[ftmp6]\n\t" "paddh %[ftmp7], %[ftmp7], %[ftmp7]\n\t" -MMI_SDC1(%[ftmp3], $29, 0x00) +MMI_SDC1(%[ftmp3], $sp, 0x00) "psubh %[ftmp7], %[ftmp7], %[ftmp1]\n\t" -MMI_SDC1(%[ftmp0], $29, 0x10) +MMI_SDC1(%[ftmp0], $sp, 0x10) "dmfc1 %[tmp1],%[ftmp2]\n\t" "xor%[ftmp2], %[ftmp2], %[ftmp2]\n\t" MMI_SDC1(%[ftmp2], %[block], 0x00) @@ -463,8 +463,8 @@ void ff_h264_idct8_add_8_mmi(uint8_t *dst, int16_t *block, int stride) "packushb %[ftmp0], %[ftmp0], %[ftmp2]\n\t" MMI_SWC1(%[ftmp3], %[dst], 0x00) MMI_SWXC1(%[ftmp0], %[dst], %[stride], 0x00) -MMI_LDC1(%[ftmp5], $29, 0x00) -MMI_LDC1(%[ftmp4], $29, 0x10) +
[FFmpeg-devel] [PATCH v6 3/6] libavutil: Detect MMI and MSA flags for MIPS
Add MMI & MSA runtime detection for MIPS.
Basically there are two code pathes. For systems that
natively support CPUCFG instruction or kernel emulated
that instruction, we'll sense this feature from HWCAP and
report the flags according to values grab from CPUCFG. For
systems that have no CPUCFG (or not export it in HWCAP),
we'll parse /proc/cpuinfo instead.
Signed-off-by: Jiaxun Yang
--
v5: Fix a stupid typo
---
libavutil/cpu.c | 10 +++
libavutil/cpu.h | 3 +
libavutil/cpu_internal.h | 2 +
libavutil/mips/Makefile | 2 +-
libavutil/mips/cpu.c | 134 ++
libavutil/mips/cpu.h | 28
libavutil/tests/cpu.c | 3 +
tests/checkasm/checkasm.c | 3 +
8 files changed, 184 insertions(+), 1 deletion(-)
create mode 100644 libavutil/mips/cpu.c
create mode 100644 libavutil/mips/cpu.h
diff --git a/libavutil/cpu.c b/libavutil/cpu.c
index 6548cc3042..52f6b9a3bf 100644
--- a/libavutil/cpu.c
+++ b/libavutil/cpu.c
@@ -51,6 +51,8 @@ static atomic_int cpu_flags = ATOMIC_VAR_INIT(-1);
static int get_cpu_flags(void)
{
+if (ARCH_MIPS)
+return ff_get_cpu_flags_mips();
if (ARCH_AARCH64)
return ff_get_cpu_flags_aarch64();
if (ARCH_ARM)
@@ -169,6 +171,9 @@ int av_parse_cpu_flags(const char *s)
{ "armv8",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_ARMV8
},.unit = "flags" },
{ "neon", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_NEON
},.unit = "flags" },
{ "vfp", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_VFP
},.unit = "flags" },
+#elif ARCH_MIPS
+{ "mmi", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_MMI
},.unit = "flags" },
+{ "msa", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_MSA
},.unit = "flags" },
#endif
{ NULL },
};
@@ -250,6 +255,9 @@ int av_parse_cpu_caps(unsigned *flags, const char *s)
{ "armv8",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_ARMV8
},.unit = "flags" },
{ "neon", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_NEON
},.unit = "flags" },
{ "vfp", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_VFP
},.unit = "flags" },
+#elif ARCH_MIPS
+{ "mmi", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_MMI
},.unit = "flags" },
+{ "msa", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_MSA
},.unit = "flags" },
#endif
{ NULL },
};
@@ -308,6 +316,8 @@ int av_cpu_count(void)
size_t av_cpu_max_align(void)
{
+if (ARCH_MIPS)
+return ff_get_cpu_max_align_mips();
if (ARCH_AARCH64)
return ff_get_cpu_max_align_aarch64();
if (ARCH_ARM)
diff --git a/libavutil/cpu.h b/libavutil/cpu.h
index 8bb9eb606b..83099dd969 100644
--- a/libavutil/cpu.h
+++ b/libavutil/cpu.h
@@ -71,6 +71,9 @@
#define AV_CPU_FLAG_VFP_VM (1 << 7) ///< VFPv2 vector mode, deprecated
in ARMv7-A and unavailable in various CPUs implementations
#define AV_CPU_FLAG_SETEND (1 <<16)
+#define AV_CPU_FLAG_MMI (1 << 0)
+#define AV_CPU_FLAG_MSA (1 << 1)
+
/**
* Return the flags which specify extensions supported by the CPU.
* The returned value is affected by av_force_cpu_flags() if that was used
diff --git a/libavutil/cpu_internal.h b/libavutil/cpu_internal.h
index 37122d1c5f..889764320b 100644
--- a/libavutil/cpu_internal.h
+++ b/libavutil/cpu_internal.h
@@ -41,11 +41,13 @@
#define CPUEXT_FAST(flags, cpuext) CPUEXT_SUFFIX_FAST(flags, , cpuext)
#define CPUEXT_SLOW(flags, cpuext) CPUEXT_SUFFIX_SLOW(flags, , cpuext)
+int ff_get_cpu_flags_mips(void);
int ff_get_cpu_flags_aarch64(void);
int ff_get_cpu_flags_arm(void);
int ff_get_cpu_flags_ppc(void);
int ff_get_cpu_flags_x86(void);
+size_t ff_get_cpu_max_align_mips(void);
size_t ff_get_cpu_max_align_aarch64(void);
size_t ff_get_cpu_max_align_arm(void);
size_t ff_get_cpu_max_align_ppc(void);
diff --git a/libavutil/mips/Makefile b/libavutil/mips/Makefile
index dbfa5aa341..5f8c9b64e9 100644
--- a/libavutil/mips/Makefile
+++ b/libavutil/mips/Makefile
@@ -1 +1 @@
-OBJS += mips/float_dsp_mips.o
+OBJS += mips/float_dsp_mips.o mips/cpu.o
diff --git a/libavutil/mips/cpu.c b/libavutil/mips/cpu.c
new file mode 100644
index 00..6b9d721939
--- /dev/null
+++ b/libavutil/mips/cpu.c
@@ -0,0 +1,134 @@
+/*
+ * 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.
+
[FFmpeg-devel] [PATCH v6 0/6] MIPS MSA & MMI Runtime detection support
This series adds MIPS MSA & MMI runtime detection support Please review. Thanks! v2: - Add CPUCFG support. - Add "-mloongson-ext" to MMIFLAGS for Loongson-3 as well. (Loongson2F don't need this flag) v3: - Address reveiew suggestions from Shiyou Yin and Weixi Gu. v4: - Disable DSP for generic CPU v5: - Clean ups - Address some GCC build warnings v6: - Address more Shiyou's comments Jiaxun Yang (6): ffbuild: Refine MIPS handling libavutils: Add parse_r helper for MIPS libavutil: Detect MMI and MSA flags for MIPS libavcodec: Enable runtime detection for MIPS MMI & MSA libavcodec: MIPS: MMI: Fix type mismatches libavcodec: MIPS: MMI: Move sp out of the clobber list configure | 172 ++-- ffbuild/common.mak | 10 +- libavcodec/mips/Makefile| 3 +- libavcodec/mips/blockdsp_init_mips.c| 40 +- libavcodec/mips/cabac.h | 2 +- libavcodec/mips/h263dsp_init_mips.c | 18 +- libavcodec/mips/h264chroma_init_mips.c | 55 +- libavcodec/mips/h264dsp_init_mips.c | 225 +++-- libavcodec/mips/h264dsp_mips.h | 18 +- libavcodec/mips/h264dsp_mmi.c | 56 +- libavcodec/mips/h264pred_init_mips.c| 207 ++-- libavcodec/mips/h264qpel_init_mips.c| 412 libavcodec/mips/hevcdsp_init_mips.c | 992 ++-- libavcodec/mips/hevcpred_init_mips.c| 40 +- libavcodec/mips/hpeldsp_init_mips.c | 180 ++-- libavcodec/mips/idctdsp_init_mips.c | 74 +- libavcodec/mips/me_cmp_init_mips.c | 50 +- libavcodec/mips/mpegvideo_init_mips.c | 48 +- libavcodec/mips/mpegvideoencdsp_init_mips.c | 21 +- libavcodec/mips/pixblockdsp_init_mips.c | 63 +- libavcodec/mips/qpeldsp_init_mips.c | 270 +++--- libavcodec/mips/vc1dsp_init_mips.c | 186 ++-- libavcodec/mips/videodsp_init.c | 10 +- libavcodec/mips/vp3dsp_init_mips.c | 44 +- libavcodec/mips/vp8dsp_init_mips.c | 240 +++-- libavcodec/mips/vp9dsp_init_mips.c | 16 +- libavcodec/mips/wmv2dsp_init_mips.c | 18 +- libavcodec/mips/wmv2dsp_mips.h | 4 +- libavcodec/mips/wmv2dsp_mmi.c | 4 +- libavcodec/mips/xvid_idct_mmi.c | 4 +- libavcodec/mips/xvididct_init_mips.c| 31 +- libavcodec/mips/xvididct_mips.h | 4 +- libavutil/cpu.c | 10 + libavutil/cpu.h | 3 + libavutil/cpu_internal.h| 2 + libavutil/mips/Makefile | 2 +- libavutil/mips/asmdefs.h| 42 + libavutil/mips/cpu.c| 134 +++ libavutil/mips/cpu.h| 28 + libavutil/tests/cpu.c | 3 + tests/checkasm/checkasm.c | 3 + 41 files changed, 1919 insertions(+), 1825 deletions(-) create mode 100644 libavutil/mips/cpu.c create mode 100644 libavutil/mips/cpu.h -- 2.27.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] [PATCH v6 1/6] ffbuild: Refine MIPS handling
To enable runtime detection for MIPS, we need to refine ffbuild part to support buildding these feature together. Firstly, we fixed configure, let it probe native ability of toolchain to decide wether a feature can to be enabled, also clearly marked the conflictions between loongson2 & loongson3 and Release 6 & rest. Secondly, we compile MMI and MSA C sources with their own flags to ensure their flags won't pollute the whole program and generate illegal code. Signed-off-by: Jiaxun Yang -- v5: Minor fixes v6: Minor fixes according to Shiyou's comments --- configure| 172 ++- ffbuild/common.mak | 10 ++- libavcodec/mips/Makefile | 3 +- 3 files changed, 109 insertions(+), 76 deletions(-) diff --git a/configure b/configure index 7495f35faa..8952c7c6fb 100755 --- a/configure +++ b/configure @@ -2551,7 +2551,7 @@ mips64r6_deps="mips" mipsfpu_deps="mips" mipsdsp_deps="mips" mipsdspr2_deps="mips" -mmi_deps="mips" +mmi_deps_any="loongson2 loongson3" msa_deps="mipsfpu" msa2_deps="msa" @@ -5002,8 +5002,6 @@ elif enabled bfin; then elif enabled mips; then -cpuflags="-march=$cpu" - if [ "$cpu" != "generic" ]; then disable mips32r2 disable mips32r5 @@ -5012,19 +5010,61 @@ elif enabled mips; then disable mips64r6 disable loongson2 disable loongson3 +disable mipsdsp +disable mipsdspr2 +disable msa +disable mmi + +cpuflags="-march=$cpu" case $cpu in -24kc|24kf*|24kec|34kc|1004kc|24kef*|34kf*|1004kf*|74kc|74kf) +# General ISA levels +mips1|mips3) +;; +mips32r2) +enable msa enable mips32r2 -disable msa ;; -p5600|i6400|p6600) -disable mipsdsp -disable mipsdspr2 +mips32r5) +enable msa +enable mips32r2 +enable mips32r5 ;; -loongson*) -enable loongson2 +mips64r2|mips64r5) +enable msa +enable mmi +enable mips64r2 enable loongson3 +;; +# Cores from MIPS(MTI) +24kc) +disable mipsfpu +enable mips32r2 +;; +24kf*|24kec|34kc|74Kc|1004kc) +enable mips32r2 +;; +24kef*|34kf*|1004kf*) +enable mipsdsp +enable mips32r2 +;; +p5600) +enable msa +enable mips32r2 +enable mips32r5 +check_cflags "-mtune=p5600" && check_cflags "-msched-weight -mload-store-pairs -funroll-loops" +;; +i6400) +enable mips64r6 +check_cflags "-mtune=i6400 -mabi=64" && check_cflags "-msched-weight -mload-store-pairs -funroll-loops" && check_ldflags "-mabi=64" +;; +p6600) +enable mips64r6 +check_cflags "-mtune=p6600 -mabi=64" && check_cflags "-msched-weight -mload-store-pairs -funroll-loops" && check_ldflags "-mabi=64" +;; +# Cores from Loongson +loongson2e|loongson2f|loongson3*) +enable mmi enable local_aligned enable simd_align_16 enable fast_64bit @@ -5032,75 +5072,43 @@ elif enabled mips; then enable fast_cmov enable fast_unaligned disable aligned_stack -disable mipsdsp -disable mipsdspr2 # When gcc version less than 5.3.0, add -fno-expensive-optimizations flag. -if [ $cc == gcc ]; then -gcc_version=$(gcc -dumpversion) -if [ "$(echo "$gcc_version 5.3.0" | tr " " "\n" | sort -rV | head -n 1)" == "$gcc_version" ]; then -expensive_optimization_flag="" -else +if test "$cc_type" = "gcc"; then +case $gcc_basever in +2|2.*|3.*|4.*|5.0|5.1|5.2) expensive_optimization_flag="-fno-expensive-optimizations" -fi +;; +*) +expensive_optimization_flag="" +;; +esac fi + case $cpu in loongson3*) +enable loongson3 +enable msa cpuflags="-march=loongson3a -mhard-float $expensive_optimization_flag" ;; loongson2e) +enable loongson2 cpuflags="-march=loongson2e -mhard-float
Re: [FFmpeg-devel] [PATCH 1/3] doc/http: Update HTTP protocol options
On 18-07-2020 05:26 pm, Jun Zhao wrote:
From: Jun Zhao
remove the timeout option docs part for HTTP protocol and add
auth_type option part.
Signed-off-by: Jun Zhao
---
doc/protocols.texi | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 64ad3f0..7b3df96 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -392,11 +392,6 @@ string describing the libavformat build. ("Lavf/")
@item user-agent
This is a deprecated option, you can use user_agent instead it.
-@item timeout
-Set timeout in microseconds of socket I/O operations used by the underlying
low level
-operation. By default it is set to -1, which means that the timeout is
-not specified.
-
@item reconnect_at_eof
If set then eof is treated like an error and causes reconnection, this is
useful
for live / endless streams.
@@ -481,6 +476,28 @@ Send an Expect: 100-continue header for POST. If set to 1
it will send, if set
to 0 it won't, if set to -1 it will try to send if it is applicable. Default
value is -1.
+@item auth_type
+
+Set HTTP authentication type. No option for Digest, since this method requires
+getting nonce parameters from the server first and can't be used straight away
like
+Basic.
+
+@table @option
+@item none
+Choose the HTTP authentication type automatically. This is the default.
+@item basic
+
+Choose the HTTP basic authentication.
+
+Basic authentication sends a Base64-encoded string that contains a user name
and password
+for the client. Base64 is not a form of encryption and should be considered
the same as
+sending the user name and password in clear text (Base64 is a reversible
encoding).
+If a resource needs to be protected, strongly consider using an authentication
scheme
+other than basic authentication. HTTPS/TLS should be used with basic
authentication.
+Without these additional security enhancements, basic authentication should
not be used
+to protect sensitive or valuable information.
+@end table
+
@end table
@subsection HTTP Cookies
LGTM.
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter: add radial and circular blur video filter
On 7/18/20, Steinar H. Gunderson wrote: > On Sat, Jul 18, 2020 at 04:59:21PM +0200, Paul B Mahol wrote: >>> Is it good that it's slow? Or do you mean that the algorithm isn't >>> actually >>> slow? >> It is pretty fast here. > > Could you quantify what you mean by “pretty fast”? (Is it fast also measured > in CPU time, or only if you have a bunch of cores to spread it out over?) It is faster than many other filters, and could be made even faster. But considering that I do all this for free, why I should listen to someone who spends 5 seconds to write review. > >>> It sure is. With -vf vblur, a simple single-threaded transcode (to >>> magicyuv) >>> drops from 64 to 5 fps. A quick perf run indicates that about 67% of the >>> CPU >>> time is spent in converting to and from polar coordinates (p2c, c2p, >>> atan2), >>> give or take a little. >> It can be made faster, but why i would do that when you complain on >> current code? > > I agree that optimizing the current algorithm is not a good way to go > when there are multiple better ones available, but you were claiming > performance was not affected at all, which fairly obviously is not true. Why you still spreading nonsense that there is better algorithm? > >> Actually, fact is that you came here at first to bring some jumbo >> about better algorithms >> with pages that had almost no valuable information. >> And later when proven wrong you started to object to current patch >> just for pure amusement. > > Can we please talk about the patch instead of personal attacks? > > Also, what do you mean by “proven wrong”? Your only “proof” so far that your > algorithm is better than the standard vector-based variations (whether > recursive, or simply by integrating along a line with bilinear filtering, > neither of which needs any trigonometry or divisions) has been an expression > of doubt -- no benchmarks, no reasoning, no back-of-the-envelope > calculations. There is no better algorithm than current one. If you want to prove different, write one! But if you do not want, then better current solution than no solution at all. It could have even same options like current implementation than just code would be changed. > >>> It's good that you fixed the quality issue you claimed didn't exist less >>> than an hour earlier. Could you please post the updated patch? >> I will keep it to my fork only. You can enjoy your negative reviews >> later at any time. > > OK, if you don't plan to actually commit this to FFmpeg master, then we > don't > need to argue further about it. I changed my mind when I looked how many benefits it give. > > /* Steinar */ > -- > Homepage: https://www.sesse.net/ > ___ > 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] avfilter: add radial and circular blur video filter
On Sat, Jul 18, 2020 at 04:59:21PM +0200, Paul B Mahol wrote: >> Is it good that it's slow? Or do you mean that the algorithm isn't actually >> slow? > It is pretty fast here. Could you quantify what you mean by “pretty fast”? (Is it fast also measured in CPU time, or only if you have a bunch of cores to spread it out over?) >> It sure is. With -vf vblur, a simple single-threaded transcode (to magicyuv) >> drops from 64 to 5 fps. A quick perf run indicates that about 67% of the CPU >> time is spent in converting to and from polar coordinates (p2c, c2p, atan2), >> give or take a little. > It can be made faster, but why i would do that when you complain on > current code? I agree that optimizing the current algorithm is not a good way to go when there are multiple better ones available, but you were claiming performance was not affected at all, which fairly obviously is not true. > Actually, fact is that you came here at first to bring some jumbo > about better algorithms > with pages that had almost no valuable information. > And later when proven wrong you started to object to current patch > just for pure amusement. Can we please talk about the patch instead of personal attacks? Also, what do you mean by “proven wrong”? Your only “proof” so far that your algorithm is better than the standard vector-based variations (whether recursive, or simply by integrating along a line with bilinear filtering, neither of which needs any trigonometry or divisions) has been an expression of doubt -- no benchmarks, no reasoning, no back-of-the-envelope calculations. >> It's good that you fixed the quality issue you claimed didn't exist less >> than an hour earlier. Could you please post the updated patch? > I will keep it to my fork only. You can enjoy your negative reviews > later at any time. OK, if you don't plan to actually commit this to FFmpeg master, then we don't need to argue further about it. /* Steinar */ -- Homepage: https://www.sesse.net/ ___ 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] avfilter: add radial and circular blur video filter
On 7/18/20, Steinar H. Gunderson wrote: > On Sat, Jul 18, 2020 at 01:31:49PM +0200, Paul B Mahol wrote: >>> In short, this patch has: >>> >>> - An unusually slow algorithm (sin, cos, atan, division; all per-pixel). >> This is actually good. > > Is it good that it's slow? Or do you mean that the algorithm isn't actually > slow? > It is pretty fast here. >> Performance is not affected at all. > > It sure is. With -vf vblur, a simple single-threaded transcode (to magicyuv) > drops from 64 to 5 fps. A quick perf run indicates that about 67% of the CPU > time is spent in converting to and from polar coordinates (p2c, c2p, atan2), > give or take a little. It can be made faster, but why i would do that when you complain on current code? Actually, fact is that you came here at first to bring some jumbo about better algorithms with pages that had almost no valuable information. And later when proven wrong you started to object to current patch just for pure amusement. > >>> - Poor output quality (strong aliasing, no subpixel precision). >> I fixed this. No thanks to your patch. > > It's good that you fixed the quality issue you claimed didn't exist less > than > an hour earlier. Could you please post the updated patch? I will keep it to my fork only. You can enjoy your negative reviews later at any time. > >>> - No comments, hardly any commit message. >> No comments are needed for developers that know how to code. > > The FFmpeg coding style disagrees: > > https://ffmpeg.org/developer.html#Comments -- “All nontrivial functions > should have a comment above them explaining what the function does, even if > it is just one sentence. All structures and their member variables should be > documented, too.” > > https://ffmpeg.org/developer.html#Patches_002fCommitting -- “Always fill out > the commit log message. Describe in a few lines what you changed and why.” > > I don't see any exceptions for “developers that know how to code”; and after > all, also those who are not so good coders should be able to understand the > code. Code is self explanatory and does not need comments for mortals. > >>> Thus, I believe it should not be merged. >> It is just your belief, no any proof given. > > I believe I fairly clearly spelled out my reasoning in the text you quoted? The reasoning is completely flawed as explained multiple times. > > /* Steinar */ > -- > Homepage: https://www.sesse.net/ > ___ > 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 v3 2/2] avcodec/put_bits: Make bit buffers 64-bit
Change BitBuf into uint64_t on 64-bit x86. This means we need to flush the
buffer less often, which is a significant speed win. All other platforms,
including all 32-bit ones, are unchanged. Output bitstream is the same.
All API constraints are kept in place, e.g., you still cannot put_bits()
more than 31 bits at a time. This is so that codecs cannot accidentally
become 64-bit-only or similar.
Benchmarking on transcoding to various formats shows consistently
positive results:
dnxhd 25.60 fps -> 26.26 fps ( +2.6%)
dvvideo 24.88 fps -> 25.17 fps ( +1.2%)
ffv1 14.32 fps -> 14.58 fps ( +1.8%)
huffyuv 58.75 fps -> 63.27 fps ( +7.7%)
jpegls 6.22 fps -> 6.34 fps ( +1.8%)
magicyuv 57.10 fps -> 63.29 fps (+10.8%)
mjpeg 48.65 fps -> 49.01 fps ( +0.7%)
mpeg1video76.41 fps -> 77.01 fps ( +0.8%)
mpeg2video75.99 fps -> 77.43 fps ( +1.9%)
mpeg4 80.66 fps -> 81.37 fps ( +0.9%)
prores12.35 fps -> 12.88 fps ( +4.3%)
prores_ks 16.20 fps -> 16.80 fps ( +3.7%)
rv20 62.80 fps -> 62.99 fps ( +0.3%)
utvideo 68.41 fps -> 76.32 fps (+11.6%)
Note that this includes video decoding and all other encoding work,
such as DCTs. If you isolate the actual bit-writing routines, it is
likely to be much more.
Benchmark details: Transcoding the first 30 seconds of Big Buck Bunny
in 1080p, Haswell 2.1 GHz, GCC 8.3, generally quantizer locked to
5.0. (Exceptions: DNxHD needs fixed bitrate, and JPEG-LS is so slow
that I only took the first 10 seconds, not 30.) All runs were done
ten times and single-threaded, top and bottom two results discarded to
get rid of outliers, arithmetic mean between the remaining six.
---
libavcodec/asvenc.c | 1 +
libavcodec/put_bits.h | 31 ---
2 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/libavcodec/asvenc.c b/libavcodec/asvenc.c
index c2c940f365..28f7a94071 100644
--- a/libavcodec/asvenc.c
+++ b/libavcodec/asvenc.c
@@ -295,6 +295,7 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
while (put_bits_count(>pb) & 31)
put_bits(>pb, 8, 0);
+flush_put_bits(>pb);
size = put_bits_count(>pb) / 32;
if (avctx->codec_id == AV_CODEC_ID_ASV1) {
diff --git a/libavcodec/put_bits.h b/libavcodec/put_bits.h
index c6a8f3ac14..ddd97906b2 100644
--- a/libavcodec/put_bits.h
+++ b/libavcodec/put_bits.h
@@ -29,12 +29,20 @@
#include
#include
+#include "config.h"
#include "libavutil/intreadwrite.h"
#include "libavutil/avassert.h"
+#if ARCH_X86_64
+// TODO: Benchmark and optionally enable on other 64-bit architectures.
+typedef uint64_t BitBuf;
+#define AV_WBBUF AV_WB64
+#define AV_WLBUF AV_WL64
+#else
typedef uint32_t BitBuf;
#define AV_WBBUF AV_WB32
#define AV_WLBUF AV_WL32
+#endif
static const int BUF_BITS = 8 * sizeof(BitBuf);
@@ -163,17 +171,11 @@ void avpriv_put_string(PutBitContext *pb, const char
*string,
void avpriv_copy_bits(PutBitContext *pb, const uint8_t *src, int length);
#endif
-/**
- * Write up to 31 bits into a bitstream.
- * Use put_bits32 to write 32 bits.
- */
-static inline void put_bits(PutBitContext *s, int n, BitBuf value)
+static inline void put_bits_no_assert(PutBitContext *s, int n, BitBuf value)
{
BitBuf bit_buf;
int bit_left;
-av_assert2(n <= 31 && value < (1UL << n));
-
bit_buf = s->bit_buf;
bit_left = s->bit_left;
@@ -215,6 +217,16 @@ static inline void put_bits(PutBitContext *s, int n,
BitBuf value)
s->bit_left = bit_left;
}
+/**
+ * Write up to 31 bits into a bitstream.
+ * Use put_bits32 to write 32 bits.
+ */
+static inline void put_bits(PutBitContext *s, int n, BitBuf value)
+{
+av_assert2(n <= 31 && value < (1UL << n));
+put_bits_no_assert(s, n, value);
+}
+
static inline void put_bits_le(PutBitContext *s, int n, BitBuf value)
{
BitBuf bit_buf;
@@ -258,6 +270,11 @@ static void av_unused put_bits32(PutBitContext *s,
uint32_t value)
BitBuf bit_buf;
int bit_left;
+if (BUF_BITS > 32) {
+put_bits_no_assert(s, 32, value);
+return;
+}
+
bit_buf = s->bit_buf;
bit_left = s->bit_left;
--
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".
[FFmpeg-devel] [PATCH v3 1/2] avcodec/put_bits: Parametrize bit buffer type
Preparatory patch for making the bit buffer different size on different
platforms; make a typedef and make all the hardcoded sizes into expressions
deriving from this size.
No functional change; generated assembler is near-identical.
---
libavcodec/mpegvideo_enc.c | 2 +-
libavcodec/put_bits.h | 95 +-
2 files changed, 53 insertions(+), 44 deletions(-)
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index c3ef40556a..21c30a9f8a 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -3914,7 +3914,7 @@ static int encode_picture(MpegEncContext *s, int
picture_number)
s->avctx->execute(s->avctx, encode_thread, >thread_context[0], NULL,
context_count, sizeof(void*));
for(i=1; ipb.buf_end == s->thread_context[i]->pb.buf)
-set_put_bits_buffer_size(>pb,
FFMIN(s->thread_context[i]->pb.buf_end - s->pb.buf, INT_MAX/8-32));
+set_put_bits_buffer_size(>pb,
FFMIN(s->thread_context[i]->pb.buf_end - s->pb.buf, INT_MAX/8-BUF_BITS));
merge_context_after_encode(s, s->thread_context[i]);
}
emms_c();
diff --git a/libavcodec/put_bits.h b/libavcodec/put_bits.h
index 7d11a3576a..c6a8f3ac14 100644
--- a/libavcodec/put_bits.h
+++ b/libavcodec/put_bits.h
@@ -32,8 +32,14 @@
#include "libavutil/intreadwrite.h"
#include "libavutil/avassert.h"
+typedef uint32_t BitBuf;
+#define AV_WBBUF AV_WB32
+#define AV_WLBUF AV_WL32
+
+static const int BUF_BITS = 8 * sizeof(BitBuf);
+
typedef struct PutBitContext {
-uint32_t bit_buf;
+BitBuf bit_buf;
int bit_left;
uint8_t *buf, *buf_ptr, *buf_end;
int size_in_bits;
@@ -57,7 +63,7 @@ static inline void init_put_bits(PutBitContext *s, uint8_t
*buffer,
s->buf = buffer;
s->buf_end = s->buf + buffer_size;
s->buf_ptr = s->buf;
-s->bit_left = 32;
+s->bit_left = BUF_BITS;
s->bit_buf = 0;
}
@@ -66,7 +72,7 @@ static inline void init_put_bits(PutBitContext *s, uint8_t
*buffer,
*/
static inline int put_bits_count(PutBitContext *s)
{
-return (s->buf_ptr - s->buf) * 8 + 32 - s->bit_left;
+return (s->buf_ptr - s->buf) * 8 + BUF_BITS - s->bit_left;
}
/**
@@ -92,7 +98,7 @@ static inline void rebase_put_bits(PutBitContext *s, uint8_t
*buffer,
*/
static inline int put_bits_left(PutBitContext* s)
{
-return (s->buf_end - s->buf_ptr) * 8 - 32 + s->bit_left;
+return (s->buf_end - s->buf_ptr) * 8 - BUF_BITS + s->bit_left;
}
/**
@@ -101,33 +107,33 @@ static inline int put_bits_left(PutBitContext* s)
static inline void flush_put_bits(PutBitContext *s)
{
#ifndef BITSTREAM_WRITER_LE
-if (s->bit_left < 32)
+if (s->bit_left < BUF_BITS)
s->bit_buf <<= s->bit_left;
#endif
-while (s->bit_left < 32) {
+while (s->bit_left < BUF_BITS) {
av_assert0(s->buf_ptr < s->buf_end);
#ifdef BITSTREAM_WRITER_LE
*s->buf_ptr++ = s->bit_buf;
s->bit_buf >>= 8;
#else
-*s->buf_ptr++ = s->bit_buf >> 24;
+*s->buf_ptr++ = s->bit_buf >> (BUF_BITS - 8);
s->bit_buf <<= 8;
#endif
s->bit_left += 8;
}
-s->bit_left = 32;
+s->bit_left = BUF_BITS;
s->bit_buf = 0;
}
static inline void flush_put_bits_le(PutBitContext *s)
{
-while (s->bit_left < 32) {
+while (s->bit_left < BUF_BITS) {
av_assert0(s->buf_ptr < s->buf_end);
*s->buf_ptr++ = s->bit_buf;
s->bit_buf >>= 8;
s->bit_left += 8;
}
-s->bit_left = 32;
+s->bit_left = BUF_BITS;
s->bit_buf = 0;
}
@@ -161,29 +167,29 @@ void avpriv_copy_bits(PutBitContext *pb, const uint8_t
*src, int length);
* Write up to 31 bits into a bitstream.
* Use put_bits32 to write 32 bits.
*/
-static inline void put_bits(PutBitContext *s, int n, unsigned int value)
+static inline void put_bits(PutBitContext *s, int n, BitBuf value)
{
-unsigned int bit_buf;
+BitBuf bit_buf;
int bit_left;
-av_assert2(n <= 31 && value < (1U << n));
+av_assert2(n <= 31 && value < (1UL << n));
bit_buf = s->bit_buf;
bit_left = s->bit_left;
/* XXX: optimize */
#ifdef BITSTREAM_WRITER_LE
-bit_buf |= value << (32 - bit_left);
+bit_buf |= value << (BUF_BITS - bit_left);
if (n >= bit_left) {
-if (3 < s->buf_end - s->buf_ptr) {
-AV_WL32(s->buf_ptr, bit_buf);
-s->buf_ptr += 4;
+if (s->buf_end - s->buf_ptr >= sizeof(BitBuf)) {
+AV_WLBUF(s->buf_ptr, bit_buf);
+s->buf_ptr += sizeof(BitBuf);
} else {
av_log(NULL, AV_LOG_ERROR, "Internal error, put_bits buffer too
small\n");
av_assert2(0);
}
bit_buf = value >> bit_left;
-bit_left += 32;
+bit_left += BUF_BITS;
}
bit_left -= n;
#else
@@ -193,14 +199,14 @@ static inline void put_bits(PutBitContext *s, int n,
unsigned int value)
} else {
bit_buf <<=
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/put_bits: Parametrize bit buffer type
On Sat, Jul 18, 2020 at 01:34:55PM +0200, Michael Niedermayer wrote: > this from libavcodec/mpegvideo_enc.c > set_put_bits_buffer_size(>pb, > FFMIN(s->thread_context[i]->pb.buf_end - s->pb.buf, INT_MAX/8-32)); > needs to be updated too OK. Including in v3, sending shortly. /* Steinar */ -- Homepage: https://www.sesse.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/put_bits: Make bit buffers 64-bit
On Sat, Jul 18, 2020 at 01:53:36PM +0200, Carl Eugen Hoyos wrote: >> +#if ARCH_AARCH64 || ARCH_IA64 || ARCH_MIPS64 || ARCH_SPARC64 || ARCH_X86_64 > I suggest to only do this for the platforms that you actually tested. OK. If so, that's x86-64 only. /* Steinar */ -- Homepage: https://www.sesse.net/ ___ 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] avfilter: add radial and circular blur video filter
On Sat, Jul 18, 2020 at 01:31:49PM +0200, Paul B Mahol wrote: >> In short, this patch has: >> >> - An unusually slow algorithm (sin, cos, atan, division; all per-pixel). > This is actually good. Is it good that it's slow? Or do you mean that the algorithm isn't actually slow? > Performance is not affected at all. It sure is. With -vf vblur, a simple single-threaded transcode (to magicyuv) drops from 64 to 5 fps. A quick perf run indicates that about 67% of the CPU time is spent in converting to and from polar coordinates (p2c, c2p, atan2), give or take a little. >> - Poor output quality (strong aliasing, no subpixel precision). > I fixed this. No thanks to your patch. It's good that you fixed the quality issue you claimed didn't exist less than an hour earlier. Could you please post the updated patch? >> - No comments, hardly any commit message. > No comments are needed for developers that know how to code. The FFmpeg coding style disagrees: https://ffmpeg.org/developer.html#Comments -- “All nontrivial functions should have a comment above them explaining what the function does, even if it is just one sentence. All structures and their member variables should be documented, too.” https://ffmpeg.org/developer.html#Patches_002fCommitting -- “Always fill out the commit log message. Describe in a few lines what you changed and why.” I don't see any exceptions for “developers that know how to code”; and after all, also those who are not so good coders should be able to understand the code. >> Thus, I believe it should not be merged. > It is just your belief, no any proof given. I believe I fairly clearly spelled out my reasoning in the text you quoted? /* Steinar */ -- Homepage: https://www.sesse.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avdevice/decklink_dec: mark the field flag if framerate > 30FPS
On Sat, Jul 18, 2020 at 09:44:03AM +0200, Marton Balint wrote:
>
>
> On Sat, 18 Jul 2020, lance.lmw...@gmail.com wrote:
>
> > On Fri, Jul 17, 2020 at 07:13:28PM +0200, Marton Balint wrote:
> > >
> > >
> > > On Fri, 17 Jul 2020, lance.lmw...@gmail.com wrote:
> > >
> > > > From: Limin Wang
> > > > > In SMPTE ST 12-1: 2014 Sec 12.2, we need to mark the frame flag
> > > if the frame rate > 30FPS to
> > > > avoid interoperability issues. It will be used by the encoder to
> > > > identify even or odd frames
> > > > and correctly calculate the frame number of the SEI TC.
> > >
> > > This feature looks like it belongs to av_timecode_get_smpte_from_framenum
> > > and not into decklink. Also checking previous timecode and guessing
> > > something is a hack, especially since you have the exact source timecode.
> > If I understand correctly, it's not hacky, for the framerate > 30, the
> > source timecode will be
> > frame pair(it's limited by 2bits limit of frame number ten digital. Below
> > is one exmaple for 50fps
> > if you tested with SDI with TC.
> > 00:00:00:24
> > 00:00:00:24
> > 00:00:00:25
> > 00:00:00:25
> > 00:00:00:00
> > 00:00:00:00
>
> Have you actually tested this with a real SDI signal containing timecode?
Yes, have tested with SDI playback by decklink UltraStudio 4K mini with TC
enabled.
>
> Thanks,
> Marton
>
> >
> > That's why I check the last TC to get the frame is even or odd.
> >
> > Why not use av_timecode_get_smpte_from_framenum(), for it's calculated by
> > the string TC by one time,
> > so it lacks the information whether it's odd or even frame.
> >
> > >
> > > Regards,
> > > Marton
> > >
> > > > > ---
> > > > libavdevice/decklink_common.h | 1 +
> > > > libavdevice/decklink_dec.cpp | 14 ++
> > > > 2 files changed, 15 insertions(+)
> > > > > diff --git a/libavdevice/decklink_common.h
> > > b/libavdevice/decklink_common.h
> > > > index bd68c7b..8ddc411 100644
> > > > --- a/libavdevice/decklink_common.h
> > > > +++ b/libavdevice/decklink_common.h
> > > > @@ -151,6 +151,7 @@ struct decklink_ctx {
> > > > int channels;
> > > > int audio_depth;
> > > > unsigned long tc_seen;// used with option wait_for_tc
> > > > +uint32_t last_tc;
> > > > };
> > > > > typedef enum { DIRECTION_IN, DIRECTION_OUT}
> > > decklink_direction_t;
> > > > diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
> > > > index dde68ff..a60c01b 100644
> > > > --- a/libavdevice/decklink_dec.cpp
> > > > +++ b/libavdevice/decklink_dec.cpp
> > > > @@ -884,12 +884,26 @@ HRESULT
> > > > decklink_input_callback::VideoInputFrameArrived(
> > > > int metadata_len;
> > > > uint8_t* packed_metadata;
> > > > AVTimecode tcr;
> > > > +AVRational rate = ctx->video_st->r_frame_rate;
> > > > > if (av_timecode_init_from_string(,
> > > ctx->video_st->r_frame_rate, tc, ctx) >= 0) {
> > > > uint32_t tc_data =
> > > > av_timecode_get_smpte_from_framenum(, 0);
> > > > int size = sizeof(uint32_t) * 4;
> > > > uint32_t *sd = (uint32_t
> > > > *)av_packet_new_side_data(, AV_PKT_DATA_S12M_TIMECODE, size);
> > > > > +/* set the field flag if frame rate
> > > > 30FPS */
> > > > +/* Refer to SMPTE ST 12-1:2014 Sec 12.2 */
> > > > +if (av_cmp_q(rate, (AVRational) {30, 1})
> > > > == 1) {
> > > > +/* Odd frame */
> > > > +if (ctx->last_tc == tc_data) {
> > > > +if (av_cmp_q(rate, (AVRational)
> > > > {50, 1}) == 0)
> > > > +tc_data |= (1 << 7);
> > > > +else
> > > > +tc_data |= (1 << 23);
> > > > +}
> > > > +}
> > > > +ctx->last_tc = tc_data;
> > > > +
> > > > if (sd) {
> > > > *sd = 1; // one TC
> > > > *(sd + 1) = tc_data; // TC
> > > > -- > 2.9.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".
> >
> > --
> > Thanks,
> > Limin Wang
> >
Re: [FFmpeg-devel] [PATCH] lavf/srt: fix build fail when used the libsrt 1.4.1
On Thu, Jul 16, 2020 at 9:35 AM myp...@gmail.com wrote: > > On Tue, Jul 14, 2020 at 9:47 PM Moritz Barsnick wrote: > > > > On Sun, Jul 12, 2020 at 22:44:46 +0800, myp...@gmail.com wrote: > > > Maybe I give an inaccurate description in the commit message, in fact, > > > libsrt 1.4.1 remove the SRTO_STRICTENC/SRTO_SMOOTHER option, it's will > > > lead to FFmpeg build fail when using libsrt version >= 1.4.1 > > > > I don't mind you description. Yet your code change references 1.4.1: > > SRT_VERSION_VALUE >= 0x010401 > > while I am trying to make the point that 1.4.0 also needs this change > > (or 1.3.0 in one case, which is already ensured by #if). > > > > After double-check, I think the patch is Ok, in fact, libsrt keeps the > deprecated SRTO_STRICTENC/SRTO_SMOOTHER options in srt.h (inclued the > options in libsrt 1.3.3/1.3.4/1.4.0) until commit > 0e2201aff6b379979cec43fee5e8f162717f6346 , so FFmpeg build with libsrt > 1.3.3/1.3.4/1.4.0 is OK with the patch. Ping ___ 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 3/3] libavcodec/jpeg2000dec: Support for PPM marker
From: Gautam Ramakrishnan
This patch adds support for PPM marker for JPEG2000
decoder. It allows the samples p1_03.j2k and p1_05.j2k
to be decoded.
---
libavcodec/jpeg2000dec.c | 111 +++
1 file changed, 101 insertions(+), 10 deletions(-)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 5e9e97eb6a..e37f834afe 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -71,6 +71,7 @@ typedef struct Jpeg2000POC {
typedef struct Jpeg2000TilePart {
uint8_t tile_index; // Tile index who refers the tile-part
const uint8_t *tp_end;
+GetByteContext header_tpg; // bit stream of header if PPM header
is used
GetByteContext tpg; // bit stream in tile-part
} Jpeg2000TilePart;
@@ -102,6 +103,13 @@ typedef struct Jpeg2000DecoderContext {
uint8_t cbps[4];// bits per sample in particular components
uint8_t sgnd[4];// if a component is signed
uint8_t properties[4];
+
+uint8_t has_ppm;
+uint8_t *packed_headers; // contains packed headers. Used only
along with PPM marker
+int packed_headers_size;
+GetByteContext packed_headers_stream;
+uint8_t in_tile_headers;
+
int cdx[4], cdy[4];
int precision;
int ncomponents;
@@ -928,6 +936,31 @@ static int get_plt(Jpeg2000DecoderContext *s, int n)
return 0;
}
+static int get_ppm(Jpeg2000DecoderContext *s, int n)
+{
+void *new;
+
+if (n < 3) {
+av_log(s->avctx, AV_LOG_ERROR, "Invalid length for PPM data.\n");
+return AVERROR_INVALIDDATA;
+}
+s->has_ppm = 1;
+bytestream2_get_byte(>g); //Zppm is skipped and not used
+new = av_realloc(s->packed_headers,
+ s->packed_headers_size + n - 3);
+if (new) {
+s->packed_headers = new;
+} else
+return AVERROR(ENOMEM);
+memset(>packed_headers_stream, 0, sizeof(s->packed_headers_stream));
+memcpy(s->packed_headers + s->packed_headers_size,
+ s->g.buffer, n - 3);
+s->packed_headers_size += n - 3;
+bytestream2_skip(>g, n - 3);
+
+return 0;
+}
+
static int get_ppt(Jpeg2000DecoderContext *s, int n)
{
Jpeg2000Tile *tile;
@@ -1039,8 +1072,19 @@ static int getlblockinc(Jpeg2000DecoderContext *s)
return res;
}
-static inline void select_stream(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile,
+static inline void select_header(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile,
int *tp_index)
+{
+s->g = tile->tile_part[*tp_index].header_tpg;
+if (bytestream2_get_bytes_left(>g) == 0 && s->bit_index == 8) {
+if (*tp_index < FF_ARRAY_ELEMS(tile->tile_part) - 1) {
+s->g = tile->tile_part[++(*tp_index)].tpg;
+}
+}
+}
+
+static inline void select_stream(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile,
+ int *tp_index, Jpeg2000CodingStyle *codsty)
{
s->g = tile->tile_part[*tp_index].tpg;
if (bytestream2_get_bytes_left(>g) == 0 && s->bit_index == 8) {
@@ -1048,8 +1092,12 @@ static inline void select_stream(Jpeg2000DecoderContext
*s, Jpeg2000Tile *tile,
s->g = tile->tile_part[++(*tp_index)].tpg;
}
}
-if (bytestream2_peek_be32(>g) == JPEG2000_SOP_FIXED_BYTES)
-bytestream2_skip(>g, JPEG2000_SOP_BYTE_LENGTH);
+if (codsty->csty & JPEG2000_CSTY_SOP) {
+if (bytestream2_peek_be32(>g) == JPEG2000_SOP_FIXED_BYTES)
+bytestream2_skip(>g, JPEG2000_SOP_BYTE_LENGTH);
+else
+av_log(s->avctx, AV_LOG_ERROR, "SOP marker not found. instead
%X\n", bytestream2_peek_be32(>g));
+}
}
static int jpeg2000_decode_packet(Jpeg2000DecoderContext *s, Jpeg2000Tile
*tile, int *tp_index,
@@ -1064,10 +1112,12 @@ static int
jpeg2000_decode_packet(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile,
return 0;
rlevel->band[0].prec[precno].decoded_layers = layno + 1;
// Select stream to read from
-if (tile->has_ppt)
+if (s->has_ppm)
+select_header(s, tile, tp_index);
+else if (tile->has_ppt)
s->g = tile->packed_headers_stream;
else
-select_stream(s, tile, tp_index);
+select_stream(s, tile, tp_index, codsty);
if (!(ret = get_bits(s, 1))) {
jpeg2000_flush(s);
@@ -1178,9 +1228,12 @@ static int jpeg2000_decode_packet(Jpeg2000DecoderContext
*s, Jpeg2000Tile *tile,
}
// Save state of stream
-if (tile->has_ppt) {
+if (s->has_ppm) {
+tile->tile_part[*tp_index].header_tpg = s->g;
+select_stream(s, tile, tp_index, codsty);
+} else if (tile->has_ppt) {
tile->packed_headers_stream = s->g;
-select_stream(s, tile, tp_index);
+select_stream(s, tile, tp_index, codsty);
}
for (bandno = 0; bandno < rlevel->nbands; bandno++) {
Jpeg2000Band *band
[FFmpeg-devel] [PATCH v2 1/3] libavcodec/jpeg2000dec: Fix codeblock decode check
From: Gautam Ramakrishnan
The codeblock decoder checks whether the mqc decoder
has decoded the right number of bytes. However, this
check does not account for the fact that the mqc encoder's
flush routine adds 2 bytes of data which does not have to be
read by the decoder. The check is modified to account for
this. This patch solves issue #4827
---
libavcodec/jpeg2000dec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 5ea6fd0b9a..5043125fe3 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -1753,9 +1753,9 @@ static int decode_cblk(Jpeg2000DecoderContext *s,
Jpeg2000CodingStyle *codsty,
pass_cnt ++;
}
-if (cblk->data + cblk->length - 2*(term_cnt < cblk->nb_terminations) !=
t1->mqc.bp) {
+if (cblk->data + cblk->length - 2 > t1->mqc.bp) {
av_log(s->avctx, AV_LOG_WARNING, "End mismatch %"PTRDIFF_SPECIFIER"\n",
- cblk->data + cblk->length - 2*(term_cnt <
cblk->nb_terminations) - t1->mqc.bp);
+ cblk->data + cblk->length - 2 - t1->mqc.bp);
}
return 1;
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 2/3] libavcodec/jpeg2000dec: Support for Parameterless Markers
From: Gautam Ramakrishnan
The JPEG2000 standard reserves marker values 0xFF30
to 0xFF3F to be used as parameterless markers. This
patch adds support to decode codestream with such
markers. This allows decoding of p0_02.j2k.
---
libavcodec/jpeg2000dec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 5043125fe3..5e9e97eb6a 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -2092,7 +2092,8 @@ static int
jpeg2000_read_main_headers(Jpeg2000DecoderContext *s)
marker = bytestream2_get_be16u(>g);
oldpos = bytestream2_tell(>g);
-
+if (marker >= 0xFF30 && marker <= 0xFF3F)
+continue;
if (marker == JPEG2000_SOD) {
Jpeg2000Tile *tile;
Jpeg2000TilePart *tp;
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] lavf/dashdec: enable custom interrup callback in sub-demuxer
From: Jun Zhao
Enable the custom callback in sub-demuxer
Signed-off-by: Jun Zhao
---
libavformat/dashdec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 694782c..c5a5ff6 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -1943,6 +1943,7 @@ static int reopen_demux_for_component(AVFormatContext *s,
struct representation
pls->ctx->flags = AVFMT_FLAG_CUSTOM_IO;
pls->ctx->probesize = s->probesize > 0 ? s->probesize : 1024 * 4;
pls->ctx->max_analyze_duration = s->max_analyze_duration > 0 ?
s->max_analyze_duration : 4 * AV_TIME_BASE;
+pls->ctx->interrupt_callback = s->interrupt_callback;
ret = av_probe_input_buffer(>pb, _fmt, "", NULL, 0, 0);
if (ret < 0) {
av_log(s, AV_LOG_ERROR, "Error when loading first fragment, playlist
%d\n", (int)pls->rep_idx);
--
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".
[FFmpeg-devel] [PATCH 1/2] libavcodec/jpeg2000dec: Fix codeblock decode check
From: Gautam Ramakrishnan
The codeblock decoder checks whether the mqc decoder
has decoded the right number of bytes. However, this
check does not account for the fact that the mqc encoder's
flush routine adds 2 bytes of data which does not have to be
read by the decoder. The check is modified to account for
this. This patch solves issue #4827
---
libavcodec/jpeg2000dec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 5ea6fd0b9a..5043125fe3 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -1753,9 +1753,9 @@ static int decode_cblk(Jpeg2000DecoderContext *s,
Jpeg2000CodingStyle *codsty,
pass_cnt ++;
}
-if (cblk->data + cblk->length - 2*(term_cnt < cblk->nb_terminations) !=
t1->mqc.bp) {
+if (cblk->data + cblk->length - 2 > t1->mqc.bp) {
av_log(s->avctx, AV_LOG_WARNING, "End mismatch %"PTRDIFF_SPECIFIER"\n",
- cblk->data + cblk->length - 2*(term_cnt <
cblk->nb_terminations) - t1->mqc.bp);
+ cblk->data + cblk->length - 2 - t1->mqc.bp);
}
return 1;
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] doc/http: Update HTTP protocol options
From: Jun Zhao
remove the timeout option docs part for HTTP protocol and add
auth_type option part.
Signed-off-by: Jun Zhao
---
doc/protocols.texi | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 64ad3f0..7b3df96 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -392,11 +392,6 @@ string describing the libavformat build. ("Lavf/")
@item user-agent
This is a deprecated option, you can use user_agent instead it.
-@item timeout
-Set timeout in microseconds of socket I/O operations used by the underlying
low level
-operation. By default it is set to -1, which means that the timeout is
-not specified.
-
@item reconnect_at_eof
If set then eof is treated like an error and causes reconnection, this is
useful
for live / endless streams.
@@ -481,6 +476,28 @@ Send an Expect: 100-continue header for POST. If set to 1
it will send, if set
to 0 it won't, if set to -1 it will try to send if it is applicable. Default
value is -1.
+@item auth_type
+
+Set HTTP authentication type. No option for Digest, since this method requires
+getting nonce parameters from the server first and can't be used straight away
like
+Basic.
+
+@table @option
+@item none
+Choose the HTTP authentication type automatically. This is the default.
+@item basic
+
+Choose the HTTP basic authentication.
+
+Basic authentication sends a Base64-encoded string that contains a user name
and password
+for the client. Base64 is not a form of encryption and should be considered
the same as
+sending the user name and password in clear text (Base64 is a reversible
encoding).
+If a resource needs to be protected, strongly consider using an authentication
scheme
+other than basic authentication. HTTPS/TLS should be used with basic
authentication.
+Without these additional security enhancements, basic authentication should
not be used
+to protect sensitive or valuable information.
+@end table
+
@end table
@subsection HTTP Cookies
--
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".
[FFmpeg-devel] [PATCH 2/3] lavf/hls: enable custom interrup callback in sub-demuxer
From: Jun Zhao Enable the custom callback in sub-demuxer Signed-off-by: Jun Zhao --- libavformat/hls.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/hls.c b/libavformat/hls.c index ba17c4e..cf0b71d 100644 --- a/libavformat/hls.c +++ b/libavformat/hls.c @@ -1984,6 +1984,7 @@ static int hls_read_header(AVFormatContext *s) read_data, NULL, NULL); pls->ctx->probesize = s->probesize > 0 ? s->probesize : 1024 * 4; pls->ctx->max_analyze_duration = s->max_analyze_duration > 0 ? s->max_analyze_duration : 4 * AV_TIME_BASE; +pls->ctx->interrupt_callback = s->interrupt_callback; url = av_strdup(pls->segments[0]->url); ret = av_probe_input_buffer(>pb, _fmt, url, NULL, 0, 0); av_free(url); -- 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/2] avcodec/put_bits: Make bit buffers 64-bit
Am Fr., 17. Juli 2020 um 21:41 Uhr schrieb Steinar H. Gunderson : > +#if ARCH_AARCH64 || ARCH_IA64 || ARCH_MIPS64 || ARCH_SPARC64 || ARCH_X86_64 I suggest to only do this for the platforms that you actually tested. > +typedef uint64_t BitBuf; > +#define AV_WBBUF AV_WB64 > +#define AV_WLBUF AV_WL64 Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/put_bits: Parametrize bit buffer type
On Fri, Jul 17, 2020 at 09:41:19PM +0200, Steinar H. Gunderson wrote:
> Preparatory patch for making the bit buffer different size on different
> platforms; make a typedef and make all the hardcoded sizes into expressions
> deriving from this size.
>
> No functional change; generated assembler is near-identical.
> ---
> libavcodec/put_bits.h | 95 +++
> 1 file changed, 52 insertions(+), 43 deletions(-)
[...]
> @@ -346,8 +352,8 @@ static inline void skip_put_bytes(PutBitContext *s, int n)
> static inline void skip_put_bits(PutBitContext *s, int n)
> {
> s->bit_left -= n;
> -s->buf_ptr -= 4 * (s->bit_left >> 5);
> -s->bit_left &= 31;
> +s->buf_ptr -= sizeof(BitBuf) * ((unsigned)s->bit_left / BUF_BITS);
> +s->bit_left &= (BUF_BITS - 1);
> }
>
> /**
> @@ -357,9 +363,12 @@ static inline void skip_put_bits(PutBitContext *s, int n)
> */
> static inline void set_put_bits_buffer_size(PutBitContext *s, int size)
> {
> -av_assert0(size <= INT_MAX/8 - 32);
> +av_assert0(size <= INT_MAX/8 - BUF_BITS);
this from libavcodec/mpegvideo_enc.c
set_put_bits_buffer_size(>pb,
FFMIN(s->thread_context[i]->pb.buf_end - s->pb.buf, INT_MAX/8-32));
needs to be updated too
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have often repented speaking, but never of holding my tongue.
-- Xenocrates
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] avfilter: add radial and circular blur video filter
On 7/18/20, Steinar H. Gunderson wrote: > On Sat, Jul 18, 2020 at 12:53:18PM +0200, Paul B Mahol wrote: >> Nope, algorithm is just fine. You are interpreting results wrongly. > > If you are not willing to tell me what is wrong with my interpretation > (outside “you are using the wrong parameters, and I won't tell you what the > right parameters are”), this is a hard claim to make. > > In short, this patch has: > > - An unusually slow algorithm (sin, cos, atan, division; all per-pixel). This is actually good. Performance is not affected at all. > - Poor output quality (strong aliasing, no subpixel precision). I fixed this. No thanks to your patch. > - No comments, hardly any commit message. No comments are needed for developers that know how to code. > > Thus, I believe it should not be merged. It is just your belief, no any proof given. > > /* Steinar */ > -- > Homepage: https://www.sesse.net/ > ___ > 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 2/2] libavcodec/jpeg2000dec: Support for PPM marker
From: Gautam Ramakrishnan
This patch adds support for PPM marker for JPEG2000
decoder. It allows the samples p1_03.j2k and p1_05.j2k
to be decoded.
---
libavcodec/jpeg2000dec.c | 111 +++
1 file changed, 101 insertions(+), 10 deletions(-)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 5043125fe3..4f380eebe8 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -71,6 +71,7 @@ typedef struct Jpeg2000POC {
typedef struct Jpeg2000TilePart {
uint8_t tile_index; // Tile index who refers the tile-part
const uint8_t *tp_end;
+GetByteContext header_tpg; // bit stream of header if PPM header
is used
GetByteContext tpg; // bit stream in tile-part
} Jpeg2000TilePart;
@@ -102,6 +103,13 @@ typedef struct Jpeg2000DecoderContext {
uint8_t cbps[4];// bits per sample in particular components
uint8_t sgnd[4];// if a component is signed
uint8_t properties[4];
+
+uint8_t has_ppm;
+uint8_t *packed_headers; // contains packed headers. Used only
along with PPM marker
+int packed_headers_size;
+GetByteContext packed_headers_stream;
+uint8_t in_tile_headers;
+
int cdx[4], cdy[4];
int precision;
int ncomponents;
@@ -928,6 +936,31 @@ static int get_plt(Jpeg2000DecoderContext *s, int n)
return 0;
}
+static int get_ppm(Jpeg2000DecoderContext *s, int n)
+{
+void *new;
+
+if (n < 3) {
+av_log(s->avctx, AV_LOG_ERROR, "Invalid length for PPM data.\n");
+return AVERROR_INVALIDDATA;
+}
+s->has_ppm = 1;
+bytestream2_get_byte(>g); //Zppm is skipped and not used
+new = av_realloc(s->packed_headers,
+ s->packed_headers_size + n - 3);
+if (new) {
+s->packed_headers = new;
+} else
+return AVERROR(ENOMEM);
+memset(>packed_headers_stream, 0, sizeof(s->packed_headers_stream));
+memcpy(s->packed_headers + s->packed_headers_size,
+ s->g.buffer, n - 3);
+s->packed_headers_size += n - 3;
+bytestream2_skip(>g, n - 3);
+
+return 0;
+}
+
static int get_ppt(Jpeg2000DecoderContext *s, int n)
{
Jpeg2000Tile *tile;
@@ -1039,8 +1072,19 @@ static int getlblockinc(Jpeg2000DecoderContext *s)
return res;
}
-static inline void select_stream(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile,
+static inline void select_header(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile,
int *tp_index)
+{
+s->g = tile->tile_part[*tp_index].header_tpg;
+if (bytestream2_get_bytes_left(>g) == 0 && s->bit_index == 8) {
+if (*tp_index < FF_ARRAY_ELEMS(tile->tile_part) - 1) {
+s->g = tile->tile_part[++(*tp_index)].tpg;
+}
+}
+}
+
+static inline void select_stream(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile,
+ int *tp_index, Jpeg2000CodingStyle *codsty)
{
s->g = tile->tile_part[*tp_index].tpg;
if (bytestream2_get_bytes_left(>g) == 0 && s->bit_index == 8) {
@@ -1048,8 +1092,12 @@ static inline void select_stream(Jpeg2000DecoderContext
*s, Jpeg2000Tile *tile,
s->g = tile->tile_part[++(*tp_index)].tpg;
}
}
-if (bytestream2_peek_be32(>g) == JPEG2000_SOP_FIXED_BYTES)
-bytestream2_skip(>g, JPEG2000_SOP_BYTE_LENGTH);
+if (codsty->csty & JPEG2000_CSTY_SOP) {
+if (bytestream2_peek_be32(>g) == JPEG2000_SOP_FIXED_BYTES)
+bytestream2_skip(>g, JPEG2000_SOP_BYTE_LENGTH);
+else
+av_log(s->avctx, AV_LOG_ERROR, "SOP marker not found. instead
%X\n", bytestream2_peek_be32(>g));
+}
}
static int jpeg2000_decode_packet(Jpeg2000DecoderContext *s, Jpeg2000Tile
*tile, int *tp_index,
@@ -1064,10 +1112,12 @@ static int
jpeg2000_decode_packet(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile,
return 0;
rlevel->band[0].prec[precno].decoded_layers = layno + 1;
// Select stream to read from
-if (tile->has_ppt)
+if (s->has_ppm)
+select_header(s, tile, tp_index);
+else if (tile->has_ppt)
s->g = tile->packed_headers_stream;
else
-select_stream(s, tile, tp_index);
+select_stream(s, tile, tp_index, codsty);
if (!(ret = get_bits(s, 1))) {
jpeg2000_flush(s);
@@ -1178,9 +1228,12 @@ static int jpeg2000_decode_packet(Jpeg2000DecoderContext
*s, Jpeg2000Tile *tile,
}
// Save state of stream
-if (tile->has_ppt) {
+if (s->has_ppm) {
+tile->tile_part[*tp_index].header_tpg = s->g;
+select_stream(s, tile, tp_index, codsty);
+} else if (tile->has_ppt) {
tile->packed_headers_stream = s->g;
-select_stream(s, tile, tp_index);
+select_stream(s, tile, tp_index, codsty);
}
for (bandno = 0; bandno < rlevel->nbands; bandno++) {
Jpeg2000Band *band
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/put_bits: Make bit buffers 64-bit
On Sat, Jul 18, 2020 at 11:53:44AM +0200, Michael Niedermayer wrote: >> +#if ARCH_AARCH64 || ARCH_IA64 || ARCH_MIPS64 || ARCH_SPARC64 || ARCH_X86_64 > this needs a #include "config.h" or something equivalent Sounds right, will fix. /* Steinar */ -- Homepage: https://www.sesse.net/ ___ 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] avfilter: add radial and circular blur video filter
On Sat, Jul 18, 2020 at 12:53:18PM +0200, Paul B Mahol wrote: > Nope, algorithm is just fine. You are interpreting results wrongly. If you are not willing to tell me what is wrong with my interpretation (outside “you are using the wrong parameters, and I won't tell you what the right parameters are”), this is a hard claim to make. In short, this patch has: - An unusually slow algorithm (sin, cos, atan, division; all per-pixel). - Poor output quality (strong aliasing, no subpixel precision). - No comments, hardly any commit message. Thus, I believe it should not be merged. /* Steinar */ -- Homepage: https://www.sesse.net/ ___ 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] avfilter: add radial and circular blur video filter
On 7/18/20, Steinar H. Gunderson wrote: > On Sat, Jul 18, 2020 at 11:06:17AM +0200, Paul B Mahol wrote: > The above picture pretty clearly shows otherwise...? Could you tell me > where my confusion would lie? The filter option amount/angle set is very small. >>> It's the default value. Could you recommend a command line? >> Unless you want to propose patch, no. > > OK, so the defaults create a broken image, and you're not willing to tell me > what parameters to use without me proposing a patch? (What would that patch > do?) > > I tried setting angle=50, and got > > http://storage.sesse.net/ffmpeg-radialblur2.png > > which looks more like a radial blur, but still is broken. Note the strong > aliasing (starburst) in the center, the jagged thick white lines (more > aliasing) on the left and right sides, and the fact that the vertical white > lines are all but gone. > > If a blur creates strong high-frequency components (ie., the very opposite > of > what a blur is supposed to do), it is a strong signal that the algorithm > chosen is just fundamentally wrong. Nope, algorithm is just fine. You are interpreting results wrongly. > > /* Steinar */ > -- > Homepage: https://www.sesse.net/ > ___ > 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] avfilter: add radial and circular blur video filter
On Sat, Jul 18, 2020 at 11:06:17AM +0200, Paul B Mahol wrote: The above picture pretty clearly shows otherwise...? Could you tell me where my confusion would lie? >>> The filter option amount/angle set is very small. >> It's the default value. Could you recommend a command line? > Unless you want to propose patch, no. OK, so the defaults create a broken image, and you're not willing to tell me what parameters to use without me proposing a patch? (What would that patch do?) I tried setting angle=50, and got http://storage.sesse.net/ffmpeg-radialblur2.png which looks more like a radial blur, but still is broken. Note the strong aliasing (starburst) in the center, the jagged thick white lines (more aliasing) on the left and right sides, and the fact that the vertical white lines are all but gone. If a blur creates strong high-frequency components (ie., the very opposite of what a blur is supposed to do), it is a strong signal that the algorithm chosen is just fundamentally wrong. /* Steinar */ -- Homepage: https://www.sesse.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/put_bits: Make bit buffers 64-bit
On Fri, Jul 17, 2020 at 09:41:20PM +0200, Steinar H. Gunderson wrote: > Change BitBuf into uint64_t on all supported 64-bit platforms. > This means we need to flush the buffer less often, which is a > significant speed win. 32-bit platforms are unchanged. > Output bitstream is the same. > > All API constraints are kept in place, e.g., you still cannot put_bits() > more than 31 bits at a time. This is so that codecs cannot accidentally > become 64-bit-only or similar. > > Benchmarking on transcoding to various formats shows consistently > positive results: > > dnxhd 25.60 fps -> 26.26 fps ( +2.6%) > dvvideo 24.88 fps -> 25.17 fps ( +1.2%) > ffv1 14.32 fps -> 14.58 fps ( +1.8%) > huffyuv 58.75 fps -> 63.27 fps ( +7.7%) > jpegls 6.22 fps -> 6.34 fps ( +1.8%) > mjpeg 48.65 fps -> 49.01 fps ( +0.7%) > mpeg1video76.41 fps -> 77.01 fps ( +0.8%) > mpeg2video75.99 fps -> 77.43 fps ( +1.9%) > mpeg4 80.66 fps -> 81.37 fps ( +0.9%) > prores12.35 fps -> 12.88 fps ( +4.3%) > prores_ks 16.20 fps -> 16.80 fps ( +3.7%) > rv20 62.80 fps -> 62.99 fps ( +0.3%) > utvideo 68.41 fps -> 76.32 fps (+11.6%) > > Note that this includes video decoding and all other encoding work, > such as DCTs. If you isolate the actual bit-writing routines, it is > likely to be much more. > > Benchmark details: Transcoding the first 30 seconds of Big Buck Bunny > in 1080p, Haswell 2.1 GHz, GCC 8.3, generally quantizer locked to > 5.0. (Exceptions: DNxHD needs fixed bitrate, and JPEG-LS is so slow > that I only took the first 10 seconds, not 30.) All runs were done > ten times and single-threaded, top and bottom two results discarded to > get rid of outliers, arithmetic mean between the remaining six. > --- > libavcodec/put_bits.h | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/libavcodec/put_bits.h b/libavcodec/put_bits.h > index c6a8f3ac14..d09c998991 100644 > --- a/libavcodec/put_bits.h > +++ b/libavcodec/put_bits.h > @@ -32,9 +32,15 @@ > #include "libavutil/intreadwrite.h" > #include "libavutil/avassert.h" > > +#if ARCH_AARCH64 || ARCH_IA64 || ARCH_MIPS64 || ARCH_SPARC64 || ARCH_X86_64 this needs a #include "config.h" or something equivalent thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6 0/7] Add support for encoding adpcm_ima_apm and muxing to apm.
On Wed, 08 Jul 2020 12:54:46 + "Zane van Iperen" wrote: > > v6: [8] > * split out header and extradata fixes > * add more-descriptive commit messages > * fix bit_rate overflow > Will rebase and push in the next few days if no objections. ___ 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] avfilter: add radial and circular blur video filter
On 7/18/20, Steinar H. Gunderson wrote: > On Sat, Jul 18, 2020 at 10:28:21AM +0200, Paul B Mahol wrote: >>> The above picture pretty clearly shows otherwise...? Could you tell me >>> where >>> my confusion would lie? >> The filter option amount/angle set is very small. > > It's the default value. Could you recommend a command line? Unless you want to propose patch, no. > > /* Steinar */ > -- > Homepage: https://www.sesse.net/ > ___ > 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] avfilter: add radial and circular blur video filter
On Sat, Jul 18, 2020 at 10:28:21AM +0200, Paul B Mahol wrote: >> The above picture pretty clearly shows otherwise...? Could you tell me where >> my confusion would lie? > The filter option amount/angle set is very small. It's the default value. Could you recommend a command line? /* Steinar */ -- Homepage: https://www.sesse.net/ ___ 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] avfilter: add radial and circular blur video filter
On 7/18/20, Steinar H. Gunderson wrote: > On Sat, Jul 18, 2020 at 10:17:27AM +0200, Paul B Mahol wrote: >>> https://storage.sesse.net/ffmpeg-radialblur.png >> You are deeply confused, filters are working just fine. > > The above picture pretty clearly shows otherwise...? Could you tell me where > my confusion would lie? The filter option amount/angle set is very small. > > /* Steinar */ > -- > Homepage: https://www.sesse.net/ > ___ > 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] avfilter: add radial and circular blur video filter
On Sat, Jul 18, 2020 at 10:17:27AM +0200, Paul B Mahol wrote: >> https://storage.sesse.net/ffmpeg-radialblur.png > You are deeply confused, filters are working just fine. The above picture pretty clearly shows otherwise...? Could you tell me where my confusion would lie? /* Steinar */ -- Homepage: https://www.sesse.net/ ___ 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] avfilter: add radial and circular blur video filter
On 7/17/20, Steinar H. Gunderson wrote: > On Sun, Jul 12, 2020 at 01:01:07PM +0200, Paul B Mahol wrote: >> +@section rblur >> +Apply Radial blur filter. > > I tried this; it looks very aliased and absolutely not like what I'd expect > from a > radial blur at all. > > $ wget > https://upload.wikimedia.org/wikipedia/commons/thumb/c/c1/PM5644.svg/1000px-PM5644.svg.png > $ ./ffmpeg -i 1000px-PM5644.svg.png -vf rblur ffmpeg-radialblur.png > > produces > > https://storage.sesse.net/ffmpeg-radialblur.png > > This is what the GIMP's “Zoom Blur” gives me on the same picture, and what I > expect a radial blur to look like: > > https://storage.sesse.net/gimp-radialblur.png > > The circular blur looks like the right effect, but it's again very aliased > and has some sort of accuracy problem: > > http://storage.sesse.net/ffmpeg-circularblur.png > > Look at the vertical lines in the left part of the picture; they have some > weird kind of staircase effect. > You are deeply confused, filters are working just fine. > /* Stienar */ > -- > Homepage: https://www.sesse.net/ > ___ > 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 1/2] avdevice/decklink_dec: mark the field flag if framerate > 30FPS
On Sat, 18 Jul 2020, lance.lmw...@gmail.com wrote:
On Fri, Jul 17, 2020 at 07:13:28PM +0200, Marton Balint wrote:
On Fri, 17 Jul 2020, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> In SMPTE ST 12-1: 2014 Sec 12.2, we need to mark the frame flag if the frame rate > 30FPS to
> avoid interoperability issues. It will be used by the encoder to identify
even or odd frames
> and correctly calculate the frame number of the SEI TC.
This feature looks like it belongs to av_timecode_get_smpte_from_framenum
and not into decklink. Also checking previous timecode and guessing
something is a hack, especially since you have the exact source timecode.
If I understand correctly, it's not hacky, for the framerate > 30, the source
timecode will be
frame pair(it's limited by 2bits limit of frame number ten digital. Below is
one exmaple for 50fps
if you tested with SDI with TC.
00:00:00:24
00:00:00:24
00:00:00:25
00:00:00:25
00:00:00:00
00:00:00:00
Have you actually tested this with a real SDI signal containing timecode?
Thanks,
Marton
That's why I check the last TC to get the frame is even or odd.
Why not use av_timecode_get_smpte_from_framenum(), for it's calculated by the
string TC by one time,
so it lacks the information whether it's odd or even frame.
Regards,
Marton
>
> ---
> libavdevice/decklink_common.h | 1 +
> libavdevice/decklink_dec.cpp | 14 ++
> 2 files changed, 15 insertions(+)
>
> diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
> index bd68c7b..8ddc411 100644
> --- a/libavdevice/decklink_common.h
> +++ b/libavdevice/decklink_common.h
> @@ -151,6 +151,7 @@ struct decklink_ctx {
> int channels;
> int audio_depth;
> unsigned long tc_seen;// used with option wait_for_tc
> +uint32_t last_tc;
> };
>
> typedef enum { DIRECTION_IN, DIRECTION_OUT} decklink_direction_t;
> diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
> index dde68ff..a60c01b 100644
> --- a/libavdevice/decklink_dec.cpp
> +++ b/libavdevice/decklink_dec.cpp
> @@ -884,12 +884,26 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
> int metadata_len;
> uint8_t* packed_metadata;
> AVTimecode tcr;
> +AVRational rate = ctx->video_st->r_frame_rate;
>
> if (av_timecode_init_from_string(, ctx->video_st->r_frame_rate, tc, ctx) >= 0) {
> uint32_t tc_data =
av_timecode_get_smpte_from_framenum(, 0);
> int size = sizeof(uint32_t) * 4;
> uint32_t *sd = (uint32_t
*)av_packet_new_side_data(, AV_PKT_DATA_S12M_TIMECODE, size);
>
> +/* set the field flag if frame rate > 30FPS */
> +/* Refer to SMPTE ST 12-1:2014 Sec 12.2 */
> +if (av_cmp_q(rate, (AVRational) {30, 1}) == 1) {
> +/* Odd frame */
> +if (ctx->last_tc == tc_data) {
> +if (av_cmp_q(rate, (AVRational) {50, 1})
== 0)
> +tc_data |= (1 << 7);
> +else
> +tc_data |= (1 << 23);
> +}
> +}
> +ctx->last_tc = tc_data;
> +
> if (sd) {
> *sd = 1; // one TC
> *(sd + 1) = tc_data; // TC
> --
> 2.9.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".
--
Thanks,
Limin Wang
___
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] avcodec/mips: fix type mismatch in h264dsp_msa.c
gcc warning: assignment from incompatible pointer type.
---
libavcodec/mips/h264dsp_mips.h | 24 +--
libavcodec/mips/h264dsp_msa.c | 94 ++
2 files changed, 62 insertions(+), 56 deletions(-)
diff --git a/libavcodec/mips/h264dsp_mips.h b/libavcodec/mips/h264dsp_mips.h
index 21b7de0..9b6f054 100644
--- a/libavcodec/mips/h264dsp_mips.h
+++ b/libavcodec/mips/h264dsp_mips.h
@@ -25,21 +25,21 @@
#include "libavcodec/h264dec.h"
#include "constants.h"
-void ff_h264_h_lpf_luma_inter_msa(uint8_t *src, int stride,
+void ff_h264_h_lpf_luma_inter_msa(uint8_t *src, ptrdiff_t stride,
int alpha, int beta, int8_t *tc0);
-void ff_h264_v_lpf_luma_inter_msa(uint8_t *src, int stride,
+void ff_h264_v_lpf_luma_inter_msa(uint8_t *src, ptrdiff_t stride,
int alpha, int beta, int8_t *tc0);
-void ff_h264_h_lpf_chroma_inter_msa(uint8_t *src, int stride,
+void ff_h264_h_lpf_chroma_inter_msa(uint8_t *src, ptrdiff_t stride,
int alpha, int beta, int8_t *tc0);
-void ff_h264_v_lpf_chroma_inter_msa(uint8_t *src, int stride,
+void ff_h264_v_lpf_chroma_inter_msa(uint8_t *src, ptrdiff_t stride,
int alpha, int beta, int8_t *tc0);
-void ff_h264_h_loop_filter_chroma422_msa(uint8_t *src, int32_t stride,
+void ff_h264_h_loop_filter_chroma422_msa(uint8_t *src, ptrdiff_t stride,
int32_t alpha, int32_t beta,
int8_t *tc0);
-void ff_h264_h_loop_filter_chroma422_mbaff_msa(uint8_t *src, int32_t stride,
+void ff_h264_h_loop_filter_chroma422_mbaff_msa(uint8_t *src, ptrdiff_t stride,
int32_t alpha, int32_t beta,
int8_t *tc0);
-void ff_h264_h_loop_filter_luma_mbaff_msa(uint8_t *src, int32_t stride,
+void ff_h264_h_loop_filter_luma_mbaff_msa(uint8_t *src, ptrdiff_t stride,
int32_t alpha, int32_t beta,
int8_t *tc0);
@@ -67,15 +67,15 @@ void ff_h264_idct8_add4_msa(uint8_t *dst, const int
*blk_offset,
int16_t *blk, int dst_stride,
const uint8_t nnzc[15 * 8]);
-void ff_h264_h_lpf_luma_intra_msa(uint8_t *src, int stride,
+void ff_h264_h_lpf_luma_intra_msa(uint8_t *src, ptrdiff_t stride,
int alpha, int beta);
-void ff_h264_v_lpf_luma_intra_msa(uint8_t *src, int stride,
+void ff_h264_v_lpf_luma_intra_msa(uint8_t *src, ptrdiff_t stride,
int alpha, int beta);
-void ff_h264_h_lpf_chroma_intra_msa(uint8_t *src, int stride,
+void ff_h264_h_lpf_chroma_intra_msa(uint8_t *src, ptrdiff_t stride,
int alpha, int beta);
-void ff_h264_v_lpf_chroma_intra_msa(uint8_t *src, int stride,
+void ff_h264_v_lpf_chroma_intra_msa(uint8_t *src, ptrdiff_t stride,
int alpha, int beta);
-void ff_h264_h_loop_filter_luma_mbaff_intra_msa(uint8_t *src, int stride,
+void ff_h264_h_loop_filter_luma_mbaff_intra_msa(uint8_t *src, ptrdiff_t stride,
int alpha, int beta);
void ff_biweight_h264_pixels16_8_msa(uint8_t *dst, uint8_t *src,
diff --git a/libavcodec/mips/h264dsp_msa.c b/libavcodec/mips/h264dsp_msa.c
index dd05982..a8c3f3c 100644
--- a/libavcodec/mips/h264dsp_msa.c
+++ b/libavcodec/mips/h264dsp_msa.c
@@ -21,7 +21,7 @@
#include "libavutil/mips/generic_macros_msa.h"
#include "h264dsp_mips.h"
-static void avc_wgt_4x2_msa(uint8_t *data, int32_t stride,
+static void avc_wgt_4x2_msa(uint8_t *data, ptrdiff_t stride,
int32_t log2_denom, int32_t src_weight,
int32_t offset_in)
{
@@ -48,8 +48,9 @@ static void avc_wgt_4x2_msa(uint8_t *data, int32_t stride,
ST_W2(src0, 0, 1, data, stride);
}
-static void avc_wgt_4x4_msa(uint8_t *data, int32_t stride, int32_t log2_denom,
-int32_t src_weight, int32_t offset_in)
+static void avc_wgt_4x4_msa(uint8_t *data, ptrdiff_t stride,
+int32_t log2_denom, int32_t src_weight,
+int32_t offset_in)
{
uint32_t tp0, tp1, tp2, tp3, offset_val;
v16u8 src0 = { 0 };
@@ -74,8 +75,9 @@ static void avc_wgt_4x4_msa(uint8_t *data, int32_t stride,
int32_t log2_denom,
ST_W4(src0, 0, 1, 2, 3, data, stride);
}
-static void avc_wgt_4x8_msa(uint8_t *data, int32_t stride, int32_t log2_denom,
-int32_t src_weight, int32_t offset_in)
+static void avc_wgt_4x8_msa(uint8_t *data, ptrdiff_t stride,
+int32_t log2_denom, int32_t src_weight,
+int32_t offset_in)
{
uint32_t tp0, tp1, tp2, tp3, offset_val;
v16u8 src0 = { 0 }, src1 = {
Re: [FFmpeg-devel] [PATCH] libavutil/video_enc_params: add block type
On Fri, Jul 17, 2020 at 02:25:24PM -0700, Yongle Lin wrote:
> On Wed, Jul 15, 2020 at 4:13 PM Mark Thompson wrote:
>
> > On 15/07/2020 18:43, Yongle Lin wrote:
> > > add block type field to AVVideoBlockParams so we could either export or
> > visualize it later.
> > > ---
> > > libavutil/video_enc_params.h | 19 +++
> > > 1 file changed, 19 insertions(+)
> > >
> > > diff --git a/libavutil/video_enc_params.h b/libavutil/video_enc_params.h
> > > index 43fa443154..8bf5f240c9 100644
> > > --- a/libavutil/video_enc_params.h
> > > +++ b/libavutil/video_enc_params.h
> > > @@ -57,6 +57,11 @@ enum AVVideoEncParamsType {
> > > AV_VIDEO_ENC_PARAMS_H264,
> > > };
> > >
> > > +enum AVVideoBlockFlags {
> > > +AV_VIDEO_ENC_BLOCK_INTRA = 1ULL << 0, /* Indicates block uses
> > intra prediction */
> >
> > The ULL is only confusing matters here - standard-conforming enum values
> > have type int. Some compilers allow it to be a larger integer type, but I
> > don't think we can rely on that extension.
> >
>
> I am thinking of defining a bit field struct to for type flags like what we
> did in other places:
> struct AVVideoBlockFlags {
> unsigned int intra:1;
> unsigned int skip:1;
> }
>
> Or we could use the same way of mb_type defined in H.264 like
> #define AV_VIDEO_ENC_BLOCK_INTRA 1ULL << 0
> #define AV_VIDEO_ENC_BLOCK_SKIP 1ULL << 1
>
> uint64_t b_type
>
>
> > > +AV_VIDEO_ENC_BLOCK_SKIP = 1ULL << 1, /* Indicates block is not
> > coded (skipped) */
> >
> > Can you define more precisely what you mean by "not coded"? Is that just
> > that it has no residuals, or does it also indicate no motion vector, or no
> > coded motion vector relative to prediction?
> >
>
> I want to make it more general which can be applied to more codec. So in
> VP9, there is a skip flag to indicate if the block has residual
> coefficients. As for H.264 you mentioned there are P_Skip and B_Skip, I
> think both of them should be considered as skip.
If you want to make it general, maybe use multiple skip flags with clear meaning
SKIP_CODED_RESIDUAL // No residual coded, the block may have a predicted
residual
SKIP_CODED_MVD // No motion vector difference coded, the block may have a
non 0 motion vector
ZERO_RESIDUAL// Block has no residual
ZERO_MV // Block has a 0,0 motion vector
also in light of motion vectors, the intra AC prediction mode / direction
should probably be exported, its kind of the equivalent of what motion
vectors are in inter blocks but for intra
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
There will always be a question for which you do not know the correct answer.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [aarch64] improve hscale by 50% with multi-threading
On Fri, Jul 17, 2020 at 11:08:02PM -0500, Sebastian Pop wrote: > hscale is bound by the number of multiply-adds available on a given core. > The attached patch doubles the number of multiply-adds by distributing half > the load to a helper thread. > > The performance improves up to 50% on Graviton2 Arm Neoverse-N1 processors. > > $ ./ffmpeg_g -nostats -f lavfi -i testsrc2=4k:d=2 -vf > bench=start,scale=1024x1024,bench=stop -f null - > before: [bench @ 0xd62c3d30] t:0.013293 avg:0.013315 max:0.013697 > min:0.013293 > after: [bench @ 0xe9346d30] t:0.009637 avg:0.009691 max:0.010005 > min:0.009637 > 38% improvement > > scale=1280x720 49% improvement > before: [bench @ 0xdba88d30] t:0.015973 avg:0.016321 max:0.016917 > min:0.015973 > after: [bench @ 0xbc78dd30] t:0.010823 avg:0.010869 max:0.011552 > min:0.010708 > > scale=852x480 45% improvement > before: [bench @ 0xeeed0d30] t:0.013731 avg:0.013727 max:0.013773 > min:0.013279 > after: [bench @ 0xf5f5dd30] t:0.009279 avg:0.009296 max:0.009328 > min:0.009187 > > scale=640x360 45% improvement > before: [bench @ 0xcee25d30] t:0.012010 avg:0.012006 max:0.012053 > min:0.011653 > after: [bench @ 0xea2b5d30] t:0.008077 avg:0.008084 max:0.008409 > min:0.008057 > > scale=284x160 36% improvement > before: [bench @ 0xdbb9ed30] t:0.008384 avg:0.008367 max:0.008421 > min:0.008193 > after: [bench @ 0xfb1d6d30] t:0.006099 avg:0.006100 max:0.006120 > min:0.006026 > aarch64/swscale.c | 44 +++- > swscale_internal.h | 15 +++ > utils.c| 14 ++ > 3 files changed, 72 insertions(+), 1 deletion(-) > 9a65bd72cd0a37e73a554e568b34f9d6bb27cb58 > 0001-aarch64-improve-hscale-by-50-with-multi-threading.patch > From 3321950c109b416e63eda59c76e6365abc2072b8 Mon Sep 17 00:00:00 2001 > From: Sebastian Pop > Date: Thu, 2 Jul 2020 16:57:58 + > Subject: [PATCH] [aarch64] improve hscale by 50% with multi-threading Multithreading support should be added in a architecture independant way Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell 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".
