Michael Niedermayer:
> On Sun, Mar 10, 2019 at 11:03:00PM +, Andreas Rheinhardt wrote:
>> Michael Niedermayer:
>>> On Fri, Mar 08, 2019 at 10:25:59AM +0100, Andreas Rheinhardt wrote:
When the new incremental parser was introduced, the old parser was
kept, because the new parser was
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark
Thompson
Sent: Wednesday, March 6, 2019 6:19 AM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v6 2/2] doc: Add libsvt_hevc encoder docs
On 05/03/2019 07:43, Jing SUN wrote:
Add docs for libsvt_hevc encoder in encoders.texi and general.texi
Signed-off-by: Jun Zhao
Signed-off-by: Huang, Zhengxu
Signed-off-by: hassene
Signed-off-by: Jing SUN
---
doc/encoders.texi | 145 ++
doc/general.texi | 8 +++
2 files
On Sun, 10 Mar 2019 at 04:43 Michael Niedermayer
wrote:
> Fixes: Out of array access
> Fixes:
> 13500/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-5769760178962432
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>
> -Original Message-
> From: Rogozhkin, Dmitry V
> Sent: Saturday, March 9, 2019 8:48 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Li, Zhong
> Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace current
> parser with MFXVideoDECODE_DecodeHeader()
>
> On Fri, 2019-03-08 at 15:40
2019-03-11 11:28 GMT+01:00, Jing SUN :
> +static void free_buffer(SvtContext *svt_enc)
> +{
> +uint8_t *in_data = (EB_H265_ENC_INPUT *)svt_enc->in_buf.pBuffer;
> +
> +av_freep(_data);
> +}
Is the cast necessary?
Does the variable make the code more readable?
Does the function make the
On 11/03/2019 06:37, Ruta Gadkari wrote:
Hi
Please find the attached patch, it rectifies the definition of cuda device
pointer for PPC64 architecture.
PPC64 support is present from Video Codec SDK 9.
Thanks
Ruta
Applied and released a new version of ffnvcodec 9.
smime.p7s
Description:
Since db772308941a2a338c7809f90d347219a6a93074 parsing of
mpeg4-extradata lead to a "Failed to parse extradata" warning, because
ff_mpeg4_decode_picture_header returns AVERROR_INVALIDDATA in case that
no VOP was found. This patch adds a parameter to signify whether a
header (where the absence of a
On 11-03-2019 12:32 PM, Jing SUN wrote:
Add docs for libsvt_hevc encoder in encoders.texi and general.texi
Signed-off-by: Jun Zhao
Signed-off-by: Huang, Zhengxu
Signed-off-by: hassene
Signed-off-by: Jing SUN
---
doc/encoders.texi | 145
From: Jing Sun
base on patch by Huang, Zhengxu from https://github.com/intel/SVT-HEVC
V4: - Fix the build error with new API in PR#52
- Fix the encoding hang issue by API change in PR#52
- Fix the last frame dropping issue
- Fix the invalid parameter causing segmentation fault issue
2019-03-11 6:36 GMT+01:00, Ruta Gadkari :
> Please find attached the patch, it enables ffnvcodec and
> nvenc, nvdec, cuvid for PPC64 architecture.
Is it supported on both little and big endian?
> This email message is for the sole use of the intended
> recipient(s) and may contain confidential
On Mon, Mar 11, 2019 at 01:59:47 +0100, Carl Eugen Hoyos wrote:
> The library needs non-free in configure and please
> use dynamic linking, not loading at run-time.
There is also no indication whatsoever where to get mvM264Ffmpeg.dll
and libmvM264Ffmpeg.so from. No-one can even attempt to run (or
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Carl
Eugen Hoyos
Sent: Monday, March 11, 2019 5:01 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH v7 1/2] lavc/svt_hevc: add libsvt hevc
encoder wrapper.
On Mon, Mar 11, 2019 at 04:17:21 +, Sun, Jing A wrote:
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Carl
> Eugen Hoyos
> > The condition is unnecessary.
> [SUN, Jing] If av_mallocz fails, free_buffer will be called with in_data
> being NULL. Checking it avoids
2019-03-07 20:55 GMT+01:00, Jun Li :
> From: jun
>
> Calculate bitrate based on fragment size, only applied when
> bitrate is not set, for example rtsp source.
Could this also be done on a higher level?
Or is smoothstreaming the only thing that needs this information?
Carl Eugen
fre 2019-03-08 klockan 21:39 + skrev Matthew Fearnley:
> > On Fri, 8 Mar 2019 at 18:07, Carl Eugen Hoyos wrote:
> > 2019-03-08 15:04 GMT+01:00, Tomas Härdin :
> > >
> > > Maybe we could coordinate 1/2/4/24-bit support with the
> >
> > I believe FFmpeg cannot support 1/2/4 bit for encoding.
2019-03-11 5:17 GMT+01:00, Sun, Jing A :
> 2019-03-08 11:36 GMT+01:00, Jing SUN :
>
>> +static void free_buffer(SvtContext *svt_enc) {
>> +EB_H265_ENC_INPUT *in_data =
>> (EB_H265_ENC_INPUT *)svt_enc->in_buf.pBuffer;
>
> Is the cast necessary?
> Or actually: Can't in_data be whatever doesn't
2019-03-11 9:49 GMT+01:00, Moritz Barsnick :
> On Mon, Mar 11, 2019 at 04:17:21 +, Sun, Jing A wrote:
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
>> Carl Eugen Hoyos
>> > The condition is unnecessary.
>> [SUN, Jing] If av_mallocz fails, free_buffer will be
From: Jing Sun
base on patch by Huang, Zhengxu from https://github.com/intel/SVT-HEVC
V4: - Fix the build error with new API in PR#52
- Fix the encoding hang issue by API change in PR#52
- Fix the last frame dropping issue
- Fix the invalid parameter causing segmentation fault issue
2019-03-11 11:57 GMT+01:00, Ronald S. Bultje :
> - How do we set up a fate station with m264 support?
We do not test any external libraries with fate.
[...]
> - How do we test that it still works after we make innocent
> changes to some API?
Same as so far: We remove the feature that isn't
sön 2019-03-10 klockan 19:03 -0700 skrev mindm...@gmail.com:
> > From: Mark Reid
>
> This patch restores the ability to add user comments for the opatom_mxf muxer.
> The ability seems to have been disabled in d9726893f31.
Seems the intent was to only disable them for D-10, so this is probably
On 11/03/2019 09:40, Carl Eugen Hoyos wrote:
2019-03-11 6:36 GMT+01:00, Ruta Gadkari :
Please find attached the patch, it enables ffnvcodec and
nvenc, nvdec, cuvid for PPC64 architecture.
Is it supported on both little and big endian?
Good question.
This email message is for the sole use
2019-03-11 11:16 GMT+01:00, Timo Rothenpieler :
> On 11/03/2019 09:40, Carl Eugen Hoyos wrote:
>> 2019-03-11 6:36 GMT+01:00, Ruta Gadkari :
>>
>>> Please find attached the patch, it enables ffnvcodec and
>>> nvenc, nvdec, cuvid for PPC64 architecture.
>>
>> Is it supported on both little and big
2019-03-11 11:37 GMT+01:00, Tomas Härdin :
> fre 2019-03-08 klockan 21:39 + skrev Matthew Fearnley:
>> > On Fri, 8 Mar 2019 at 18:07, Carl Eugen Hoyos
>> > wrote:
>> > 2019-03-08 15:04 GMT+01:00, Tomas Härdin :
>> > >
>> > > Maybe we could coordinate 1/2/4/24-bit support with the
>> >
>> > I
Hi,
On Mon, Mar 11, 2019 at 4:53 AM Moritz Barsnick wrote:
> On Mon, Mar 11, 2019 at 01:59:47 +0100, Carl Eugen Hoyos wrote:
> > The library needs non-free in configure and please
> > use dynamic linking, not loading at run-time.
>
> There is also no indication whatsoever where to get
mån 2019-03-11 klockan 11:43 +0100 skrev Carl Eugen Hoyos:
> > 2019-03-11 11:37 GMT+01:00, Tomas Härdin :
> > fre 2019-03-08 klockan 21:39 + skrev Matthew Fearnley:
> > > > On Fri, 8 Mar 2019 at 18:07, Carl Eugen Hoyos
> > > > wrote:
> > > > > > > > 2019-03-08 15:04 GMT+01:00, Tomas Härdin :
Yufei He (12019-03-11):
> Matrox M264 is similar to other hardware codecs.
>
> I saw amf_load_library and nvenc_load_library in ffmpeg.
Past practices do not constitute precedents.
> We got a lot customers using ffmpeg and they want to use Matrox M264 to do
> transcoding.
If you make the
The earlier version didn't really check that the 'p' of a "p\0" is
actually part of a user_data section, instead it treated the first
"p\0" after the start of a user_data section as end of a user_data
section if it is close enough to the beginning of the user_data section;
it actually needn't be
2019-03-11 12:07 GMT+01:00, Tomas Härdin :
> mån 2019-03-11 klockan 11:43 +0100 skrev Carl Eugen Hoyos:
>> > 2019-03-11 11:37 GMT+01:00, Tomas Härdin :
>> > fre 2019-03-08 klockan 21:39 + skrev Matthew Fearnley:
>> > > > On Fri, 8 Mar 2019 at 18:07, Carl Eugen Hoyos
>> > > > wrote:
>> > > > >
Hi Carl
Matrox M264 is similar to other hardware codecs.
I saw amf_load_library and nvenc_load_library in ffmpeg.
Matrox M264 is the same.
We got a lot customers using ffmpeg and they want to use Matrox M264 to do
transcoding.
Thanks a lot.
Yufei.
static int
On Mon, Mar 11, 2019 at 12:50 AM Sun, Jing A wrote:
> I just searched my inbox again but failed to find that email of question
> you mentioned.
>
Yeah I often see my mail bounced with this message:
Address not foundYour message wasn't delivered to *jun.z...@intel.com*
because the address
Hi
It seems ffmpeg can only generate AVCC box if I set extradata in my encoder's
init function, it does not take the extradata if I make it in receive_packet
function.
But I don't have sps and pps when the encoder's init function is called. I only
can get it when I get first encoded frame.
> From: Nicolas George
>
> Yufei He (12019-03-11):
> > Matrox M264 is similar to other hardware codecs.
> >
> > I saw amf_load_library and nvenc_load_library in ffmpeg.
>
> Past practices do not constitute precedents.
>
> > We got a lot customers using ffmpeg and they want to use Matrox M264 to do
On Mon, 11 Mar 2019, at 17:46, Soft Works wrote:
> I still wonder why recent discussions are often referring to GPL even
> though ffmpeg is released under LGPL.
Because LGPL is a derivative of the GPL, unfortunately.
And there are a lot more jurisprudence on the GPL, than on the LGPL.
And LGPL
On Mon, 11 Mar 2019, at 17:21, Soft Works wrote:
> While I don’t care much about Matrox, I’m a bit surprised about the
> recent sounds here. Should we expect ffmpeg to drop most hw
> accelerations, then?
Absolutely not.
> IANAL, but aren’t drivers clearly considered to be system components?
> From: Jean-Baptiste Kempf
>
> On Mon, 11 Mar 2019, at 17:21, Soft Works wrote:
> > While I don’t care much about Matrox, I’m a bit surprised about the
> > recent sounds here. Should we expect ffmpeg to drop most hw
> > accelerations, then?
>
> Absolutely not.
I very glad to hear that :-)
> >
Yufei He (12019-03-11):
> It seems ffmpeg can only generate AVCC box if I set extradata in my
> encoder's init function, it does not take the extradata if I make it
> in receive_packet function.
>
> But I don't have sps and pps when the encoder's init function is
> called. I only can get it when
Thanks Carl for review.
Smooth is not the only one need bitrate for manifest, Dash also need this
value for "Bandwidth" field:
https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/dashenc.c#L730
Although there is some difference, both the calculation are based on
fragment size, which is the
2019-03-11 18:58 GMT+01:00, Jun Li :
> Smooth is not the only one need bitrate for manifest, Dash also need this
> value for "Bandwidth" field:
> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/dashenc.c#L730
> Although there is some difference, both the calculation are based on
>
On Sun, Mar 10, 2019 at 11:03:00PM +, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Fri, Mar 08, 2019 at 10:25:59AM +0100, Andreas Rheinhardt wrote:
> >> When the new incremental parser was introduced, the old parser was
> >> kept, because the new parser was unable to handle the way
Hi,
On Mon, Mar 11, 2019 at 12:21 PM Soft Works wrote:
> > From: Nicolas George
> >
> > Yufei He (12019-03-11):
> > > Matrox M264 is similar to other hardware codecs.
> > >
> > > I saw amf_load_library and nvenc_load_library in ffmpeg.
> >
> > Past practices do not constitute precedents.
> >
>
On Mon, Mar 11, 2019 at 10:39:20AM +0400, Kieran Kunhya wrote:
> On Sun, 10 Mar 2019 at 04:43 Michael Niedermayer
> wrote:
>
> > Fixes: Out of array access
> > Fixes:
> > 13500/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-5769760178962432
> >
> > Found-by: continuous fuzzing
On Mon, Mar 11, 2019 at 01:28:18PM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Mar 11, 2019 at 12:21 PM Soft Works wrote:
>
> > > From: Nicolas George
> > >
> > > Yufei He (12019-03-11):
> > > > Matrox M264 is similar to other hardware codecs.
> > > >
> > > > I saw amf_load_library and
On Mon, Mar 11, 2019 at 2:55 AM Tomas Härdin wrote:
> sön 2019-03-10 klockan 19:03 -0700 skrev mindm...@gmail.com:
> > > From: Mark Reid
> >
> > This patch restores the ability to add user comments for the opatom_mxf
> muxer.
> > The ability seems to have been disabled in d9726893f31.
>
> Seems
From: Mark Reid
---
tests/fate/mxf.mak | 15 ++-
tests/ref/fate/mxf-d10-user-comments| 1 +
tests/ref/fate/mxf-opatom-user-comments | 1 +
tests/ref/fate/mxf-user-comments| 1 +
4 files changed, 17 insertions(+), 1 deletion(-)
create mode 100644
From: Mark Reid
---
doc/muxers.texi | 4 ++--
libavformat/mxfenc.c | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 372fab2f92..aac7d94edf 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1629,7 +1629,7 @@ ffmpeg -i
On Mon, Mar 11, 2019 at 23:23:15 +0100, Ulf Zibis wrote:
> >> I believe, it's faster because of:
> > Please post some numbers if your patch is supposed to
> > speed up the filter.
>
> Hm, I have no clue how to do this. I thing the listed arguments speak
> for themselves. Is there a kind of
On Mon, 2019-03-11 at 17:23 +0800, Li, Zhong wrote:
> > -Original Message-
> > From: Rogozhkin, Dmitry V
> > Sent: Saturday, March 9, 2019 8:48 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Li, Zhong
> > Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace
> > current
> > parser
Hi!
Attached patch is supposed to fix HandBrake issue 1964, FFmpeg
currently fails to identify WebVTT in Matroska (only webm is supported
as container). I don't have the original sample to test though.
Please comment, Carl Eugen
From d4cdbc94e4adf8ee4b1f576b60c0e743f9f8928f Mon Sep 17 00:00:00
2019-03-12 0:25 GMT+01:00, Moritz Barsnick :
> On Mon, Mar 11, 2019 at 23:23:15 +0100, Ulf Zibis wrote:
>> >> I believe, it's faster because of:
>> > Please post some numbers if your patch is supposed to
>> > speed up the filter.
>>
>> Hm, I have no clue how to do this. I thing the listed
On Mon, 2019-03-11 at 17:23 +0800, Li, Zhong wrote:
> > -Original Message-
> > From: Rogozhkin, Dmitry V
> > Sent: Saturday, March 9, 2019 8:48 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Li, Zhong
> > Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace
> > current
> > parser
pix_fmts[1] is misleading. And I think it can be quite easily
avoided.
If I understand the code correctly, qsv_decode_preinit is the place
(and the only place) where you need an array of pix_fmts. You actually
request ffmpeg to select one of the formats and program it into avctx.
Is that right?
mån 2019-03-11 klockan 13:22 -0700 skrev mindm...@gmail.com:
> From: Mark Reid
>
> ---
> tests/fate/mxf.mak | 15 ++-
> tests/ref/fate/mxf-d10-user-comments| 1 +
> tests/ref/fate/mxf-opatom-user-comments | 1 +
> tests/ref/fate/mxf-user-comments|
Hi,
I have made some refactoring to vf_fillborders.c.
My motivation came from using this filter as a template for a new
filter. Refactoring the code was a good exercise to understand FFmpeg's
data models.
I think, the code is now much better readable and I believe, it's faster
because of:
-
Here is attached the "commit" patch, if you like this more.
-Ulf
Am 11.03.19 um 22:59 schrieb Ulf Zibis:
> Hi,
>
> I have made some refactoring to vf_fillborders.c.
>
> My motivation came from using this filter as a template for a new
> filter. Refactoring the code was a good exercise to
Am 11.03.19 um 23:08 schrieb Carl Eugen Hoyos:
> You are not supposed to mix cosmetic changes
> like removing braces or moving variable declarations
> with actual code changes.
Hm difficult, because the code changes are dependent from different
variables.
But I'll give it a try to make some
On Mon, Mar 11, 2019 at 12:36:08PM +0100, Andreas Rheinhardt wrote:
> The earlier version didn't really check that the 'p' of a "p\0" is
> actually part of a user_data section, instead it treated the first
> "p\0" after the start of a user_data section as end of a user_data
> section if it is
Michael Niedermayer:
> On Mon, Mar 11, 2019 at 12:36:08PM +0100, Andreas Rheinhardt wrote:
>> The earlier version didn't really check that the 'p' of a "p\0" is
>> actually part of a user_data section, instead it treated the first
>> "p\0" after the start of a user_data section as end of a
mån 2019-03-11 klockan 13:22 -0700 skrev mindm...@gmail.com:
> From: Mark Reid
>
> ---
> doc/muxers.texi | 4 ++--
> libavformat/mxfenc.c | 2 ++
> 2 files changed, 4 insertions(+), 2 deletions(-)
Looks OK
/Tomas
___
ffmpeg-devel mailing list
2019-03-11 22:59 GMT+01:00, Ulf Zibis :
> I have made some refactoring to vf_fillborders.c.
You are not supposed to mix cosmetic changes
like removing braces or moving variable declarations
with actual code changes.
> My motivation came from using this filter as a template
> for a new filter.
On Mon, Mar 11, 2019 at 11:32:05AM +0100, Andreas Rheinhardt wrote:
> Since db772308941a2a338c7809f90d347219a6a93074 parsing of
> mpeg4-extradata lead to a "Failed to parse extradata" warning, because
> ff_mpeg4_decode_picture_header returns AVERROR_INVALIDDATA in case that
> no VOP was found.
On Mon, 11 Mar 2019 23:07:37 +0100
Ulf Zibis wrote:
> From 74dda304bf7a0a31873518187438815d08533934 Mon Sep 17 00:00:00 2001
> From: Ulf Zibis
> Date: 11.03.2019, 23:04:15
>
> Beautified + accelerated
Commit message title prefix for filter patches are usually in the form
of:
62 matches
Mail list logo
