On Sun, Oct 14, 2018 at 3:07 AM Michael Niedermayer
wrote:
>
> On Fri, Oct 12, 2018 at 09:41:04PM +0800, Jun Zhao wrote:
> > case 1:
> > use the hexdump -C SMM0005.rcv get:
> > size skip (size - 4)
> > ||
> >
On Sat, Oct 13, 2018 at 06:24:52PM +0200, Martin Vignali wrote:
> >
> > Applied
> >
> >
> Seems like fate-mxf-reel_name doesn't pass after your patchs
> make fate-mxf-reel_name SAMPLES=fate-suite
this also broke 2 other fate tests:
make: *** [fate-mxf-reel_name] Error 1
make: *** [fate-copy-trac49
On Fri, Oct 12, 2018 at 01:13:45AM +0100, Derek Buitenhuis wrote:
> On 11/10/2018 23:39, Alex Sukhanov wrote:
> > The only "spec" I'm aware of:https://wiki.multimedia.cx/index.php/IVF
>
> Yeah, not really a spec.
>
> I have no strong objections, I guess.
so IIUC noone is against this ?
if so i w
v3: - add size check when probe as Michael's comments.
- update commit msg
- for Jerome's comments, I don't find a way to adjusted the handle for
"0x000c"
v2: - split the patch (Carl Eugen Hoyos's comments).
Jun Zhao (2):
lavf/vc1test: fix vc1test can't probe some RCV file.
lavf/v
case 1:
use the hexdump -C SMM0005.rcv get:
size skip (size - 4)
||
VV
18 00 00 c5 05 00 00 00 4d f1 0a 11 00 e0 01 00
0010 00 d0 02 00 00 0c 00 00 00 88 13
rcv is commonly used as extension for vc1 test stream files.
Signed-off-by: Jun Zhao
---
libavformat/vc1test.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/libavformat/vc1test.c b/libavformat/vc1test.c
index e029ff4..39b7716 100644
--- a/libavformat/vc1test.c
+++ b/li
Signed-off-by: Paul B Mahol
---
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/asrc_sinc.c | 457 +++
3 files changed, 459 insertions(+)
create mode 100644 libavfilter/asrc_sinc.c
diff --git a/libavfilter/Makefile b/libavfilt
On Sat, Oct 13, 2018 at 6:43 PM Mark Thompson wrote:
> On 06/10/18 07:21, Landgraph wrote:
> > 1. Old logic meaned: everywhere, except Windows, ffmpeg has to use HW
> acceleration, but on Windows ffmpeg has to use (unavailable) software
> encode by default
> > 2. Software encode is available only
On Fri, Oct 12, 2018 at 09:41:04PM +0800, Jun Zhao wrote:
> case 1:
> use the hexdump -C SMM0005.rcv get:
> size skip (size - 4)
> ||
> VV
> 18 00 00 c5 05 00 00 0
On Sat, Oct 13, 2018 at 8:28 PM Hendrik Leppkes wrote:
>
> On Sat, Oct 13, 2018 at 8:26 PM Michael Niedermayer
> wrote:
> >
> > On Fri, Oct 12, 2018 at 02:35:04PM +0100, jos...@ob-encoder.com wrote:
> > > From: Josh de Kock
> > >
> > > This test ensures that you are able to send N number of slic
On Sat, Oct 13, 2018 at 8:26 PM Michael Niedermayer
wrote:
>
> On Fri, Oct 12, 2018 at 02:35:04PM +0100, jos...@ob-encoder.com wrote:
> > From: Josh de Kock
> >
> > This test ensures that you are able to send N number of slice NALUs in
> > slice threaded mode to be decoded simultaneously
> > ---
On Fri, Oct 12, 2018 at 02:35:04PM +0100, jos...@ob-encoder.com wrote:
> From: Josh de Kock
>
> This test ensures that you are able to send N number of slice NALUs in slice
> threaded mode to be decoded simultaneously
> ---
>
> Ignore the previous patch, had some dead code in it. This now
> w
Hello,
Following Carl Eugen comment,
and this commit :
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=b38d4874
Add name of the author of the inline mmxext version of shuffle2103 at the
top of the asm file
Martin
0001-swscale-x86-rgb2rgb.asm-add-Ivo-Van-Poorten-name-to-.patch
Description
This work is partially sponsored by VideoLAN.
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 1 +
libavcodec/agm.c| 701
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 7 +
libavformat/ri
On 10/13/18, Carl Eugen Hoyos wrote:
> 2018-10-13 19:16 GMT+02:00, Paul B Mahol :
>> On 10/13/18, Carl Eugen Hoyos wrote:
>>> 2018-10-13 14:35 GMT+02:00, Paul B Mahol :
On 10/12/18, Paul B Mahol wrote:
> Fixes #6821.
>
Will comitt with this above sentence removed.
>>>
>>>
2018-10-13 19:16 GMT+02:00, Paul B Mahol :
> On 10/13/18, Carl Eugen Hoyos wrote:
>> 2018-10-13 14:35 GMT+02:00, Paul B Mahol :
>>> On 10/12/18, Paul B Mahol wrote:
Fixes #6821.
>>>
>>> Will comitt with this above sentence removed.
>>
>> Why did you remove it?
>
> Because I have not got
On 10/13/18, Carl Eugen Hoyos wrote:
> 2018-10-13 14:35 GMT+02:00, Paul B Mahol :
>> On 10/12/18, Paul B Mahol wrote:
>>> Fixes #6821.
>>>
>>
>> Will comitt with this above sentence removed.
>
> Why did you remove it?
Because I have not got any reply regarding mplayer.
__
2018-10-13 14:35 GMT+02:00, Paul B Mahol :
> On 10/12/18, Paul B Mahol wrote:
>> Fixes #6821.
>>
>
> Will comitt with this above sentence removed.
Why did you remove it?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org
> > You mean, increase the height of the output frame ?
> > If yes :
> > Do you think it's better to duplicate each value, or duplicate the
> current
> > lines several times ?
>
> Your pick.
>
New patch in attach,
for gray 8, 9, 10, duplicate lines ramp several times, to have 16 pix height
(probab
On 11/10/18 06:38, Zhong Li wrote:
> ffmpeg | branch: master | Zhong Li | Mon Sep 17 19:16:44
> 2018 +0800| [681aa7d14f97fd98181ca6d61e11be48fe65692d] | committer: Zhong Li
>
> lavu/qsv: make a copy as libmfx alignment requirement for uploading
>
> Libmfx requires 16 bytes aligned input/output
On 06/10/18 07:21, Landgraph wrote:
> 1. Old logic meaned: everywhere, except Windows, ffmpeg has to use HW
> acceleration, but on Windows ffmpeg has to use (unavailable) software encode
> by default
> 2. Software encode is available only if you provide corresponding software
> MediaSDK library,
>
> Applied
>
>
Seems like fate-mxf-reel_name doesn't pass after your patchs
make fate-mxf-reel_name SAMPLES=fate-suite
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 10/13/18, Martin Vignali wrote:
>>
>> The 256x <=16 size is not very useful.
>>
>
> You mean, increase the height of the output frame ?
> If yes :
> Do you think it's better to duplicate each value, or duplicate the current
> lines several times ?
Your pick.
___
>
> The 256x <=16 size is not very useful.
>
You mean, increase the height of the output frame ?
If yes :
Do you think it's better to duplicate each value, or duplicate the current
lines several times ?
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@
On 10/13/18, Martin Vignali wrote:
> Hello,
>
> Patch in attach add a video generator which output all gray value for the
> given pix_fmt
> Also add fate test for each target pix_fmt.
>
> The goal is to have a generator for testing swscale unscaled conversion
> later
>
> The size of the output dep
Hello,
Patch in attach add a video generator which output all gray value for the
given pix_fmt
Also add fate test for each target pix_fmt.
The goal is to have a generator for testing swscale unscaled conversion
later
The size of the output depend of the pix_fmt
gray8 output a 256x1 frame
gray9 l
On 10/13/18, Michael Niedermayer wrote:
> On Wed, Oct 10, 2018 at 01:22:24PM +0200, Paul B Mahol wrote:
>> This work is partially sponsored by VideoLAN.
>>
>> Signed-off-by: Paul B Mahol
>> ---
>>
>
>> The AGM3 variant decodes with some artifacts.
>
> I looked a bit as you asked on IRC but wasnt
On Wed, Oct 10, 2018 at 01:22:24PM +0200, Paul B Mahol wrote:
> This work is partially sponsored by VideoLAN.
>
> Signed-off-by: Paul B Mahol
> ---
>
> The AGM3 variant decodes with some artifacts.
I looked a bit as you asked on IRC but wasnt able to really fix it in
the time i had available
On 10/12/18, Paul B Mahol wrote:
> Fixes #6821.
>
Will comitt with this above sentence removed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> thats eliminates my concern
>
> Pushed, thanks.
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Le mer. 10 oct. 2018 à 17:13, Marc-Antoine ARNAUD <
arnaud.marcanto...@gmail.com> a écrit :
> I have updated the patch with our discussion.
> It took information only from the codec context.
>
> Marc-Antoine
>
> Hello,
If i correctly understand (which is not sure :-) :
the colorspace for AVCodec
On Sat, Oct 13, 2018 at 4:51 PM Jerome Borsboom
wrote:
>
> > On Sat, Oct 13, 2018 at 12:55 AM mypopy at gmail.com
> > wrote:
> >>
> >> On Fri, Oct 12, 2018 at 10:35 PM Carl Eugen Hoyos
> > wrote:
> >> >
> >> > 2018-10-12 15:41 GMT+02:00, Jun Zhao :
> >> > > case 1:
> >> > > use the hexdump -C S
2018-10-13 8:31 GMT+02:00, Gilles :
> here is a fix for issue: https://trac.ffmpeg.org/ticket/4560
This ticket was fixed years ago and the issue is not
reproducible with current FFmpeg git head.
> Background: since FFmpeg 3.3, it is not possible to force
> the rotation metadata to 0, when video
Hi!
Attached patch fixes a warning, I wonder if the value is actually
supposed to use somewhere...
Please comment, Carl Eugen
From ee679d874aeacc027edcd370464bd7ea7fd7ae7d Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sat, 13 Oct 2018 13:10:29 +0200
Subject: [PATCH] lavf/mxfenc: Remove a
On 10/01/2018 06:09 PM, Mina wrote:
Hi,
This patch was part of GSoC Color Constancy filter. It introduces an
improved color constancy filter(weighted_greyedge) based on the
already pushed greyedge. I'm sending it again after updating it
against latest version of master.
V2 changes:
- fi
> On Sat, Oct 13, 2018 at 12:55 AM mypopy at gmail.com
> wrote:
>>
>> On Fri, Oct 12, 2018 at 10:35 PM Carl Eugen Hoyos
> wrote:
>> >
>> > 2018-10-12 15:41 GMT+02:00, Jun Zhao :
>> > > case 1:
>> > > use the hexdump -C SMM0005.rcv get:
>> > > size skip (size - 4
before this change, scale_vaapi hard coding the scaling mode, add a
new option "mode" to setting the scaling mode, it can be use to change
scaling algorithm for performance/quality trade off.
Signed-off-by: Jun Zhao
---
libavfilter/vf_scale_vaapi.c | 33 ++---
1 fil
37 matches
Mail list logo
