Hello all,
Just wondering if anyone had any thoughts on the grepability issue,
which I believe is the only potential issue/breaking change with this
patch.
Thanks,
Kevin
On Sun, Jun 11, 2017 at 9:59 PM, Kevin Mark wrote:
> Hi Michael,
>
> Hoping to get your thoughts on the grepability issue (wr
From: George Boyle
For the blue and violet noise, I took the pink and brown noise
respectively and subtracted the offsets instead of adding them. When I
eyeball the frequency spectrum of the resulting outputs it looks correct
to me, i.e. the blue graph appears to be a mirror image of the pink, an
This prevents ABI issues with GetBitContext.
Signed-off-by: James Almer
---
libavcodec/dca.c| 15 ++-
libavcodec/dca.h| 7 +--
libavcodec/dca_core.c | 2 +-
libavcodec/dca_parser.c | 4 +---
libavformat/dtsdec.c| 4 +---
5 files changed, 22 insertions(+)
Hi,
I'd like to report a tsan warning about a data race in libavcodec/h264_direct.c.
1. Steps to reproduce:
./configure --samples=~/fate-suite/ --toolchain=clang-tsan --disable-stripping
make fate-h264 THREADS=4
2. Here is an excerpt of the tsan warning in
tests/data/fate/h264-conformance-frex
I researched the history of the line in h264_slice.c that this patch deleted.
That line was implicitly added in commit
4da2ac5c7a491b20be62ad19d77526e62aa57c69:
http://git.videolan.org/gitweb.cgi/ffmpeg.git/?p=ffmpeg.git;a=patch;h=4da2ac5c7a491b20be62ad19d77526e62aa57c69
Although commit 4da2ac5c
On 2017/7/19 7:30, Mark Thompson wrote:
> On 17/07/17 03:51, Jun Zhao wrote> On 2017/7/11 15:58, wm4 wrote:
>>> On Tue, 11 Jul 2017 12:06:10 +0800
>>> Jun Zhao wrote:
>>>
From 0e4d230ae4c98949a962c6bbdad31d216b54bb6a Mon Sep 17 00:00:00 2001
From: Jun Zhao
Date: Tue, 21 Mar 2017
Fixes OOM
Fixes: 2674/clusterfuzz-testcase-minimized-4999700518273024
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/diracdec.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff
Fixes: runtime error: shift exponent 64 is too large for 64-bit type 'residual'
(aka 'unsigned long')
Fixes: 2674/clusterfuzz-testcase-minimized-4999700518273024
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
On 7/10/2017 11:11 AM, foo86 wrote:
> These values will be used by the parser. Prefix them with DCA_
> appropriately.
> ---
> libavcodec/dca_core.c | 68
> +++
> libavcodec/dca_core.h | 28 +
> libavcodec/dca_lbr.c | 9 ++-
Hi Ronald,
On Tue, Jul 18, 2017 at 11:41 AM, Ronald S. Bultje wrote:
>
> Reminds me a little of
> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=e72690b18da064f6c0f04f09ccde72b6636e3159.
> From a quick look, it appears that default_ref[] is unconditionally
> initialized in initialise_ref_list()
default_ref[] is unconditionally initialized in h264_initialise_ref_list()
(called from ff_h264_build_ref_list(), called from h264_slice_init()).
This fixes the following tsan warning when running fate-h264:
WARNING: ThreadSanitizer: data race (pid=31070)
Write of size 8 at 0x7bbc82a8 by th
On 17/07/17 03:51, Jun Zhao wrote> On 2017/7/11 15:58, wm4 wrote:
>> On Tue, 11 Jul 2017 12:06:10 +0800
>> Jun Zhao wrote:
>>
>>> From 0e4d230ae4c98949a962c6bbdad31d216b54bb6a Mon Sep 17 00:00:00 2001
>>> From: Jun Zhao
>>> Date: Tue, 21 Mar 2017 11:04:41 +0800
>>> Subject: [V2] examples/vaapi_de
On 18/07/17 05:08, Jun Zhao wrote:
> From ee094ddd0fedecc81ee0107df58fc0ec80369c13 Mon Sep 17 00:00:00 2001
> From: Jun Zhao
> Date: Tue, 18 Jul 2017 00:01:09 -0400
> Subject: [PATCH] lavc/vaapi_encode_h265: Remove duplicate
> slice_segment_address.
>
> the VAEncSliceParameterBufferHEVC in libva
On Tue, Jul 18, 2017 at 10:33 PM, Vittorio Giovara
wrote:
> Based off mpv automatic tonemapping capabilities.
Cool stuff, will have to test this soon. Thanks for putting an example
in the docs.
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 18 July 2017 at 19:42, Nicolas George wrote:
> Le decadi 30 messidor, an CCXXV, Paul B Mahol a écrit :
> > To not cause drama on git repo I kindly ask Michael to remove your git
> > push access.
>
> I will leave the people who have that kind of power judge who must be
> banished :
>
> The one
On Sun, Jul 09, 2017 at 02:28:28PM +0200, Clément Bœsch wrote:
> On Sat, Jul 08, 2017 at 11:07:48PM +0200, Michael Niedermayer wrote:
> [...]
> > 5 days passed with no comments and no suggestions on how to implement
> > this better.
> > does anyone object to the fix as in the patch to be applied ?
On Sun, Jul 16, 2017 at 01:06:55AM +0200, Michael Niedermayer wrote:
> Fixes: runtime error: shift exponent 47 is too large for 32-bit type 'int'
> Fixes: 2581/clusterfuzz-testcase-minimized-4681474395602944
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master
Based off mpv automatic tonemapping capabilities.
Signed-off-by: Vittorio Giovara
---
Updated following an off-list review.
Vittorio
doc/filters.texi | 104
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_tonemap.c | 309 ++
The packet queue is referenced in internal so it needs to be flushed
before the internal structure is freed.
Signed-off-by: Steven Siloti
---
libavformat/utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 38d247c6cd..582836
Updated patch that fixes other ctts modification code to use the new
ctts_allocated_size value; I've verified this passes fate.
- dale
On Tue, Jul 18, 2017 at 9:53 AM, Dale Curtis
wrote:
> Resending as it's own message per contribution rules. I've also attached
> the patch in case the formattin
Hi Wah-Teng,
On Tue, Jul 18, 2017 at 12:59 PM, Wan-Teh Chang <
wtc-at-google@ffmpeg.org> wrote:
> Hi,
>
> I'd like to report a tsan warning about a data race in the h264 decoder.
>
> 1. Steps to reproduce:
>
> ./configure --samples=~/fate-suite/ --toolchain=clang-tsan
> --disable-stripping
>
Le decadi 30 messidor, an CCXXV, Paul B Mahol a écrit :
> To not cause drama on git repo I kindly ask Michael to remove your git
> push access.
I will leave the people who have that kind of power judge who must be
banished :
The one who made useful reviews to the patches, with constructive
commen
On 7/18/17, Nicolas George wrote:
> Le decadi 30 messidor, an CCXXV, Paul B Mahol a ecrit :
>> Design is just fine. You need to be more constructive, otherwise I will
>> just assume you want to be evil and ignore your comments.
>
> This is not true, anybody who reads the mailing-list can see it (I
Le decadi 30 messidor, an CCXXV, Paul B Mahol a écrit :
> Design is just fine. You need to be more constructive, otherwise I will
> just assume you want to be evil and ignore your comments.
This is not true, anybody who reads the mailing-list can see it (I can
provide links if necessary).
Please
On 7/18/17, Nicolas George wrote:
> Le decadi 30 messidor, an CCXXV, Paul B Mahol a ecrit :
>> You are unable to work with as a team.
>
> You may notice that my message did not contain anything ad-hominem.
> This, on the other hand, is pure ad-hoinem.
>
>> I see nothing wrong with either demuxer o
On Sat, 8 Jul 2017, Marton Balint wrote:
This also add supports for 4K DeckLink cards because they always output the
ancillary data in 10-bit.
v2:
- only try teletext decoding for 576i PAL mode
- some comments as requested by Aaron Levinson
Signed-off-by: Marton Balint
Applied the series,
Hi,
I'd like to report a tsan warning about a data race in the h264 decoder.
1. Steps to reproduce:
./configure --samples=~/fate-suite/ --toolchain=clang-tsan --disable-stripping
make fate-h264 THREADS=4
2. Here is an excerpt of the tsan warning in
tests/data/fate/h264-conformance-ba1_ft_c.err
Resending as it's own message per contribution rules. I've also attached
the patch in case the formatting gets trashed.
When sidx box support is enabled, the code will skip reading all
trun boxes (each containing ctts entries for samples inthat box).
If seeks are attempted before all ctts values
The patch does not fix the tsan warning it was intended to fix.
Reverting the patch moves the av_log() back to the outside of the lock.
Signed-off-by: Wan-Teh Chang
---
libavcodec/pthread_frame.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/pthread_frame.c
Signed-off-by: Peter Große
---
tests/fate/filter-video.mak | 5 +
tests/ref/fate/filter-overlay-main-alpha | 15 +++
2 files changed, 20 insertions(+)
create mode 100644 tests/ref/fate/filter-overlay-main-alpha
diff --git a/tests/fate/filter-video.mak b/tests/fate/
On 7/18/2017 3:48 PM, Nicolas George wrote:
> The reasons are exactly the same as the commit that it restores. I will
> include that and the other comments you request once I can access my
> work tree comfortably.
OK.
- Derek
___
ffmpeg-devel mailing li
Le decadi 30 messidor, an CCXXV, Derek Buitenhuis a écrit :
> Doesn't say /why/ it's being reverted. Please update
> the commit message to do so.
The reasons are exactly the same as the commit that it restores. I will
include that and the other comments you request once I can access my
work tree c
Le decadi 30 messidor, an CCXXV, Paul B Mahol a écrit :
> You are unable to work with as a team.
You may notice that my message did not contain anything ad-hominem.
This, on the other hand, is pure ad-hoinem.
> I see nothing wrong with either demuxer or decoder code and no
> duplicated lines of c
On 7/18/2017 3:30 PM, Paul B Mahol wrote:
> I actually like this 'design', as its more like VS one.
I wasn't commenting on the code/design itself, but the commit message,
or rather, lack thereof.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg
On 7/18/17, Derek Buitenhuis wrote:
> On 7/17/2017 3:19 PM, Nicolas George wrote:
>> Signed-off-by: Nicolas George
>> ---
>> libavfilter/framesync2.c | 166
>> +++
>> libavfilter/framesync2.h | 77 --
>> 2 files changed, 82 inserti
On 7/17/2017 3:19 PM, Nicolas George wrote:
> Signed-off-by: Nicolas George
> ---
> libavfilter/framesync2.c | 166
> +++
> libavfilter/framesync2.h | 77 --
> 2 files changed, 82 insertions(+), 161 deletions(-)
So what does this
On 7/17/2017 3:19 PM, Nicolas George wrote:
> This reverts commit 04aa09c4bcf2d5a634a35da3a3ae3fc1abe30ef8.
>
> The fate-ffm change is caused by field_order now being set
> on the output format because the first frame arrives earlier.
> The fate-mxf change is assumed to be the same.
>
> Signed-of
On 7/18/17, Nicolas George wrote:
> Le decadi 30 messidor, an CCXXV, Paul B Mahol a ecrit :
>>I will fork FFmpeg.
>
> It is the third time you make that threat. Out of principle, I want to
> reply to anybody making it : please go ahead and good riddance.
>
> Seriously, only somebod
Le decadi 30 messidor, an CCXXV, Paul B Mahol a écrit :
> I will fork FFmpeg.
It is the third time you make that threat. Out of principle, I want to
reply to anybody making it : please go ahead and good riddance.
Seriously, only somebody unable to working in a team and respecting
On 7/18/17, Nicolas George wrote:
> Le decadi 30 messidor, an CCXXV, Paul B Mahol a ecrit :
>> I'm not going to listen your non-useful comments.
>
> My comments have been constructive. Pushing with outstanding objections
> like that is against the project policy. If you do it on purpose, your
> Gi
Le decadi 30 messidor, an CCXXV, Paul B Mahol a écrit :
> I'm not going to listen your non-useful comments.
My comments have been constructive. Pushing with outstanding objections
like that is against the project policy. If you do it on purpose, your
Git right should be revoked.
--
Nicolas Geo
On 7/18/17, Nicolas George wrote:
> Le decadi 30 messidor, an CCXXV, Paul B Mahol a ecrit :
>> I believe your approach is fine.
>
> The huge duplication between decoder and demuxer is definitely not fine.
> You need to find a solution before pushing anything.
I'm not going to listen your non-usef
On 7/18/17, Vittorio Giovara wrote:
> ---
> libavfilter/vf_zscale.c | 46 +-
> 1 file changed, 21 insertions(+), 25 deletions(-)
>
OK
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/ma
On 7/18/17, Vittorio Giovara wrote:
> ---
> libavfilter/vf_zscale.c | 52
> +
> 1 file changed, 31 insertions(+), 21 deletions(-)
>
> diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
> index a128db6267..466689dbc5 100644
> --- a/libavf
---
libavfilter/vf_zscale.c | 52 +
1 file changed, 31 insertions(+), 21 deletions(-)
diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index a128db6267..466689dbc5 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -
With and without alpha.
---
TODO: version bump
I am aware support for bpp > 2 is not present but the scope
of these formats is limited to a specific usecase, and contained
in libavfilter only.
Suggestions for reflecting this in documentation are welcome.
Cheers,
Vittorio
libavutil/pixdesc.c
Based off mpv automatic tonemapping capabilities.
Signed-off-by: Vittorio Giovara
---
TODO: version bump, changelog entry.
Thanks to Niklas Haas for mentoring me during the development
of this filter.
Vittorio
doc/filters.texi | 101
libavfilter/Makefile | 1 +
l
---
libavfilter/vf_zscale.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index 466689dbc5..d96edb3ade 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -179,6 +179,7 @@ static int query_formats(AVFi
---
libavfilter/vf_zscale.c | 46 +-
1 file changed, 21 insertions(+), 25 deletions(-)
diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index d7b1612f3c..a128db6267 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -421
Le decadi 30 messidor, an CCXXV, Paul B Mahol a écrit :
> I believe your approach is fine.
The huge duplication between decoder and demuxer is definitely not fine.
You need to find a solution before pushing anything.
Regards,
--
Nicolas George
___
f
On 7/16/17, Paras Chadha wrote:
> On Sun, Jul 16, 2017 at 10:06 PM, Paul B Mahol wrote:
>
>> Can you give link to file which holds more than one FITS image?
>>
>
> Yes, here is the file: https://fits.gsfc.nasa.gov/samples/EUVEngc4151imgx.
> fits
>
I believe your approach is fine. There could not
Am 18.07.2017 um 13:24 schrieb Yogender Gupta:
Add P016 support to NVENC.
Thanks,
Yogender
All three patches look fine to me in general.
I vaguely remember there being some reason for P016 being missing so
far, but it might be long fixed.
I'm not at home and can't really push patches from h
On Sun, Jul 16, 2017 at 08:26:57PM +0200, Peter Große wrote:
> On Sun, 16 Jul 2017 18:33:33 +0200
> Paul B Mahol wrote:
>
> >
> > how can one reproduce this bug?
>
> ffmpeg -i fate-suite/mfx/track_01_v02.mxf -filter_complex \
> "movie=fate-suite/png1/lena-rgba.png[logo];[v:0][logo]overlay" -an
Add P016 support to NVENC.
Thanks,
Yogender
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
Added yuv444p16 to hwcontext_cuda.
Thanks,
Yogender
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
dist
Added 10/16bit formats to hwupload_cuda.
Thanks,
Yogender
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
2017-05-02 16:29 GMT+02:00 Carl Eugen Hoyos :
> New, fixed patch attached.
Patch applied.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Wed, Jul 12, 2017 at 05:30:04PM +0200, Clément Bœsch wrote:
> On Wed, Jul 12, 2017 at 05:14:14PM +0200, Nicolas George wrote:
> > Le quartidi 24 messidor, an CCXXV, Clement Boesch a écrit :
> > > ---
> > > ffmpeg_opt.c | 22 +-
> > > 1 file changed, 13 insertions(+), 9 delet
On Wed, Jul 12, 2017 at 8:44 PM, Muhammad Faiz wrote:
> Rework it to improve performance. Now mutex is not shared by workers,
> instead each worker has its own mutex and condition variable. This
> reduces lock contention between workers. Also use atomic variable for
> counter.
>
> The interface al
59 matches
Mail list logo
