On Wed, Mar 4, 2020 at 10:47 AM Carl Eugen Hoyos wrote:
> Am Mi., 4. März 2020 um 18:57 Uhr schrieb James Almer :
> >
> > On 3/4/2020 1:56 PM, Carl Eugen Hoyos wrote:
> > > Am Mi., 4. März 2020 um 17:53 Uhr schrieb Sebastian Hubbard
> > > :
> > >>
> > >> I knew this was an ABI change and probably
As it turns out the last patch still lets a lot of jpegs get misidentified.
This new version avoids the problem by checking for jpeg magic at the start.
I also added a FATE test, and attached the jpeg for the test.
On Tue, Aug 27, 2019 at 6:30 PM Niki Bowe wrote:
>
>
> On Sun, Aug
On Sun, Aug 25, 2019 at 11:39 AM Michael Niedermayer
wrote:
> On Fri, Aug 23, 2019 at 04:03:10PM -0700, Niki Bowe wrote:
> > On Thu, Aug 22, 2019 at 2:30 AM Paul B Mahol wrote:
> >
> > > On Thu, Aug 22, 2019 at 11:19 AM Carl Eugen Hoyos
> > > wrote:
> > &
On Thu, Aug 22, 2019 at 2:30 AM Paul B Mahol wrote:
> On Thu, Aug 22, 2019 at 11:19 AM Carl Eugen Hoyos
> wrote:
>
> > Am Mi., 21. Aug. 2019 um 23:05 Uhr schrieb Niki Bowe
> > :
> > >
> > > On Mon, Aug 19, 2019 at 7:22 PM Carl Eugen Hoyos
> > wrote
On Mon, Aug 19, 2019 at 7:22 PM Carl Eugen Hoyos wrote:
>
> This score would mean that mjpeg can never be detected.
> I suspect you have to reduce one of the demuxers to "- 1".
>
>
Thanks Carl.
Attached patch to reduce mpeg probe by -1, which also fixes the issue.
Alternatively I could bump both
On Tue, Feb 5, 2019 at 4:33 PM Niki Bowe wrote:
> Hi Carl.
> You are of course correct.
> Attached replacement patch.
>
>
> On Mon, Feb 4, 2019 at 6:24 PM Carl Eugen Hoyos
> wrote:
>
>> 2019-02-05 3:11 GMT+01:00, Nikolas Bowe :
>>
>&g
Hi Carl.
You are of course correct.
Attached replacement patch.
On Mon, Feb 4, 2019 at 6:24 PM Carl Eugen Hoyos wrote:
> 2019-02-05 3:11 GMT+01:00, Nikolas Bowe :
>
> > +if (mov->tracks[i].eac3_priv)
> > +av_freep(&mov->tracks[i].eac3_priv);
>
> I would have expected that th
My apologies.
I realized I applied my patch incorrectly before sending this.
I will send a corrected version tomorrow
On Thu, Jan 31, 2019 at 4:28 PM Nikolas Bowe wrote:
> If a hardware encoder is used, the pixel format may be a hardware pixel
> format.
> This leads to invalid VPCC atom being
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_write_ac3_tag.
It is not always extradata related.
Eg EAC3 parses the packets during muxing to build the dec3 atom. Perhaps
this should be made extradata, bu
Hi James,
I passed along your wish for aom_codec_get_global_headers().
Tom created this bug for tracking:
https://bugs.chromium.org/p/aomedia/issues/detail?id=2012
On Mon, Jul 9, 2018 at 11:29 AM James Almer wrote:
> aom_codec_get_global_headers() is not implemented as of libaom 1.0.0
> for AV1
On Fri, Feb 16, 2018 at 3:25 PM, Nikolas Bowe wrote:
> ---
> libavformat/flvdec.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> index 0217cef842..b86451fcbf 100644
> --- a/libavformat/flvdec.c
> +++ b/libavformat/flvdec.
On Fri, Jan 19, 2018 at 3:00 PM, Michael Niedermayer wrote:
> On Fri, Jan 19, 2018 at 02:48:08PM -0800, Nikolas Bowe wrote:
> > Found via fuzzing
> > ---
> > libavformat/rpl.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/rpl.c b/libavformat/rpl.c
> >
In the file the fuzzer produced the frame rate is incredibly small
(7.29112e-304).
I thought %e (or %g if you prefer) produced the most appropriate and
readable log message.
Also happy to just remove the frame rate from the log if you prefer?
On Thu, Jan 18, 2018 at 4:02 PM, Carl Eugen Hoyos
wrot
Thank you Kieran, Michael, Derek, and Carl.
I ran some benchmarks and the patch I provided really does have a speed
impact so I was considering alternative ways to achieve the same result.
After a little thought last week I came to the same conclusion as Michael
that a single rbsp_buffer per packe
On Thu, Oct 19, 2017 at 3:39 PM, Carl Eugen Hoyos
wrote:
> 2017-10-19 20:46 GMT+02:00 Nikolas Bowe :
> > Found via fuzzing.
> > /tmp/poc is a 1 MB mpegts file generated via fuzzing, where 1 packet has
> many NALUs
> > Before this change:
> > $ /usr/bin/time -f "\t%M Max Resident Set Size (Kb)"
ping.
On Fri, Sep 9, 2016 at 12:48 PM, Nikolas Bowe wrote:
> Currently when using target_level with EAC3 it produces silence. This
> small patch fixes target_level for decoding EAC3.
>
> Example:
> ffmpeg -y -i /tmp/test.wav -acodec eac3 -dialnorm -14 -ac 6 -b:a 384000
> /tmp/test.m2ts
> ffmpeg
16 matches
Mail list logo
