> -Original Message-
> From: Kieran Kunhya
> Sent: Mittwoch, 7. Mai 2025 16:16
> To: FFmpeg development discussions and patches
> Cc: softworkz
> Subject: Re: [FFmpeg-devel] [PATCH 0/4] [Please Ignore] ci_test
>
> On Wed, May 7, 2025 at 4:24 AM ffmpegagent wr
On Wed, May 7, 2025 at 4:24 AM ffmpegagent wrote:
>
> This is for testing Patchwork CI builds, not for merging.
>
> softworkz (4):
> ci_test: Fail configure
> ci_test: Fail build
> ci_test: Fail fate
> ci_test: All good
>
>
>
> base-commit: 2b6303762fc0850b3bd841ebd234c336271f657c
> Publis
Hi
On Sun, Apr 06, 2025 at 01:16:27PM +0200, Michael Niedermayer wrote:
> Hi all
>
> This patchset adds all the extensions i found on trac and its links to
> allowed_extensions for hls.
> There was one testcase only so most of this is untested. It may be
> needed to add the extensions also to de
Hi
On Sun, Apr 06, 2025 at 09:20:58AM -0400, Leo Izen wrote:
> On 4/6/25 7:16 AM, Michael Niedermayer wrote:
> > Hi all
> >
> > This patchset adds all the extensions i found on trac and its links to
> > allowed_extensions for hls.
> > There was one testcase only so most of this is untested. It ma
On 4/6/25 7:16 AM, Michael Niedermayer wrote:
Hi all
This patchset adds all the extensions i found on trac and its links to
allowed_extensions for hls.
There was one testcase only so most of this is untested. It may be
needed to add the extensions also to demuxers or as exceptions
specific to hl
L. E. Segovia:
> Hi all,
>
> This is a patch to fix building FFmpeg without having DCE enabled.
> This was previously attempted by Andreas Rheinhardt in commit
> 40e6575aa3eed64cd32bf28c00ae57edc5acb25a. However, this is not remotely
> enough for MSVC; one can quickly check for this by configurin
On Sun, Oct 30, 2022 at 1:48 PM Mark Reid wrote:
>
>
> On Wed, Oct 12, 2022 at 3:06 PM Mark Reid wrote:
>
>>
>>
>> On Thu, Sep 29, 2022 at 11:08 AM wrote:
>>
>>> From: Mark Reid
>>>
>>> This patch series adds swscale input/output support for the packed rgb
>>> float formats.
>>> A few of the f
On Wed, Oct 12, 2022 at 3:06 PM Mark Reid wrote:
>
>
> On Thu, Sep 29, 2022 at 11:08 AM wrote:
>
>> From: Mark Reid
>>
>> This patch series adds swscale input/output support for the packed rgb
>> float formats.
>> A few of the filters also needed support the larger 96/128 bit packed
>> pixel si
On Thu, Sep 29, 2022 at 11:08 AM wrote:
> From: Mark Reid
>
> This patch series adds swscale input/output support for the packed rgb
> float formats.
> A few of the filters also needed support the larger 96/128 bit packed
> pixel sizes.
>
> I also plan to eventually add lossless unscaled convers
> -Original Message-
> From: ffmpeg-devel On Behalf Of Hendrik
> Leppkes
> Sent: Monday, January 10, 2022 11:31 AM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH 0/4] avcodec/dvbsubdec, dvdsubdec: don't
> dump images to
On Fri, Jan 7, 2022 at 5:14 PM Soft Works wrote:
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of Hendrik
> > Leppkes
> > Sent: Friday, January 7, 2022 11:32 AM
> > To: FFmpeg development discussions and patches
> > Su
> -Original Message-
> From: ffmpeg-devel On Behalf Of Marton
> Balint
> Sent: Friday, January 7, 2022 10:53 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH 0/4] avcodec/dvbsubdec, dvdsubdec: don't
> dump images to
On Fri, 7 Jan 2022, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of Marton
Balint
Sent: Friday, January 7, 2022 8:57 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH 0/4] avcodec/dvbsubdec, dvdsubdec: don't
dump imag
> -Original Message-
> From: ffmpeg-devel On Behalf Of Marton
> Balint
> Sent: Friday, January 7, 2022 8:57 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH 0/4] avcodec/dvbsubdec, dvdsubdec: don't
> dump images to
On Fri, 7 Jan 2022, ffmpegagent wrote:
It's annoying and unexpected, but still useful at times (as I've realized
just recently).
This is a follow-up to the earlier submission here:
https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg128080.html
There has been a comment from Anton, quest
> -Original Message-
> From: ffmpeg-devel On Behalf Of Hendrik
> Leppkes
> Sent: Friday, January 7, 2022 11:32 AM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH 0/4] avcodec/dvbsubdec, dvdsubdec: don't
> dump images to
On Fri, Jan 7, 2022 at 11:20 AM Hendrik Leppkes wrote:
>
> On Fri, Jan 7, 2022 at 5:50 AM ffmpegagent wrote:
> >
> > It's annoying and unexpected, but still useful at times (as I've realized
> > just recently).
> >
> > This is a follow-up to the earlier submission here:
> > https://www.mail-archi
On Fri, Jan 7, 2022 at 5:50 AM ffmpegagent wrote:
>
> It's annoying and unexpected, but still useful at times (as I've realized
> just recently).
>
> This is a follow-up to the earlier submission here:
> https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg128080.html
>
> There has been a comme
Reorganized a bit for easier replying.
Also, while i think this is an important discussion, i do not see why
it should stop de-deprecation of a good API. Deprecating the device
capabilities API cleaned up avformat a bit, but various other function
pointers are left. A redesign would clean them all
Nicolas, I agree with what you said, and you obviously have given this
more thought than me. Your and Anton's replies provide two by now
pretty clear different views, I hope more will chime in.
I will only highlight some things below.
On Fri, Jun 11, 2021 at 3:17 PM Nicolas George wrote:
> Input
Anton Khirnov (12021-06-11):
> And it would be really really REALLY nice if you finally learned to
> distinguish between your personal opinions, official project policy, and
> objective truth.
Have you missed the part where I ask you to give arguments?
Regards,
--
Nicolas George
signature.a
Quoting Nicolas George (2021-06-11 14:14:57)
> Anton Khirnov (12021-06-09):
> > > > There is no timeline, it depends on someone sitting down and doing the
> > > > work. The options proposed so far were
> > > > 1) merging libavdevice into libavformat
> > > > 2) making libavdevice into an independent
Quoting Diederick C. Niehorster (2021-06-10 15:29:57)
> > The problem is that libavdevice is a separate library from libavformat,
> > but fundamentally depends on accessing libavformat internals.
>
> Ah ok, so this is at first instance about cleanup/separation, not
> necessarily about adding new f
Diederick C. Niehorster (12021-06-10):
> Let me respond on two levels.
>
> Before exploring the design space of a separation of libavdevice and
> libavformat below, I think it is important to first comment on the
> current state (and whether the AVDevice Capabilities part of my patch
> series shou
Anton Khirnov (12021-06-09):
> > > There is no timeline, it depends on someone sitting down and doing the
> > > work. The options proposed so far were
> > > 1) merging libavdevice into libavformat
> > > 2) making libavdevice into an independent library with an independent
> > >API
> > > 3) movi
Let me respond on two levels.
Before exploring the design space of a separation of libavdevice and
libavformat below, I think it is important to first comment on the
current state (and whether the AVDevice Capabilities part of my patch
series should be blocked by this discussion).
Importantly, I
Quoting Diederick C. Niehorster (2021-06-09 21:49:28)
> On Wed, Jun 9, 2021 at 8:18 PM Anton Khirnov wrote:
> >
> > Quoting Diederick C. Niehorster (2021-06-05 16:51:32)
> > > On Sat, Jun 5, 2021 at 4:36 PM Anton Khirnov wrote:
> > > > Sorry to rain on your parade, but I don't think we should go
On Wed, Jun 9, 2021 at 8:18 PM Anton Khirnov wrote:
>
> Quoting Diederick C. Niehorster (2021-06-05 16:51:32)
> > On Sat, Jun 5, 2021 at 4:36 PM Anton Khirnov wrote:
> > > Sorry to rain on your parade, but I don't think we should go ahead with
> > > this before deciding what is to be done with li
Quoting Diederick C. Niehorster (2021-06-05 16:51:32)
> On Sat, Jun 5, 2021 at 4:36 PM Anton Khirnov wrote:
> > Sorry to rain on your parade, but I don't think we should go ahead with
> > this before deciding what is to be done with libavdevice. The last
> > discussion about it died without being
Anton Khirnov (12021-06-05):
> Sorry to rain on your parade, but I don't think we should go ahead with
> this before deciding what is to be done with libavdevice. The last
> discussion about it died without being resolved, but the issues are
> still present.
So, now we have somebody who wants to w
On Sat, Jun 5, 2021 at 4:36 PM Anton Khirnov wrote:
> Sorry to rain on your parade, but I don't think we should go ahead with
> this before deciding what is to be done with libavdevice. The last
> discussion about it died without being resolved, but the issues are
> still present.
I understand. I
Quoting Diederick Niehorster (2021-06-04 00:45:48)
> ** Resending as it seems they didn't all make it..**
>
> Undeprecating the avdevice capabilities API and implementing it for the
> dshow device. Much needed. Together with the other patches i sent, a
> dshow device can now be properly used progr
在 2021/2/23 下午2:47, 殷时友 写道:
2021年2月19日 下午1:28，Jiaxun Yang 写道：
Get MMI optimizations build for Loongson-2 again.
Tested on Loongson-2 and Loongson-3A.
Jiaxun Yang (4):
avutil/mips: Use MMI_{L,S}QC1 macro in {SAVE,RECOVER}_REG
avutil/mips: Extract load store with shift C1 pair marco
av
On Tue, Feb 23, 2021, at 2:47 PM, 殷时友 wrote:
>
> > 2021年2月19日 下午1:28，Jiaxun Yang 写道：
> >
> > Get MMI optimizations build for Loongson-2 again.
> > Tested on Loongson-2 and Loongson-3A.
> >
> > Jiaxun Yang (4):
> > avutil/mips: Use MMI_{L,S}QC1 macro in {SAVE,RECOVER}_REG
> > avutil/mips: Ex
> 2021年2月19日 下午1:28，Jiaxun Yang 写道：
>
> Get MMI optimizations build for Loongson-2 again.
> Tested on Loongson-2 and Loongson-3A.
>
> Jiaxun Yang (4):
> avutil/mips: Use MMI_{L,S}QC1 macro in {SAVE,RECOVER}_REG
> avutil/mips: Extract load store with shift C1 pair marco
> avcodec/mips: Use MM
Am Sa., 30. Jan. 2021 um 10:20 Uhr schrieb Christophe Gisquet
:
>
> Nobody complained so the CIDs are likely litle used.
https://trac.ffmpeg.org/ticket/7342
There are also tickets #7258 and #3707.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffm
On 11.11.2020 13:58, Timo Rothenpieler wrote:
Will push series soon if no one objects.
applied
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-de
Will push series soon if no one objects.
___
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".
On Wed, Jul 29, 2020 at 06:10:57PM +0800, Shiyou Yin wrote:
> Fixed four prob encountered when compiling ffmpeg with clang on mips.
> configure: ./configure --disable-mmi --cc=clang --cxx=clang++ --ld=clang
>
> [PATCH 1/4] [mips]: Fix register constraint error reported by clang.
> [PATCH 2/4] [mi
Am 04.07.19 um 16:28 schrieb Thilo Borgmann:
> Am 30.06.19 um 14:11 schrieb Thilo Borgmann:
>> Hi,
>>
>> some cleanup and $SUBJECT.
>>
>> Documentation and reindent follows afterwards.
>
> Will add docs and push with remarks from Moritz soonish - if there are no
> more comments coming in.
Pushed
Am 30.06.19 um 14:11 schrieb Thilo Borgmann:
> Hi,
>
> some cleanup and $SUBJECT.
>
> Documentation and reindent follows afterwards.
Will add docs and push with remarks from Moritz soonish - if there are no more
comments coming in.
-Thilo
___
ffmpeg-
On 20/05/2019 23:33, Mark Thompson wrote:
> On 12/05/2019 20:00, Jonas Karlman wrote:
>> From what I understand support for composed layers wont be added to AMD as
>> it technically are multiple objects. I am not even sure if AMD have support
>> for NV12 as a drm plane format.
>
> Yeah. Mesa de
On 12/05/2019 20:00, Jonas Karlman wrote:
> On 2019-05-12 19:28, Mark Thompson wrote:
>> On 09/05/2019 20:38, Jonas Karlman wrote:
>>> Hello,
>>>
>>> When a multi-layer AVDRMFrameDescriptor is used to describe a frame the
>>> overall
>>> frame format is missing and applications need to deduce the
On 2019-05-12 19:28, Mark Thompson wrote:
> On 09/05/2019 20:38, Jonas Karlman wrote:
>> Hello,
>>
>> When a multi-layer AVDRMFrameDescriptor is used to describe a frame the
>> overall
>> frame format is missing and applications need to deduce the frame
>> DRM_FORMAT_*
>> based on sw_format or th
On 09/05/2019 20:38, Jonas Karlman wrote:
> Hello,
>
> When a multi-layer AVDRMFrameDescriptor is used to describe a frame the
> overall
> frame format is missing and applications need to deduce the frame DRM_FORMAT_*
> based on sw_format or the layers format.
>
> This patchset adds a AVDRMFrame
Amit Kale 于2018年9月26日周三 下午1:50写道：
>
> Hi,
>
> I am sending an HLS manifest file output patch containing fixes broken down
> in four parts as follows
> 0001-Fix-computation-of-vs-start_pos.patch
> 0002-Add-a-new-hls_flag-peak_segment_bw.patch
> 0003-Adds-a-new-hls_flag-avg_bw.patch
> 0004-fix-mast
On Mon, Aug 13, 2018 at 9:52 PM Jun Zhao wrote:
>
> V1: - add a new avfilter_graph_get_class function for AVFilterGraph
options.
> - fix can't dump "slice" sub-option for AVFilter.
> - fix can't dump mpeg4videodec options issue. (use command "ffmpeg -h
decoder=mpeg4")
>
> Jun Zhao (4):
>
Hi,
On Tue, Dec 6, 2016 at 7:04 AM, James Darnley wrote:
> On 2016-12-05 19:32, James Darnley wrote:
> > Fixed the problem Michael highlighted. Dropped the intra functions
> until it
> > becomes clear why their performance is unexpected. Updated the
> benchmarks with
> > results from a Nehalem
On 2016-12-05 19:32, James Darnley wrote:
> Fixed the problem Michael highlighted. Dropped the intra functions until it
> becomes clear why their performance is unexpected. Updated the benchmarks with
> results from a Nehalem and used (slightly) more accurate data.
>
> Regarding the age of MMX:
On Tue, 4 Oct 2016, Josh de Kock wrote:
On 01/10/2016 18:27, Carlos Fernandez Sanz wrote:
- Addresses new comments such as like idx value checking and filename
checking
Carlos Fernandez (4):
Adding SCTE-35 CUI codec
SCTE-35 extraction from mpegts
SCTE-35 support in hlsenc
Correct In
On Tue, Oct 4, 2016 at 12:11 PM, Josh de Kock wrote:
> Putting SCTE35 support in another library like Upipe was suggested as well.
This is something that I don't understand. Should FFmpeg just ignore
the existance of this very important standard in the professional
video world? Drive users to so
On 01/10/2016 18:27, Carlos Fernandez Sanz wrote:
- Addresses new comments such as like idx value checking and filename checking
Carlos Fernandez (4):
Adding SCTE-35 CUI codec
SCTE-35 extraction from mpegts
SCTE-35 support in hlsenc
Correct Indentation
libavcodec/avcodec.h| 2 +
Oops, forgot to send this in reply to the previous thread. Should I re-send?
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/200092.html
On Wed, Sep 28, 2016 at 11:28 AM, Jon Toohill wrote:
> Trimming trailing_padding samples from the end of the track is not yet
> implemented.
>
> Jon To
On Wed, Sep 21, 2016 at 01:42:05PM -0700, Mark Reid wrote:
> Hi
>
> Here is a set of mxf files that contain such metadata
>
> https://dl.dropboxusercontent.com/u/170952/fate/mxf/track_00_v01.mxf
> https://dl.dropboxusercontent.com/u/170952/fate/mxf/track_01_v02.mxf
> https://dl.dropboxusercontent
On 15/09/2016 11:11, Thomas Volkert wrote:
[...]
Yes, it is quite a bit of unnecessary overhead, but it's much cleaner
than #ifdeffery in a single source file.
In general, I don't like the idea of having 2 source files with almost
the same content. This usually indicates to me that the code s
On 15.09.2016 08:55, Josh de Kock wrote:
On 14/09/2016 23:44, Thomas Volkert wrote:
On 15.09.2016 00:27, Josh de Kock wrote:
Hi,
Resending this set with ffplay now having two versions, a SDL2 and a
SDL1 version. I've integrated all comments up until now (hopefully).
Josh
Josh de Kock (3):
On 14/09/2016 23:44, Thomas Volkert wrote:
On 15.09.2016 00:27, Josh de Kock wrote:
Hi,
Resending this set with ffplay now having two versions, a SDL2 and a
SDL1 version. I've integrated all comments up until now (hopefully).
Josh
Josh de Kock (3):
lavd: Add SDL2 output device
ffplay: m
On 9/14/2016 7:44 PM, Thomas Volkert wrote:
> On 15.09.2016 00:27, Josh de Kock wrote:
>> Hi,
>>
>> Resending this set with ffplay now having two versions, a SDL2 and a
>> SDL1 version. I've integrated all comments up until now (hopefully).
>>
>> Josh
>>
>> Josh de Kock (3):
>>lavd: Add SDL2 ou
On 15.09.2016 00:27, Josh de Kock wrote:
Hi,
Resending this set with ffplay now having two versions, a SDL2 and a
SDL1 version. I've integrated all comments up until now (hopefully).
Josh
Josh de Kock (3):
lavd: Add SDL2 output device
ffplay: make copy for SDL1
MAINTAINERS: update my
On Mon, Jul 18, 2016 at 3:50 PM, Carl Eugen Hoyos wrote:
> Mark Reid gmail.com> writes:
>
>> I meant add the extension to the raw muxer. Yes it would trival.
>
> Sounds like a good idea.
okay will do, I'll send a patch
>
>> The raw dnxhd demuxer has support for the format. support was added
>>
Mark Reid gmail.com> writes:
> I meant add the extension to the raw muxer. Yes it would trival.
Sounds like a good idea.
> The raw dnxhd demuxer has support for the format. support was added
> couple months ago in commit 8395b6e.
Sorry for the confusion, Carl Eugen
___
On Mon, Jul 18, 2016 at 3:12 PM, Carl Eugen Hoyos wrote:
> Mark Reid gmail.com> writes:
>
>> On Sun, Jul 17, 2016 at 11:06 AM, Carl Eugen Hoyos wrote:
>> > Mark Reid gmail.com> writes:
>> >
>> >> The following patch series adds support for dnxhr encoding.
>> >> I added dnxhr as a profile to the
Mark Reid gmail.com> writes:
> On Sun, Jul 17, 2016 at 11:06 AM, Carl Eugen Hoyos wrote:
> > Mark Reid gmail.com> writes:
> >
> >> The following patch series adds support for dnxhr encoding.
> >> I added dnxhr as a profile to the dnxhd encoder.
> >
> > Is there also a raw format that our demuxer
On Sun, Jul 17, 2016 at 11:06 AM, Carl Eugen Hoyos wrote:
> Mark Reid gmail.com> writes:
>
>> The following patch series adds support for dnxhr encoding.
>> I added dnxhr as a profile to the dnxhd encoder.
>
> Is there also a raw format that our demuxer currently does
> not auto-detect (and / or
Mark Reid gmail.com> writes:
> The following patch series adds support for dnxhr encoding.
> I added dnxhr as a profile to the dnxhd encoder.
Is there also a raw format that our demuxer currently does
not auto-detect (and / or not demux)?
Carl Eugen
___
On Tue, Apr 19, 2016 at 4:20 AM, Michael Niedermayer
wrote:
> should be ok
Thanks, pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Mon, Apr 18, 2016 at 07:03:40PM +0200, Henrik Gramner wrote:
> Anton Mitrofanov (3):
> x86inc: Fix AVX emulation of some instructions
> x86inc: Improve handling of %ifid with multi-token parameters
> x86inc: Enable AVX emulation in additional cases
>
> Henrik Gramner (1):
> x86inc: Fix
>>>Ronald S. Bultje schrieb am Sa, 26.3.2016:
> Hi,
>
> On Fri, Mar 25, 2016 at 6:30 PM, Thomas Mundt ffmpeg.org> wrote:
>
>> These patches add bt.2020 colorspace and 10 and 12 bit depth support.
>> The calculation of the Y component is simplified but with identical
>> results.
>> Some unused v
Hi,
On Fri, Mar 25, 2016 at 6:30 PM, Thomas Mundt <
loudmax-at-yahoo...@ffmpeg.org> wrote:
> These patches add bt.2020 colorspace and 10 and 12 bit depth support.
> The calculation of the Y component is simplified but with identical
> results.
> Some unused variables are removed.
> The YUV croma
Hi,
On Fri, Mar 25, 2016 at 3:55 PM, Ganesh Ajjanagadde
wrote:
> On Fri, Mar 25, 2016 at 12:11 PM, Paul B Mahol wrote:
> > On 3/25/16, Ganesh Ajjanagadde wrote:
> >> On Fri, Mar 25, 2016 at 9:36 AM, Nicolas George
> wrote:
> >>> Le sextidi 6 germinal, an CCXXIV, Ganesh Ajjanagadde a ecrit :
>
On 3/25/2016 4:55 PM, Ganesh Ajjanagadde wrote:
> If anyone cares here, I do not know why we can't use inline asm or
> intrinsics
With Inline asm and intrinsics you're 100% dependent on the compiler
doing the right thing. The latter more so than the former.
So a function compiled with gcc 4.9 migh
On Fri, Mar 25, 2016 at 12:11 PM, Paul B Mahol wrote:
> On 3/25/16, Ganesh Ajjanagadde wrote:
>> On Fri, Mar 25, 2016 at 9:36 AM, Nicolas George wrote:
>>> Le sextidi 6 germinal, an CCXXIV, Ganesh Ajjanagadde a ecrit :
Depends on if it is small or not. Yes, in many codecs, FFT's are short
>
On 3/25/16, Ganesh Ajjanagadde wrote:
> On Fri, Mar 25, 2016 at 9:36 AM, Nicolas George wrote:
>> Le sextidi 6 germinal, an CCXXIV, Ganesh Ajjanagadde a ecrit :
>>> Depends on if it is small or not. Yes, in many codecs, FFT's are short
>>> length ones, e.g 512. However, on long lengths, e.g 8192+
On Fri, Mar 25, 2016 at 09:29:56AM -0700, Ganesh Ajjanagadde wrote:
> On Fri, Mar 25, 2016 at 8:23 AM, Hendrik Leppkes wrote:
> > If performance is the only reason one might want an external library,
> > then its a much better idea to try to optimize the code we have, that
> > way more people auto
On 3/25/2016 12:25 PM, Hendrik Leppkes wrote:
> Also for the record, most of the external libraries that duplicate
> internal functionality existed before the internal functionality was
> improved/implemented, or the current internal variant is still not
> quite on the level.
> Sometimes its just c
On Fri, Mar 25, 2016 at 9:36 AM, Nicolas George wrote:
> Le sextidi 6 germinal, an CCXXIV, Ganesh Ajjanagadde a écrit :
>> Depends on if it is small or not. Yes, in many codecs, FFT's are short
>> length ones, e.g 512. However, on long lengths, e.g 8192+, as seen
>> from the benches, there are som
Le sextidi 6 germinal, an CCXXIV, Ganesh Ajjanagadde a écrit :
> Depends on if it is small or not. Yes, in many codecs, FFT's are short
> length ones, e.g 512. However, on long lengths, e.g 8192+, as seen
> from the benches, there are sometimes 2x variations at the moment.
And how much of the actu
On Fri, Mar 25, 2016 at 8:23 AM, Hendrik Leppkes wrote:
> On Fri, Mar 25, 2016 at 3:34 PM, Ganesh Ajjanagadde
> wrote:
>> On Fri, Mar 25, 2016 at 12:35 AM, Clément Bœsch wrote:
>>> On Thu, Mar 24, 2016 at 05:50:48PM -0700, Ganesh Ajjanagadde wrote:
Ganesh Ajjanagadde (4):
configure:
On Fri, Mar 25, 2016 at 4:23 PM, Hendrik Leppkes wrote:
> On Fri, Mar 25, 2016 at 3:34 PM, Ganesh Ajjanagadde
> wrote:
>> On Fri, Mar 25, 2016 at 12:35 AM, Clément Bœsch wrote:
>>> On Thu, Mar 24, 2016 at 05:50:48PM -0700, Ganesh Ajjanagadde wrote:
Ganesh Ajjanagadde (4):
configure:
On Fri, Mar 25, 2016 at 3:34 PM, Ganesh Ajjanagadde wrote:
> On Fri, Mar 25, 2016 at 12:35 AM, Clément Bœsch wrote:
>> On Thu, Mar 24, 2016 at 05:50:48PM -0700, Ganesh Ajjanagadde wrote:
>>> Ganesh Ajjanagadde (4):
>>> configure: add fftw3 detection
>>> lavc/fftw: add initial fftw wrapper
>>>
On 25 March 2016 at 14:34, Ganesh Ajjanagadde wrote:
>
> like libopus based decoding instead of native FFmpeg decoding,
>
The decoders differ in output on broken/invalid files made using libopusenc
(at extremely low bitrates, way below the 5k minimum the spec says).
> the multiple AAC encoders/
On Fri, Mar 25, 2016 at 12:35 AM, Clément Bœsch wrote:
> On Thu, Mar 24, 2016 at 05:50:48PM -0700, Ganesh Ajjanagadde wrote:
>> Ganesh Ajjanagadde (4):
>> configure: add fftw3 detection
>> lavc/fftw: add initial fftw wrapper
>> lavc/fft-test: add FFTW3 tests
>> lavc/fft-test: update benchm
On Thu, Mar 24, 2016 at 05:50:48PM -0700, Ganesh Ajjanagadde wrote:
> Ganesh Ajjanagadde (4):
> configure: add fftw3 detection
> lavc/fftw: add initial fftw wrapper
> lavc/fft-test: add FFTW3 tests
> lavc/fft-test: update benchmark code
>
Why?
Using an external library for such an essent
On 3/2/2016 4:30 PM, foo86 wrote:
> This fixes some potential issues I've identified within new DCA decoder. It is
> probably a good idea to backport these patches into 3.0 release branch.
>
> foo86 (4):
> avcodec/dca: clear X96 channels if nothing was decoded
> avcodec/dca: fix av_cold placem
On Thu, Feb 18, 2016 at 04:12:25PM +0100, Michael Niedermayer wrote:
> On Thu, Feb 18, 2016 at 04:10:22PM +0100, Michael Niedermayer wrote:
> > On Thu, Feb 18, 2016 at 03:49:24PM +0100, Hendrik Leppkes wrote:
> > > On Thu, Feb 18, 2016 at 3:35 PM, Michael Niedermayer
> > > wrote:
> > > > The recen
On Thu, Feb 18, 2016 at 04:10:22PM +0100, Michael Niedermayer wrote:
> On Thu, Feb 18, 2016 at 03:49:24PM +0100, Hendrik Leppkes wrote:
> > On Thu, Feb 18, 2016 at 3:35 PM, Michael Niedermayer
> > wrote:
> > > The recent merges broke dependency handling
> > > This patchset reverts the changes
> >
On Thu, Feb 18, 2016 at 03:49:24PM +0100, Hendrik Leppkes wrote:
> On Thu, Feb 18, 2016 at 3:35 PM, Michael Niedermayer
> wrote:
> > The recent merges broke dependency handling
> > This patchset reverts the changes
> >
> > See: 0217 23:15 Hendrik Leppkes Re: [FFmpeg-devel] [PATCH 1/3] configure:
On Thu, Feb 18, 2016 at 3:35 PM, Michael Niedermayer
wrote:
> The recent merges broke dependency handling
> This patchset reverts the changes
>
> See: 0217 23:15 Hendrik Leppkes Re: [FFmpeg-devel] [PATCH 1/3] configure: Use
> set_all to force the dependency refresh
>
>
I would prefer if you squa
On Thu, Nov 26, 2015 at 11:15 AM, John Warburton wrote:
> On Thu, Nov 26, 2015 at 1:26 PM, Ganesh Ajjanagadde wrote:
>
>>> Does removing the L fix it?
>
>> Read up a bit and suspect it should, and more generally long double is
>> a can of worms on ppc with bugs on some compilers:
>> https://gcc.g
On Thu, Nov 26, 2015 at 1:26 PM, Ganesh Ajjanagadde wrote:
>> Does removing the L fix it?
> Read up a bit and suspect it should, and more generally long double is
> a can of worms on ppc with bugs on some compilers:
> https://gcc.gnu.org/wiki/Ieee128PowerPC, ABI in transition,
> https://llvm.org
On Thu, Nov 26, 2015 at 8:07 AM, Ganesh Ajjanagadde wrote:
> On Thu, Nov 26, 2015 at 5:23 AM, John Warburton
> wrote:
>> On Fri, Nov 13, 2015 at 4:42 PM, Ganesh Ajjanagadde
>> wrote:
>>>
>>> 4/4 is a "best effort" patch that maximizes accuracy on all platforms for
>>> avcodec/faandct. It result
On Thu, Nov 26, 2015 at 5:23 AM, John Warburton wrote:
> On Fri, Nov 13, 2015 at 4:42 PM, Ganesh Ajjanagadde
> wrote:
>>
>> 4/4 is a "best effort" patch that maximizes accuracy on all platforms for
>> avcodec/faandct. It results in concrete accuracy benefits on the "default"
>> x86-64
>> GNU/Lin
On Fri, Nov 13, 2015 at 4:42 PM, Ganesh Ajjanagadde
wrote:
>
> 4/4 is a "best effort" patch that maximizes accuracy on all platforms for
> avcodec/faandct. It results in concrete accuracy benefits on the "default"
> x86-64
> GNU/Linux platform.
>
> Patches tested with FATE. ppc untested.
Sorry t
On date Monday 2014-10-20 23:56:58 +0200, Lukasz Marek encoded:
> Some time ago I wanted to setup internet camera streaming via ffserver
> and I faced the same probalem as #1275.
> It was over a year ago, so I don't remember correctly, but a conclusion
> from debugging was that codec's private data
On 23.09.2014, at 23:36, Christophe Gisquet
wrote:
> They have little to no benefit (none speedwise) and could be altogether
> dropped. I'm still submitting them to give them a chance before that.
I consider code cleanup to have more than just "little to no benefit".
But I don't know the code so
On Fri, Aug 22, 2014 at 02:04:36PM +0200, Mickaël Raulet wrote:
> for the whole patchset.
all applied
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by a
for the whole patchset.
Mickaël
Le 22 août 2014 à 13:25, Michael Niedermayer a écrit :
> On Fri, Aug 22, 2014 at 11:40:17AM +0200, Mickaël Raulet wrote:
>> Patch okay.
>
> patch applied
>
> just to make sure i dont misunderstand, that "okay" was just for this
> patch or the whole patchset ?
>
On Fri, Aug 22, 2014 at 11:40:17AM +0200, Mickaël Raulet wrote:
> Patch okay.
patch applied
just to make sure i dont misunderstand, that "okay" was just for this
patch or the whole patchset ?
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In fact, the
Patch okay.
Mickaël
Le 4 août 2014 à 10:31, Christophe Gisquet a
écrit :
> Hi,
>
> 2014-08-02 14:48 GMT+02:00 Michael Niedermayer :
>> seems to fail with
>> libavcodec/x86/hevc_mc.asm:1258: error: (add:2) cannot reference symbol
>> `MAX_PB_SIZE' in preprocessor
>
> I forgot the initial patch
Hi,
2014-08-04 15:20 GMT+02:00 Michael Niedermayer :
> cc-ing Mickael, so its not missed
Ping.
The objection was mostly that openhevc was working on some arm
optimization. That should be pretty easy even for Mickael, considering
this code:
https://github.com/OpenHEVC/FFmpeg/blob/rext/libavcodec/
1 - 100 of 106 matches
Mail list logo
