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
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
> 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
_
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
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
> 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
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 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: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
>
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
> 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 :
>
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:
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
> -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
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
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
> -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
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
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
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"?
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 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/
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
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
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!
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
.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
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
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
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-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
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"
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: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
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 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 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: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]));
>> >
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
> 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
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
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
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
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
./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
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);
> > +
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 +---
> 在 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
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日，下午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):
> 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 /
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
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
53 matches
Mail list logo
