The code using ff_exp2 (namely ff_acelp_decode_gain_code) use it only if
G729_BITEXACT is defined. So disable it if not.
Signed-off-by: Andreas Rheinhardt
---
Alternatively one can also remove the G729_BITEXACT code altogether.
libavcodec/celp_math.c | 2 ++
1 file changed, 2 insertions(+)
Signed-off-by: Andreas Rheinhardt
---
libavcodec/x86/diracdsp_init.c | 38 ++
1 file changed, 2 insertions(+), 36 deletions(-)
diff --git a/libavcodec/x86/diracdsp_init.c b/libavcodec/x86/diracdsp_init.c
index 8633c66743..8baacf3129 100644
---
Signed-off-by: Andreas Rheinhardt
---
libavcodec/x86/diracdsp_init.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/libavcodec/x86/diracdsp_init.c b/libavcodec/x86/diracdsp_init.c
index cd663f2d23..8633c66743 100644
---
This allowed to remove forward declarations. Because compilers expect
declarations for all functions they encounter even when it is within
blocks disabled via "if (0 && foo)", one has to use a real #if in
ff_diracdsp_init_x86.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/x86/diracdsp_init.c
Unused since 80944df720da98d6e5ee0e355db5814735914ec9.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/x86/constants.c| 1 -
libavcodec/x86/h264_intrapred.asm | 4
2 files changed, 5 deletions(-)
diff --git a/libavcodec/x86/constants.c b/libavcodec/x86/constants.c
index
Unused since a1f3b18bf55f106c974eacb1dc831be4d2bd5277, yet as nonstatic
functions the compiler can't detect this, so that these functions aren't
stripped and no warning is emitted.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/x86/diracdsp_init.c | 7 ---
1 file changed, 7 deletions(-)
The last user of g15Mask, r15Mask, g16Mask and r16Mask was disabled
in 77a416e8aab77058b542030870fd7178b62d2a62 and finally removed in
36e8de07ed62609df45d064b56501e3084d25723; b15Mask and b16Mask were
apparently always unused (except for in_asm_used_var_warning_killer,
a function that only
Signed-off-by: Andreas Rheinhardt
---
libavcodec/acelp_vectors.c | 11 ---
libavcodec/acelp_vectors.h | 1 -
2 files changed, 12 deletions(-)
diff --git a/libavcodec/acelp_vectors.c b/libavcodec/acelp_vectors.c
index 798217d73b..0d4de0e4c3 100644
--- a/libavcodec/acelp_vectors.c
+++
mmx_grnmask is unused since 531f97b0c32d1d421f3ac614e002c53951658115,
the other constants since e934194b6a4159b7960cabefb0dd8b998c1961e8.
Signed-off-by: Andreas Rheinhardt
---
libswscale/x86/yuv2rgb.c | 8
1 file changed, 8 deletions(-)
diff --git a/libswscale/x86/yuv2rgb.c
mask24hh etc. are unused since f099fbf5f3ac1d6b3753fc8dfda6558572111fbd,
mask32b and mask32r since 296609f859a587575b91fe9e9691f2707d6e8136,
mask32g since b38d487466e68bd6baf2889017d2a751831560f0 and mask32 since
f8a138be5257f751ef7d3c6b7ab534c0434e90e7.
Signed-off-by: Andreas Rheinhardt
---
ff_acelp_decode_8bit_to_1st_delay3, ff_acelp_decode_4bit_to_2nd_delay3
and ff_acelp_decode_5_6_bit_to_2nd_delay3 are all only used once (by
g729dec) whereas ff_acelp_decode_9bit_to_1st_delay6 and
ff_acelp_decode_6bit_to_2nd_delay6 are completely unused; with the
possible exception of
It is only used there.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/rangecoder.c | 19 ---
libavcodec/rangecoder.h | 9 -
libavcodec/tests/rangecoder.c | 28 +++-
3 files changed, 27 insertions(+), 29 deletions(-)
diff --git
Unused since 4624656797b667eb6405186682eb04e74dfd90fd.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mqc.h| 3 ---
libavcodec/mqcenc.c | 5 -
2 files changed, 8 deletions(-)
diff --git a/libavcodec/mqc.h b/libavcodec/mqc.h
index 8bf7223d41..73604d5efe 100644
--- a/libavcodec/mqc.h
Added in 0c79b1402a48a99f32435a0f5ad2364c58c6fcf3 to use it a function
that was never used and was itself removed in
676f1f533e2c2960d81784188592a066b9ff1c3d.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ac3tab.c | 13 -
libavcodec/ac3tab.h | 1 -
2 files changed, 14
It is only used inside code guarded by #ifdef DEBUG, i.e. it is normally
unused.
Signed-off-by: Andreas Rheinhardt
---
libavformat/asf.c | 6 --
libavformat/asf.h | 1 -
libavformat/asfdec_f.c | 8 +++-
3 files changed, 7 insertions(+), 8 deletions(-)
diff --git
Below are the example steps to do object detection:
1. download and install l_openvino_toolkit_p_2021.1.110.tgz from
https://software.intel.com/content/www/us/en/develop/tools/openvino-toolkit/download.html
or, we can get source code (tag 2021.1), build and install.
2. export LD_LIBRARY_PATH
Signed-off-by: Guo, Yejun
---
libavfilter/f_sidedata.c | 2 ++
libavfilter/vf_showinfo.c | 38 ++
2 files changed, 40 insertions(+)
diff --git a/libavfilter/f_sidedata.c b/libavfilter/f_sidedata.c
index 3757723375..912fb0d881 100644
---
Signed-off-by: Guo, Yejun
---
doc/APIchanges | 2 ++
libavutil/frame.c | 1 +
libavutil/frame.h | 7 +++
libavutil/version.h | 2 +-
4 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index c353d2d281..3c6e9e351e 100644
---
They will be used for filters such as detect and classify.
Signed-off-by: Guo, Yejun
---
libavfilter/bbox.h | 45 +
1 file changed, 45 insertions(+)
diff --git a/libavfilter/bbox.h b/libavfilter/bbox.h
index 116158d59e..7c63dfa727 100644
---
Some function had exceed 30 inline assembly register oprands limiation
when using LOONGSON2 version of MMI macros. We can avoid that by take
$at, which is register reserved for assembler, as temporary register.
As none of instructions used in these macros is pseudo, it is safe to
utilize $at
Loongson3's extention instructions (prefixed with gs) are widely used
in our MMI codebase. However, these instructions are not avilable on
Loongson-2E/F while MMI code should work on these processors.
Previously we introduced mmiutils marcos to provide backward compactbility
but newly commited
We're doing some fancy hacks with load store with shift C1
beside unaligned load store. Create a marco for l/r pair
to allow us use it in these places.
Signed-off-by: Jiaxun Yang
---
libavutil/mips/mmiutils.h | 49 ---
1 file changed, 30 insertions(+), 19
{SAVE,RECOVER}_REG will be avilable for Loongson2 again,
also comment about the magic.
Signed-off-by: Jiaxun Yang
---
libavutil/mips/mmiutils.h | 32 +---
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/libavutil/mips/mmiutils.h
Get MMI optimizations build for Loongson-2 again.
Tested on Loongson-2 and Loongson-3A.
Jiaxun Yang (4):
avutil/mips: Use MMI_{L,S}QC1 macro in {SAVE,RECOVER}_REG
avutil/mips: Extract load store with shift C1 pair marco
avcodec/mips: Use MMI marcos to replace Loongson3 instructions
From: "Chen,Wenbin"
Fix #9095. Qsv decoder assume that after calling seek funcion, the first
frame should be key frame. However this is not true for some videos. If
the frame is not key frame after seek(), there will be error. Conditional
statements are added to skip these frame until reading a
>
>
>
> > All h266 conformance test clips will not detect as other formats. But if
> > you have a well-designed clip, it may be. This is normal case for a raw
> > bytestream detector.
>
> I'm mainly asking because the H.264 probe function does check some PS IDs
> to have a bit more confidence that
Signed-off-by: Paul B Mahol
---
libavcodec/cfhdencdsp.c | 3 +
libavcodec/x86/Makefile | 2 +
libavcodec/x86/cfhdencdsp.asm| 426 +++
libavcodec/x86/cfhdencdsp_init.c | 46
4 files changed, 477 insertions(+)
create mode 100644
Feb 18, 2021, 16:43 by geo...@nsup.org:
> Lynne (12021-02-17):
>
>> It's more actively developed by a large margin, and I generally
>>
>
> This is an interesting argument.
>
>> prefer its API and how it works internally.
>>
>
> Can you give more details? Which differences make you prefer it?
>
>
Signed-off-by: Paul B Mahol
---
libavcodec/cfhdenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/cfhdenc.c b/libavcodec/cfhdenc.c
index 9c8ba3700c..b2993cf2a9 100644
--- a/libavcodec/cfhdenc.c
+++ b/libavcodec/cfhdenc.c
@@ -742,7 +742,7 @@ static int
Signed-off-by: Paul B Mahol
---
libavcodec/cfhdenc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/cfhdenc.c b/libavcodec/cfhdenc.c
index 1e89ffc41c..9c8ba3700c 100644
--- a/libavcodec/cfhdenc.c
+++ b/libavcodec/cfhdenc.c
@@ -270,10 +270,10 @@ static
This is needed to implement x86 SIMD.
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 2 +-
libavcodec/cfhdenc.c| 123 +++-
libavcodec/cfhdencdsp.c | 76 +
libavcodec/cfhdencdsp.h | 41 ++
4 files changed,
To Andreas Rheinhardt,
You are right. The last byte 0x80 is rbsp_trailing_bits.
Before macOS 11 there is no problem of the generated SEI.
To Rick Kern,
After macOS 11, the encoded SEI nalu length changes from 20
to 25, the following code should help you to confirm it.
Place these code to
On 2/17/2021 5:24 PM, Paul B Mahol wrote:
On Tue, Feb 16, 2021 at 6:31 PM Alan Kelly <
alankelly-at-google@ffmpeg.org> wrote:
Looks like there are no comments, is this OK to be applied? Thanks
Applied, thanks for pinging.
Valgrind complains about this change. The checkasm test
Mark Thompson (12021-02-18):
> I wrote the last packet a second ago and got a callback for
> writeability from the loop, but didn't have anything to write back
> then so I did nothing.
>
> Now I have a packet to write, but the event loop is sitting idle in its
> poll() call.
>
> You've said I'm
On 18/02/2021 08:47, Nuo Mi wrote:
On Thu, Feb 18, 2021 at 6:52 AM Mark Thompson wrote:
On 17/02/2021 01:51, Nuo Mi wrote:
+for (i = 0; i < p->buf_size - 1; i++) {
+code = (code << 8) + p->buf[i];
+if ((code & 0xff00) == 0x100) {
+uint8_t nal2 = p->buf[i +
On 18/02/2021 21:44, Nicolas George wrote:
Mark Thompson (12021-02-18):
When is the callback for an output stream called? What if it doesn't
have a packet available to write right now, but will do later?
It will be called when data has been written, of course. If there is no
data to write,
On 18/02/2021 15:20, Nuo Mi wrote:
+return AVERROR(ENOMEM);
+}
+h266->ph = (H266RawPH*)h266->ph_ref->data;
+memcpy(h266->ph, >sh_picture_header,
sizeof(H266RawPH));
This memcpy() is naughty - if that was a ref to a previous picture header
then you've
On 18/02/2021 15:14, Nuo Mi wrote:
On Thu, Feb 18, 2021 at 8:04 AM Mark Thompson wrote:
On 17/02/2021 01:51, Nuo Mi wrote:
---
configure |2 +
libavcodec/Makefile |1 +
libavcodec/cbs.c |6 +
On Thu, Feb 18, 2021 at 1:26 PM James Zern
wrote:
> On Thu, Feb 18, 2021 at 11:01 AM Wonkap Jang
> wrote:
> >
> > Getting rid of unnecessary use of AVDictionary object in parsing
> > vpx_svc_ref_frame_config.
> > ---
> > libavcodec/libvpxenc.c | 73 +++---
>
Mark Thompson (12021-02-18):
> When is the callback for an output stream called? What if it doesn't
> have a packet available to write right now, but will do later?
It will be called when data has been written, of course. If there is no
data to write, the stream is just idle.
> I think this
On Thu, Feb 18, 2021 at 11:01 AM Wonkap Jang
wrote:
>
> Getting rid of unnecessary use of AVDictionary object in parsing
> vpx_svc_ref_frame_config.
> ---
> libavcodec/libvpxenc.c | 73 +++---
> 1 file changed, 55 insertions(+), 18 deletions(-)
>
lgtm, just a
On 18/02/2021 20:55, Nicolas George wrote:
Mark Thompson (12021-02-18):
If the existing remote-socket-only poll is sufficent (so no local
events), then I think I have misunderstood your original definition of
the event loop because I was expecting that other threads would be
able to interact
Mark Thompson (12021-02-18):
> If the existing remote-socket-only poll is sufficent (so no local
> events), then I think I have misunderstood your original definition of
> the event loop because I was expecting that other threads would be
> able to interact with it.
Threading is one of the goals,
On 18/02/2021 15:39, Nicolas George wrote:
Mark Thompson (12021-02-17):
I'm not sure you can avoid writing Windows code for this to work at
all, because I don't think poll() as we have now is sufficient to get
the functionality you want.
I'm sure I can avoid writing Windows code, because, as
On 2/18/2021 11:41 AM, James Almer wrote:
This includes removing pointless static function forward declarations.
Signed-off-by: James Almer
---
libswscale/x86/swscale.c | 40 ++-
libswscale/x86/swscale_template.c | 1 -
2 files changed, 23
Wonkap Jang (12021-02-18):
> Getting rid of unnecessary use of AVDictionary object in parsing
> vpx_svc_ref_frame_config.
> ---
> libavcodec/libvpxenc.c | 73 +++---
> 1 file changed, 55 insertions(+), 18 deletions(-)
No more remarks from me. Thanks.
Regards,
Getting rid of unnecessary use of AVDictionary object in parsing
vpx_svc_ref_frame_config.
---
libavcodec/libvpxenc.c | 73 +++---
1 file changed, 55 insertions(+), 18 deletions(-)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index
Wonkap Jang (12021-02-17):
> Getting rid of unnecessary use of AVDictionary object in parsing
> vpx_svc_ref_frame_config.
> ---
> libavcodec/libvpxenc.c | 76 --
> 1 file changed, 58 insertions(+), 18 deletions(-)
Thanks for the updated patch. It looks
Here is the reworked patch properly attached.
Sorry about the duplicate mail, I just noticed I had a mishap with my
mail client and the previous patch was scrubbed.
Signed-off-by: Philip-Dylan Gleonec
Co-developed-by: Steinar H. Gunderson
---
libavcodec/libopusdec.c | 107
On Wed, Feb 17, 2021 at 4:41 PM Wonkap Jang wrote:
> Getting rid of unnecessary use of AVDictionary object in parsing
> vpx_svc_ref_frame_config.
> ---
> libavcodec/libvpxenc.c | 76 --
> 1 file changed, 58 insertions(+), 18 deletions(-)
>
> diff --git
Lynne (12021-02-17):
> It's more actively developed by a large margin, and I generally
This is an interesting argument.
> prefer its API and how it works internally.
Can you give more details? Which differences make you prefer it?
One of the things that I like about libev is that it makes
Mark Thompson (12021-02-17):
> I'm not sure you can avoid writing Windows code for this to work at
> all, because I don't think poll() as we have now is sufficient to get
> the functionality you want.
I'm sure I can avoid writing Windows code, because, as I have already
pointed, our current
>
>> > +return AVERROR(ENOMEM);
>> > +}
>> > +h266->ph = (H266RawPH*)h266->ph_ref->data;
>> > +memcpy(h266->ph, >sh_picture_header,
>> sizeof(H266RawPH));
>>
>> This memcpy() is naughty - if that was a ref to a previous picture header
>> then you've just
On Thu, Feb 18, 2021 at 8:04 AM Mark Thompson wrote:
> On 17/02/2021 01:51, Nuo Mi wrote:
> > ---
> > configure |2 +
> > libavcodec/Makefile |1 +
> > libavcodec/cbs.c |6 +
> > libavcodec/cbs_h2645.c
This includes removing pointless static function forward declarations.
Signed-off-by: James Almer
---
libswscale/x86/swscale.c | 40 ++-
libswscale/x86/swscale_template.c | 1 -
2 files changed, 23 insertions(+), 18 deletions(-)
diff --git
Andreas Rheinhardt:
>>> Could you elaborate?
>>> I would have expected that the normal use case is not have a
>>> lossy input and that the new feature is always useful if data
>>> was lost.
>>
>> The use-case for FEC is typically RTP stream where audio is compressed
>> with opus. In that case,
Set pushed with all Martin's changes implemented. More NEON & updates soon.
--
Josh
On 2021-02-04 12:32, Josh Dekker wrote:
Hi,
Rebases the unpushed part of my patches on top of Reimar's set. Also
implements Martin's suggestions except 'unrolling the loop' for SAO band
function, will update
Andreas Rheinhardt:
> The MPEG-PS muxer uses a custom queue of custom packets. To keep track
> of it, it has a pointer (named predecode_packet) to the head of the
> queue and a pointer to where the next packet is to be added (it points
> to the next-pointer of the last element of the queue);
Andreas Rheinhardt:
> This patch also fixes a -Wtautological-constant-out-of-range-compare
> warning from Clang and a -Wtype-limits warning from GCC on systems
> where size_t is 64bits and unsigned 32bits. The reason for this seems
> to be that variable (whose value derives from sizeof() and can
Quoting Paul B Mahol (2021-02-18 13:27:26)
> On Thu, Feb 18, 2021 at 1:15 PM Anton Khirnov wrote:
>
> > Quoting Paul B Mahol (2021-02-17 14:33:25)
> > > On Wed, Feb 17, 2021 at 12:31 PM Anton Khirnov
> > wrote:
> > >
> > > Is helgrind report clean with your patch set?
> >
> > Helgrind is not
On Thu, Feb 18, 2021 at 1:15 PM Anton Khirnov wrote:
> Quoting Paul B Mahol (2021-02-17 14:33:25)
> > On Wed, Feb 17, 2021 at 12:31 PM Anton Khirnov
> wrote:
> >
> > Is helgrind report clean with your patch set?
>
> Helgrind is not clean before your patch, after your patch, or after my
> set.
Quoting Paul B Mahol (2021-02-17 14:34:18)
> On Wed, Feb 17, 2021 at 12:33 PM Anton Khirnov wrote:
>
> > Quoting Paul B Mahol (2021-02-17 11:52:31)
> > > On Tue, Feb 16, 2021 at 9:26 PM Anton Khirnov wrote:
> > > > @@ -1088,23 +1084,23 @@ static int handle_p_frame_apng(AVCodecContext
> > > >
Quoting Paul B Mahol (2021-02-17 14:33:25)
> On Wed, Feb 17, 2021 at 12:31 PM Anton Khirnov wrote:
>
> Is helgrind report clean with your patch set?
Helgrind is not clean before your patch, after your patch, or after my
set. The reason is because helgrind does not understand atomics, so its
On Thu, Feb 18, 2021 at 6:52 AM Mark Thompson wrote:
> On 17/02/2021 01:51, Nuo Mi wrote:
>
> > +for (i = 0; i < p->buf_size - 1; i++) {
> > +code = (code << 8) + p->buf[i];
> > +if ((code & 0xff00) == 0x100) {
> > +uint8_t nal2 = p->buf[i + 1];
> > +
>
>
>
> > +enum {
> > +//6.2 we can have 3 sample arrays
> > +MAX_SAMPLE_ARRAYS = 3,
>
> Needs the "VVC_" prefix.
>
fixed
>
> > +
> > +//7.4.3.3 vps_max_layers_minus1 is u(6)
> > +VVC_MAX_LAYERS = 64,
> > +
> > +//7.4.3.3 The value of vps_max_sublayers_minus1 shall be in the
>
mån 2021-02-15 klockan 17:55 +0100 skrev Andreas Rheinhardt:
> Doing so is still bitexact.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/mxfenc.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index
66 matches
Mail list logo
