On Sun, Apr 22, 2018 at 02:51:16AM +0100, Rostislav Pehlivanov wrote:
[...]
> I think av_thread_message_queue_elems would be a better name, had to think
> for a good period of time what "nelem" meant.
I'm afraid of "queue_elems" implying "queuing elements" so I went for
the more explicit av_thread
On 22.04.2018 01:48, Carl Eugen Hoyos wrote:
> 2018-04-22 1:30 GMT+02:00, Hendrik Leppkes :
>> On Sat, Apr 21, 2018 at 10:15 PM, Carl Eugen Hoyos
>> wrote:
>>> 2018-04-21 21:59 GMT+02:00, Thomas Volkert :
On 21.04.2018 21:46, Carl Eugen Hoyos wrote:
> 2018-04-21 21:37 GMT+02:00, Hen
On Sun, 22 Apr 2018 08:41:18 +0800
Liu Steven wrote:
> > 在 2018年4月22日，上午5:23，wm4 写道：
> >
> > On Sat, 21 Apr 2018 22:55:33 +0200
> > Carl Eugen Hoyos wrote:
> >
> >> 2018-04-19 4:45 GMT+02:00, Steven Liu :
> >>>
> >>>
> On 19 Apr 2018, at 03:20, wm4 wrote:
>
> On Wed,
On Sun, 22 Apr 2018, Clément Bœsch wrote:
On Sun, Apr 22, 2018 at 02:51:16AM +0100, Rostislav Pehlivanov wrote:
[...]
I think av_thread_message_queue_elems would be a better name, had to think
for a good period of time what "nelem" meant.
I'm afraid of "queue_elems" implying "queuing elemen
On Fri, 20 Apr 2018, wm4 wrote:
On Thu, 19 Apr 2018 23:25:03 +0200
Marton Balint wrote:
Signed-off-by: Marton Balint
---
doc/APIchanges| 3 +++
libavutil/pixdesc.c | 3 +--
libavutil/pixdesc.h | 8 ++--
libavutil/tests/pixdesc.c | 4
libavutil/version.h
On Fri, 20 Apr 2018, Michael Niedermayer wrote:
On Thu, Apr 19, 2018 at 09:32:19PM +0200, Marton Balint wrote:
A pixel format which has a palette also has alpha, without this patch the
format negotiation might have preferred formats without alpha even if the
source had alpha.
Signed-off-by:
On 21/04/18 23:29, Carl Eugen Hoyos wrote:
> 2018-04-21 23:33 GMT+02:00, Rostislav Pehlivanov :
>> On 21 April 2018 at 21:24, Carl Eugen Hoyos wrote:
>>
>>> 2018-04-20 6:30 GMT+02:00, Rostislav Pehlivanov :
>>>
+[AV_PIX_FMT_P010] =
VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PA
On Sun, 22 Apr 2018 13:44:19 +0200 (CEST)
Marton Balint wrote:
> On Fri, 20 Apr 2018, Michael Niedermayer wrote:
>
> > On Thu, Apr 19, 2018 at 09:32:19PM +0200, Marton Balint wrote:
> >> A pixel format which has a palette also has alpha, without this patch the
> >> format negotiation might hav
On Sun, 22 Apr 2018 13:24:11 +0200 (CEST)
Marton Balint wrote:
> On Fri, 20 Apr 2018, wm4 wrote:
>
> > On Thu, 19 Apr 2018 23:25:03 +0200
> > Marton Balint wrote:
> >
> >> Signed-off-by: Marton Balint
> >> ---
> >> doc/APIchanges| 3 +++
> >> libavutil/pixdesc.c | 3 +--
>
From: Thomas Volkert
---
Changelog | 1 +
configure | 31 ++--
libavformat/Makefile | 1 +
libavformat/rtmpdh.c | 55
libavformat/rtmpdh.h | 5 +
libavformat/tls_mbedtls.c | 351 ++
libavf
---
TODO: APIChanges + lavu minor bump (not done yet because it will
conflict with the threadmessage patch)
---
libavutil/opt.c | 6 ++
libavutil/opt.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index 3b0aab4ee8..99282605f5 100644
--- a/libavutil/op
---
There are probably a bunch of other options and I don't plan to look for
them, I just needed at least one example of use.
---
libavformat/http.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index aa6348f28b..3a35bc7eac 100644
---
On Sun, 22 Apr 2018 16:38:08 +0200
Clément Bœsch wrote:
> ---
> TODO: APIChanges + lavu minor bump (not done yet because it will
> conflict with the threadmessage patch)
> ---
> libavutil/opt.c | 6 ++
> libavutil/opt.h | 1 +
> 2 files changed, 7 insertions(+)
>
> diff --git a/libavutil/op
Matching previous commit for H.264.
---
libavcodec/vaapi_encode_h265.c | 114 +++--
1 file changed, 54 insertions(+), 60 deletions(-)
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 5203c6871d..ba6b426eed 100644
--- a/libavcod
This will make it easier to support options in common between different
encoders. It also cleans up some of the field naming.
---
libavcodec/vaapi_encode_h264.c | 228 +
1 file changed, 115 insertions(+), 113 deletions(-)
diff --git a/libavcodec/vaapi_enco
Stuff:
* Refactor to make the setup process and options generally more sensible.
* Dynamically choose profile (don't require that the user sets it for e.g.
10-bit H.265).
* Cleaned rate control setup (better debug and fix overflows).
* Better explanation of packed header problems (for the Mesa enc
---
libavcodec/vaapi_encode_mjpeg.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/libavcodec/vaapi_encode_mjpeg.c b/libavcodec/vaapi_encode_mjpeg.c
index c949e89646..983c77d194 100644
--- a/libavcodec/vaapi_encode_mjpeg.c
+++ b/libavcodec/vaapi_encode_mjpe
---
libavcodec/vaapi_encode_mpeg2.c | 50 -
1 file changed, 24 insertions(+), 26 deletions(-)
diff --git a/libavcodec/vaapi_encode_mpeg2.c b/libavcodec/vaapi_encode_mpeg2.c
index 42df77ea49..5dd1f39cbc 100644
--- a/libavcodec/vaapi_encode_mpeg2.c
+++ b/liba
Previously there was one fixed choice for each codec (e.g. H.265 -> Main
profile), and using anything else then required an explicit option from
the user. This changes to selecting the profile based on the input format
and the set of profiles actually supported by the driver (e.g. P010 input
will
The only common option here is low_power - it was previously supported
for H.264 only, that specific option is removed.
---
doc/encoders.texi | 14 --
libavcodec/vaapi_encode.h | 9 +
libavcodec/vaapi_encode_h264.c | 8 ++--
libavcodec/vaapi_encode_h265.
The codec-specific context now contains both the common context and the
codec-specific options directly.
---
libavcodec/vaapi_encode.c | 10 --
libavcodec/vaapi_encode.h | 11 ---
libavcodec/vaapi_encode_h264.c | 2 --
libavcodec/vaapi_encode_h265.c | 2 --
libavcod
---
libavcodec/vaapi_encode_vp8.c | 31 ++-
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/libavcodec/vaapi_encode_vp8.c b/libavcodec/vaapi_encode_vp8.c
index b4c5521d1f..c182b6918a 100644
--- a/libavcodec/vaapi_encode_vp8.c
+++ b/libavcodec/vaapi_encod
---
libavcodec/vaapi_encode_vp9.c | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/libavcodec/vaapi_encode_vp9.c b/libavcodec/vaapi_encode_vp9.c
index 9108699ac3..6e62213bc9 100644
--- a/libavcodec/vaapi_encode_vp9.c
+++ b/libavcodec/vaapi_encod
Include the common options, and also named options for setting the profile
and level.
---
libavcodec/vaapi_encode_mpeg2.c | 53 +++--
1 file changed, 51 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vaapi_encode_mpeg2.c b/libavcodec/vaapi_encode_mpeg2.c
---
libavcodec/vaapi_encode.c | 38 ++
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index bb0f4c6fdf..9c5cfc7a65 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -9
Choose what types of reference frames will be used based on what types
are available, and make the intra-only mode explicit (GOP size one,
which must be used for MJPEG).
---
libavcodec/vaapi_encode.c | 83 +++--
libavcodec/vaapi_encode.h | 1 +
liba
This was added in libva 2.1.0 (VAAPI 1.1.0). Use AVCodecContext.qmax,
matching the existing behaviour for qmin, and clean up the defaults so
that we only pass min/max when explicitly set.
---
doc/encoders.texi | 3 ++-
libavcodec/vaapi_encode.c | 3 +++
libavcodec/vaapi_encode
Query which modes are supported and select between VBR and CBR based
on that. Removes all of the codec-specific rate control mode selection
code. Also ensures that target percentage and window size match the
target bitrate and RC buffer size in all cases where they are not
explicitly specified.
-
---
libavcodec/vaapi_encode.c | 15 ---
libavcodec/vaapi_encode.h | 4
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 609fc604c1..bb0f4c6fdf 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_
The codec sequence headers may contain fields which can overwrite the
fine parameters given in the specific settings (e.g. a crude bitrate
value vs. the max-rate / target-percentage / etc. values in
VAEncMiscParameterRateControl). Always reapply all global parameters
after a sequence header to avo
This was previously accessible only via AVCodecContext.compression_level
for all encoders except H.264 where it was also a private option. This
makes it an explicit option everywhere.
---
libavcodec/vaapi_encode.c | 87 ++
libavcodec/vaapi_encode.h
---
doc/encoders.texi | 24
1 file changed, 24 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 861f9f4f1f..b451142cfb 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2631,12 +2631,36 @@ Use CABAC.
@item cavlc
Use CAVLC.
@end table
+
+@
---
libavcodec/vaapi_encode_h264.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index 018a843932..899fbdbb99 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -970,7 +970,7 @@ s
Add a larger warning more clearly explaining the consequences of missing
packed header support in the driver. Also only write the extradata if the
user actually requests it via the GLOBAL_HEADER flag.
---
libavcodec/vaapi_encode.c | 118 +---
libavcodec/v
constraint_set1_flag should be set for constrained baseline and main
profiles, because the stream conforms to main profile.
constraint_set3_flag should be set for high profile when the stream
is intra-only.
constraint_set4_flag should always be set for main and high profiles
because interlaced en
Clarify that the list is the naughty list, and therefore being on it is
not desirable. The i965 driver does not need to be on the list after
version 2.0 (when the standard parameter buffer rendering behaviour was
changed).
---
libavutil/hwcontext_vaapi.c | 27 +++
1 file c
---
configure | 4 +-
libavcodec/Makefile | 1 +
libavcodec/cbs.c | 6 +
libavcodec/cbs_internal.h | 1 +
libavcodec/cbs_jpeg.c | 487 ++
libavcodec/cbs_jpeg.h
---
libavcodec/vaapi_encode_h264.c | 32
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index 899fbdbb99..7454611be9 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_e
Including a unit test.
---
libavcodec/Makefile| 3 +-
libavcodec/h264_levels.c | 130 +
libavcodec/h264_levels.h | 53
libavcodec/tests/.gitignore| 1 +
libavcodec/tests/h264_levels.c | 183 ++
Also adds 4:2:2, 4:4:4 and RGB support.
---
doc/encoders.texi | 17 +-
libavcodec/vaapi_encode_mjpeg.c | 528 +---
2 files changed, 345 insertions(+), 200 deletions(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index b451142cfb..ceddfdda6
On 15/04/18 20:45, Alexander Kravchenko wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
>> Mark Thompson
>> Sent: Sunday, April 15, 2018 7:31 PM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH 5/5] amfenc: Remove
On 19/04/18 03:18, Song, Ruiling wrote:
>> Note that OpenCL <-> D3D11 won't work on AMD for normal video surfaces
>> (NV12) because there is no support for multiple-plane textures, so it's only
>> going
>> to work with DXVA2 currently. Intel has an extension
>> ("cl_intel_d3d11_nv12_media_sharing
On 22 April 2018 at 12:46, Mark Thompson wrote:
> On 21/04/18 23:29, Carl Eugen Hoyos wrote:
> > 2018-04-21 23:33 GMT+02:00, Rostislav Pehlivanov :
> >> On 21 April 2018 at 21:24, Carl Eugen Hoyos wrote:
> >>
> >>> 2018-04-20 6:30 GMT+02:00, Rostislav Pehlivanov :
> >>>
> +[AV_PIX_FMT_P
On 22 April 2018 at 17:21, Rostislav Pehlivanov wrote:
>
>
> On 22 April 2018 at 12:46, Mark Thompson wrote:
>
>> On 21/04/18 23:29, Carl Eugen Hoyos wrote:
>> > 2018-04-21 23:33 GMT+02:00, Rostislav Pehlivanov :
>> >> On 21 April 2018 at 21:24, Carl Eugen Hoyos
>> wrote:
>> >>
>> >>> 2018-04-2
On Sun, Apr 22, 2018 at 12:33:14PM +0200, Marton Balint wrote:
>
>
> On Sun, 22 Apr 2018, Clément Bœsch wrote:
>
> > On Sun, Apr 22, 2018 at 02:51:16AM +0100, Rostislav Pehlivanov wrote:
> > [...]
> > > I think av_thread_message_queue_elems would be a better name, had to think
> > > for a good p
On 22/04/18 17:28, Rostislav Pehlivanov wrote:
> On 22 April 2018 at 17:21, Rostislav Pehlivanov wrote:
>> On 22 April 2018 at 12:46, Mark Thompson wrote:
>>> On 21/04/18 23:29, Carl Eugen Hoyos wrote:
2018-04-21 23:33 GMT+02:00, Rostislav Pehlivanov :
> On 21 April 2018 at 21:24, Carl E
On 22/04/18 17:36, Mark Thompson wrote:
> On 22/04/18 17:28, Rostislav Pehlivanov wrote:
>> On 22 April 2018 at 17:21, Rostislav Pehlivanov wrote:
>>> On 22 April 2018 at 12:46, Mark Thompson wrote:
On 21/04/18 23:29, Carl Eugen Hoyos wrote:
> 2018-04-21 23:33 GMT+02:00, Rostislav Pehliv
This commit adds a Vulkan hwcontext, currently capable of mapping DRM and
VAAPI frames but additional functionality can be added later to support
importing of D3D11 surfaces as well as exporting to various other APIs.
This context requires the newest stable version of the Vulkan API,
and once the
It tries to do something similar to it with YUV images, but RGB images
are done properly.
Signed-off-by: Rostislav Pehlivanov
---
configure | 1 +
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfi
Signed-off-by: Rostislav Pehlivanov
---
libavutil/hwcontext_opencl.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
index 43b5c5ae0c..1d18da37bf 100644
--- a/libavutil/hwcontext_opencl.c
+++ b/libavutil/hwcontext
The plan is to eventually be able to apply effects and encode entirely
on the GPU.
Rostislav Pehlivanov (8):
hwcontext_internal: add ff_hwframe_map_replace
hwcontext_opencl: use ff_hwframe_map_replace()
lavu: add a Vulkan hwcontext
lavfi: add common Vulkan filtering code
lavfi: add a Vul
Used to fix unmapping when no direct interop exists between APIs.
Signed-off-by: Rostislav Pehlivanov
---
libavutil/hwcontext.c | 7 +++
libavutil/hwcontext_internal.h | 5 +
2 files changed, 12 insertions(+)
diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index 70c5
This commit adds a common code for use in Vulkan filters. It attempts
to ease the burden of writing Vulkan image filtering to a minimum,
which is pretty much a requirement considering how verbose the API is.
It supports both compute and graphic pipelines and manages to abstract
the API to such a l
Could be done in-plane with the main image but framesync segfaults.
Signed-off-by: Rostislav Pehlivanov
---
configure | 1 +
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/vf_overlay_vulkan.c | 458 +++
Can convert to RGB using very fast fixed-function conversions.
Signed-off-by: Rostislav Pehlivanov
---
configure | 1 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_scale_vulkan.c | 386 ++
4 fi
Signed-off-by: Rostislav Pehlivanov
---
configure | 1 +
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/vf_avgblur_vulkan.c | 343
4 files changed, 346 insertions(+)
create mode 100644 libavfi
On 22 April 2018 at 17:51, Mark Thompson wrote:
> On 22/04/18 17:36, Mark Thompson wrote:
> > On 22/04/18 17:28, Rostislav Pehlivanov wrote:
> >> On 22 April 2018 at 17:21, Rostislav Pehlivanov
> wrote:
> >>> On 22 April 2018 at 12:46, Mark Thompson wrote:
> On 21/04/18 23:29, Carl Eugen H
2018-04-14 11:31 GMT+02:00 Martin Vignali :
>
> >
>> > For the proxy chroma version is also the same matrix use in prores_aw
>>
>> Patch is OK then, assumming FATE still passes.
>>
>>
>> Ok thanks for comments.
> It passes fate test for me (but prores_ks have few fate test !)
>
> I will wait few d
On 22 April 2018 at 17:59, Rostislav Pehlivanov wrote:
>
>
> On 22 April 2018 at 17:51, Mark Thompson wrote:
>
>> On 22/04/18 17:36, Mark Thompson wrote:
>> > On 22/04/18 17:28, Rostislav Pehlivanov wrote:
>> >> On 22 April 2018 at 17:21, Rostislav Pehlivanov
>> wrote:
>> >>> On 22 April 2018 a
2018-04-08 22:21 GMT+02:00 Martin Vignali :
> Hello,
>
> New patch in attach,
> Remove the C part of the sse/avx func, and integrate all the process in
> the ASM func
>
> A little bit faster, and avoid the macro in x86/rgb2rgb.c.
>
>
> Remove the debug message in the checkasm test
and pushed
Mart
2018-04-22 14:47 GMT+02:00, Thomas Volkert :
> From: Thomas Volkert
> @@ -1638,6 +1640,7 @@ EXTERNAL_LIBRARY_GPL_LIST="
> libx265
> libxavs
> libxvid
> +mbedtls
How do you detect that this is not the "current version" of mbed?
And why is LGPLv3 not supported?
Please make this
Carl Eugen Hoyos (2018-04-22):
> How do you detect that this is not the "current version" of mbed?
Is it really our responsibility?
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@
2018-04-22 20:00 GMT+02:00, Nicolas George :
> Carl Eugen Hoyos (2018-04-22):
>> How do you detect that this is not the "current version" of mbed?
>
> Is it really our responsibility?
We try to always do it and I believe that allowing LGPL makes
more sense and less headache: Since we do the checks
I have not reviewed the source code due to time constraints, but here I go:
Multidimensional arrays need be implemented, where every odd array is used
as some sort of a fallback thread (used for extra processing),
multithreading can help this
binary trees need to be implemented multidimensional
[mpeg4 @ 0x14af5e0] has_b_frames is larger in decoder than demuxer 1 > 0.
https://drive.google.com/open?id=1pwmlVi7GhHQmIh8UcL0_ZF1RyFOKGs82
ffmpeg version 2.8.14-0ubuntu0.16.04.1 Copyright (c) 2000-2018 the FFmpeg
developers
built with gcc 5.4.0 (Ubuntu 5.4.0-6ubuntu1~16.04.9) 20160609
confi
On 19/04/18 17:00, Oscar Amoros Huguet wrote:
>
> Hi!
>
> We changed 4 files in ffmpeg, libavcodec/nvdec.c, libavutil/hwcontext.c,
> libavutil/hwcontext_cuda.h, libavutil/hwcontext_cuda.c.
>
> The purpose of this modification is very simple. We needed, for performance
> reasons (per frame exec
On 4/18/2018 10:49 AM, James Almer wrote:
> Should be useful for muxers that require values as defined in the
> vpcc atom but don't need to write the atom itself.
>
> Signed-off-by: James Almer
> ---
> libavformat/vpcc.c | 29 -
> libavformat/vpcc.h | 11 +++
>
Fixes infinite loop
Fixes:
6858/clusterfuzz-testcase-ffmpeg_AV_CODEC_ID_MSMPEG4V3_fuzzer-4681563766784000
Fixes: 6890/clusterfuzz-testcase-ffmpeg_AV_CODEC_ID_WMV1_fuzzer-4756103142309888
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-of
Fixes: runtime error: signed integer overflow: 197710 * 10923 cannot be
represented in type 'int'
Fixes:
7010/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-5667127596941312
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signe
Hi,
V3 drops the MLTI part, no idea how it survived
02fff499362daedcdcb0a9cdd517257843600563 on our side...
Also dropped audio override, could not get a sample requiring it.
Adapted to current HEAD.
Thanks,
Thilo
___
ffmpeg-devel mailing list
ffmpeg-d
-Thilo
From a8d3f717d2e35f2b81cd05e5baf4a6dc5900ee34 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann
Date: Tue, 17 Apr 2018 22:53:02 +0200
Subject: [PATCH 1/3] Add muxing/demuxing of RMHD
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/rm.c | 1 +
liba
-Thilo
From 14d93400443457ea935d42cadf7bc7e2b2e4447f Mon Sep 17 00:00:00 2001
From: Thilo Borgmann
Date: Tue, 17 Apr 2018 22:55:02 +0200
Subject: [PATCH 2/3] Add codec wrapper for librv11
---
MAINTAINERS | 1 +
configure | 5 +
fftools/ffmpeg_opt.c| 2 +-
liba
-Thilo
From 49c6fa2051f2c1d2955405df938d930313b8f2a2 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann
Date: Tue, 17 Apr 2018 22:55:29 +0200
Subject: [PATCH 3/3] Add docs and Changelog
---
Changelog | 2 ++
doc/encoders.texi | 92 +++
doc/
2018-04-21 7:59 GMT+02:00, Ruslan Baskou :
> [mpeg4 @ 0x14af5e0] has_b_frames is larger in decoder than demuxer 1 > 0.
This is ticket #6019.
Thank you for the sample, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mai
Create a buffer from the data instead and use the buffer destructor to free the
DeckLink frame. This avoids a memcpy of the frame data.
Signed-off-by: Marton Balint
---
libavdevice/decklink_dec.cpp | 12
1 file changed, 12 insertions(+)
diff --git a/libavdevice/decklink_dec.cpp b/l
Signed-off-by: Marton Balint
---
libavdevice/decklink_dec.cpp | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 10535dc388..510637676c 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -475,16 +47
On 4/22/18, Thilo Borgmann wrote:
> Hi,
>
> V3 drops the MLTI part, no idea how it survived
> 02fff499362daedcdcb0a9cdd517257843600563 on our side...
> Also dropped audio override, could not get a sample requiring it.
>
> Adapted to current HEAD.
I'm strongly against applying this to our tree.
__
On 4/22/18, Thilo Borgmann wrote:
> -Thilo
>
To many changes, hard to track.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
also fixes: runtime error: index 1456 out of bounds for type 'int16_t [16]'
Found-by: durandal_1707
Signed-off-by: Michael Niedermayer
---
libavcodec/vc1_block.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vc1_block.c b/libavcodec/vc1_block.c
index f9f26
On Sun, Apr 22, 2018 at 09:33:04AM +0200, Clément Bœsch wrote:
> On Sun, Apr 22, 2018 at 02:51:16AM +0100, Rostislav Pehlivanov wrote:
> [...]
> > I think av_thread_message_queue_elems would be a better name, had to think
> > for a good period of time what "nelem" meant.
>
> I'm afraid of "queue_e
On Sun, Apr 22, 2018 at 01:44:19PM +0200, Marton Balint wrote:
>
>
> On Fri, 20 Apr 2018, Michael Niedermayer wrote:
>
> >On Thu, Apr 19, 2018 at 09:32:19PM +0200, Marton Balint wrote:
> >>A pixel format which has a palette also has alpha, without this patch the
> >>format negotiation might have
On 4/22/2018 6:43 PM, Paul B Mahol wrote:
> On 4/22/18, Thilo Borgmann wrote:
>> Hi,
>>
>> V3 drops the MLTI part, no idea how it survived
>> 02fff499362daedcdcb0a9cdd517257843600563 on our side...
>> Also dropped audio override, could not get a sample requiring it.
>>
>> Adapted to current HEAD.
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Sunday, April 22, 2018 3:21 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] lavf: make overlay_qsv work
> based on framesync
>
> On 03/04/18 02:50, Ruiling Song wrote:
>
On Mon, 23 Apr 2018, Michael Niedermayer wrote:
On Sun, Apr 22, 2018 at 01:44:19PM +0200, Marton Balint wrote:
On Fri, 20 Apr 2018, Michael Niedermayer wrote:
On Thu, Apr 19, 2018 at 09:32:19PM +0200, Marton Balint wrote:
A pixel format which has a palette also has alpha, without this pa
On Sun, Apr 22, 2018 at 04:29:05PM +0100, Mark Thompson wrote:
> Previously there was one fixed choice for each codec (e.g. H.265 -> Main
> profile), and using anything else then required an explicit option from
> the user. This changes to selecting the profile based on the input format
> and the
> On 20/04/18 08:27, Haihao Xiang wrote:
> > Similar to cbs_h264, cbs_h265_{read, write}_nal_unit() can handle HEVC
> > prefix SEI NAL units now. Currently mastering display colour volume SEI
> > message is added only, we may add more SEI message if needed later
> >
> > Signed-off-by: Haihao Xian
From: Karthick Jeyapal
Otherwise some versions of chrome browser returns "codec not supported" error
---
libavformat/dashenc.c | 34 --
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index fefe3ce..a5f5
From: Karthick Jeyapal
---
libavformat/vpcc.c | 53 ++---
libavformat/vpcc.h | 2 +-
2 files changed, 51 insertions(+), 4 deletions(-)
diff --git a/libavformat/vpcc.c b/libavformat/vpcc.c
index 66d0df6..7951448 100644
--- a/libavformat/vpcc.c
+++
From: Karthick Jeyapal
There is a separate muxer(webmdashenc.c) for supporting VP9+webm output in DASH.
Hence in this muxer we will focus on supporting VP9 in MP4
Have verified playout support of VP9+MP4 in Chrome and Firefox.
---
libavformat/dashenc.c | 3 +--
1 file changed, 1 insertion(+), 2
89 matches
Mail list logo
