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
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
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-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 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
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:
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
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
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: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: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
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
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/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 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
>
> 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
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
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
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 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,
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
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
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
>
> > 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
>
> > 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
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
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
>
>
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
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
>
> 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
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
>
> 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:
>>
>> 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.
>>
>
>
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, 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 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 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 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 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 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 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 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 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 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: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 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
46 matches
Mail list logo