From: Ravindra
---
libavformat/http.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/libavformat/http.c b/libavformat/http.c
index 344fd60..a93fa54 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -1611,6 +1611,18 @@ static int http_write(URLContext *h, const uint8
From: Ravindra
When http persistent conenction is enabled for streaming, TCP window size
reduces consistently and reaches zero
---
libavformat/http.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/libavformat/http.c b/libavformat/http.c
index 344fd60..a93fa54 100644
--- a/lib
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 11 +++
libavfilter/Makefile | 1 +
libavfilter/af_drmeter.c | 233 +++
libavfilter/allfilters.c | 1 +
4 files changed, 246 insertions(+)
create mode 100644 libavfilter/af_drmeter.c
On Mon, Mar 05, 2018 at 03:53:04PM -0800, Sasi Inguva wrote:
> This patch seems to be doing the wrong thing and breaking seek tests for us.
>
> As far as I understand , seeking for most containers is based on "decoding
> timestamp". Unless AV_SEEK_TO_PTS flag is specified in container, which is
>
On Wed, Mar 07, 2018 at 01:35:20AM +0200, Jan Ekström wrote:
> On Wed, Mar 7, 2018 at 12:19 AM, Stefan _ wrote:
> > Hi,
> >
> > attached patch fixes an issue with the previous mediacodec patch.
> >
>
> LGTM.
>
> `strstr(name, "OMX.SEC") && strstr(name, ".sw.")`
>
> ..will most likely have less
Here is the fourth version of the PCM patch with updated testcases.
The blocksize of the PCM decoder is hard-coded. This creates
unnecessary delay when reading low-rate (<100Hz) streams. This creates
issues when multiplexing multiple streams, since other inputs are only
opened/read after a low-r
C0deAi (2018-03-06):
> Prevent uninitialized value 'pb[1]' being passed as an
> argument on line 143.
>
> Signed-off-by: C0deAi
> ---
> libavformat/img2enc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Nack. Passing NULL to avio_write() is just as wrong as passing
uninitialized. And
On Tue, Mar 06, 2018 at 01:15:55PM -0800, Aman Gupta wrote:
> From: Aman Gupta
>
> The default behavior of the mediacodec decoder before this commit
> was to delay flushes until all pending hardware frames were
> returned to the decoder. This was useful for certain types of
> applications, but wa
A bunch of independent patches related to FFV1 encoder and decoder,
fixing some issues found during development of FFV1 regression tests
(plan is to use a part of these regression tests in FATE).
Some of the patches prevent FFmpeg to create buggy files, without fixing
the issue.
My point of vi
A buggy file (before the patch preventing such issue is applied):
ffmpeg -y -f lavfi -i mandelbrot=s=31x31 -vframes 1 -c ffv1 -slices 961
a.mkv
Then with:
ffmpeg -y -f lavfi -i mandelbrot=s=31x31 -vframes 1 source.jpg
ffmpeg -y -i a.mkv a.jpg
There is no error message despite the fact the stre
There is a message when coder type is forced to a value not chosen by
user, but no message when version is forced to a value not chosen by user.
This patch adds such message for more coherency in the messages, and the
user is informed that the command is not fully respected.
ffmpeg f lavfi -i m
When there is 1 pixel per slice for the first half of slices, the
encoder creates buggy slices.
Example:
ffmpeg -f lavfi -i mandelbrot=s=8x8 -vf format=yuv444p -t 1 -c ffv1
-coder 1 -context 0 -g 1 -level 3 -slices 64 -slicecrc 1 a.mkv
ffmpeg -f lavfi -i mandelbrot=s=9x9 -vf format=yuv444p -t 1
When there is 1 pixel per slice for the first half of slices, the
encoder creates buggy slices.
Example:
ffmpeg -f lavfi -i mandelbrot=s=8x8 -vf format=yuv444p -t 1 -c ffv1
-coder 1 -context 0 -g 1 -level 3 -slices 64 -slicecrc 1 a.mkv
ffmpeg -f lavfi -i mandelbrot=s=9x9 -vf format=yuv444p -t 1
There is a message when coder type is forced to a value not chosen by
user, but no message when version is forced to a value not chosen by user.
This patch adds such message for more coherency in the messages, and the
user is informed that the command is not fully respected.
ffmpeg f lavfi -i m
When all luma samples for a chroma sample are not in the same slice,
resulting bitstream is valid but the compression then decompression is
not lossless.
ffmpeg -y -f lavfi -i mandelbrot=s=1925x1080 -vf format=yuv411p -vframes
1 -c ffv1 -slices 16 a.mkv
ffmpeg -y -f lavfi -i mandelbrot=s=1925x
FFV1 decoder supports up to 1024 slices but FFV1 encoder permits only
961 (31x31) slices.
This patch permits to create 1024 (32x32) slices.
From 494115e12981a9c54bf04b63a13ef50364349de2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?=
Date: Wed, 7 Mar 2018 10:49:24 +0100
Su
With some sources having specific pix_fmt (9/10/12/14 bit), the source
is padded to 16-bit when the pix_fmt is not supported natively by the
FFV1 encoder.
Nothing is lost ("cutting" to the source bitdepth permits to retrieve
the exact source), but the source bitdepth is not indicated so it is no
On Wed, Mar 07, 2018 at 12:41:13AM +0100, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes fate on big-endian, I failed to fix drawutils for P016.
>
> Please comment (or fix the underlying issue), Carl Eugen
> libavfilter/drawutils.c |2 +-
> tests/ref/fate/filter-pixfmts-pa
The message about the need of a recent FFmpeg version when encoding
alpha plane is 5+ year old, not really relevant anymore.
This patch removes the message.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg
The message about the need of a recent FFmpeg version when encoding
alpha plane is 5+ year old, not really relevant anymore.
This patch removes the message.
From 8e3bbad708b5a3a24920133c5bef0b7399375393 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?=
Date: Wed, 7 Mar 2018
On Tue, Mar 06, 2018 at 02:25:12PM -0800, Aman Gupta wrote:
> From: Aman Gupta
>
> Some streams include both a53 and scte20 data. Before this commit,
> the scte20 data would be used instead of the a53 data.
>
> See https://s3.amazonaws.com/tmm1/ccaptions/scte20plusa53.ts,
> which produced garbag
On Tue, Mar 06, 2018 at 12:47:15PM -0800, Josh Allmann wrote:
> ---
> doc/bitstream_filters.texi | 5 +
> libavcodec/noise_bsf.c | 12
> libavcodec/version.h | 2 +-
> 3 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/doc/bitstream_filters.texi b/doc/b
On Tue, Mar 06, 2018 at 12:45:33PM -0800, Aman Gupta wrote:
> From: Aman Gupta
>
> ---
> libavcodec/aacdec.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
You can kill me, but you cannot
> On Mar 7, 2018, at 12:49 PM, Michael Niedermayer
> wrote:
>
> On Tue, Mar 06, 2018 at 02:25:12PM -0800, Aman Gupta wrote:
>> From: Aman Gupta
>>
>> Some streams include both a53 and scte20 data. Before this commit,
>> the scte20 data would be used instead of the a53 data.
>>
>> See https:/
Friendly ping. I'd like to not have to land this in Chromium before upstream
ffmpeg, but I may need to soon.
On Tue, Mar 6, 2018 at 1:56 PM, Michael Niedermayer
wrote:
> Fixes: Chromium bug 800123
> Reported-by: Matt Wolenetz
> Reviewed-by: Matt Wolenetz
> Signed-off-by: Michael Niedermayer
On Wed, Mar 7, 2018 at 9:49 AM Michael Niedermayer
wrote:
> On Tue, Mar 06, 2018 at 02:25:12PM -0800, Aman Gupta wrote:
> > From: Aman Gupta
> >
> > Some streams include both a53 and scte20 data. Before this commit,
> > the scte20 data would be used instead of the a53 data.
> >
> > See https://s
Friendly ping. I'd like to not have to land this in Chromium before upstream
ffmpeg, but I may need to soon.
On Tue, Mar 6, 2018 at 1:56 PM, Michael Niedermayer
wrote:
> Fixes: Chromium bug 800123
> Reported-by: Matt Wolenetz
> Reviewed-by: Matt Wolenetz
> Signed-off-by: Michael Niedermayer
Friendly ping. I'd like to not have to land this in Chromium before upstream
ffmpeg, but I may need to soon.
On Tue, Mar 6, 2018 at 6:43 AM, Michael Niedermayer
wrote:
> Fixes: runtime error: signed integer overflow: 5 * -2147483647 cannot be
> represented in type 'int'
> Fixes: Chromium bug 81
On 3/7/18, Matthew Wolenetz wrote:
> Friendly ping. I'd like to not have to land this in Chromium before upstream
> ffmpeg, but I may need to soon.
>
> On Tue, Mar 6, 2018 at 1:56 PM, Michael Niedermayer
> wrote:
>
>> Fixes: Chromium bug 800123
>> Reported-by: Matt Wolenetz
>> Reviewed-by: Matt
> From what I've seen in US broadcast television, scte20 is only used on
> standard-def content and everything else uses normal a53.
A53 is definitely the more popular standard, and all that is approved for
distribution in digital over the air broadcasts. SCTE-20 would only be found
further up
Friendly ping. I'd like to not have to land this in Chromium before
upstream ffmpeg, but I may need to soon.
On Tue, Mar 6, 2018 at 1:56 PM, Michael Niedermayer
wrote:
> Fixes: Chromium bug 800123
> Reported-by: Matt Wolenetz
> Reviewed-by: Matt Wolenetz
> Signed-off-by: Michael Niedermayer
>
Friendly ping. I'd like to not have to land this in Chromium before
upstream ffmpeg, but I may need to soon.
On Tue, Mar 6, 2018 at 6:43 AM, Michael Niedermayer
wrote:
> Fixes: runtime error: signed integer overflow: 5 * -2147483647 cannot be
> represented in type 'int'
> Fixes: Chromium bug 817
Friendly ping. I'd like to not have to land this in Chromium before
upstream ffmpeg, but I may need to soon.
On Tue, Mar 6, 2018 at 1:56 PM, Michael Niedermayer
wrote:
> Fixes: Chromium bug 800123
> Reported-by: Matt Wolenetz
> Reviewed-by: Matt Wolenetz
> Signed-off-by: Michael Niedermayer
>
On Wed, Mar 07, 2018 at 10:09:58AM -0800, Matt Wolenetz wrote:
> Friendly ping. I'd like to not have to land this in Chromium before
> upstream ffmpeg, but I may need to soon.
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The misfortune of the
On Wed, Mar 07, 2018 at 10:10:09AM -0800, Matt Wolenetz wrote:
> Friendly ping. I'd like to not have to land this in Chromium before
> upstream ffmpeg, but I may need to soon.
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who would give u
On Wed, Mar 07, 2018 at 10:14:09AM -0800, Matt Wolenetz wrote:
> Friendly ping. I'd like to not have to land this in Chromium before
> upstream ffmpeg, but I may need to soon.
will apply
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
it is not once nor twice bu
On Mon, Mar 05, 2018 at 04:43:56PM -0800, Matthew Wolenetz wrote:
>
> vorbisdec.c |1 +
> 1 file changed, 1 insertion(+)
> ade25a35093139e9555c2a6563e950e31c150697
> 0001-lavc-vorbisdec-Allow-avcodec_open2-to-call-.close.patch
> From 7471c1d223b860c13793abfd93174d1557f77d6f Mon Sep 17 00:0
On Mon, Mar 05, 2018 at 08:46:43PM +, Rostislav Pehlivanov wrote:
> On 3 March 2018 at 16:20, Aurelien Jacobs wrote:
>
> > On Thu, Mar 01, 2018 at 10:46:07PM +, Rostislav Pehlivanov wrote:
> > > On 1 March 2018 at 20:45, Aurelien Jacobs wrote
> > >
> > > >
> > > > So what I propose is to
On Tue, 6 Mar 2018, Marton Balint wrote:
Accepting 'u' suffix for a time specification is neither intuitive nor
consistent (now that we don't accept m). Also there was a bug in the code
accepting an extra 's' even after 'ms'.
Signed-off-by: Marton Balint
---
libavutil/parseutils.c | 7 +++---
On 07/03/18 03:56, Dylan Fernando wrote:
> Thanks, it works now
>
> Would trying to implement an OpenCL version of vf_fade be a good idea for a
> qualification task, or would it be a better idea to try a different filter?
That sounds like a sensible choice to me, though if you haven't written a
On Tue, Mar 06, 2018 at 01:02:48AM +0100, Marton Balint wrote:
> Accepting 'u' suffix for a time specification is neither intuitive nor
> consistent (now that we don't accept m).
The 'm' SI prefix is still accepted in various time options, and the 'u'
prefix is still accepted in those options even
*** Hi everybody! I Implemented vf_convolution_opencl filter as qualification
task for GSoC Video filtering with OpenCL project***
Danil Iashchenko (1):
add vf_convolution_opencl
configure | 1 +
libavfilter/Makefile| 2 +
libavfilter/allfilters.c
---
configure | 1 +
libavfilter/Makefile| 2 +
libavfilter/allfilters.c| 1 +
libavfilter/opencl/convolution.cl | 80
libavfilter/opencl_source.h | 2 +
libavfilter/vf_convolution_opencl.c | 374
On Wed, 7 Mar 2018, Aurelien Jacobs wrote:
On Tue, Mar 06, 2018 at 01:02:48AM +0100, Marton Balint wrote:
Accepting 'u' suffix for a time specification is neither intuitive nor
consistent (now that we don't accept m).
The 'm' SI prefix is still accepted in various time options, and the 'u'
On Wed, Mar 07, 2018 at 11:45:03PM +0100, Marton Balint wrote:
>
>
> On Wed, 7 Mar 2018, Aurelien Jacobs wrote:
>
> > On Tue, Mar 06, 2018 at 01:02:48AM +0100, Marton Balint wrote:
> > > Accepting 'u' suffix for a time specification is neither intuitive nor
> > > consistent (now that we don't ac
On Thu, Mar 8, 2018 at 12:05 AM, Aurelien Jacobs wrote:
> On Wed, Mar 07, 2018 at 11:45:03PM +0100, Marton Balint wrote:
>>
>>
>> On Wed, 7 Mar 2018, Aurelien Jacobs wrote:
>>
>> > On Tue, Mar 06, 2018 at 01:02:48AM +0100, Marton Balint wrote:
>> > > Accepting 'u' suffix for a time specification i
On 7 March 2018 at 18:03, Michael Niedermayer wrote:
> On Tue, Mar 06, 2018 at 12:47:15PM -0800, Josh Allmann wrote:
>> ---
>> doc/bitstream_filters.texi | 5 +
>> libavcodec/noise_bsf.c | 12
>> libavcodec/version.h | 2 +-
>> 3 files changed, 18 insertions(+), 1 del
On Wed, Mar 07, 2018 at 11:37:00PM +, Josh Allmann wrote:
> On 7 March 2018 at 18:03, Michael Niedermayer wrote:
> > On Tue, Mar 06, 2018 at 12:47:15PM -0800, Josh Allmann wrote:
> >> ---
> >> doc/bitstream_filters.texi | 5 +
> >> libavcodec/noise_bsf.c | 12
> >> libav
On Wed, Mar 07, 2018 at 04:45:20PM +0100, Jerome Martinez wrote:
> A buggy file (before the patch preventing such issue is applied):
> ffmpeg -y -f lavfi -i mandelbrot=s=31x31 -vframes 1 -c ffv1 -slices 961
> a.mkv
>
> Then with:
> ffmpeg -y -f lavfi -i mandelbrot=s=31x31 -vframes 1 source.jpg
> f
On Wed, Mar 07, 2018 at 04:49:24PM +0100, Jerome Martinez wrote:
> There is a message when coder type is forced to a value not chosen by user,
> but no message when version is forced to a value not chosen by user.
> This patch adds such message for more coherency in the messages, and the
> user is
On 07/03/18 07:10, Xiang, Haihao wrote:
>
> Hi Mark,
>
> Do you have any comment to this patch? FFmpeg-vaapi fails to use low power
> mode
> for H.264 encoding.
I still want to clean up all of this configuration stuff, but I guess it works
ok for now. So, I fixed the overlong line and applied
On Thu, Mar 08, 2018 at 12:14:00AM +0100, Hendrik Leppkes wrote:
> On Thu, Mar 8, 2018 at 12:05 AM, Aurelien Jacobs wrote:
> > On Wed, Mar 07, 2018 at 11:45:03PM +0100, Marton Balint wrote:
> >>
> >>
> >> On Wed, 7 Mar 2018, Aurelien Jacobs wrote:
> >>
> >> > On Tue, Mar 06, 2018 at 01:02:48AM +01
On 07/03/18 07:07, Xiang, Haihao wrote:
> On Tue, 2018-03-06 at 14:42 +, Mark Thompson wrote:
>> On 06/03/18 06:04, Eoff, Ullysses A wrote:
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
Mark Thompson
Sent: Tuesday, Februa
On 08/03/2018 01:17, Michael Niedermayer wrote:
In the cases where the error is about a scalar value, that value should
be printed in the error message (unless it was alread printed elsewhere)
Patch modified, showing the scalar value.
From 13db9fc4da1d0e531e516bd87d084233e231f0e7 Mon Sep 17 00
On 08/03/2018 01:33, Michael Niedermayer wrote:
On Wed, Mar 07, 2018 at 04:49:24PM +0100, Jerome Martinez wrote:
There is a message when coder type is forced to a value not chosen by user,
but no message when version is forced to a value not chosen by user.
This patch adds such message for more
On 3/7/2018 1:42 AM, Yingming Fan wrote:
> From: Yingming Fan
>
> ---
> Previous patch test 8 9 and 10 bit depth, because i consult codes from
> hevc_idct and hevc_add_res.
> While this patch test 8 10 and 12 bit depth like what VP9 does. I will
> submit another patch fix these issue in hevc_
It's trivial to craft a HTTP response that will make the code for
skipping trailing whitespace access and possibly overwrite bytes outside
of the memory allocation. Why this can happen is blindingly obvious: it
accesses cstr[strlen(cstr)-1] without checking whether the string is
empty.
---
libavfo
libavformat prints a warning that the cookie couldn't be parsed (see
callers of parse_cookie()). This is obviously not true - it could be
parsed, but was simply ignored. Don't return an error to avoid the
warning.
---
libavformat/http.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
If the string consists entirely of whitespace, this could in theory
continue to write '\0' before the start of the memory allocation. In
practice, it didn't really happen: the generic HTTP header parsing code
already skips leading whitespaces, so the string is either empty, or
consists a non-whites
On 3/6/2018 3:49 PM, Mark Thompson wrote:
> This can remove units with types in or not in a given set from a stream.
> For example, it can be used to remove all non-VCL NAL units from an H.264 or
> H.265 stream.
> ---
> On 06/03/18 17:27, Hendrik Leppkes wrote:
>> On Tue, Mar 6, 2018 at 3:51 PM, Er
---
libavformat/movenc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 5b1e66c897..fb8462ed9a 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -554,7 +554,6 @@ static int mov_write_eac3_tag(AVIOContext *pb, MOVTrack
*track)
From: Meng Wang
Signed-off-by: Meng Wang
---
As FFmpeg hevc decoder have no SAO neon optimization, we add sao_band and
sao_edge neon codes in this patch.
I have already submit a patch called 'checkasm/hevc_sao : add hevc_sao for
checkasm' several days ago.
Results below was printed by hevc_sao
On Wed, Mar 7, 2018 at 10:35 AM Devin Heitmueller <
dheitmuel...@ltnglobal.com> wrote:
>
> > From what I've seen in US broadcast television, scte20 is only used on
> > standard-def content and everything else uses normal a53.
>
> A53 is definitely the more popular standard, and all that is approve
From: Yingming Fan
---
We have 8 10 and 12 SIMD codes, but previous checkasm hevc_idct only test 8
and 10 bit depth.
tests/checkasm/hevc_idct.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/checkasm/hevc_idct.c b/tests/checkasm/hevc_idct.c
index eea712101d..c2
64 matches
Mail list logo
