On Wed, Feb 6, 2019 at 9:51 PM Carl Eugen Hoyos wrote:
> Why don't you put your "formula" into your own github repository?
I could do that, but as I've mentioned, providing an official formula
(within a separate repository, not in the source tree!) would make it
easier for end users to discover,
On Thu, Feb 7, 2019, 02:22 Carl Eugen Hoyos 2019-02-07 0:57 GMT+01:00, Jan Ekström :
> > From: Masaki Tanaka
> >
> > Seems to fix mistaken cases of discontinuity handling in MPEG-TS
> > when program structure changes.
> >
> > Additional changes to patch from its original state by Jan Ekström.
> >
On 2/6/2019 10:13 PM, chcunningham wrote:
> Codec information may change while reading ogg packets. Update the
> stream's internal avctx to match.
> ---
> libavformat/oggparseogm.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavformat/oggparseogm.c b/libavformat/oggparseogm.c
>
Thanks, this works great. Stand by for patch.
On Wed, Feb 6, 2019 at 8:38 AM Hendrik Leppkes wrote:
> On Thu, Jan 31, 2019 at 11:29 PM Chris Cunningham
> wrote:
> >
> > On Wed, Jan 30, 2019 at 5:43 PM James Almer wrote:
> >
> > > On 1/30/2019 10:20 PM, Chris Cunningham wrote:
> > > >>
> > > >>
This is a follow up to feedback in
http://ffmpeg.org/pipermail/ffmpeg-devel/2019-February/239751.html
On Wed, Feb 6, 2019 at 5:13 PM chcunningham
wrote:
> Codec information may change while reading ogg packets. Update the
> stream's internal avctx to match.
> ---
> libavformat/oggparseogm.c | 3
Codec information may change while reading ogg packets. Update the
stream's internal avctx to match.
---
libavformat/oggparseogm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/oggparseogm.c b/libavformat/oggparseogm.c
index a07453760b..b07a5d55ba 100644
--- a/libavformat/oggp
On Thu, Jan 31, 2019 at 1:25 AM Michael Niedermayer
wrote:
>
> Changes 19sec to 10ms (12559) runtime, 17sec to 177ms (12570)
> Fixes: Timeout
> Fixes:
> 12559/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AC3_fuzzer-5666516266123264
> Fixes:
> 12561/clusterfuzz-testcase-minimized-ffmpeg_AV_C
2019-02-07 0:57 GMT+01:00, Jan Ekström :
> From: Masaki Tanaka
>
> Seems to fix mistaken cases of discontinuity handling in MPEG-TS
> when program structure changes.
>
> Additional changes to patch from its original state by Jan Ekström.
> ---
>
> Had been meaning to post this for comments/discuss
Detecting missing tfhd avoids re-using tfhd track info from the previous
moof. For files with multiple tracks, this may make a mess of the
avindex and fragindex, which can later trigger av_assert0 in
mov_read_trun().
---
libavformat/isom.h | 1 +
libavformat/mov.c | 10 ++
2 files change
From: Masaki Tanaka
Seems to fix mistaken cases of discontinuity handling in MPEG-TS
when program structure changes.
Additional changes to patch from its original state by Jan Ekström.
---
Had been meaning to post this for comments/discussion for a while, as
this seems to make timestamps contin
On Thu, Jan 31, 2019 at 01:23:51AM +0100, Michael Niedermayer wrote:
> Changes 19sec to 10ms (12559) runtime, 17sec to 177ms (12570)
> Fixes: Timeout
> Fixes:
> 12559/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AC3_fuzzer-5666516266123264
> Fixes:
> 12561/clusterfuzz-testcase-minimized-ffmp
On Fri, Feb 01, 2019 at 10:48:54PM +0100, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/mpegvideo_enc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
will apply
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
On Tue, Feb 05, 2019 at 10:42:32AM -0800, Baptiste Coudurier wrote:
> Hi Niki,
>
>
> > On Feb 4, 2019, at 6:03 PM, Niki Bowe wrote:
> >
> > Hi Baptiste.
> > I agree. This patch does cause it to fail in mov_write_header in the given
> > example, by propagating the errors returned from mov_writ
Hi,
On Wed, Feb 6, 2019 at 1:43 PM Helmut K. C. Tessarek
wrote:
> Anyhow, I don't think that adding a formula to the ffmpeg src tree is
> the right approach.
I don't think that's the suggestion. Separate Github repo belonging to
the FFmpeg Github organization.
Thanks,
Kyle
_
Hi,
On Wed, Feb 6, 2019 at 1:20 PM Reto Kromer wrote:
>
> Werner Robitza wrote:
>
> >I propose that FFmpeg maintains its own ffmpeg formula under
> >its GitHub organization
>
> I second the idea.
+1
>
> (Homebrew works now on any modern x86_64 architecture running
> Linux, macOS and Windows with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2019-02-06 21:41, Werner Robitza wrote:
> Please let me know your thoughts.
I'd like to know why people always think that brew is the best way to
get ports.
Have you looked into MacPorts? No issues with ffmpeg there.
If something should be missi
Werner Robitza wrote:
>I propose that FFmpeg maintains its own ffmpeg formula under
>its GitHub organization
I second the idea.
(Homebrew works now on any modern x86_64 architecture running
Linux, macOS and Windows with Linux.)
>I am happy to maintain this formula – and maybe there are other
>c
2019-02-06 21:41 GMT+01:00, Werner Robitza :
> I am happy to maintain this formula
Why don't you put your "formula" into your own github repository?
We already provide a build script and we believe that it works
very well, in addition a kind supporter offers osx binaries.
Carl Eugen
___
Dear all,
Homebrew has, with its 2.0 release, removed all options for its core
formulae [1], including ffmpeg. This means users can no longer add
non-default dependencies that aren't included in the core formula [2].
That creates a bit of a messy situation, as users are expecting to be
able to bui
2019-02-06 20:17 GMT+01:00, Michael Niedermayer :
> On Wed, Feb 06, 2019 at 01:57:37PM +0100, Carl Eugen Hoyos wrote:
>> 2019-02-03 18:21 GMT+01:00, Michael Niedermayer :
>> > Fixes: 1377/clusterfuzz-testcase-minimized-5487049807233024
>> > Fixes: assertion failure in sbr_sum_square_c()
>>
>> This
On Wed, Feb 06, 2019 at 01:57:37PM +0100, Carl Eugen Hoyos wrote:
> 2019-02-03 18:21 GMT+01:00, Michael Niedermayer :
> > Fixes: 1377/clusterfuzz-testcase-minimized-5487049807233024
> > Fixes: assertion failure in sbr_sum_square_c()
>
> This changes the output, no?
in normal cases, no it should n
On Thu, Jan 31, 2019 at 11:29 PM Chris Cunningham
wrote:
>
> On Wed, Jan 30, 2019 at 5:43 PM James Almer wrote:
>
> > On 1/30/2019 10:20 PM, Chris Cunningham wrote:
> > >>
> > And this definitely means there's a bug elsewhere. This parser should
> > have not been used for codecs ids oth
On Mon, Feb 04, 2019 at 04:33:37PM -0800, Chris Cunningham wrote:
> >
> > The underlined bit above seems like the root cause. Where should we be
> > updating st->internal->avctx->codec_id?
> >
>
> Friendly ping for review
I dont have a testcase so i cant test but possibly setting need_context_upd
On Mon, Feb 04, 2019 at 04:30:29PM -0800, chcunningham wrote:
> Bad content may contain stsc boxes with a first_chunk index that
> exceeds stco.entries (chunk_count). This ammends the existing check to
> include cases where chunk_count == 0.
> ---
> libavformat/mov.c | 7 +--
> 1 file changed,
On Wed, Feb 06, 2019 at 02:50:02PM +0100, Reimar Döffinger wrote:
> On 6 February 2019 11:46:52 CET, Michael Niedermayer
> wrote:
> >On Tue, Feb 05, 2019 at 05:03:02PM +, Eoff, Ullysses A wrote:
>
> >> I'm getting an ssl error
> >> with pwclient today. This is the first time I've tried usin
On 06/02/2019 14:50, Reimar Döffinger wrote:
As I remember, apache actually wants certificate and chain separately, so we
might need to create and use 2 different ones (even if the difference is just a
cat command or so).
https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatechainfi
On 6 February 2019 11:46:52 CET, Michael Niedermayer
wrote:
>On Tue, Feb 05, 2019 at 05:03:02PM +, Eoff, Ullysses A wrote:
>> I'm getting an ssl error
>> with pwclient today. This is the first time I've tried using
>pwclient since this
>> upgrade, so not sure if it's related.
>>
>> ssl.SSL
2019-02-03 18:21 GMT+01:00, Michael Niedermayer :
> Fixes: 1377/clusterfuzz-testcase-minimized-5487049807233024
> Fixes: assertion failure in sbr_sum_square_c()
This changes the output, no?
Why are the asm implementations not affected?
Carl Eugen
___
ff
On Wed, Feb 6, 2019, 13:38 Carl Eugen Hoyos 2019-02-05 18:22 GMT+01:00, Jan Ekström :
>
> > My initial idea was to get a reference going with libaribb24 which had
> > a defined interface and thus I didn't have to look too much into the
> > "how the sausage is done" part of it. After that I would h
2019-02-04 21:27 GMT+01:00, Paweł Wegner :
> Signed-off-by: Paweł Wegner
> ---
> libavformat/dashdec.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index f4f4e935de..89acd5807d 100644
> --- a/libavformat/dashdec.c
> +
On Tue, Feb 5, 2019 at 12:53 AM Carl Eugen Hoyos wrote:
> 2019-02-04 21:27 GMT+01:00, Paweł Wegner :
>
> > any reason why this commit:
> >
> https://github.com/FFmpeg/FFmpeg/commit/d54ae9b782c85e626a1e49a8ee204728746227d1#diff-ce2d1d31314e57cff2d1f3eb78988c88R1903
> > disables seeking in dash dem
2019-02-05 18:22 GMT+01:00, Jan Ekström :
> My initial idea was to get a reference going with libaribb24 which had
> a defined interface and thus I didn't have to look too much into the
> "how the sausage is done" part of it. After that I would have started
> looking into these two things in order
On 06/02/2019 11:46, Michael Niedermayer wrote:
There is also a new lets encrypt certificate, these expire frequently
The problem probably is that the server didnt sent the full chain of
certificates
ive manually made a certificate that works now but reimars script needs
an update so it cats all
On Tue, Feb 05, 2019 at 05:03:02PM +, Eoff, Ullysses A wrote:
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > Michael Niedermayer
> > Sent: Friday, February 01, 2019 4:53 AM
> > To: FFmpeg development discussions and patches
> >
34 matches
Mail list logo
