On 28-07-2018 03:33 AM, Tomas Härdin wrote:
woot! I didn't know the mov demuxer dumped such things. It is quite
slow however, since it will scan through every leaf atom in the file.
For example, running time ffmpeg -i input.mov -v 56 2>&1 | wc on a 1.5
GiB MP4 on an SSD takes:
Use the subfil
Signed-off-by: James Almer
---
fftools/cmdutils.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index b8de319fe4..9cfbc45c2b 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -1956,7 +1956,10 @@ static void show_help_bsf(
Fixes crashes like "ffmpeg -h bsf" caused by passing NULL to strcmp()
Signed-off-by: James Almer
---
libavcodec/bitstream_filters.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index c21373621c..3433921554 100644
--- a/lib
Signed-off-by: hwren
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 234b655..40186d1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -143,6 +143,7 @@ Codecs:
asv* Michael Niedermayer
atrac3plus*
On 7/27/2018 10:58 PM, Michael Niedermayer wrote:
> On Fri, Jul 27, 2018 at 11:57:49AM -0300, James Almer wrote:
>> Certain AVCodecParameters, like the contents of the extradata, may be changed
>> by the init() function of any of the bitstream filters in the chain.
>>
>> Signed-off-by: James Almer
On Fri, Jul 27, 2018 at 11:57:49AM -0300, James Almer wrote:
> Certain AVCodecParameters, like the contents of the extradata, may be changed
> by the init() function of any of the bitstream filters in the chain.
>
> Signed-off-by: James Almer
> ---
> Now it's not going to be called after the code
On Fri, Jul 27, 2018 at 08:06:15PM +0300, Sergey Lavrushkin wrote:
> Hello,
>
> The first patch provides on the fly generation of default DNN models,
> that eliminates data duplication for model weights. Also, files with
> internal weights
> were replaced with automatically generated one for model
On Sat, Sep 02, 2017 at 09:22:17AM +, Andrew Sun wrote:
> This commit adds support for 32-bpc YUV-based floating-point pixel formats.
> ---
> doc/APIchanges | 2 ++
> libavutil/pixdesc.c | 75
> +
> libavutil/pixfmt.h | 11
>
On Fri, Jul 27, 2018 at 05:27:44PM +0530, Naveed Basha wrote:
> Hi All,
>
> I used av_read_frame to get the AVPacket from encoded h264 file. But when
> this packet (00 00 01 05 94 5a 33 e7 4d 6b d7 ad 13 86 ff 47 83 93 31 f1 e3
> 0a) is in the input stream (h264 video) ffmpeg decoder stops decodin
On Fri, Jul 27, 2018 at 11:42:57AM -0300, James Almer wrote:
> On 7/27/2018 7:22 AM, Danil Iashchenko wrote:
> > Add lumakey_opencl filter. Behaves like existing lumakey filter.
> >
> > ---
> >
> > On Wed, Jul 25, 2018 at 10:50:43AM -0300, James Almer wrote:
> >>> On 7/25/2018 9:13 AM, Danil Ias
applied
smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This commit adds support for 32-bpc YUV-based floating-point pixel formats.
---
doc/APIchanges | 2 ++
libavutil/pixdesc.c | 75 +
libavutil/pixfmt.h | 11
libavutil/version.h | 2 +-
4 files changed, 89 insertions(+), 1 deletion
fre 2018-07-27 klockan 19:54 +0530 skrev Gyan Doshi:
>
> On 27-07-2018 07:36 PM, Tomas Härdin wrote:
>
> > This is something the PeerTube guys need, and this seemed a
> > straightforward enough approach. Feedback appreciated
>
> Not a patch review, just a note that one can do this with
> ffmpeg/
On Wed, Jul 25, 2018 at 10:11:47PM -0300, James Almer wrote:
> ~4x speedup in dump_extradata()
>
> Signed-off-by: James Almer
> ---
> libavcodec/dump_extradata_bsf.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
should be ok
and nice speedup
thx
[...]
--
Michael GnuPG fi
On Thu, Jul 26, 2018 at 09:13:41AM +0200, Tobias Rapp wrote:
> Signed-off-by: Tobias Rapp
> ---
> tests/audiogen.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/audiogen.c b/tests/audiogen.c
> index 8d596b5..c43bb70 100644
> --- a/tests/audiogen.c
> +++ b/tests/a
---
libavcodec/libopusenc.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/libavcodec/libopusenc.c b/libavcodec/libopusenc.c
index 4ae81b0bb2..6b450ec317 100644
--- a/libavcodec/libopusenc.c
+++ b/libavcodec/libopusenc.c
@@ -27,6 +27,7 @@
#include "bytestream.h"
#inc
On Thu, Jul 26, 2018 at 03:51:07PM +0800, Zhong Li wrote:
> Encoder frame_number may be double-counted if some frames are cached and then
> flushed.
> Take qsv encoder (some frames are cached firsty for asynchronism) as example,
> ./ffmpeg -loglevel verbose -hwaccel qsv -c:v h264_qsv -i in.mp4 -vf
Hi,
On Fri, Jul 27, 2018 at 10:59 AM, Pedro Arthur wrote:
> 2018-07-27 11:31 GMT-03:00 Ronald S. Bultje :
> > Hi,
> >
> > On Fri, Jul 27, 2018 at 10:16 AM, Pedro Arthur
> wrote:
> >
> >> Hi,
> >>
> >> 2018-07-27 8:12 GMT-03:00 Ronald S. Bultje :
> >> >
> >> > NN is different. The exposed softwa
On 27 July 2018 at 18:12, Rostislav Pehlivanov wrote:
>
> And the coding style is just the tip, there are dozens of things I
> disagree with, such as the custom float to 8 bit conversions, when filters
> already exist which take in floats (zscale).
>
I should probably expand on what I mean by th
On 27 July 2018 at 17:48, Pedro Arthur wrote:
> 2018-07-27 12:07 GMT-03:00 Rostislav Pehlivanov :
> > On 27 July 2018 at 15:11, James Almer wrote:
> >
> >> On 7/27/2018 8:04 AM, Rostislav Pehlivanov wrote:
> >> > Reference - IRC and j-b's earlier email.
> >> > Coding style issues:
> >> > DNNMode
On 7/27/2018 12:07 PM, Rostislav Pehlivanov wrote:
> On 27 July 2018 at 15:11, James Almer wrote:
>
>> On 7/27/2018 8:04 AM, Rostislav Pehlivanov wrote:
>>> Reference - IRC and j-b's earlier email.
>>> Coding style issues:
>>> DNNModel* ff_dnn_load_model_native(const char* model_filename)
>>>
>>>
2018-07-27 12:07 GMT-03:00 Rostislav Pehlivanov :
> On 27 July 2018 at 15:11, James Almer wrote:
>
>> On 7/27/2018 8:04 AM, Rostislav Pehlivanov wrote:
>> > Reference - IRC and j-b's earlier email.
>> > Coding style issues:
>> > DNNModel* ff_dnn_load_model_native(const char* model_filename)
>> >
>
On 7/26/2018 12:38 AM, James Almer wrote:
> Signed-off-by: James Almer
> ---
> tests/fate/libavutil.mak | 1 +
> tests/ref/fate/encryption-info | 0
> 2 files changed, 1 insertion(+)
> delete mode 100644 tests/ref/fate/encryption-info
>
> diff --git a/tests/fate/libavutil.mak b/tests/fate
On 27 July 2018 at 15:11, James Almer wrote:
> On 7/27/2018 8:04 AM, Rostislav Pehlivanov wrote:
> > Reference - IRC and j-b's earlier email.
> > Coding style issues:
> > DNNModel* ff_dnn_load_model_native(const char* model_filename)
> >
> > We never ever do stupid things like put the asterix fir
On Fri, 27 Jul 2018, at 16:59, Pedro Arthur wrote:
> 2018-07-27 11:31 GMT-03:00 Ronald S. Bultje :
> > Hi,
> >
> > On Fri, Jul 27, 2018 at 10:16 AM, Pedro Arthur wrote:
> >
> >> Hi,
> >>
> >> 2018-07-27 8:12 GMT-03:00 Ronald S. Bultje :
> >> >
> >> > NN is different. The exposed software *uses*
2018-07-27 11:31 GMT-03:00 Ronald S. Bultje :
> Hi,
>
> On Fri, Jul 27, 2018 at 10:16 AM, Pedro Arthur wrote:
>
>> Hi,
>>
>> 2018-07-27 8:12 GMT-03:00 Ronald S. Bultje :
>> >
>> > NN is different. The exposed software *uses* but does not *generate* the
>> > coefficients. In fact, the meaning of mo
Signed-off-by: James Almer
---
libavcodec/vp9_superframe_bsf.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavcodec/vp9_superframe_bsf.c b/libavcodec/vp9_superframe_bsf.c
index 52569ab097..ea6750750b 100644
--- a/libavcodec/vp9_superframe_bsf.c
+++ b/libavcodec/vp9_superfr
Signed-off-by: James Almer
---
I'm not 100% sure this is correct. I also don't know if the CBS contexts need
to be fully reinitialized or not in this scenario. Because if so, then every
bsf using cbs will require a flush() callback as well.
libavcodec/h264_redundant_pps_bsf.c | 9 +
1 fi
Signed-off-by: James Almer
---
libavcodec/mpeg4_unpack_bframes_bsf.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavcodec/mpeg4_unpack_bframes_bsf.c
b/libavcodec/mpeg4_unpack_bframes_bsf.c
index c2b779a9d5..e9c535f390 100644
--- a/libavcodec/mpeg4_unpack_bframes_bsf.c
+++ b/liba
Certain AVCodecParameters, like the contents of the extradata, may be changed
by the init() function of any of the bitstream filters in the chain.
Signed-off-by: James Almer
---
Now it's not going to be called after the codec has been opened.
libavcodec/decode.c | 4
1 file changed, 4 inse
Initialize the bsfs once when opening the codec and uninitialize them once when
closing it, instead of at every codec flush/seek.
Signed-off-by: James Almer
---
I think i didn't miss any bsf with internal state that needs a flush()
callback, but an extra pair of eyes (or more) to make sure would
Signed-off-by: James Almer
---
libavcodec/h264_mp4toannexb_bsf.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavcodec/h264_mp4toannexb_bsf.c
b/libavcodec/h264_mp4toannexb_bsf.c
index 292d106433..a263df9948 100644
--- a/libavcodec/h264_mp4toannexb_bsf.c
+++ b/libavcodec/h264
Signed-off-by: James Almer
---
libavcodec/vp9_superframe_split_bsf.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavcodec/vp9_superframe_split_bsf.c
b/libavcodec/vp9_superframe_split_bsf.c
index 9c4aa33dc1..77bfcb4cdf 100644
--- a/libavcodec/vp9_superframe_split_bsf.c
+++ b/li
Meant to reset the internal bsf state without the need to reinitialize it.
Signed-off-by: James Almer
---
Missing APIChanges entry and version bump.
libavcodec/avcodec.h | 6 ++
libavcodec/bsf.c | 10 ++
2 files changed, 16 insertions(+)
diff --git a/libavcodec/avcodec.h b/lib
On 7/27/2018 7:22 AM, Danil Iashchenko wrote:
> Add lumakey_opencl filter. Behaves like existing lumakey filter.
>
> ---
>
> On Wed, Jul 25, 2018 at 10:50:43AM -0300, James Almer wrote:
>>> On 7/25/2018 9:13 AM, Danil Iashchenko wrote:
Add lumakey_opencl filter. Behaves like existing lumake
Hi,
On Fri, Jul 27, 2018 at 10:16 AM, Pedro Arthur wrote:
> Hi,
>
> 2018-07-27 8:12 GMT-03:00 Ronald S. Bultje :
> >
> > NN is different. The exposed software *uses* but does not *generate* the
> > coefficients. In fact, the meaning of most coefficients is completely
> > opaque. They are just mu
> On Jul 27, 2018, at 22:20, James Almer wrote:
>
> On 7/27/2018 10:43 AM, James Almer wrote:
>> On 7/27/2018 9:10 AM, Liu Steven wrote:
>>>
>>>
在 2018年7月20日,上午10:58,Steven Liu 写道:
hwren 于2018年7月19日周四 上午10:38写道:
>
> Ping, any comments for following patches?
wil
On 27-07-2018 07:36 PM, Tomas Härdin wrote:
This is something the PeerTube guys need, and this seemed a
straightforward enough approach. Feedback appreciated
Not a patch review, just a note that one can do this with ffmpeg/ffprobe
and basic *nix tools.
To check for moof,
ffmpeg -i i
On Fri, Jul 27, 2018 at 4:03 PM, James Darnley wrote:
> On 2018-07-27 15:05, Henrik Gramner wrote:
>> Can't you just use 7 GPR:s on x86-32 as well?
>
> I'm sure I've done that in the past and at least 1 platform has always
> complained due to PIE or stack alignment or whatever, I think. I went
>
On 27 July 2018 at 12:47, James Darnley wrote:
> On 2018-07-26 17:29, Rostislav Pehlivanov wrote:
> > On 26 July 2018 at 12:28, James Darnley wrote:
> > +cglobal vertical_compose_haar_10bit, 3, 6, 4, b0, b1, w
> >> +DECLARE_REG_TMP 4,5
> >> +
> >> +mova m2, [pd_1]
> >> +mov r3d, wd
On 7/27/2018 10:43 AM, James Almer wrote:
> On 7/27/2018 9:10 AM, Liu Steven wrote:
>>
>>
>>> 在 2018年7月20日,上午10:58,Steven Liu 写道:
>>>
>>> hwren 于2018年7月19日周四 上午10:38写道:
Ping, any comments for following patches?
>>> will push after one week if there have no objections.
>> pushed.
>
> Yo
Hi,
2018-07-27 8:12 GMT-03:00 Ronald S. Bultje :
>
> NN is different. The exposed software *uses* but does not *generate* the
> coefficients. In fact, the meaning of most coefficients is completely
> opaque. They are just multiplier and addition constants with no obvious
> relationship to reality,
On 7/27/2018 8:04 AM, Rostislav Pehlivanov wrote:
> Reference - IRC and j-b's earlier email.
> Coding style issues:
> DNNModel* ff_dnn_load_model_native(const char* model_filename)
>
> We never ever do stupid things like put the asterix first. The author of
> the patch should have known better and
Tobias Rapp (2018-07-26):
> Add tests for upmixing and downmixing with audio channel counts that
> have a corresponding default layout and also tests where there is no
> default layout.
>
> Update the existing "stereo4" test so it actually outputs stereo like
> the other stereo tests. Rename the p
Hi
This is something the PeerTube guys need, and this seemed a
straightforward enough approach. Feedback appreciated
/TomasFrom 8d5627c02cc2da8708b5342b58d2a6eaebf189c5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Fri, 27 Jul 2018 13:54:52 +0200
Subject: [PATCH] qt-fastst
On 2018-07-27 15:05, Henrik Gramner wrote:
> On Fri, Jul 27, 2018 at 1:47 PM, James Darnley wrote:
>> On 2018-07-26 17:29, Rostislav Pehlivanov wrote:
+cglobal horizontal_compose_haar_10bit, 3, 6+ARCH_X86_64, 4, b, temp_, w,
x, b2
+DECLARE_REG_TMP 2,5
+%if ARCH_X86_64
>
On 7/27/2018 9:10 AM, Liu Steven wrote:
>
>
>> 在 2018年7月20日,上午10:58,Steven Liu 写道:
>>
>> hwren 于2018年7月19日周四 上午10:38写道:
>>>
>>> Ping, any comments for following patches?
>> will push after one week if there have no objections.
> pushed.
You forgot to include avs2_parser.o and libdavs2.o in two
On Fri, Jul 27, 2018 at 1:47 PM, James Darnley wrote:
> On 2018-07-26 17:29, Rostislav Pehlivanov wrote:
>>> +cglobal horizontal_compose_haar_10bit, 3, 6+ARCH_X86_64, 4, b, temp_, w,
>>> x, b2
>>> +DECLARE_REG_TMP 2,5
>>> +%if ARCH_X86_64
>>> +%define tail r6d
>>> +%else
>>> +
Rostislav Pehlivanov (2018-07-27):
> Reference - IRC
I think I agree with you on the issue at hand, but this point raises
again an issue I would like to emphasize:
Not everybody in the project does, or even can, participate in IRC
discussions. And while these discussions are archived, they are no
> 在 2018年7月20日,上午10:58,Steven Liu 写道:
>
> hwren 于2018年7月19日周四 上午10:38写道:
>>
>> Ping, any comments for following patches?
> will push after one week if there have no objections.
pushed.
BTW, Huiwen, submit FATE please, can you maintain the AVS2 codec module?
Thanks
>>
>>
>>
>>
>>
>>
Hi All,
I used av_read_frame to get the AVPacket from encoded h264 file. But when
this packet (00 00 01 05 94 5a 33 e7 4d 6b d7 ad 13 86 ff 47 83 93 31 f1 e3
0a) is in the input stream (h264 video) ffmpeg decoder stops decoding
frames for any subsequent AVPackets. But if I skip this packet to prov
On 2018-07-26 17:29, Rostislav Pehlivanov wrote:
> On 26 July 2018 at 12:28, James Darnley wrote:
> +cglobal vertical_compose_haar_10bit, 3, 6, 4, b0, b1, w
>> +DECLARE_REG_TMP 4,5
>> +
>> +mova m2, [pd_1]
>> +mov r3d, wd
>> +and wd, ~(mmsize/4 - 1)
>> +shl wd, 2
>> +
I did a 24h test with this, and it seems to fix the issue.
Will apply and backport to 4.0 in 24h if nobody objects.
smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/l
Hi,
On Fri, Jul 27, 2018 at 7:02 AM, Ronald S. Bultje
wrote:
> Hi,
>
> On Thu, Jul 26, 2018 at 11:49 PM, Pedro Arthur
> wrote:
>
>> Taking the vp9 as example, sure the coeficients are obtained by the
>> 'poly3' but the real data are the polynomial coeficients, does any one
>> asks where these p
On 27 July 2018 at 03:04, Pedro Arthur wrote:
> Hi,
>
> I'm surprised with this patch, there wasn't any concern raised in the
> patch review process.
>
It slipped through, and we (and you) should have known better.
> 2018-07-26 16:26 GMT-03:00 Rostislav Pehlivanov :
> > As discussed recently,
Add lumakey_opencl filter. Behaves like existing lumakey filter.
---
On Wed, Jul 25, 2018 at 10:50:43AM -0300, James Almer wrote:
>> On 7/25/2018 9:13 AM, Danil Iashchenko wrote:
>> > Add lumakey_opencl filter. Behaves like existing lumakey filter.
>>
>> Isn't it possible to keep each of these
Hi,
On Thu, Jul 26, 2018 at 11:49 PM, Pedro Arthur wrote:
> Taking the vp9 as example, sure the coeficients are obtained by the
> 'poly3' but the real data are the polynomial coeficients, does any one
> asks where these polynomial coeficients came from, reproducibility,
> etc? Your comparison do
2018-07-27 4:04 GMT+02:00, Pedro Arthur :
> Does we impose all requiriments imposed for NN weights
> on all other data stored in ffmpeg?
(As explained before:)
No, we clearly do not.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http
Hello,
On Fri, 27 Jul 2018, at 05:49, Pedro Arthur wrote:
> > Are NN weights a single, one-line (10-character) expression? Please
> > elaborate. Why isn't that 10-character function documented anywhere?
> I think you missed the point, I wrote "can be obtained from a training
> process over a datas
On Fri, Jul 27, 2018 at 12:03:46AM +0300, Jan Ekström wrote:
> Clang is more strict about some things.
> ---
> libavfilter/aarch64/vf_nlmeans_neon.S | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/aarch64/vf_nlmeans_neon.S
> b/libavfilter/aarch64/vf_nlmea
On 7/26/18 6:52 PM, Antonio Morell wrote:
> ---
> libavformat/dashenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index a9b8b1d4f6..ae57fd5493 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -868
61 matches
Mail list logo