On 3/17/2018 11:13 PM, James Almer wrote:
> On 3/17/2018 10:54 PM, Michael Niedermayer wrote:
>> On Sat, Mar 17, 2018 at 10:39:25PM -0300, James Almer wrote:
>>> On 3/17/2018 10:28 PM, Michael Niedermayer wrote:
On Fri, Mar 16, 2018 at 08:16:01PM -0300, James Almer wrote:
> There's no need
On 3/17/2018 10:54 PM, Michael Niedermayer wrote:
> On Sat, Mar 17, 2018 at 10:39:25PM -0300, James Almer wrote:
>> On 3/17/2018 10:28 PM, Michael Niedermayer wrote:
>>> On Fri, Mar 16, 2018 at 08:16:01PM -0300, James Almer wrote:
There's no need to allocate a new packet for it.
Sign
On Sat, Mar 17, 2018 at 10:39:25PM -0300, James Almer wrote:
> On 3/17/2018 10:28 PM, Michael Niedermayer wrote:
> > On Fri, Mar 16, 2018 at 08:16:01PM -0300, James Almer wrote:
> >> There's no need to allocate a new packet for it.
> >>
> >> Signed-off-by: James Almer
> >> ---
> >> libavcodec/noi
On 3/17/2018 10:33 PM, Michael Niedermayer wrote:
> On Sat, Mar 17, 2018 at 09:26:32PM -0300, James Almer wrote:
>> On 3/17/2018 8:48 PM, Michael Niedermayer wrote:
>>> On Fri, Mar 16, 2018 at 03:21:41PM -0300, James Almer wrote:
Signed-off-by: James Almer
---
This is a proof of con
On 3/17/2018 10:28 PM, Michael Niedermayer wrote:
> On Fri, Mar 16, 2018 at 08:16:01PM -0300, James Almer wrote:
>> There's no need to allocate a new packet for it.
>>
>> Signed-off-by: James Almer
>> ---
>> libavcodec/noise_bsf.c | 30 --
>> 1 file changed, 8 insertio
On Sat, Mar 17, 2018 at 09:26:32PM -0300, James Almer wrote:
> On 3/17/2018 8:48 PM, Michael Niedermayer wrote:
> > On Fri, Mar 16, 2018 at 03:21:41PM -0300, James Almer wrote:
> >> Signed-off-by: James Almer
> >> ---
> >> This is a proof of concept for a dynamic size buffer pool API.
> >>
> >> Fo
On Fri, Mar 16, 2018 at 08:16:01PM -0300, James Almer wrote:
> There's no need to allocate a new packet for it.
>
> Signed-off-by: James Almer
> ---
> libavcodec/noise_bsf.c | 30 --
> 1 file changed, 8 insertions(+), 22 deletions(-)
should be ok assumung the the pac
On 2018-03-13 20:08 +0100, Thilo Borgmann wrote:
> Am 13.03.18 um 19:52 schrieb Paul B Mahol:
> > On 3/13/18, Thilo Borgmann wrote:
> >> Hi,
> >>
> >>> once again, FFmpeg has been accepted for CLT 2018 in Chemnitz, Germany!
> >>> This "Chemnitzer Linux Tage" will take place on 10th and 11th of Mar
On 3/17/2018 8:48 PM, Michael Niedermayer wrote:
> On Fri, Mar 16, 2018 at 03:21:41PM -0300, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> This is a proof of concept for a dynamic size buffer pool API.
>>
>> For the purpose of easy testing and reviewing I replaced the current
>> linke
On Fri, Mar 16, 2018 at 03:21:41PM -0300, James Almer wrote:
> Signed-off-by: James Almer
> ---
> This is a proof of concept for a dynamic size buffer pool API.
>
> For the purpose of easy testing and reviewing I replaced the current
> linked list used to keep a pool of fixed size buffers with th
On 3/17/2018 5:10 PM, Martin Vignali wrote:
> Thanks for the comments,
>
> New patch in attach
>
> Martin
Should be ok.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 3/17/18, Alexander Strasser wrote:
> On 2018-03-15 17:38 +0100, Paul B Mahol wrote:
>> On 3/13/18, Thilo Borgmann wrote:
>> > Am 13.03.18 um 19:52 schrieb Paul B Mahol:
>> >> On 3/13/18, Thilo Borgmann wrote:
>> >>> Hi,
>> >>>
>> once again, FFmpeg has been accepted for CLT 2018 in Chemn
On 2018-03-15 17:38 +0100, Paul B Mahol wrote:
> On 3/13/18, Thilo Borgmann wrote:
> > Am 13.03.18 um 19:52 schrieb Paul B Mahol:
> >> On 3/13/18, Thilo Borgmann wrote:
> >>> Hi,
> >>>
> once again, FFmpeg has been accepted for CLT 2018 in Chemnitz, Germany!
> This "Chemnitzer Linux Tag
On 3/17/18, Martin Vignali wrote:
>>
>> Obviously for whatever reason files are tagged as limited, when in fact
>> they are full range.
>>
>> I couldn't find source of this bug. But your patch is wrong, as it
>> ignores
>> color_range if it is set to limited, even if such files are useless.
>>
>
>
>
> Obviously for whatever reason files are tagged as limited, when in fact
> they are full range.
>
> I couldn't find source of this bug. But your patch is wrong, as it ignores
> color_range if it is set to limited, even if such files are useless.
>
I think there is two problem here
1 - Frame ta
On 3/17/18, Martin Vignali wrote:
>>
>> Those checks are there for the reason, fix your samples.
>>
>
> Same wrong output if i convert the sample to png, and run unpremultiply
> filter.
Two wrongs does not make something bad suddenly good.
Obviously for whatever reason files are tagged as limite
>
> Those checks are there for the reason, fix your samples.
>
Same wrong output if i convert the sample to png, and run unpremultiply
filter.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Thanks for the comments,
New patch in attach
Martin
0001-fate-hapqa_extract-add-test-for-hapqa_extract-bsf.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 3/17/18, Martin Vignali wrote:
> Hello,
>
> Patch in attach change premultiply/unpremultiply filter for RGB input
> to process it at full range
>
> Avoid very strange result in unpremultiply mode
>
> To test :
> ./ffmpeg -i ./fate-suite/mov/mov_alpha_premult.mov -vf
> unpremultiply=inplace=1 re
2018-03-17 19:17 GMT+01:00 Martin Vignali :
> Hello,
>
> Patch in attach add test for premultiply filter in inplace mode (use the
> alpha channel of the src)
> for 8 bits RGBA input.
>
> tested on X86_64 and x86_32
>
> can be test with :
> make fate-filter-premultiply-rgba-8 SAMPLES=fate-suite
>
>
Hello,
Patch in attach change premultiply/unpremultiply filter for RGB input
to process it at full range
Avoid very strange result in unpremultiply mode
To test :
./ffmpeg -i ./fate-suite/mov/mov_alpha_premult.mov -vf
unpremultiply=inplace=1 resStraight.png -y
./ffmpeg -i ./fate-suite/mov/mov_a
>
> > fixes channels such as DL/DR, which will now write to
> LeftTotal/RightTotal
> Is this correct?
To the best of my understanding, this is correct; however, I'm by no means
an expert on this subject, so I'd love to know if I'm wrong here. The
flip-side for reading MOVs is already implemented
>
> > From my reading of this, the 'udta' atom can appear as a child of a
> 'trak'
> > atom, and can have an optional child 'name',
>
> Then why is it optional?
>
I've made this an optional movflag in attempt to be extra careful. I'm new
to this code-base and am err-ing on the side of caution. I'd
2018-03-17 19:57 GMT+01:00, Courtland Idstrom :
> Hi -
>
> Thanks for the feedback here. I'll fix that commit message. I believe this
> is the most relevant reference material regarding the userdata ('udta') tag
> for Quicktime:
>
> https://developer.apple.com/library/content/documentation/QuickTim
On 3/17/2018 2:54 PM, Martin Vignali wrote:
> Hello,
>
> Patch in attach add test for the bsf filter
>
> test extract color and alpha
> with the three main kind of hap frame :
> - no snappy compression
> - snappy compression and one chunk
> - snappy compression and several chunks (16 here)
>
> l
Hi -
Thanks for the feedback here. I'll fix that commit message. I believe this
is the most relevant reference material regarding the userdata ('udta') tag
for Quicktime:
https://developer.apple.com/library/content/documentation/QuickTime/Reference/QTRef_AtomsResources/Content/QTRef_AtomsResource
Hello
Patch in attach add SIMD for 16 bit version of
grainextract
grainmerge
average
extremity
negation
003 : modify DIFFERENCE macro to reduce line duplication
004 : add SIMD for grainextract, grainmerge, average, extremity, negation
005 : add checkasm test for grainextract, grainmerge, average,
Hello,
Patch in attach add test for premultiply filter in inplace mode (use the
alpha channel of the src)
for 8 bits RGBA input.
tested on X86_64 and x86_32
can be test with :
make fate-filter-premultiply-rgba-8 SAMPLES=fate-suite
Martin
0002-fate-vf_premultiply-add-test-for-rgba-8-bits-inpla
Hello,
Patch in attach add test for the bsf filter
test extract color and alpha
with the three main kind of hap frame :
- no snappy compression
- snappy compression and one chunk
- snappy compression and several chunks (16 here)
like the bsf filter need to be used with vtag and encoder edition
a
Ok, thank you for the feedback, I'll do this in the future. Still getting
the hang of submitting patches this way. Should I resubmit this patch (just
part 1), and if I do so, what would be the best way to indicate on the
mailing list that I'm submitting a new patch to replace the one(s) here?
Tha
>
> In that case we can let the test using "none" compression (bypass the
> snappy part)
> and remove only snappy1 and snappy16 test
> Like in patch in attach.
>
>
Pushed
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/list
On 3/17/2018 12:31 PM, Paul B Mahol wrote:
> On 3/17/18, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> tests/fate/dca.mak | 5 +
>> 1 file changed, 5 insertions(+)
>>
>
> lgtm
Pushed, thanks.
___
ffmpeg-devel mailing list
ffmpeg-deve
On 3/17/18, James Almer wrote:
> Signed-off-by: James Almer
> ---
> tests/fate/dca.mak | 5 +
> 1 file changed, 5 insertions(+)
>
lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Fri, 16 Mar 2018 15:51:26 -0400
Joe Koberg wrote:
> I'm saying I don't think it needs it - MPEGTS does seem to handle the
> discontinuous input fine if I just concatenate it.
>
> MPEG TS packets themselves do have a discontinuity flag in the
> adaptation field, but again it looks like it migh
On 3/14/2018 2:42 AM, Jun Zhao wrote:
>
> 0005-lavc-extract_extradata_bsf-support-dump-options.patch
>
>
> From 3d49b455b8bea2ee311b011fd9078e180c7bdf9a Mon Sep 17 00:00:00 2001
> From: Jun Zhao
> Date: Thu, 8 Mar 2018 14:05:53 +0800
> Subject: [PATCH V3 05/11] lavc/extract_extradata_bsf: suppo
2018-03-17 3:33 GMT+01:00, Courtland Idstrom :
> Hi -
>
> I'm working with a post-production workflow to mux 5.1 wav audio into a mov
> file (each channel specified as a separate track), with correct channel
> assignments written as metadata. I'm able to get everything except for the
> Center chann
2018-03-17 3:29 GMT+01:00, Courtland Idstrom :
> Adds the ability to support writing channel labels to mov files if the
> layout_tag fails, instead of printing a warning and skipping the tag. This
> fixes channels such as DL/DR, which will now write to LeftTotal/RightTotal
Is this correct?
> ins
2018-03-17 3:26 GMT+01:00, Courtland Idstrom :
> Example:
> ffmpeg -i in.mov -movflags write_track_title -metadata:s:a:0
> title="Eng-FullMix"
Is this defined by the QuickTime specification?
The commit message should be split so the first line
is <80 chars.
Carl Eugen
_
2018-03-17 3:26 GMT+01:00, Courtland Idstrom :
> ---
> Changelog | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Changelog b/Changelog
> index 7969b414c4..32a93d916a 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -47,7 +47,7 @@ version :
> - native SBC encoder and decode
Fixes Coverity CID 1419523.
Signed-off-by: Marton Balint
---
libavdevice/decklink_common.cpp | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index da414ed5f8..b889033cf8 100644
--- a/libavdev
Hi!
Attached patch is supposed to silence a warning on some systems (seen
on Debian logs).
Please test and review, Carl Eugen
From 841d9ed2db4f3e071ecc681e4f50ff61df2ea358 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sat, 17 Mar 2018 12:42:07 +0100
Subject: [PATCH] lavu/hwcontext_vaapi:
2018-03-17 6:43 GMT+01:00, dylanf...@gmail.com :
> From: drfer3
> --- /dev/null
> +++ b/libavfilter/opencl/avgblur.cl
> @@ -0,0 +1,60 @@
> +/*
> + * Author: Dylan Fernando
* Copyright (c) 2018 Dylan Fernando
Carl Eugen
___
ffmpeg-devel mailing list
f
2018-03-17 7:05 GMT+01:00, Gagandeep Singh :
> Thanks, sure will take care next time :)
Next task for you is to find out what "top-posting" means
and avoid it here;-)
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mai
2018-03-17 10:42 GMT+01:00, Gagandeep Singh :
> ticket #5522: interlaced frame required horizontal-temporal inverse
> transform. though the output is not satisfactory yet.
> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
> index a064cd1599..b17c7c1dc5 100644
> --- a/libavcodec/cfhd.c
> +++ b/l
2018.03.14. 20:29 keltezéssel, Nicolas George írta:
Bodecs Bela (2018-03-14):
In case of some content, astreamselect filter remains in non active
state.
please review this pacth. I am not sure this is the right fix of this.
I am not sure either. framesync was not designed for audio. I would l
ticket #5522: interlaced frame required horizontal-temporal inverse
transform. though the output is not satisfactory yet.
---
libavcodec/cfhd.c | 102 --
libavcodec/cfhd.h | 3 +-
2 files changed, 85 insertions(+), 20 deletions(-)
diff --git a
46 matches
Mail list logo