./ffmpeg -f lavfi -i yuvtestsrc=duration=1:size=1200x1440 \
-s 1200x1440 -f null -vframes 100 -pix_fmt $i -nostats \
-cpuflags 0 -v error -
This uses 32-bit mul, so POWER8 only.
The following output formats get about 4.5x speedup:
rgb24
39980 UNITS in yuv2packed1, 32768 runs,
On Thu, 21 Mar 2019 01:20:21 +0100
Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch makes the only argument to the common probe() function const.
>
> Please comment, Carl Eugen
LGTM
- Lauri
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https:/
Carl Eugen Hoyos (12019-03-20):
> +if (par->codec_id != AV_CODEC_ID_AAC && par->codec_id !=
> AV_CODEC_ID_MP4ALS) {
> +av_log(ctx, AV_LOG_ERROR, "Only AAC, LATM and ALS are supported\n");
> +return AVERROR_INVALIDDATA;
> +}
I think EINVAL is more correct in this kind of ca
Marton Balint (12019-03-21):
> Maybe just set the packet corrupt flag and log an error, but return the
> partial buffer?
I think it may be the best solution. But it would be interesting to know
how the tools react to it.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
__
From: "Yan, FengX"
Signed-off-by: Yan, FengX
Signed-off-by: Decai Lin
---
libavcodec/vaapi_hevc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c
index 19aabcd..373ffc4 100644
--- a/libavcodec/vaapi_hevc.c
+++ b/libavcodec/v
On Thu, 21 Mar 2019, at 07:35, Dennis Mungai wrote:
> And apparently calling out specific parties involved in this was translated
> as an ad hominem attack.
Single-outing one person, when you don't know half of the discussion is not a
nice way of interacting within this project.
Especially when y
tor 2019-03-21 klockan 01:20 +0100 skrev Carl Eugen Hoyos:
> Hi!
>
> Attached patch makes the only argument to the common probe() function
> const.
Looks good to me. Passes FATE.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmp
2019-03-21 11:21 GMT+01:00, Tomas Härdin :
> tor 2019-03-21 klockan 01:20 +0100 skrev Carl Eugen Hoyos:
>> Hi!
>>
>> Attached patch makes the only argument to the common probe() function
>> const.
>
> Looks good to me. Passes FATE.
Patch applied.
Thank you both, Carl Eugen
___
On Wed, Mar 20, 2019 at 05:41:31PM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Wed, Mar 20, 2019 at 4:15 PM Gyan wrote:
>
> >
> >
> > On 21-03-2019 01:32 AM, Marton Balint wrote:
> > >
> > >
> > > On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote:
> > >
> > >> On Wed, 20 Mar 2019, at 20:52, Marton
On 20.03.2019 21:36, Jean-Baptiste Kempf wrote:
On Wed, 20 Mar 2019, at 18:03, Maksym Veremeyenko wrote:
On 20.03.2019 17:37, Jean-Baptiste Kempf wrote:
On Wed, 20 Mar 2019, at 16:35, Martin Vignali wrote:
[...]
We don't talk about a contribution remove for technical reason.
But a contributor
Maksym Veremeyenko (12019-03-21):
> i just extrapolated your main statement *The work was removed because the
> library is 100% closed source and userland.* that should be applied to any
> parts of ffmpeg... or not?
Please stop being shifty: what parts of FFmpeg precisely are you
suggesting to rem
On 21.03.2019 13:31, Nicolas George wrote:
Maksym Veremeyenko (12019-03-21):
i just extrapolated your main statement *The work was removed because the
library is 100% closed source and userland.* that should be applied to any
parts of ffmpeg... or not?
Please stop being shifty: what parts of F
Maksym Veremeyenko (12019-03-21):
> i am just trying to get attention on way and reason of how code was removed
> and floating reasons from to remove...
Then please stop your whataboutism.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
__
Hi,
On Thu, Mar 21, 2019 at 7:31 AM Nicolas George wrote:
> Maksym Veremeyenko (12019-03-21):
> > i just extrapolated your main statement *The work was removed because the
> > library is 100% closed source and userland.* that should be applied to
> any
> > parts of ffmpeg... or not?
>
> Please s
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Decai Lin
> Sent: Thursday, March 21, 2019 17:30
> To: ffmpeg-devel@ffmpeg.org
> Cc: Yan, FengX ; Lin, Decai
> Subject: [FFmpeg-devel] [PATCH v1 1/1] vaapi_hevc: Fix double-free issue.
>
> Fr
On 3/21/2019 6:06 AM, Nicolas George wrote:
> Carl Eugen Hoyos (12019-03-20):
>> +if (par->codec_id != AV_CODEC_ID_AAC && par->codec_id !=
>> AV_CODEC_ID_MP4ALS) {
>> +av_log(ctx, AV_LOG_ERROR, "Only AAC, LATM and ALS are supported\n");
>> +return AVERROR_INVALIDDATA;
>> +}
On Thu, 21 Mar 2019, at 12:29, Maksym Veremeyenko wrote:
> >> when do you plan to remove nVidia and BlackmagicDesign parts that is
> >> /closed source and userland/ ?
> >
> > 0) addressing me directly like that is unfair, and unjust;
>
> i just extrapolated your main statement *The work was remov
On Thu, 21 Mar 2019, at 12:48, Ronald S. Bultje wrote:
> So that's nvidia stuff (npp/cuda) and blackmagic. (I'm filtering out the
> various ssl/aac components because they may be GPL-incompatible, but they
> are opensource.)
I explained the case for those 2 cases.
I've asked for clarifications to
On Thu, 21 Mar 2019 at 16:56, Jean-Baptiste Kempf wrote:
> On Thu, 21 Mar 2019, at 12:48, Ronald S. Bultje wrote:
> > So that's nvidia stuff (npp/cuda) and blackmagic. (I'm filtering out the
> > various ssl/aac components because they may be GPL-incompatible, but they
> > are opensource.)
>
> I e
On Thu, 21 Mar 2019 at 12:52, Jean-Baptiste Kempf wrote:
> On Thu, 21 Mar 2019, at 07:35, Dennis Mungai wrote:
> > And apparently calling out specific parties involved in this was
> translated
> > as an ad hominem attack.
>
> Single-outing one person, when you don't know half of the discussion is
Use "a:0,agroup:aud_low,default:Yes,name:Chinese,language:CHN
a:1,agroup:aud_low,language:ENG
a:2,agroup:aud_high,default:Yes,name:Chinese,language:CHN
a:3,agroup:aud_high,language:ENG
v:0,agroup:aud_low v:1,agroup:aud_high"
to create master m3u8 list.
Result:
EXTM3U
EXT-X-VER
This makes sure we don't regress on 70c8c8a818f39bc262565ec29fae2baffb3e1660.
Signed-off-by: Derek Buitenhuis
---
Sample: http://chromashift.org/two_first_slice.mp4 (Trimmed to 500KiB like Carl
requested).
MD5: 58b637d5500c2911d8cfe99fee86cb04
---
tests/fate/hevc.mak | 3 +++
t
On 20.03.2019 22:13, Dennis Mungai wrote:
[...]
The primary agitator here seems to be kierank:
https://trac.ffmpeg.org/ticket/7589?cversion=0&cnum_hist=10#comment:5
What undisclosed history do you have with Newtek (see the reference to
"Andrew") above that isn't disclosed above?
Secondly, you're
On Thu, Mar 21, 2019, 5:54 PM Maksym Veremeyenko wrote:
> On 20.03.2019 22:13, Dennis Mungai wrote:
> [...]
> > The primary agitator here seems to be kierank:
> > https://trac.ffmpeg.org/ticket/7589?cversion=0&cnum_hist=10#comment:5
> >
> > What undisclosed history do you have with Newtek (see th
On Thu, 21 Mar 2019, at 16:14, Ali KIZIL wrote:
> I think the source code itself doesn't violate GPL. It use an external lib,
> just like drivers.
Drivers have a GPL exception.
external libraries do not.
--
Jean-Baptiste Kempf - President
+33 672 704 734
__
On Thu, 21 Mar 2019 at 17:54, Maksym Veremeyenko wrote:
> On 20.03.2019 22:13, Dennis Mungai wrote:
> [...]
> > The primary agitator here seems to be kierank:
> > https://trac.ffmpeg.org/ticket/7589?cversion=0&cnum_hist=10#comment:5
> >
> > What undisclosed history do you have with Newtek (see th
On Thu, 21 Mar 2019 at 18:17, Jean-Baptiste Kempf wrote:
>
>
> On Thu, 21 Mar 2019, at 16:14, Ali KIZIL wrote:
> > I think the source code itself doesn't violate GPL. It use an external
> lib,
> > just like drivers.
>
> Drivers have a GPL exception.
> external libraries do not.
>
> --
> Jean-Bapt
On 3/21/2019 11:48 AM, Derek Buitenhuis wrote:
> This makes sure we don't regress on 70c8c8a818f39bc262565ec29fae2baffb3e1660.
>
> Signed-off-by: Derek Buitenhuis
> ---
> Sample: http://chromashift.org/two_first_slice.mp4 (Trimmed to 500KiB like
> Carl requested).
> MD5: 58b637d5500c2911d8cfe99f
On 21/03/2019 15:26, James Almer wrote:
> Are you sure the faulty packet is the third one? When i debugged this
> the one that reproduced the issue was the 31st. Or is this a cut sample
> starting from the faulty RAP?
Definitely sure it's covered within this command, and file's number of packets.
This makes sure we don't regress on 70c8c8a818f39bc262565ec29fae2baffb3e1660.
Signed-off-by: Derek Buitenhuis
---
Same sample link as v2.
Also of note: I'm only adding the -t arg because FATE doesn't seem to have
a good way to allow ffmpeg to return a non-zero error code, but also have
the test
On 21/03/2019 15:29, Derek Buitenhuis wrote:
> Definitely sure it's covered within this command, and file's number of
> packets.
>
> Easy to verify: Run the fate test with your patch reverted, and it deadlocks.
Scratch that. I was mistaken, it doesn't work with the trimmed file...
Re-testing, a
On 3/21/2019 12:38 PM, Derek Buitenhuis wrote:
> This makes sure we don't regress on 70c8c8a818f39bc262565ec29fae2baffb3e1660.
>
> Signed-off-by: Derek Buitenhuis
> ---
> Same sample link as v2.
Tried to upload it, but i'm still having the same issues as last time.
Someone else will have to.
>
On 21/03/2019 16:19, James Almer wrote:
> FATE_HEVC-$(call DEMDEC, MOV, HEVC)
Changed locally.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi
On transcoding from 1080p .ts files to .mp4 files with my m264 codec,
audio of the output .mp4 files stutters.
We found audio of the stuttering files is vbr.
I did not set aac encoding bitrate. somehow it becomes vbr when I use my
m264 codec on transcoding 1080p files.
It works well for 10
Signed-off-by: James Almer
---
libavcodec/cbs_av1_syntax_template.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/cbs_av1_syntax_template.c
b/libavcodec/cbs_av1_syntax_template.c
index 48f4fab514..93bba1e5ad 100644
--- a/libavcodec/cbs_av1_syntax_templ
Hi
It seems FFmpeg supports reading all kinds of mxf files from Sony and
Panasonics. it's very good to find that FFmpeg can support Sony XAVC
QuadHD files and find the essence data is actually H.264.
Our customers have a lot of high data rate mxf files from Sony and
Panasonics. They need trans
On 3/16/19, Martin Vignali wrote:
> Hello
>
> Patch in attach change bitstream version in prores frame header
> (based on RDD36)
> 0 for 422
> 1 for 444 with ou without alpha
>
> 001 : Fix for prores_aw (update 444 fate test)
> 002 : Fix for prores_ks (no fate update because 444 is not tested for
On 3/21/2019 5:33 PM, Paul B Mahol wrote:
> On 3/16/19, Martin Vignali wrote:
>> Hello
>>
>> Patch in attach change bitstream version in prores frame header
>> (based on RDD36)
>> 0 for 422
>> 1 for 444 with ou without alpha
>>
>> 001 : Fix for prores_aw (update 444 fate test)
>> 002 : Fix for pro
The title is in unicode so I guess we can just encode it to utf8.
I can write a simple C code to do that.
What should I change in the patch though regarding this?
Can you give me more details on what exactly to implement?
___
ffmpeg-devel mailing list
ffm
On Thu, Mar 21, 2019 at 01:19:48PM -0300, James Almer wrote:
> On 3/21/2019 12:38 PM, Derek Buitenhuis wrote:
> > This makes sure we don't regress on
> > 70c8c8a818f39bc262565ec29fae2baffb3e1660.
> >
> > Signed-off-by: Derek Buitenhuis
> > ---
> > Same sample link as v2.
>
> Tried to upload it,
On 3/21/2019 6:30 PM, Michael Niedermayer wrote:
> On Thu, Mar 21, 2019 at 01:19:48PM -0300, James Almer wrote:
>> On 3/21/2019 12:38 PM, Derek Buitenhuis wrote:
>>> This makes sure we don't regress on
>>> 70c8c8a818f39bc262565ec29fae2baffb3e1660.
>>>
>>> Signed-off-by: Derek Buitenhuis
>>> ---
>
tor 2019-03-21 klockan 18:48 + skrev Yufei He:
> Hi
>
> It seems FFmpeg supports reading all kinds of mxf files from Sony and
> Panasonics. it's very good to find that FFmpeg can support Sony XAVC
> QuadHD files and find the essence data is actually H.264.
>
> Our customers have a lot of hi
2019-03-21 16:33 GMT+01:00, Derek Buitenhuis :
> On 21/03/2019 15:29, Derek Buitenhuis wrote:
>> Definitely sure it's covered within this command, and file's number of
>> packets.
>>
>> Easy to verify: Run the fate test with your patch reverted, and it
>> deadlocks.
>
> Scratch that. I was mistaken
2019-03-21 21:41 GMT+01:00, Swaraj Hota :
> The title is in unicode so I guess we can just encode it to utf8.
> I can write a simple C code to do that.
> What should I change in the patch though regarding this?
> Can you give me more details on what exactly to implement?
There is metadata in FFmpe
Add new enum for RTSP/RTP HTTPS tunneling. Tested on Axis and
Bosch cameras.
---
libavformat/rtsp.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/rtsp.h b/libavformat/rtsp.h
index 9a7f366b39..b49278fc20 100644
--- a/libavformat/rtsp.h
+++ b/libavformat/rtsp.h
@@ -42,6 +42,7 @@ en
Add https based tunneling for RTSP/RTP. Tested on Axis and Bosch cameras.
Https is widely used for security consideration.
---
libavformat/rtsp.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index ae8811234a..4661654967 100644
Hi Marton,
hi Nicolas!
On 2019-03-21 10:07 +0100, Nicolas George wrote:
> Marton Balint (12019-03-21):
> > Maybe just set the packet corrupt flag and log an error, but return the
> > partial buffer?
>
> I think it may be the best solution. But it would be interesting to know
> how the tools react
On 3/21/19, James Almer wrote:
> On 3/21/2019 5:33 PM, Paul B Mahol wrote:
>> On 3/16/19, Martin Vignali wrote:
>>> Hello
>>>
>>> Patch in attach change bitstream version in prores frame header
>>> (based on RDD36)
>>> 0 for 422
>>> 1 for 444 with ou without alpha
>>>
>>> 001 : Fix for prores_aw
2019-03-21 23:24 GMT+01:00, Jun Li :
> Add new enum for RTSP/RTP HTTPS tunneling. Tested on Axis and
> Bosch cameras.
> ---
> libavformat/rtsp.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/rtsp.h b/libavformat/rtsp.h
> index 9a7f366b39..b49278fc20 100644
> --- a/libavforma
On Thu, Mar 21, 2019 at 3:59 PM Carl Eugen Hoyos wrote:
> 2019-03-21 23:24 GMT+01:00, Jun Li :
> > Add new enum for RTSP/RTP HTTPS tunneling. Tested on Axis and
> > Bosch cameras.
> > ---
> > libavformat/rtsp.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/libavformat/rtsp.h b/l
2019-03-21 5:10 GMT+01:00, Jing Sun :
> +if (avctx->pix_fmt == AV_PIX_FMT_YUV420P10LE) {
> +av_log(avctx, AV_LOG_DEBUG , "Encoder 10 bits depth input\n");
> +
> +// Encoding the source frames of the compressed 10-bit format
> +// supported by SVT-HEVC requires an extra
Add https based tunneling for RTSP/RTP. Tested on Axis and Bosch cameras.
Https is widely used for security consideration.
---
libavformat/rtsp.c | 8 ++--
libavformat/rtsp.h | 1 +
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index ae8
On Thu, Mar 21, 2019 at 11:09:21AM -0400, Shaofei Wang wrote:
> It enabled MULTIPLE SIMPLE filter graph concurrency, which bring above about
> 4%~20% improvement in some 1:N scenarios by CPU or GPU acceleration
>
> Below are some test cases and comparison as reference.
> (Hardware platform: Intel(
Signed-off-by: Zhengxu Huang
Signed-off-by: Hassene Tmar
Signed-off-by: Jun Zhao
Signed-off-by: Jing Sun
---
configure| 4 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/libsvt_hevc.c | 501 +++
4 f
Friday, March 22, 2019 7:52 AM, Carl Eugen:
> +if (avctx->pix_fmt == AV_PIX_FMT_YUV420P10LE) {
> +av_log(avctx, AV_LOG_DEBUG , "Encoder 10 bits depth
> + input\n");
> +
> +// Encoding the source frames of the compressed 10-bit format
> +// supported by SVT-HEVC require
> -Original Message-
> From: Fu, Linjie
> Sent: 2019年3月21日 20:20
> To: FFmpeg development discussions and patches
>
> Cc: Yan, FengX ; Lin, Decai
> Subject: RE: [FFmpeg-devel] [PATCH v1 1/1] vaapi_hevc: Fix double-free
> issue.
>
> > -Original Message-
> > From: ffmpeg-devel [m
56 matches
Mail list logo
