On 19-04-2019 08:41 PM, Gyan wrote:
On 16-04-2019 01:12 PM, Gyan wrote:
Patch revised as per
http://www.ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242591.html
If no more changes, plan to push tomorrow morning.
Pushed as 3153a6502a28b20a0da822daf32bcd8f7c90d721
Gyan
___
NEON:
5225 UNITS in fft15, 65536 runs, 0 skips
C:
7889 UNITS in fft15, 65535 runs, 1 skips
Posting this to maybe get some advice, its too slow for any noticeable
decoding speed increase.
>From 534dd20b4961c2f0c4131fbbadac5f1940bad3a0 Mon Sep 17 00:00:00 2001
From: Lynne
Date: Sat,
They're not used and they're incorrect.
>From 91a284e48b6fca5595e75ec2b5d5fc5eae6b71f9 Mon Sep 17 00:00:00 2001
From: Lynne
Date: Sat, 20 Apr 2019 02:04:51 +0100
Subject: [PATCH 1/2] arch64/asm-offsets: remove old CELT offsets
They're not used and they're incorrect.
---
libavcodec/aarch64/asm-o
Fixes: signed integer overflow: -2147483648 + -1 cannot be represented in type
'int'
Fixes:
14107/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUEMOTION2_fuzzer-5694078680825856
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-
Fixes ticket #2956.
Signed-off-by: Swaraj Hota
---
I have tested it on all the samples provided in the ticket and
it works for all of them.
Please comment.
---
Changelog| 1 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/ifv.c| 332 ++
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, 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
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
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
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 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
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
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
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
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
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
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
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
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 ++
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
---
The only difference between this version and the earlier versio
On Fri, Apr 19, 2019, at 2:15 PM, Hendrik Leppkes wrote:
>
> The first mail like that arrived, and handling of it of course
> depends on the mail client in question. But at least Patchwork doesn't
> seem to like it much, it quite simply still attributes it to the
> "shared" mail.
> Not sure if th
2019-04-18 14:07 GMT+02:00, Carl Eugen Hoyos :
> 2019-04-18 12:16 GMT+02:00, Michael Niedermayer :
>>> Silences a warning with clang:
>>> warning: implicit conversion from 'int' to 'int16_t' (aka 'short')
>>> changes
>>> value from 44130 to -21406
>>> ---
>>> libavfilter/vf_fspp.h |2 +-
>>>
2019-04-19 16:18 GMT+02:00, Carl Eugen Hoyos :
> Attached patch is necessary for msvc compilation on wsl.
Patch applied, in-tree msvc compilation with wsl works for
all targets.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://f
On Fri, Apr 19, 2019 at 8:23 PM Lou Logan wrote:
>
> On Thu, 18 Apr 2019 18:01:27 -0400
> "Lou Logan" wrote:
> >
> > But we can certainly give it a try if you like. I'm not sure how patchwork
> > will handle it.
>
> (Didn't realize my webmail client wasn't actually wrapping my text
> although it
The earlier version of the webm_chunk muxer had several bugs:
1. If the first packet of an audio stream didn't have a PTS of zero,
then no chunk will be started before a packet is delivered to the
underlying Matroska/WebM muxer, i.e. the AVFormatContext used to write
these packets had a NULL as AV
Up until now, it was simply presumed that the first packet had a pts of
zero; otherwise the duration of the first chunk was wrong.
Signed-off-by: Andreas Rheinhardt
---
libavformat/webm_chunk.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/libavformat/webm_chunk.
The last argument of av_strlcpy is supposed to contain the size of the
destination buffer, but it was filled with the size of the source
string, effectively negating its very purpose.
Signed-off-by: Andreas Rheinhardt
---
As the author information in my previous patchset has been munged, I
resend
--- Begin Message ---
Fixes: UBSan runtime error
Found-by: Clusterfuzz
---
libavformat/mov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index d5ce077e63..7e7de5962d 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2940,7 +294
On 4/19/19, Nicolas George wrote:
> Paul B Mahol (12019-04-19):
>> I'm really sorry for insulting you, and I will try to not repeat it.
>
> Accepted, although I have a feeling that "try" is weak.
>
> Now, you have complained about what you call my "one liners". I do not
> know if you realize, but
On Fri, Apr 19, 2019 at 19:20:50 +0200, Thomas Jammet wrote:
> @@ -6189,6 +6192,7 @@ enabled libopus && {
> enabled libpulse && require_pkg_config libpulse libpulse
> pulse/pulseaudio.h pa_context_new
> enabled librsvg && require_pkg_config librsvg librsvg-2.0
> librs
Attached patch resolves the issue mentioned within.
>From 10800493523b9274e7cc8784b65cc183a94b7281 Mon Sep 17 00:00:00 2001
From: Takayuki 'January June' Suwa
Date: Thu, 18 Apr 2019 10:56:40 +0900
Subject: [PATCH] avdevice/alsa: fix indefinite stop on closing PCM capture
Sorry, I forgot to take r
On Thu, 18 Apr 2019 18:01:27 -0400
"Lou Logan" wrote:
>
> But we can certainly give it a try if you like. I'm not sure how patchwork
> will handle it.
(Didn't realize my webmail client wasn't actually wrapping my text
although it was doing it in the window at the expected lengths.)
I just chang
Paul B Mahol (12019-04-19):
> I'm really sorry for insulting you, and I will try to not repeat it.
Accepted, although I have a feeling that "try" is weak.
Now, you have complained about what you call my "one liners". I do not
know if you realize, but I have adopted the policy of not wasting lines
On Sat, Apr 13, 2019 at 01:36:45AM +0200, Michael Niedermayer wrote:
> Fixes: Timeout (64sec ->2 sec)
> Fixes:
> 14131/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMV2_fuzzer-5719879556005888
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects
On 4/19/19, Nicolas George wrote:
> Paul B Mahol (12019-04-19):
>> I'm really sorry.
>
> For what, and what do you intend to do about it?
I'm really sorry for insulting you, and I will try to not repeat it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffm
On Fri, Apr 12, 2019 at 12:58:27AM +0200, Michael Niedermayer wrote:
> Fixes: assertion failure
> Fixes:
> 14078/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_INDEO5_fuzzer-5760571284127744
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffm
On Fri, 19 Apr 2019 00:05:00 +
Andreas Rheinhardt wrote:
> But now I am unsure whether I should resend my patchsets?
At this point I suggest resending as it will allow the commiter to
avoid having to adjust the author and will help avoid mistakes.
On Sun, Apr 07, 2019 at 05:32:36PM +0200, Michael Niedermayer wrote:
> It seems the specification does not limit the value to 32bit
>
> Fixes: signed integer overflow: -109611143 * 24 cannot be represented in type
> 'int'
> Fixes:
> 13477/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_f
On 4/18/19, Tobias Rapp wrote:
> On 18.04.2019 11:40, Michael Niedermayer wrote:
>> On Thu, Apr 18, 2019 at 10:30:49AM +0200, Paul B Mahol wrote:
>>> On 4/18/19, Michael Niedermayer wrote:
On Thu, Apr 18, 2019 at 01:19:58AM +0200, Michael Niedermayer wrote:
> On Wed, Apr 17, 2019 at 06:1
Paul B Mahol (12019-04-19):
> I'm really sorry.
For what, and what do you intend to do about it?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-dev
On 4/19/19, Nicolas George wrote:
> Paul B Mahol (12019-04-19):
>> I'm really sorry if that hurt you.
>
> That's not excuses for the insult.
I'm really sorry.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmp
On Mon, 08. Apr 14:03, Andriy Gelman wrote:
> From: Andriy Gelman
>
> This commit replaces packet assignment operator with av_packet_move_ref
> when there is a packet ownership transfer.
> ---
> Michael, the update patch now has correct behavior for ticket 4221.
>
> libavformat/utils.c | 30 +++
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 2 +
libavfilter/vf_lut3d.c | 91 ++
2 files changed, 93 insertions(+)
diff --git a/doc/filters.texi b/doc/filters.texi
index 606d682e84..aaa9163d89 100644
--- a/doc/filters.texi
+++ b/doc/filters.t
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 2 ++
libavfilter/vf_lut3d.c | 77 ++
2 files changed, 79 insertions(+)
diff --git a/doc/filters.texi b/doc/filters.texi
index 4dd1a5de85..606d682e84 100644
--- a/doc/filters.texi
+++ b/doc/filters.
Here is the updated version of the patch.
Thomas Jammet
---
configure | 4 +
doc/protocols.texi | 120 +++
libavformat/Makefile| 1 +
libavformat/librtmfp.c | 247
libavformat/protocols.c | 1 +
5 files change
Paul B Mahol (12019-04-19):
> I'm really sorry if that hurt you.
That's not excuses for the insult.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-
On 4/18/2019 9:56 PM, Dan Sanders via ffmpeg-devel wrote:
>>> +#define APE_TAG_FLAG_CONTAINS_HEADER (1U << 31)
>>
>> Isn't it enough with this one only?
>
> Yes, only APE_TAG_FLAG_CONTAINS_HEADER is problematic. I changed all
> of them because the tags are only used in unsigned contexts anyway.
On 4/19/19, Nicolas George wrote:
> Paul B Mahol (12019-04-19):
>> I'm very civil here.
>
> https://ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242839.html
I'm really sorry if that hurt you.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https:/
2019-04-19 16:12 GMT+02:00, Carl Eugen Hoyos :
> 2019-04-19 13:11 GMT+02:00, Carl Eugen Hoyos :
>
>> Attached patch is needed here for fate on wsl with msvc, not
>> sure why I didn't need this with mingw-gcc.
>
> Better tested and correct variant attached.
And a third attempt.
No idea why the othe
Paul B Mahol (12019-04-19):
> I'm very civil here.
https://ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242839.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above,
On 4/19/19, Nicolas George wrote:
> Paul B Mahol (12019-04-19):
>> What you actually want?
>
> I demand, that you behave in a civil manner.
I'm very civil here.
If I'm not polite than that is because of your snarky comments.
You already blocked several my patches for no apparent
good reason.
In
Paul B Mahol (12019-04-19):
> What you actually want?
I demand, that you behave in a civil manner.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-d
On 4/19/19, Nicolas George wrote:
> Michael Niedermayer (12019-04-19):
>> As i have been asked to look into this
>
> Not to look into this: to take action.
>
>> Everyone, the subject of discussions should be FFmpeg and the
>> technologies
>> sorounding it. Insults, "Ad hominem" argumentation/attac
Michael Niedermayer (12019-04-19):
> As i have been asked to look into this
Not to look into this: to take action.
> Everyone, the subject of discussions should be FFmpeg and the technologies
> sorounding it. Insults, "Ad hominem" argumentation/attacks, and so on lead
> to a hostile climate that
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Pedro Arthur
> Sent: Friday, April 19, 2019 10:43 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] native mode in FFmpeg DNN module
>
> Hi,
>
> Em sex, 19
On Fri, Apr 19, 2019 at 08:09:28AM +, Andreas Håkon via ffmpeg-devel wrote:
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, 18 de April de 2019 22:13, Michael Niedermayer
> wrote:
>
> > On Thu, Apr 18, 2019 at 07:46:43AM +, Andreas Håkon via ffmpeg-devel
> > wrote:
> >
> > > Hi,
>
On Thu, Apr 18, 2019 at 05:12:14PM -0700, Dan Sanders via ffmpeg-devel wrote:
> Fixes: UBSan runtime error
> Found-by: Clusterfuzz
> ---
> libavformat/apetag.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/apetag.c b/libavformat/apetag.c
> index cdc6
On 16-04-2019 01:12 PM, Gyan wrote:
Patch revised as per
http://www.ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242591.html
If no more changes, plan to push tomorrow morning.
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpe
On Fri, Apr 19, 2019 at 08:23:35AM +, Andreas Håkon via ffmpeg-devel wrote:
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, 18 de April de 2019 22:07, Michael Niedermayer
> wrote:
>
> >
> > fails to apply cleanly
> >
> > Applying: libavformat: fix inputs initialization in mpegts muxer w
Andreas Rheinhardt:
> 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
Hi,
Em sex, 19 de abr de 2019 às 05:41, Guo, Yejun escreveu:
>
> Option 2)
> Write c code in FFmpeg to convert tensorflow file format (format 1) directly
> into memory representation (format 3), and so we controls everything in
> ffmpeg community. And the conversion can be extended to import mo
On Fri, Apr 5, 2019 at 12:06 AM James Almer wrote:
>
> On 4/3/2019 7:17 PM, Hendrik Leppkes wrote:
> > The transcode() helper function will already prepend the TARGET_PATH to
> > the sample path, if its a relative path. This avoids an issue on
> > Windows, where the relative path check could fail.
Hi!
Attached patch is necessary for msvc compilation on wsl.
Please comment, Carl Eugen
From 1a6921f6b1f4655a59263ba22aa9e3210143c49b Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Fri, 19 Apr 2019 16:16:19 +0200
Subject: [PATCH] configure: Add .exe suffix to some Windows executable names
2019-04-19 13:11 GMT+02:00, Carl Eugen Hoyos :
> Attached patch is needed here for fate on wsl with msvc, not
> sure why I didn't need this with mingw-gcc.
Better tested and correct variant attached.
Please comment, Carl Eugen
From ef2c43835568dc541b2d88e393768d5457845daa Mon Sep 17 00:00:00 200
2019-04-19 14:25 GMT+02:00, Ulf Zibis :
>
> Am 19.04.19 um 13:38 schrieb Paul B Mahol:
>>
>> Use either av_freep(&s->filler) or av_free(s->filler).
>
> It works fine without 'p'.
Please use av_freep() for context variables.
Carl Eugen
___
ffmpeg-devel m
On 4/19/19, Nicolas George wrote:
> Still rejected.
As ML administrator previously wrote you need to provide technical reasons
for rejection to make rejection valid.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listin
Still rejected.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Signed-off-by: Paul B Mahol
---
Now with 2 filters merged into one and more sample formats.
---
doc/filters.texi | 18 +++
libavfilter/Makefile | 1 +
libavfilter/af_asampling.c | 280 +
libavfilter/allfilters.c | 1 +
4 files changed, 30
Signed-off-by: Paul B Mahol
---
With more sample formats support.
---
doc/filters.texi | 27
libavfilter/Makefile | 1 +
libavfilter/af_asoftclip.c | 289 +
libavfilter/allfilters.c | 1 +
4 files changed, 318 insertions(+)
create m
On Fri, Apr 19, 2019 at 11:34:04AM +0200, Paul B Mahol wrote:
> On 4/19/19, Nicolas George wrote:
> > Paul B Mahol (12019-04-19):
> >> This is not about sample rate negotiation.
> >
> > Yes it is.
>
> Give proof.
>
> No, you need to argue better your pathetic behavior.
>
> >
> >> Bad argumentat
On 4/19/19, Ulf Zibis wrote:
>
> Am 19.04.19 um 14:35 schrieb Paul B Mahol:
>>> Do I really need the init function, as it has to do nothing in my case?
>> If it does nothing, you can safely remove it.
>
> Thanks!
>
>>> For performance testing I use the like:
>>> -f rawvideo -pix_fmt gray16 -s 400x
RFC-4566 do not give any limit of size on interger parameters given in fmtp
line.
By reading some more RFCs it is possible to find examples where some integers
parameters are greater than 32 (see RFC-6416, 7.4)
Instead I propose to check just check the eventual integer overflow.
Using INT_MIN an
Hello ? :)
On 4/10/19 1:26 PM, Mathieu Duponchelle wrote:
> No problem, note that the added indentation is because a loop
> was added :)
>
> On 4/10/19 1:14 AM, Carl Eugen Hoyos wrote:
>> 2019-03-23 0:22 GMT+01:00, Mathieu Duponchelle :
>>> It is perfectly valid to have multiple CC Picture User Da
Am 19.04.19 um 14:35 schrieb Paul B Mahol:
>> Do I really need the init function, as it has to do nothing in my case?
> If it does nothing, you can safely remove it.
Thanks!
>> For performance testing I use the like:
>> -f rawvideo -pix_fmt gray16 -s 400x600 -i /dev/zero
>>
>> Are there doubts i
On 4/19/19, Ulf Zibis wrote:
>
> Am 19.04.19 um 13:38 schrieb Paul B Mahol:
>>
>> Use either av_freep(&s->filler) or av_free(s->filler).
>
> It works fine without 'p'. Thanks!
>
> Do I really need the init function, as it has to do nothing in my case?
If it does nothing, you can safely remove it.
Am 19.04.19 um 13:38 schrieb Paul B Mahol:
>
> Use either av_freep(&s->filler) or av_free(s->filler).
It works fine without 'p'. Thanks!
Do I really need the init function, as it has to do nothing in my case?
static av_cold int init(AVFilterContext *ctx)
{
FillBordersContext *s = ctx->priv;
2019-04-18 13:58 GMT+02:00, Carl Eugen Hoyos :
> Attached patch silences several warnings when compiling for win32.
Patch applied.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To uns
2019-04-18 0:53 GMT+02:00, Carl Eugen Hoyos :
> Attached patch fixes ticket #7853.
Patch applied.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or em
2019-04-18 13:53 GMT+02:00, Carl Eugen Hoyos :
> Attached patch silences a warning that is shown with some gcc versions.
Patch applied.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
T
2019-03-28 19:35 GMT+01:00, Carl Eugen Hoyos :
> Attached patch fixes ticket #7816 for me.
Patch applied.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link abov
On 19-04-2019 09:57 AM, Gyan wrote:
On 19-04-2019 01:04 AM, Gyan wrote:
On 17-04-2019 11:30 PM, Gyan wrote:
On 17-04-2019 11:11 PM, Vittorio Giovara wrote:
On Wed, Apr 17, 2019 at 12:26 AM Gyan wrote:
On 13-04-2019 05:23 PM, Gyan wrote:
Will be helpful for correct result in filter
On 4/19/19, Ulf Zibis wrote:
> Hi,
>
> to libavfilter/vf_fillborders.c I've added the following:
> ===
> typedef struct FillBordersContext {
> [.]
> uint16_t *filler;
>
> void (*fillborders)(struct FillBordersContext *s, AVFrame *fram
---
src/security | 12
1 file changed, 12 insertions(+)
diff --git a/src/security b/src/security
index 9175aba..bdcce15 100644
--- a/src/security
+++ b/src/security
@@ -3,6 +3,14 @@
FFmpeg 4.1
+4.1.3
+
+Fixes following vulnerabilities:
+
+
+CVE-2019-11338, f1ecebcdb72b5928b585ec
Hi,
to libavfilter/vf_fillborders.c I've added the following:
===
typedef struct FillBordersContext {
[.]
uint16_t *filler;
void (*fillborders)(struct FillBordersContext *s, AVFrame *frame);
} FillBordersContext;
// following must b
Hi!
Attached patch is needed here for fate on wsl with msvc, not
sure why I didn't need this with mingw-gcc.
Please comment, Carl Eugen
From 35400d93f9d0a16d275be4c60b8d4ef04cac82f8 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Fri, 19 Apr 2019 13:08:21 +0200
Subject: [PATCH] tests/fate-
On 4/19/19, Gyan wrote:
>
>
> On 19-04-2019 02:43 PM, Nicolas George wrote:
>> Paul B Mahol (12019-04-19):
>>> Users that know what they are doing will do:
>>>
>>> upsample=4,some additional filtering,alimiter=parameters,some
>>> additional filtering,downsample=4
>> Bad design. We have sample rate
On 19-04-2019 02:43 PM, Nicolas George wrote:
Paul B Mahol (12019-04-19):
Users that know what they are doing will do:
upsample=4,some additional filtering,alimiter=parameters,some
additional filtering,downsample=4
Bad design. We have sample rate negotiation.
How about a filter that can st
On 4/19/19, Nicolas George wrote:
> Paul B Mahol (12019-04-19):
>> Look, you are full of shit.
>
> Unacceptable. Excuses expected.
I will ignore your one liners, snarky replies.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/m
Paul B Mahol (12019-04-19):
> Look, you are full of shit.
Unacceptable. Excuses expected.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-req
Hi,
On 4/15/19, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> doc/filters.texi | 15 +++
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c | 1 +
> libavfilter/vf_lagfun.c | 252 +++
> 4 files changed, 269 insertions(+)
>
On 4/19/19, Nicolas George wrote:
> Paul B Mahol (12019-04-19):
>> This is not about sample rate negotiation.
>
> Yes it is.
Give proof.
No, you need to argue better your pathetic behavior.
>
>> Bad argumentation.
>
> Then argue better.
>
> Patches rejected for now.
Look, you are full of shit
Paul B Mahol (12019-04-19):
> This is not about sample rate negotiation.
Yes it is.
> Bad argumentation.
Then argue better.
Patches rejected for now.
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailma
On 4/19/19, Nicolas George wrote:
> Paul B Mahol (12019-04-19):
>> Users that know what they are doing will do:
>>
>> upsample=4,some additional filtering,alimiter=parameters,some
>> additional filtering,downsample=4
>
> Bad design. We have sample rate negotiation.
This is not about sample rate n
Paul B Mahol (12019-04-19):
> Users that know what they are doing will do:
>
> upsample=4,some additional filtering,alimiter=parameters,some
> additional filtering,downsample=4
Bad design. We have sample rate negotiation.
> This is already done by SoX.
We are not SoX.
--
Nicolas George
On 4/19/19, Nicolas George wrote:
> Paul B Mahol (12019-04-19):
>> This is used as part of other filtering. Namely when filter needs to
>> oversample
>> audio when processing - it then upsample audio before processing and
>> downsample
>> it by same factor after processing it.
>
> How do you inten
Paul B Mahol (12019-04-19):
> This is used as part of other filtering. Namely when filter needs to
> oversample
> audio when processing - it then upsample audio before processing and
> downsample
> it by same factor after processing it.
How do you intend to implement that? Filters cannot call ot
‐‐‐ Original Message ‐‐‐
On Thursday, 18 de April de 2019 11:01, Andreas Håkon via ffmpeg-devel
wrote:
> Hi,
>
> This patch resolves one very specific use case:
>
> - When you use the mpegts muxer;
> - And use the global parameter “-copyts”;
> - And use the parameter “-muxrate” for
Hi,
The DNN module currently supports two backends, tensorflow (dnn_backend_tf.c)
and native(dnn_backend_native.c). The native mode has external dependency, imho
it's not good and need a change. I think it is still a proper timing for the
change, for the limited functionality and performance of
‐‐‐ Original Message ‐‐‐
On Thursday, 18 de April de 2019 22:07, Michael Niedermayer
wrote:
>
> fails to apply cleanly
>
> Applying: libavformat: fix inputs initialization in mpegts muxer with filters
> Using index info to reconstruct a base tree...
> error: patch failed: fftools/ffmpeg
‐‐‐ Original Message ‐‐‐
On Thursday, 18 de April de 2019 22:13, Michael Niedermayer
wrote:
> On Thu, Apr 18, 2019 at 07:46:43AM +, Andreas Håkon via ffmpeg-devel
> wrote:
>
> > Hi,
> > This is the second part of my previous patch:
> > https://patchwork.ffmpeg.org/patch/12783/
> >
1 - 100 of 101 matches
Mail list logo
