On 02-04-2019 05:31 PM, Gyan wrote:
On 01-04-2019 02:54 PM, Tomas Härdin wrote:
sön 2019-03-31 klockan 00:11 +0530 skrev Gyan:
Regression since, I believe, 42cb050a05
Sounds like there should be a test case to go along with it so it
doesn't re-regress in the future :)
Turns out there's a
On Wed, Apr 3, 2019 at 11:57 AM Andriy Gelman wrote:
>
> From: Andriy Gelman
>
> ---
> libavcodec/avpacket.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> index 8f0603df78..6ae092ed31 100644
> --- a/libavcodec/avpacket.c
> +++ b/libavcod
Hello,
I've observed a big problem with one of my sources that i have. It is
H264 video data and AAC audio (48 khz).
Below is a file that is a dump of part of a stream from this source
which i try to stream to Youtube LIVE and only what i get is a sound
with a lot of cracking noise and clear
On 03-04-2019 10:03 AM, Gyan wrote:
On 02-04-2019 04:57 PM, Gyan wrote:
I ran full fate and some tests failed as the ffmpeg binary wasn't
found. Suffixes weren't respected. Fixed.
I can run fate only occasionally. Maybe one of the regular FATE
submitters could set a suffix (and extension)
On 02-04-2019 04:57 PM, Gyan wrote:
I ran full fate and some tests failed as the ffmpeg binary wasn't
found. Suffixes weren't respected. Fixed.
I can run fate only occasionally. Maybe one of the regular FATE
submitters could set a suffix (and extension) to keep a check on this.
Will push s
Use the profile constraint flags to determine the exact va_profile for
HEVC_REXT.
Directly cast PTLCommon to H265RawProfileTierLevel, and use ff_h265_get_profile
to get the exact profile.
Signed-off-by: Linjie Fu
---
[v2]: use constraint flags to determine the exact profile, expose the
codec-spe
Parse all the constraint flags according to ITU-T Rec. H.265 (02/2018).
It can be passed to hw decoders to detemine the exact profile for Range
Extension HEVC.
Adjust the sequence of members in PTLCommon to match H265RawProfileTierLevel.
Signed-off-by: Linjie Fu
---
libavcodec/hevc_ps.c | 44 +
From: Andriy Gelman
---
libavcodec/avpacket.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 8f0603df78..6ae092ed31 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -44,6 +44,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
pkt->f
On 4/1/2019 8:39 PM, Mark Thompson wrote:
> ---
> libavcodec/cbs_av1_syntax_template.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/libavcodec/cbs_av1_syntax_template.c
> b/libavcodec/cbs_av1_syntax_template.c
> index 76eb90b279..a9bf78e4ad 100644
> --- a/libavcodec
On 4/1/2019 8:39 PM, Mark Thompson wrote:
> This simplifies the parser and improves performance by reducing the number
> of allocations and eliminating redundant copies.
> ---
> libavcodec/av1_parser.c | 63 +
> 1 file changed, 13 insertions(+), 50 deletions
On Sat, Mar 9, 2019 at 11:44 PM Thomas Xu wrote:
>
> +for (int index = 0; index < nb_rois; index++) {
> +av_log(ctx, AV_LOG_INFO, "index: %d, region: (%d %d)/(%d %d), qp
> offset: %d/%d",
> + index, roi->left, roi->top, roi->right, roi->bottom,
> roi->qoffset.num, roi->qo
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Wednesday, April 3, 2019 5:52 AM
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] lavc/qsvenc: enable hevc gpb
> option
>
> 2019-04-02 10:00 GMT+02:00,
On Thu, Mar 28, 2019 at 9:23 PM Jun Zhao wrote:
>
> From: Jun Zhao
>
> Use %.12g replace %.f when save AMF NUMBER(double) type to
> metadata. And update fate ref.
>
> before this fix, we get FLV metadata like:
>
> Metadata:
> lasttimestamp : 113
> lastkeyframetimestamp: 112
>
> after t
---
doc/encoders.texi | 46 ++
1 file changed, 46 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 94337d009c..a669ac3739 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1434,6 +1434,12 @@ value is 1, which will be slow
Fixes: out of array access
Fixes:
13997/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5701427252428800
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/agm.c | 3 ++-
1 file chan
On Tue, Apr 02, 2019 at 09:19:26PM +0200, Paul B Mahol wrote:
> On 4/2/19, Michael Niedermayer wrote:
> > Fixes: out of array access
> > Fixes:
> > 13997/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5701427252428800
> >
> > Found-by: continuous fuzzing process
> > https://github.co
2019-03-28 19:35 GMT+01:00, Carl Eugen Hoyos :
> Attached patch fixes ticket #7816 for me.
>
> Please review, Carl Eugen
Ping.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubsc
2019-04-03 0:25 GMT+02:00, Ulf Zibis :
> So please throw away the old one and use the new
> patch 11.
That patch does not apply:
The patch wants to remove "enum" from line 27, but that
is an include in current FFmpeg.
Carl Eugen
___
ffmpeg-devel mailing
Am 02.04.19 um 23:33 schrieb Carl Eugen Hoyos:
>> I again could enhance the performance up to 20 %.
>>
>> Patch 11: Correction of version from 28.03.19 22:01 CET. Fixed compiler
>> warning.
>> Patch 12: Moved multiplication with linesize out of for loop for
>> performance; side effect: reduces foo
2019-04-01 23:57 GMT+02:00, Hendrik Leppkes :
> Bug reports should go on Trac or the API user mailing list.
The ffmpeg-user mailing list is actually the preferred place.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.or
2019-04-02 10:00 GMT+02:00, Zhong Li :
> GPB is the default type, just contains forward references but the
> slice_type is B slice with higher encoding efficiency than regular P
> slice, but lower performance.
>
> Add an option to allow user to set regular P slice.
Ok.
> +{ "gpb", "GPB (gener
2019-04-02 22:16 GMT+02:00, Matthew Fearnley :
> By the way, is there a recommended way to enable #ifdef blocks
> when building ffmpeg?
--extra-cflags come to mind.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mai
2019-04-02 22:26 GMT+02:00, Ulf Zibis :
> Hi again,
>
> Am 28.03.19 um 22:01 schrieb Ulf Zibis:
>> As you can see from the benchmark log included in the
>> vf_fillbd_benchmark_9.patch I have attained a performance gain up to 45
>> %.
>> It is remarkable, that in several cases the processing of 16-b
> On 2 Apr 2019, at 16:48, Tomas Härdin wrote:
>
> mån 2019-04-01 klockan 13:29 +0100 skrev Matthew Fearnley:
> On 1 Apr 2019, at 10:28, Tomas Härdin wrote:
>>>
>>> fre 2019-03-29 klockan 22:23 + skrev Matthew Fearnley:
>> On Wed, 27 Mar 2019 at 09:42, Tomas Härdin wrote:
>>
On 4/2/19, Michael Niedermayer wrote:
> Fixes: out of array access
> Fixes:
> 13997/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5701427252428800
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niede
On 4/1/2019 8:39 PM, Mark Thompson wrote:
> +static int cbs_av1_parse_obu(CodedBitstreamContext *ctx,
> + void *priv, int obu_type,
> + const uint8_t *data, size_t data_size)
> +{
> +CodedBitstreamUnit unit;
> +int err;
> +
> +// T
On 4/2/2019 3:36 PM, James Almer wrote:
> On 4/1/2019 8:39 PM, Mark Thompson wrote:
>> ---
>> Unsure about this one - while the patch is short, it's rather invasive in a
>> pretty ugly way with how it abuses the read call. It will still do
>> allocations for the decomposition because of that, ev
On 4/1/2019 8:39 PM, Mark Thompson wrote:
> ---
> Unsure about this one - while the patch is short, it's rather invasive in a
> pretty ugly way with how it abuses the read call. It will still do
> allocations for the decomposition because of that, even though we don't
> really want them.
>
> A
Fixes: out of array access
Fixes:
13997/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5701427252428800
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/agm.c | 3 +++
1 file chan
Hendrik Leppkes:
> On Tue, Apr 2, 2019 at 5:55 PM Andreas Rheinhardt via ffmpeg-devel
> wrote:
>>
>> Hello,
>>
>> thanks for taking a look at this.
>>
>> Hendrik Leppkes:
>>> On Tue, Apr 2, 2019 at 3:36 PM Andreas Rheinhardt via ffmpeg-devel
>>> wrote:
Up until now, the writing process
On 4/2/2019 1:23 PM, Hendrik Leppkes wrote:
> On Tue, Apr 2, 2019 at 5:55 PM Andreas Rheinhardt via ffmpeg-devel
> wrote:
>>
>> Hello,
>>
>> thanks for taking a look at this.
>>
>> Hendrik Leppkes:
>>> On Tue, Apr 2, 2019 at 3:36 PM Andreas Rheinhardt via ffmpeg-devel
>>> wrote:
Up unti
Hendrik Leppkes:
> On Tue, Apr 2, 2019 at 3:36 PM Andreas Rheinhardt via ffmpeg-devel
> wrote:
>> @@ -383,8 +388,8 @@ static void
>> end_ebml_master_crc32_preliminary(AVIOContext *pb, AVIOContext **dyn
>> uint8_t *buf;
>> int size = avio_get_dyn_buf(*dyn_cp, &buf);
>>
>> +pu
On Tue, Apr 2, 2019 at 3:36 PM Andreas Rheinhardt via ffmpeg-devel
wrote:
> @@ -383,8 +388,8 @@ static void end_ebml_master_crc32_preliminary(AVIOContext
> *pb, AVIOContext **dyn
> uint8_t *buf;
> int size = avio_get_dyn_buf(*dyn_cp, &buf);
>
> +put_ebml_num(pb, size, master
On Tue, Apr 2, 2019 at 5:55 PM Andreas Rheinhardt via ffmpeg-devel
wrote:
>
> Hello,
>
> thanks for taking a look at this.
>
> Hendrik Leppkes:
> > On Tue, Apr 2, 2019 at 3:36 PM Andreas Rheinhardt via ffmpeg-devel
> > wrote:
> >>
> >> Up until now, the writing process for level 1 elements (those
Up until now, a block's relative offset has been reported as the offset
in the log messages output when writing blocks; given that it is
impossible to know the real offset from the beginning of the file at
this point due to the fact that it is not yet known how many bytes will
be used for the conta
Hello,
thanks for taking a look at this.
Hendrik Leppkes:
> On Tue, Apr 2, 2019 at 3:36 PM Andreas Rheinhardt via ffmpeg-devel
> wrote:
>>
>> Up until now, the writing process for level 1 elements (those elements
>> for which CRC-32 elements are written by default) was this in case the
>> output
mån 2019-04-01 klockan 13:29 +0100 skrev Matthew Fearnley:
> > > > On 1 Apr 2019, at 10:28, Tomas Härdin wrote:
> >
> > fre 2019-03-29 klockan 22:23 + skrev Matthew Fearnley:
> > > > > On Wed, 27 Mar 2019 at 09:42, Tomas Härdin wrote:
> > > > > Additional minor fix: use PTRDIFF_SPECIFIER for
tis 2019-03-26 klockan 22:13 + skrev Matthew Fearnley:
> Support is #ifdef'd out at this stage, using ZMBV_ENABLE_24BPP (like in
> the zmbv.c decoder)
> ---
> libavcodec/zmbvenc.c | 9 +
> 1 file changed, 9 insertions(+)
Pushed
/Tomas
___
f
Am 01.04.19 um 22:08 schrieb Carl Eugen Hoyos:
>> Can you please tell me more detailed, what is wrong with the indentations?
> It’s correct as it is now.
You are sure?
line 125: there is a double space
line 130: the indentation is not aligned with the upper square bracket
lines 310..318: the code
Signed-off-by: Zhong Li
---
libavcodec/qsvenc.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index e76c580b4a..55f1223f02 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -629,9 +629,10 @@ static int init_video_p
GPB is the default type, just contains forward references but the
slice_type is B slice with higher encoding efficiency than regular P
slice, but lower performance.
Add an option to allow user to set regular P slice.
Fix ticket#6870
Test data on Intel Kabylake (i7-7567U CPU @ 3.50GHz):
1. ffmpeg
On 4/2/2019 9:16 AM, Hendrik Leppkes wrote:
> On Mon, Apr 1, 2019 at 4:59 PM James Almer wrote:
>>
>> On 4/1/2019 9:13 AM, Lynne wrote:
>>> Mar 31, 2019, 11:49 PM by jamr...@gmail.com:
>>>
A float ret value needs to be in xmm0, and you swapped m0 with m2 on
Win64. This is the source of t
On Tue, Apr 2, 2019 at 3:36 PM Andreas Rheinhardt via ffmpeg-devel
wrote:
>
> Up until now, the writing process for level 1 elements (those elements
> for which CRC-32 elements are written by default) was this in case the
> output was seekable: Write the EBML ID, write an "unkown length" EBML
> nu
On 4/2/19, Nick Renieris wrote:
> I don't mind either way, but I'm writing my GSoC proposal at the
> moment and wanted an answer.
>
> If there's no clear answer, is it something TBD that I don't need to
> specify in the proposal?
I do not think we can use libdng.
_
After the last few commits, the functions for writing master elements
with CRC-32 elements didn't really make use of the ebml_master
structure any more, so remove these parameters from the functions.
The only things that still need to be kept are the positions of the
level 1 elements that are writ
Up until now, a block's relative offset has been reported as the offset
in the log messages output when writing blocks; given that it is
impossible to know the real offset from the beginning of the file at
this point due to the fact that it is not yet known how many bytes will
be used for the conta
Up until now, the length field of most level 1 elements has been written
using eight bytes, although it is known in advance how much space the
content of said elements will take up so that it would be possible to
determine the minimal amount of bytes for the length field. This
commit changes this.
Up until now, the check for whether to write CRC32 elements was always
mkv->write_crc && mkv->mode != MODE_WEBM. This is equivalent to simply
set write_crc to zero in WebM-mode. And this is what this commit does.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 11 ++-
1
Up until now, the writing process for level 1 elements (those elements
for which CRC-32 elements are written by default) was this in case the
output was seekable: Write the EBML ID, write an "unkown length" EBML
number of the desired length, then write the element into a dynamic
buffer, then write
A Matroska EBML ID can only be maximally four bytes long, so make the
variables denoting EBML IDs uint32_t instead of unsigned int to
better reflect this.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 32
1 file changed, 16 insertions(+), 16 d
Fixes intendation, whitespace, a typo and renames a variable
(dyn_bc->cluster_bc) to make its meaning clearer and to bring
it more in line with the naming of similar variables.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 103 +++---
1 file ch
Given that in both the seekable as well as the non-seekable mode dynamic
buffers are used to write level 1 elements and that now no seeks are
used in the seekable case any more, the two modes can be combined; as a
consequence, the non-seekable mode automatically inherits the ability to
write CRC-32
Up until e7ddafd515dc9826915b739d0b977a63c21e96af the Matroska muxer
wrote a secondary seek head referencing all the clusters. When this
was changed, a (now completely wrong) comment remained and the unique
remaining seek head was still called main_seekhead. This has been
changed.
Signed-off-by: A
Since 4e3bdf729a80f868b014ceb02901d87198b545a5 there is no reason any
more to treat the seekable and non-seekable cases separate with regards
to the log message for a new cluster. This effectively reverts
d41aeea8a64bab5d7aacd602f7214f95baad109f.
Also improved the log message: "pts 80dts 0" -> "pt
Up until now the EBML Header length field has been written with eight
bytes, although the EBML Header is always so small that only one byte
is needed for it. This patch saves seven bytes for every Matroska/Webm
file.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c| 5
All places where end_ebml_master_crc32_preliminary are used already
check for whether the output is seekable, so the check in the function
is redundant.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavformat/matroskaenc.c
The upper bounds currently used for determining the size of a CuePoint's
length field can be improved somewhat; as a result, a CuePoint
containing three CueTrackPositions will now only need a size field
with one byte length.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 12 ++
The earlier code included the size of the BlockGroup's length field and
the EBML ID in the calculation of the size for the payload and ignored
the size of the duration's length field. This meant that Blockgroups
corresponding to packets with size 2^(7n) - 17 - n - i, i = 0,..., n - 1,
n = 1,..., 8
At this point, ts already includes the ts_offset so that the relative
time written with the cluster is already given by ts - mkv->cluster_pts.
It is this number that needs to fit into an int16_t.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 2 +-
1 file changed, 1 insertion(
Hello,
this patchset is mostly concerned with reducing the unnecessary overhead
of the Matroska muxer; this overhead mostly comes from not using the
minimal amount of bytes when writing the length field of master
elements. The length fields of most level 1 elements are currently
written on eight b
On 02-04-2019 05:38 PM, Hendrik Leppkes wrote:
On Tue, Apr 2, 2019 at 1:27 PM Gyan wrote:
I ran full fate and some tests failed as the ffmpeg binary wasn't found.
Suffixes weren't respected. Fixed.
I can run fate only occasionally. Maybe one of the regular FATE
submitters could set a suffix
On 04/01/2019 05:57 PM, Hendrik Leppkes wrote:
> On Mon, Apr 1, 2019 at 7:21 PM Yufei He wrote:
>> Hi
>>
>> There may be a bug for .mp4 reader.
>>
>> On decoding some ntsc mp4 files with my h.264 codec, from actvx I received,
>>
>> avctx->framerate.den is 100
>>
>> avctx->framerate.num is 2997
>>
I don't mind either way, but I'm writing my GSoC proposal at the
moment and wanted an answer.
If there's no clear answer, is it something TBD that I don't need to
specify in the proposal?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmp
Any consensus on using libdng?
Στις Τετ, 20 Μαρ 2019 στις 5:03 μ.μ., ο/η Nick Renieris
έγραψε:
>
> Στις Τετ, 20 Μαρ 2019 στις 4:17 μ.μ., ο/η Paul B Mahol
> έγραψε:
> > DNG I posted should be decodeable by default, without need for extra
> > option(s).
>
> The DNG contents themselves? As in, not
On Mon, Apr 1, 2019 at 4:59 PM James Almer wrote:
>
> On 4/1/2019 9:13 AM, Lynne wrote:
> > Mar 31, 2019, 11:49 PM by jamr...@gmail.com:
> >
> >> A float ret value needs to be in xmm0, and you swapped m0 with m2 on
> >> Win64. This is the source of the fate failure.
> >>
> > Attached a patch to fi
On Tue, Apr 2, 2019 at 1:27 PM Gyan wrote:
>
> I ran full fate and some tests failed as the ffmpeg binary wasn't found.
> Suffixes weren't respected. Fixed.
>
> I can run fate only occasionally. Maybe one of the regular FATE
> submitters could set a suffix (and extension) to keep a check on this.
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Tuesday, April 2, 2019 06:24
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/hevc_ps: parse constraint flags for
> HEVC REXT
>
> On 01/04/2019 22
Parse all the constraint flags according to ITU-T Rec. H.265 (02/2018).
It can be passed to hw decoders to detemine the exact profile for Range
Extension HEVC.
Signed-off-by: Linjie Fu
---
libavcodec/hevc_ps.c | 44
libavcodec/hevc_ps.h | 11
On 01-04-2019 02:54 PM, Tomas Härdin wrote:
sön 2019-03-31 klockan 00:11 +0530 skrev Gyan:
Regression since, I believe, 42cb050a05
Sounds like there should be a test case to go along with it so it
doesn't re-regress in the future :)
Turns out there's already a test. But the command is ineff
153372 UNITS in postfilter_c, 65536 runs, 0 skips
73164 UNITS in postfilter_neon, 65536 runs, 0 skips -> 2.1x speedup
80591 UNITS in deemphasis_c, 131072 runs, 0 skips
43969 UNITS in deemphasis_neon, 131072 runs, 0 skips -> 1.83x speedup
Total decoder speedup: ~15% on a
I ran full fate and some tests failed as the ffmpeg binary wasn't found.
Suffixes weren't respected. Fixed.
I can run fate only occasionally. Maybe one of the regular FATE
submitters could set a suffix (and extension) to keep a check on this.
Thanks,
Gyan
From 287c7244ef6370de45771c7979ec6b65
On 3/24/19 6:00 PM, Karthick J wrote:
> ---
> doc/muxers.texi | 3 ++
> libavformat/dashenc.c | 119 --
> 2 files changed, 84 insertions(+), 38 deletions(-)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index aac7d94edf..83ae017d6c 100644
> -
72 matches
Mail list logo
