Please ignore those commented lines which will be removed in the v2 patch, they
were referred from previous reap_filters() code.
"if (HAVE_THREADS && !abr_pipeline)" looks better.
Could you add more about "not work with thread emulation"? Thx.
-Original Message-
From: ffmpeg-devel [mai
Also caused by some old mingw64 toolchain? Will try to avoid the error in v2
patch. Thanks
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
Michael Niedermayer
Sent: Thursday, January 10, 2019 7:36 AM
To: FFmpeg development discussions and patch
Liu Steven (12019-01-10):
> How should i understand the mean “the fragment part should not have
> arrived there in the first place.” ?
>
> When i use wget to get http://ffmpeg.org/helloworld/test#hello=24
> wget -dS http://ffmpeg.org/helloworld/test#hello=24
> the request is GET /
> 在 2019年1月10日，下午4:54，Nicolas George 写道：
>
> Liu Steven (12019-01-10):
>>How should i understand the mean “the fragment part should not have
>> arrived there in the first place.” ?
>>
>>When i use wget to get http://ffmpeg.org/helloworld/test#hello=24
>>wget -dS http://ffmpeg.org/
Liu Steven (12019-01-10):
> Ok, I get that mean, let me think how to fix that.
Do you know why the fragment was there in the first place and what its
role was?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel ma
> 在 2019年1月10日，下午5:09，Nicolas George 写道：
>
> Liu Steven (12019-01-10):
>> Ok, I get that mean, let me think how to fix that.
>
> Do you know why the fragment was there in the first place and what its
> role was?
I guess that is used for them web browser or player, i will ask that infomation
f
On Wed, 9 Jan 2019 21:55:30 +0100
Carl Eugen Hoyos wrote:
> 2019-01-08 10:08 GMT+01:00, Lauri Kasanen :
> > The existing code was in no released kernel that I can see. The corrected
> > code
> > was added in 3.9.
> >
> > Signed-off-by: Lauri Kasanen
> > ---
> > libavutil/ppc/cpu.c | 10 +---
On Wed, 9 Jan 2019 22:26:25 +0100
Carl Eugen Hoyos wrote:
> > +#ifdef __GNUC__
> > +// GCC does not support vmuluwm yet. Bug open.
> > +__asm__("vmuluwm %0, %1, %2" : "=v"(vtmp) : "v"(vin32l),
> > "v"(vfilter[j]));
> > +vleft = vec_add(vleft, vtmp);
> > +
./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt
yuv420p16be \
-s 1920x1728 -f null -vframes 100 -v error -nostats -
9-14 bit funcs get about 6x speedup, 16-bit gets about 15x.
Fate passes, each format tested with an image to video conversion.
Only POWER8 includes 32-bit vec
mån 2019-01-07 klockan 15:38 +0200 skrev Lauri Kasanen:
> On Mon, 7 Jan 2019 13:44:56 +0100
> Michael Niedermayer wrote:
>
> > > The modern approaches, DCT, FFT, wavelets and such transforms,
> > > are all
> > > likely too slow to decode.
> >
> > you said it can do mpeg1 and xvid, these are DCT
This program only takes 2 arguments
Remove comment that was never right
---
tests/api/api-h264-slice-test.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/tests/api/api-h264-slice-test.c
b/tests/api/api-h264-slice-test.c
index b893737bca..dee93b8349 100644
--- a/tests/ap
On 1/10/19 12:12 PM, Rafaël Carré wrote:
> -fprintf(stderr, "Usage: %sfile>\n", argv[0]);
I can't use git send-email with google so I had to copy paste the patch
into thunderbird.
The 2 lines above probably needs concatenating to apply the patch
> +if (argc < 3) {
> +fpr
El mar., 8 ene. 2019 a las 18:49, Derek Buitenhuis (<
derek.buitenh...@gmail.com>) escribió:
> On 08/01/2019 16:35, Andoni Morales wrote:
> > In a multilib toolchain dlltool has to be configured with the correct
> > architecture options.
> > This option allows configuring dlltool this way:
> > --d
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Linjie Fu
> Sent: Thursday, November 29, 2018 2:14 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie
> Subject: [FFmpeg-devel] [PATCH,v5] lavc/qsvenc: add VDENC support for
> H264
>
> Add VDENC(lowpower mode) support for
Rafaël Carré wrote:
> I can't use git send-email with google so I had to copy paste the patch
> into thunderbird.
You can use "git format-patch" and attach the created patch file in Thunderbird.
$ git format-patch HEAD^
or
$ git format-patch
556d7d9e3b09157555310466a47e25a9ebfd8f4e^..556d7d9e3b
2019-01-10 10:48 GMT+01:00, Lauri Kasanen :
> On Wed, 9 Jan 2019 22:26:25 +0100
> Carl Eugen Hoyos wrote:
>
>> > +#ifdef __GNUC__
>> > +// GCC does not support vmuluwm yet. Bug open.
>> > +__asm__("vmuluwm %0, %1, %2" : "=v"(vtmp) : "v"(vin32l),
>> > "v"(vfilter[j]));
>> >
2019-01-10 10:45 GMT+01:00, Lauri Kasanen :
> On Wed, 9 Jan 2019 21:55:30 +0100
> Carl Eugen Hoyos wrote:
>
>> 2019-01-08 10:08 GMT+01:00, Lauri Kasanen :
>> > The existing code was in no released kernel that I can see. The
>> > corrected
>> > code
>> > was added in 3.9.
>> >
>> > Signed-off-by: L
2019-01-10 10:14 GMT+01:00, Liu Steven :
>
>
>> 在 2019年1月10日，下午5:09，Nicolas George 写道：
>>
>> Liu Steven (12019-01-10):
>>> Ok, I get that mean, let me think how to fix that.
>>
>> Do you know why the fragment was there in the first place and what its
>> role was?
>
> I guess that is used for them
2019-01-10 14:51 GMT+01:00, Linjie Fu :
> +#if QSV_HAVE_VDENC
> +{ "low_power", "enable low power mode(experimental: many limitations by
> mfx version, BRC modes, etc.)", OFFSET(qsv.low_power), AV_OPT_TYPE_BOOL, {
> .i64 = 0 }, 0, 1, VE},
> +#endif
This seems wrong to me: The visibility of a
2019-01-10 9:18 GMT+01:00, Wang, Shaofei :
> Please ignore those commented lines which will be removed in
> the v2 patch, they were referred from previous reap_filters() code.
>
> "if (HAVE_THREADS && !abr_pipeline)" looks better.
> Could you add more about "not work with thread emulation"?
My q
On Thu, 10 Jan 2019 18:09:21 +0100
Carl Eugen Hoyos wrote:
> >> > -goto out;
> >>
> >> This seems like an unrelated change.
> >
> > It's necessary. HWCAP appears before HWCAP2 in the array, so if the
> > code jumps out in HWCAP, it never gets to checking the CAP2 bits like
> > pow
2019-01-10 9:54 GMT+01:00, Guo, Yejun :
> +roi = (AVRegionOfInterest*)((char*)roi +
> roi->self_size);
Isn't this roi++?
If yes, please change this.
I also wonder if the wording (elsewhere) of "returns EINVAL
if size is zero" is correct: Shouldn't it be "size must be >0"
2019-01-10 18:21 GMT+01:00, Lauri Kasanen :
> On Thu, 10 Jan 2019 18:09:21 +0100
> Carl Eugen Hoyos wrote:
>
>> >> > -goto out;
>> >>
>> >> This seems like an unrelated change.
>> >
>> > It's necessary. HWCAP appears before HWCAP2 in the array, so if the
>> > code jumps out in HWCA
On Wed, Jan 9, 2019 at 6:32 PM Rodger Combs wrote:
> Instead of assuming id 0 is used, use the same logic as used for PPS,
> where all available entries in the list are emitted.
>
Patch LGTM. Apart from the SEGV fix, this probably helps VideoToolbox
decode certain types of samples with multiple
2019-01-07 18:37 GMT+01:00, Ronald S. Bultje :
> Hi,
>
> On Mon, Jan 7, 2019 at 12:22 PM Lauri Kasanen wrote:
>
>> On Mon, 7 Jan 2019 12:02:58 -0500
>> "Ronald S. Bultje" wrote:
>>
>> > Have you considered vp8? It may sound weird but this is basically what
>> vp8
>> > was great at: being really s
Hello,
just a kind reminder. - What is the next step, is there anything more I
should improve, check, modify,...?
For me, the filter works as intended.
@Nicolas: Can you answer my remaining three questions below, please?
Regards,
Uwe
Am 02.01.19 um 23:34 schrieb Uwe Freese:
Hello,
Here's
.rodata directive from GAS assembly produces .rodata as read/write for COFF
object file by default (object file format for Windows), but read only for
ELF. This change marks it as read only explicitly for COFF.
The issue happens when building Chromium for Windows ARM64, with FFmpeg.
---
libavuti
Hi!
Attached untested patch tries to limit the effects of setting a high
bitrate for qsv.
Works around ticket #7663.
Please comment, Carl Eugen
From 9c51b260a0c65fe7fbf18ac5235f3336be66502c Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 10 Jan 2019 21:50:04 +0100
Subject: [PATCH] lav
Hi!
Attached patch fixes ticket #7600.
Please comment, Carl Eugen
From 90492e635c461f328a18cb6a55a71206f9cd5aeb Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 10 Jan 2019 21:56:28 +0100
Subject: [PATCH] lavc/libaomenc: Support lossless encoding.
Tested-by: Ewout ter Hoeven
---
liba
Hi!
I don't know how urgent this is and how easily this can be triggered
with AVCPBProperties but we had issues with bitrates > INT32MAX in the
past, so looking at this code before realizing the qsv bitrate issue
is Intel-related I thought this patch cannot hurt.
Please comment, Carl Eugen
From 6
We should use mfxInfoMFX::BRCParamMultiplier to handle high bitrate. See my
new comment in #7663
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Carl
> Eugen Hoyos
> Sent: Thursday, January 10, 2019 12:53 PM
> To: FFmpeg development discus
2019-01-10 22:32 GMT+01:00, Eoff, Ullysses A :
> We should use mfxInfoMFX::BRCParamMultiplier to handle high bitrate.
Sadly, the rules here forbid an answer.
;-)
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/
On Thu, 10 Jan 2019 at 20:59, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes ticket #7600.
>
> Please comment, Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
You can alr
2019-01-10 23:35 GMT+01:00, Rostislav Pehlivanov :
> On Thu, 10 Jan 2019 at 20:59, Carl Eugen Hoyos wrote:
>
>> Hi!
>>
>> Attached patch fixes ticket #7600.
> You can already do that via -b:v 0 -crf 0, same as with libvpx, can't you?
Then why does libvpx have an undeprecated option "lossless"?
Should fix failures on x86_32.
Signed-off-by: James Almer
---
tests/checkasm/af_afir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/checkasm/af_afir.c b/tests/checkasm/af_afir.c
index 54e2f68d6c..e3fb76e8e0 100644
--- a/tests/checkasm/af_afir.c
+++ b/tests/checkasm/a
On 1/10/2019 6:27 PM, Carl Eugen Hoyos wrote:
> Hi!
>
> I don't know how urgent this is and how easily this can be triggered
> with AVCPBProperties but we had issues with bitrates > INT32MAX in the
> past, so looking at this code before realizing the qsv bitrate issue
> is Intel-related I thought
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Friday, January 11, 2019 1:19 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH V8 2/2] avcodec/libx264: add
2019-01-11 1:37 GMT+01:00, Guo, Yejun :
>> 2019-01-10 9:54 GMT+01:00, Guo, Yejun :
>>
>> > +roi = (AVRegionOfInterest*)((char*)roi +
>> > roi->self_size);
>>
>> Isn't this roi++?
>> If yes, please change this.
>
> no, it's not roi++, the reason is that struct AVRegionOfInte
Fixes: memleak
Fixes:
12244/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_NUV_fuzzer-5099447273390080
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
---
libavcodec/nuv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/nuv.c
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Friday, January 11, 2019 8:54 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH V8 2/2] avcodec/libx264: add
Hi!
Attached patch fixes ticket #6797, please comment.
Carl Eugen
From f0d1c43a791f44eee5ae3174baf367a73e59283e Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Fri, 11 Jan 2019 02:53:06 +0100
Subject: [PATCH] lavc/psd: Support CMYK images.
Fixes ticket #6797.
---
libavcodec/psd.c | 43
2019-01-11 2:55 GMT+01:00, Carl Eugen Hoyos :
> Hi!
>
> Attached patch fixes ticket #6797, please comment.
New patch with 16bit support attached.
Please comment, Carl Eugen
From 5f879539ee7fecd57bd3de9f7c6363d9b7779b5b Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Fri, 11 Jan 2019 03:20:
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Friday, January 11, 2019 1:06 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/qsvenc: add VDENC
> support for H264
>
> 2019-01-10 14:51 GMT+01:00, Linjie Fu :
>
2018-12-22 21:32 GMT+01:00, Paul B Mahol :
> On 12/22/18, Steinar H. Gunderson wrote:
>> On Sat, Dec 22, 2018 at 09:18:11PM +0100, Paul B Mahol wrote:
>>> Unacceptable, I'm not adding another yuv420p variant.
>>
>> Well, if returning YCC as YCC is unacceptable, and converting YCC to RGB
>> is
>> u
2019-01-11 3:28 GMT+01:00, Li, Zhong :
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Carl Eugen Hoyos
>> Sent: Friday, January 11, 2019 1:06 AM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/qsvenc: add VDENC
>> support for H264
>
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Li, Zhong
> Sent: Friday, January 11, 2019 10:29 AM
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/qsvenc: add VDENC
> support for H264
>
> > From: ffmpeg-devel [mai
2019-01-11 3:39 GMT+01:00, Li, Zhong :
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Li, Zhong
>> Sent: Friday, January 11, 2019 10:29 AM
>> To: FFmpeg development discussions and patches
>>
>> Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/qsvenc: add VDENC
>> s
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Friday, January 11, 2019 10:39 AM
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/qsvenc: add VDENC
> support for H264
>
> 2019-01-11 3:28 GM
fix ticket: 7369
check the duration is less than the fragment duration,
retry when the condition is true.
don't control the download speed when reading header
Signed-off-by: Steven Liu
---
libavformat/dashdec.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/li
2019-01-11 4:42 GMT+01:00, Li, Zhong :
>> >> 2019-01-10 14:51 GMT+01:00, Linjie Fu :
>> >>
>> >> > +#if QSV_HAVE_VDENC
>> >> > +{ "low_power", "enable low power mode(experimental: many
>> >> > +limitations by
>> >> > mfx version, BRC modes, etc.)", OFFSET(qsv.low_power),
>> >> > AV_OPT_TYPE_BO
> Which libx264 option is / can be hidden?
This one:
#if X264_BUILD >= 144
{ "autovariance-biased", "Auto-variance AQ with bias to dark scenes", 0,
AV_OPT_TYPE_CONST, {.i64 = X264_AQ_AUTOVARIANCE_BIASED}, INT_MIN, INT_MAX, VE,
"aq_mode" },
#endif
_
On Fri, Jan 11, 2019 at 03:23:49AM +0100, Carl Eugen Hoyos wrote:
> 2019-01-11 2:55 GMT+01:00, Carl Eugen Hoyos :
> > Hi!
> >
> > Attached patch fixes ticket #6797, please comment.
>
> New patch with 16bit support attached.
>
> Please comment, Carl Eugen
> From 5f879539ee7fecd57bd3de9f7c6363d9b7
Given that leading_zero_8bits can be included many times at the beginning
of a NAL unit, blindly taking the startcode as 3 bytes will leave 0x00
in last frame.
When startcode is found, go back to find all leading_zero_8bits in
current buffer and pc->buffer to cut correctly.
Update the FATE checks
53 matches
Mail list logo
