On 02/06/2019 21:19, Derek Buitenhuis wrote:
> This has nothing to do with API changes, it's a Rust toolchain (build
> system, specifically) thing. These changes don't change API/ABI.
Also to add: We will probably be cutting a 'real' rav1e release soon (0.1.0),
I think. That could also be a place
On 21/05/2019 06:18, Li, Zhong wrote:
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Mark Thompson
>> Sent: Monday, May 6, 2019 10:49 PM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: [FFmpeg-devel] [PATCH 5/7] hwcontext_vaapi: Add option to set
>> driver name
>>
>> For
---
doc/ffmpeg.texi | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index cd35eb49c8..ccd490d1a7 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -950,8 +950,32 @@ device type:
@item vaapi
@var{device} is
On Sun, May 26, 2019 at 01:46:32AM +0530, Swaraj Hota wrote:
> Fixes ticket #2956.
>
> Signed-off-by: Swaraj Hota
> ---
> Minor changes based on previous discussions.
> Seeking is fixed.
> ---
> Changelog| 1 +
> libavformat/Makefile | 1 +
> libavformat/allformats.c |
On 02/06/2019 19:27, Carl Eugen Hoyos wrote:
> Since a lot of unexpected changes can happen after months,
> this sounds to me like a strong reason to wait.
This has nothing to do with API changes, it's a Rust toolchain (build
system, specifically) thing. These changes don't change API/ABI.
-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Saturday, June 1, 2019 4:43 AM
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [PATCH 1/3] lavf/qsv_vpp: add frame format
> option
>
> Am Fr., 31. Mai 2019 um
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Saturday, June 1, 2019 4:41 AM
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [PATCH 3/3] lavf/qsv: use av_cold for init/uninit
>
> Am Fr., 31. Mai 2019 um
On 02/06/2019 19:45, Moritz Barsnick wrote:
> https://github.com/lu-zero/crav1e says:
>
> Status
> The API is far from stable
Yeah, that's not super true any more, and I'll remove it.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Fixes: Timeout (15sec -> 0.5sec)
Fixes:
14846/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FMVC_fuzzer-5068322120400896
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/fmvc.c | 3 +++
1
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Jun Zhao
> Sent: Saturday, June 01, 2019 12:58 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Jun Zhao
> Subject: [FFmpeg-devel] [PATCH V1 3/3] lavf/sr: Refine the coding style for
> init
>
>
> -Original Message-
> From: Fu, Linjie
> Sent: Monday, June 3, 2019 1:17 PM
> To: Li, Zhong ; FFmpeg development discussions and
> patches
> Subject: RE: [FFmpeg-devel] [PATCH, v2 1/2] lavf/qsvvpp: allocate
> continuous memory
>
> > -Original Message-
> > From: Li, Zhong
> >
> I intent to push the awk version. I will wait at least until
> Thursday, so people can further test, comment, or object.
No further comments here.
Thanks!
Avi
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Sun, Jun 2, 2019 at 4:19 PM Paul B Mahol wrote:
>
> On 6/1/19, Jun Zhao wrote:
> > From: Jun Zhao
> >
> > Add slice threading support, use the command like:
> >
> > ./ffmpeg -i input -vf colorlevels -f null /dev/null
> >
> > with 1080p h264 clip, the fps from 39 fps to 79 fps
> > in the
Hi all,
hi Avi!
Sorry for the late reply.
On 2019-05-07 12:22 +, avih wrote:
> > patch1 (awk) configure: print_in_columns: replace pr with awk version:
> > http://ffmpeg.org/pipermail/ffmpeg-devel/2019-May/243380.html
> > patch2 (shell) configure: sort decoder/encoder/filter/... names in
1. The extra information in slice headers was parsed incorrectly:
In the first reading pass to derive the length of the extra information,
one should look at bits n, n + 9, n + 18, ... and check whether they
equal one (further extra information) or zero (end of extra information),
but instead bits
Remove superfluous trailing zeros from slices. Because MPEG-2 slices
can end with zero bits a safe number of trailing zero bits is always
kept.
More explicitly, 6 + max{f_code[i][1] - 1, i = 0,1, f_code[i][1] != 0xf}
is an upper bound for the number of possible trailing zeros that are
part of the
If a sequence display extension is read with colour_description equal to
zero, but a user wants to add one or more of the colour_description
elements, then the colour_description elements the user did not explicitly
request to be set are set to zero and not to the value equal to
Up until now, a temporary variable was used and initialized every time a
value was read in CBS; if reading turned out to be successfull, this
value was overwritten (without having ever been looked at) with the
value read if reading was successfull; on failure the variable wasn't
touched either.
On Sun, Jun 2, 2019 at 4:13 PM Paul B Mahol wrote:
>
> On 6/1/19, Jun Zhao wrote:
> > --
> > 1.7.1
> >
>
> Should be ok if md5 hash does not change.
>
Yes, both changes pass the md5 hash test. Will apply, Thanks
___
ffmpeg-devel mailing list
> -Original Message-
> From: Li, Zhong
> Sent: Friday, May 31, 2019 17:20
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Fu, Linjie
> Subject: RE: [FFmpeg-devel] [PATCH, v2 1/2] lavf/qsvvpp: allocate
> continuous memory
>
> > From: ffmpeg-devel
On 29/05/2019 05:54, Andreas Rheinhardt wrote:
> Mark Thompson:
>> On 22/05/2019 02:04, Andreas Rheinhardt wrote:
>>> MPEG-2 picture and slice headers can contain optional extra information;
>>> both use the same syntax for their extra information. And cbs_mpeg2's
>>> implementations of both were
On 31/05/2019 23:08, Carl Eugen Hoyos wrote:
> So is your patch meant to wait until this merge is done?
> I would suggest so...
Soon has a (TM) beside it for a reason (there needs to be some
work done on Rust itself first, I think.) I would expect it to
take at least 1-2 months. The API itself
Hi Carl
This is the error message I get. It seems like libavdevice.a is llvm
bitcode.
Thanks
-Adrian
./configure --cc=clang --enable-lto && make -j28
AR libavcodec/libavcodec.a
LD ffmpeg_g
LD ffprobe_g
/usr/bin/ld: skipping incompatible libavdevice/libavdevice.a when searching
for
Am So., 2. Juni 2019 um 19:54 Uhr schrieb Derek Buitenhuis
:
>
> On 31/05/2019 23:08, Carl Eugen Hoyos wrote:
> > So is your patch meant to wait until this merge is done?
> > I would suggest so...
>
> Soon has a (TM) beside it for a reason (there needs to be some
> work done on Rust itself first,
On 6/2/19, Carl Eugen Hoyos wrote:
> Am So., 2. Juni 2019 um 19:54 Uhr schrieb Derek Buitenhuis
> :
>>
>> On 31/05/2019 23:08, Carl Eugen Hoyos wrote:
>> > So is your patch meant to wait until this merge is done?
>> > I would suggest so...
>>
>> Soon has a (TM) beside it for a reason (there needs
On Sun, Jun 02, 2019 at 18:46:17 +0100, Derek Buitenhuis wrote:
> take at least 1-2 months. The API itself won't change.
https://github.com/lu-zero/crav1e says:
Status
The API is far from stable
Just sayin',
Moritz
___
ffmpeg-devel mailing list
On 6/1/19, Jun Zhao wrote:
> From: Jun Zhao
>
> Used the command for 1080p h264 clip as follow:
>
> a). ffmpeg -i input -vf lutyuv="u=128:v=128" -f null /dev/null
> b). ffmpeg -i input -vf lutrgb="g=0:b=0" -f null /dev/null
>
> after enabled the slice threading, the fps change from:
>
> a).
On 6/1/19, Jun Zhao wrote:
> From: Jun Zhao
>
> Add slice threading support, use the command like:
>
> ./ffmpeg -i input -vf colorlevels -f null /dev/null
>
> with 1080p h264 clip, the fps from 39 fps to 79 fps
> in the local(Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz)
>
> Signed-off-by: Jun Zhao
Signed-off-by: Steven Liu
---
doc/muxers.texi | 4
libavformat/dashenc.c | 4 ++--
libavformat/hlsenc.c | 27 ++-
libavformat/hlsplaylist.c | 11 ---
libavformat/hlsplaylist.h | 5 +++--
5 files changed, 39 insertions(+), 12 deletions(-)
On 02-06-2019 06:44 PM, Steven Liu wrote:
Signed-off-by: Steven Liu
---
doc/muxers.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 7f3758b117..46580091ba 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -995,7 +995,7 @@
> 在 2019年6月2日，21:29，Gyan 写道：
>
>
>
> On 02-06-2019 06:44 PM, Steven Liu wrote:
>> Signed-off-by: Steven Liu
>> ---
>> doc/muxers.texi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>> index 7f3758b117..46580091ba 100644
>> ---
On 29/05/2019 05:12, Andreas Rheinhardt wrote:
> Mark Thompson:
>> On 22/05/2019 02:04, Andreas Rheinhardt wrote:
>>> If a sequence display extension is read with colour_description equal to
>>> zero, but a user wants to add one or more of the colour_description
>>> elements, then the
Signed-off-by: Steven Liu
---
doc/muxers.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 7f3758b117..46580091ba 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -995,7 +995,7 @@ By default, a single hls variant containing all
On 02-06-2019 06:03 PM, Steven Liu wrote:
Signed-off-by: Steven Liu
---
doc/muxers.texi | 4
libavformat/dashenc.c | 4 ++--
libavformat/hlsenc.c | 27 ++-
libavformat/hlsplaylist.c | 11 ---
libavformat/hlsplaylist.h | 5 +++--
Signed-off-by: Steven Liu
---
doc/muxers.texi | 4
libavformat/dashenc.c | 4 ++--
libavformat/hlsenc.c | 27 ++-
libavformat/hlsplaylist.c | 11 ---
libavformat/hlsplaylist.h | 5 +++--
5 files changed, 39 insertions(+), 12 deletions(-)
On 26/05/2019 19:40, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/cbs_h264.h | 6 ++
> libavcodec/cbs_h2645.c| 1 +
> libavcodec/cbs_h264_syntax_template.c | 17 +
> 3 files changed, 24 insertions(+)
>
> diff --git
On 06/05/2019 22:02, Mark Thompson wrote:
> The maxDpbPicBuf value which is used in the DPB size calculation depends
> on the profile (it's usually 6, but 7 for screen-extended profiles).
> ---
> libavcodec/h265_profile_level.c | 86 -
>
On 15/04/2019 04:35, Song, Ruiling wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
>> Mark Thompson
>> Sent: Wednesday, April 10, 2019 6:07 AM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: [FFmpeg-devel] [PATCH v4 1/7] vf_crop: Add
38 matches
Mail list logo
