On 12/21/2015 05:06 AM, Mats Peterson wrote:
More issues...
I've noticed that FFmpeg blindly assumes that 1-bit QuickTime Animation
(qtrle) video is black & white. This is not necessarily true. The two
colors can be any color, just like in 1-bit PNG. Unfortunately this
black & white assumption f
More issues...
I've noticed that FFmpeg blindly assumes that 1-bit QuickTime Animation
(qtrle) video is black & white. This is not necessarily true. The two
colors can be any color, just like in 1-bit PNG. Unfortunately this
black & white assumption for 1-bit video seems hardcoded into the qtr
On Sun, Dec 20, 2015 at 12:15:17PM +0100, Andreas Cadhalpun wrote:
> On 20.12.2015 00:55, Michael Niedermayer wrote:
> > On Sat, Dec 19, 2015 at 11:49:02PM +0100, Andreas Cadhalpun wrote:
> >> A negative bits_per_coded_sample doesn't make sense.
> >> If it is too large, the size calculation for av_
On Sun, Dec 20, 2015 at 12:04 PM, Ganesh Ajjanagadde
wrote:
> Source code is from Boost:
> http://www.boost.org/doc/libs/1_46_1/boost/math/special_functions/erf.hpp
> with appropriate modifications for FFmpeg.
>
> Tested on interval -6 to 6 (beyond which it saturates), +/-NAN, +/-INFINITY
> under
Previously it included the SRC_PATH in every title.
Signed-off-by: Andreas Cadhalpun
---
doc/Makefile| 7 ---
doc/doxy-wrapper.sh | 11 ++-
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/doc/Makefile b/doc/Makefile
index 3e67c2a..afa7e22 100644
--- a/doc/Mak
On 12/20/2015 05:54 PM, compn wrote:
On Sat, 19 Dec 2015 08:56:36 +0100
Piotr Bandurski wrote:
And ir21.dll ?
http://www.moviecodec.com/download-video-codecs/indeo-2-319598me-30/
16bit codec means that it wont load on win2k/winxp so thats why i never
got it working in mplayer's binary code
Source code is from Boost:
http://www.boost.org/doc/libs/1_46_1/boost/math/special_functions/erf.hpp
with appropriate modifications for FFmpeg.
Tested on interval -6 to 6 (beyond which it saturates), +/-NAN, +/-INFINITY
under -fsanitize=undefined on clang to test for possible undefined behavior.
On 12/16/2015 7:40 AM, Michael Niedermayer wrote:
> On Thu, Dec 10, 2015 at 08:02:27PM -0300, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> libavcodec/x86/hevc_sao_10bit.asm | 150
>> ++
>> 1 file changed, 54 insertions(+), 96 deletions(-)
>
> te
On 12/20/2015 4:34 PM, Christophe Gisquet wrote:
> Hi,
>
> 2015-12-16 4:24 GMT+01:00 James Almer :
>> On 12/10/2015 8:02 PM, James Almer wrote:
>>> Signed-off-by: James Almer
>>> ---
>>> libavcodec/x86/hevc_sao_10bit.asm | 142
>>> +++---
>>> 1 file changed, 57 i
Hi,
2015-12-16 4:24 GMT+01:00 James Almer :
> On 12/10/2015 8:02 PM, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> libavcodec/x86/hevc_sao_10bit.asm | 142
>> +++---
>> 1 file changed, 57 insertions(+), 85 deletions(-)
>
>
> Ping for patchset.
Went
On Fri, Dec 18, 2015 at 9:45 PM, Ganesh Ajjanagadde
wrote:
> lrint is faster here on -ftree-vectorize with GCC. This is likely simply
> an artifact of GCC's rather terrible auto-vectorizer, since as per the
> instruction set manuals cvtsd2si and cvttsd2si (or their vector equivalents)
> have ident
On Sat, 19 Dec 2015 08:56:36 +0100
Piotr Bandurski wrote:
> > And ir21.dll ?
>
> http://www.moviecodec.com/download-video-codecs/indeo-2-319598me-30/
16bit codec means that it wont load on win2k/winxp so thats why i never
got it working in mplayer's binary codec loader.
the 16bit codecs will w
On Sun, 20 Dec 2015 15:48:55 + (UTC)
Carl Eugen Hoyos wrote:
> Nicolas George nsup.org> writes:
>
> > Le decadi 30 frimaire, an CCXXIV, Carl Eugen Hoyos a écrit :
> > > But your patch doesn't work...
> >
> > Can you explain?
>
> The first frame still gets dropped with your patch
> attach
Nicolas George nsup.org> writes:
> Le decadi 30 frimaire, an CCXXIV, Carl Eugen Hoyos a écrit :
> > But your patch doesn't work...
>
> Can you explain?
The first frame still gets dropped with your patch
attached.
> It worked when I submitted it, I think.
You think?
(I still wonder why field
Le decadi 30 frimaire, an CCXXIV, Carl Eugen Hoyos a écrit :
> But your patch doesn't work...
Can you explain? It worked when I submitted it, I think.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing
Nicolas George nsup.org> writes:
> Le decadi 30 frimaire, an CCXXIV, Carl Eugen Hoyos a écrit :
> > Video filter decimate currently (always) drops the first frame
> > because its diff values are all 0. Attached patch tries to fix
> > ticket #4990.
> > Better suggestions on how to detect "first
Le decadi 30 frimaire, an CCXXIV, Carl Eugen Hoyos a écrit :
> Video filter decimate currently (always) drops the first frame
> because its diff values are all 0. Attached patch tries to fix
> ticket #4990.
> Better suggestions on how to detect "first frame" welcome.
I already proposed a patch f
Hi!
Video filter decimate currently (always) drops the first frame
because its diff values are all 0. Attached patch tries to fix
ticket #4990.
Better suggestions on how to detect "first frame" welcome.
Please comment, Carl Eugen
diff --git a/libavfilter/vf_decimate.c b/libavfilter/vf_decimate.
Signed-off-by: Paul B Mahol
---
libavfilter/Makefile | 1 +
libavfilter/af_aequalizer30band.c | 358 ++
libavfilter/allfilters.c | 1 +
3 files changed, 360 insertions(+)
create mode 100644 libavfilter/af_aequalizer30band.c
diff --gi
Am 20.12.2015 um 15:11 schrieb Nicolas George:
> Le decadi 30 frimaire, an CCXXIV, Matthias Hunstock a écrit :
>> Decklink cards actually do just some bitbanging: take digital input in
>> "raw" format (AFAIK UYVY422 10 bit, PCM 16bit) and copy that into your RAM.
>
> Take digital input... from whe
Le decadi 30 frimaire, an CCXXIV, Matthias Hunstock a écrit :
> Decklink cards actually do just some bitbanging: take digital input in
> "raw" format (AFAIK UYVY422 10 bit, PCM 16bit) and copy that into your RAM.
Take digital input... from where?
> Another possibility is to demux each channel as
Am 20.12.2015 um 14:53 schrieb Nicolas George:
> Le decadi 30 frimaire, an CCXXIV, Matthias Hunstock a écrit :
>> SDI just transports 16 mono channels of audio, without any implied
>> semantic of what is in there. So the closest matching layouts are 2.0,
>> 8.0 and 16.0, if they existed.
>
> That
Le decadi 30 frimaire, an CCXXIV, Matthias Hunstock a écrit :
> SDI just transports 16 mono channels of audio, without any implied
> semantic of what is in there. So the closest matching layouts are 2.0,
> 8.0 and 16.0, if they existed.
That does not mean anything. The channel layout called 5.1 "e
Am 20.12.2015 um 13:16 schrieb Carl Eugen Hoyos:
> Matthias Hunstock fem.tu-ilmenau.de> writes:
>
>> +/* Check audio channel option for valid values: 2, 8 or 16 */
>> +switch (cctx->audio_channels) {
>> +case 2:
>> +case 8:
>
> If decklink provides 8 channels, are they su
Matthias Hunstock fem.tu-ilmenau.de> writes:
> +/* Check audio channel option for valid values: 2, 8 or 16 */
> +switch (cctx->audio_channels) {
> +case 2:
> +case 8:
If decklink provides 8 channels, are they supposed
to be in a specific layout or could they implement
a
As it is already written in the documentation, BMD DeckLink cards
are capable of capturing 2, 8 or 16 audio channels (for SDI Inputs).
Currently the value is hardcoded to 2. Introduces new option.
Signed-off-by: Matthias Hunstock
---
doc/indevs.texi | 13 -
libavdevic
Am 19.12.2015 um 23:29 schrieb Timothy Gu:
>> PS. I did not find any ressources on how to properly name new FFmpeg
>> options, e.g. to be consistent. Using the existing "ac" option did >>
not work.
> In this situation, it is always good to check what others are using :)
>
> In this case, all the
On 18.12.2015 16:41, Andreas Cadhalpun wrote:
> Subject: [PATCH] nuv: sanitize negative fps rate
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavformat/nuv.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/libavformat/nuv.c b/libavformat/nuv.c
> index 2a1b70f..c30da60 100644
On 20.12.2015 01:50, Ganesh Ajjanagadde wrote:
> On Sat, Dec 19, 2015 at 2:49 PM, Andreas Cadhalpun
> wrote:
>> Otherwise the too samll buffer is directly used in the frame, causing
> samll-> small
Fixed before pushing.
> sorry, can't review further.
Thanks, anyway.
Best regards,
Andreas
On 20.12.2015 01:11, Michael Niedermayer wrote:
> On Sat, Dec 19, 2015 at 11:49:14PM +0100, Andreas Cadhalpun wrote:
>> Otherwise the too samll buffer is directly used in the frame, causing
>> segmentation faults, when trying to use the frame.
>>
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> liba
On 20.12.2015 00:35, Michael Niedermayer wrote:
> On Sat, Dec 19, 2015 at 11:47:54PM +0100, Andreas Cadhalpun wrote:
>> This fixes NULL pointer dereferencing.
>>
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavformat/mlvdec.c | 5 +
>> 1 file changed, 5 insertions(+)
>
> iam not maintaine
On 20.12.2015 00:55, Michael Niedermayer wrote:
> On Sat, Dec 19, 2015 at 11:49:02PM +0100, Andreas Cadhalpun wrote:
>> A negative bits_per_coded_sample doesn't make sense.
>> If it is too large, the size calculation for av_get_packet overflows,
>> resulting in allocation of a too small buffer.
>>
32 matches
Mail list logo
