On 12/14/2015 06:32 AM, Mats Peterson wrote:
On 12/14/2015 03:40 AM, Carl Eugen Hoyos wrote:
Hi!
Attached patch based on 3ece3e4c by Martin Storsjö fixes ticket #5071
for me.
I can't see how duplicating the code from mov.c could be acceptable.
Please comment, Carl Eugen
On 12/14/2015 03:40 AM, Carl Eugen Hoyos wrote:
Hi!
Attached patch based on 3ece3e4c by Martin Storsjö fixes ticket #5071 for me.
I can't see how duplicating the code from mov.c could be acceptable.
Please comment, Carl Eugen
___
ffmpeg-devel maili
On 12/14/2015 03:40 AM, Carl Eugen Hoyos wrote:
Hi!
Attached patch based on 3ece3e4c by Martin Storsjö fixes ticket #5071 for me.
I can't see how duplicating the code from mov.c could be acceptable.
Please comment, Carl Eugen
___
ffmpeg-devel maili
Hi,
On Sun, Dec 13, 2015 at 7:29 PM, Ganesh Ajjanagadde
wrote:
> The worst part is that it is a bad idea to do runtime dispatch on the
> fma() itself, as the function call overhead will be nonneglible, and
> so one can't create a helper API in avutil or elsewhere. Thus, it can
> only be used whe
Hi!
Attached patch based on 3ece3e4c by Martin Storsjö fixes ticket #5071 for me.
I can't see how duplicating the code from mov.c could be acceptable.
Please comment, Carl Eugen
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index b77e7e8..b82f2a2 100644
--- a/libavformat/matr
On 2015/12/11 17:20, Timo Rothenpieler wrote:
* PGP Signed by an unknown key
Hi all, before switching to the new released nvenc6.0 header, can you
take a look at this fix?
I'm fine with making it the default, the only concern i have is weather
it has any side-effects, like reduced performance
On Sun, Dec 13, 2015 at 10:51:31PM +0100, Andreas Cadhalpun wrote:
> nlsf can be negative, but a negative index for silk_cosine doesn't work.
> ---
> libavcodec/opus_silk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/opus_silk.c b/libavcodec/opus_silk.c
> i
On Sun, Dec 13, 2015 at 6:55 PM, James Almer wrote:
[...]
>
> FP_FAST_FMA is apparently not defined on mingw-w64 even though it supports
> fma() and generates FMA3/4 instructions when targeting relevant CPUs.
Guess some implementer took the "optional" literally and decided not to bother.
>
> I a
On Sun, Dec 13, 2015 at 08:52:54PM +0530, Anshul wrote:
> Hello,
>
> Its regarding ticket #5067(avformat:open): crash on Mapping
> Multicast TV Stream to HLS with "Exactly one WebVTT stream is
> needed" as message
>
> I have attached patch for hls not failing in condition where
> subtitles stream
On 12/13/2015 8:08 PM, Ganesh Ajjanagadde wrote:
> On Sun, Dec 13, 2015 at 5:55 PM, Ganesh Ajjanagadde
> wrote:
>> On Sun, Dec 13, 2015 at 5:47 PM, Ronald S. Bultje wrote:
>>> Hi,
>>>
>>> On Sun, Dec 13, 2015 at 4:59 PM, Ganesh Ajjanagadde
>>> wrote:
fma is a faster function on archite
On Sun, Dec 13, 2015 at 09:56:06PM +0100, Andreas Cadhalpun wrote:
> Also correct the check to reject log < 7, because UPDATE_CACHE only
> guarantees 25 meaningful bits.
>
> This fixes undefined behavior:
> runtime error: shift exponent is negative
>
> Testing with START/STOP timers in get_ue_gol
On Sun, Dec 13, 2015 at 5:55 PM, Ganesh Ajjanagadde
wrote:
> On Sun, Dec 13, 2015 at 5:47 PM, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Sun, Dec 13, 2015 at 4:59 PM, Ganesh Ajjanagadde
>> wrote:
>>>
>>> fma is a faster function on architectures supporting a native CPU
>>> instruction for it.
>>> T
On Sun, Dec 13, 2015 at 5:47 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Dec 13, 2015 at 4:59 PM, Ganesh Ajjanagadde
> wrote:
>>
>> fma is a faster function on architectures supporting a native CPU
>> instruction for it.
>> This may be tested by the ISO C optionally defined FP_FAST_FMA. Althoug
Hi,
On Sun, Dec 13, 2015 at 4:59 PM, Ganesh Ajjanagadde
wrote:
> fma is a faster function on architectures supporting a native CPU
> instruction for it.
> This may be tested by the ISO C optionally defined FP_FAST_FMA. Although
> in the x86 lineup this came fairly late
> (from Haswell onwards, a
This macro unconditionally used out[-1], which causes an out of bounds
read, if out is the very beginning of the buffer.
Signed-off-by: Andreas Cadhalpun
---
libavcodec/exr.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index
On 13.12.2015 23:20, Rostislav Pehlivanov wrote:
> On Sun, 2015-12-13 at 22:24 +0100, Andreas Cadhalpun wrote:
>> This should fix this test failing on kfreebsd, a regression since
>> 6e5dbe7, which decreased the CMP_TARGET by 1.
>>
>> Signed-off-by: Andreas Cadhalpun
>
> LGTM,
Pushed.
Best rega
On Sun, 2015-12-13 at 22:24 +0100, Andreas Cadhalpun wrote:
> This should fix this test failing on kfreebsd, a regression since
> 6e5dbe7, which decreased the CMP_TARGET by 1.
>
> Signed-off-by: Andreas Cadhalpun
LGTM,
Thanks
___
ffmpeg-devel mailing
fma is a faster function on architectures supporting a native CPU instruction
for it.
This may be tested by the ISO C optionally defined FP_FAST_FMA. Although
in the x86 lineup this came fairly late
(from Haswell onwards, and hence is absent unless appropriate -march is passed),
numerous other arc
nlsf can be negative, but a negative index for silk_cosine doesn't work.
---
libavcodec/opus_silk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/opus_silk.c b/libavcodec/opus_silk.c
index 841d1ed..3ac83b8 100644
--- a/libavcodec/opus_silk.c
+++ b/libavcodec/opus_s
This should fix this test failing on kfreebsd, a regression since
6e5dbe7, which decreased the CMP_TARGET by 1.
Signed-off-by: Andreas Cadhalpun
---
I haven't tested this on kfreebsd, but it seems obvious [1]:
stddev: 823.32 PSNR: 38.02 MAXDIFF:15809 bytes: 1675800/ 1679360
stddev: |823.32 -
Also correct the check to reject log < 7, because UPDATE_CACHE only
guarantees 25 meaningful bits.
This fixes undefined behavior:
runtime error: shift exponent is negative
Testing with START/STOP timers in get_ue_golomb, one for the first
branch (A) and one for the second (B), shows that there is
On 12/13/2015 09:16 PM, Mats Peterson wrote:
On 12/13/2015 09:05 PM, Mats Peterson wrote:
On 12/13/2015 09:02 PM, Mats Peterson wrote:
On 12/13/2015 08:48 PM, Mats Peterson wrote:
I just discovered that I've been incorrectly using the "i" loop
variable
in my patch, which is actually used by a
On 12/13/2015 09:05 PM, Mats Peterson wrote:
On 12/13/2015 09:02 PM, Mats Peterson wrote:
On 12/13/2015 08:48 PM, Mats Peterson wrote:
I just discovered that I've been incorrectly using the "i" loop variable
in my patch, which is actually used by a track element loop at line 1718
in matroskadec
On 12/13/2015 09:02 PM, Mats Peterson wrote:
On 12/13/2015 08:48 PM, Mats Peterson wrote:
I just discovered that I've been incorrectly using the "i" loop variable
in my patch, which is actually used by a track element loop at line 1718
in matroskadec.c. This will works as long as there is only v
On 12/13/2015 08:48 PM, Mats Peterson wrote:
I just discovered that I've been incorrectly using the "i" loop variable
in my patch, which is actually used by a track element loop at line 1718
in matroskadec.c. This will works as long as there is only video in the
Matroska file, that's why I didn't
I just discovered that I've been incorrectly using the "i" loop variable
in my patch, which is actually used by a track element loop at line 1718
in matroskadec.c. This will works as long as there is only video in the
Matroska file, that's why I didn't discover it until I tried one with
audio a
---
libavcodec/get_bits.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libavcodec/get_bits.h b/libavcodec/get_bits.h
index 0d3db1f..0a61c80 100644
--- a/libavcodec/get_bits.h
+++ b/libavcodec/get_bits.h
@@ -539,6 +539,17 @@ void ff_free_vlc(VLC *vlc);
index = SHOW_
Hello,
Its regarding ticket #5067(avformat:open): crash on Mapping Multicast TV
Stream to HLS with "Exactly one WebVTT stream is needed" as message
I have attached patch for hls not failing in condition where subtitles
streams are of bitmap type and ts containing data streams mapped to output
Am 13.12.2015 um 14:18 schrieb Moritz Barsnick:
> On Sun, Dec 13, 2015 at 11:54:32 +0100, Stefan Pöschel wrote:
>> So far an AC-3 elementary stream is refered to in the PMT according to
>> System A (ATSC). An E-AC-3 ES in contrast is embedded the System B (DVB) way.
>
> Interesting, that's apparen
On 12/13/2015 12:10 PM, Mats Peterson wrote:
On 12/13/2015 12:01 PM, Paul B Mahol wrote:
On 12/13/15, Mats Peterson wrote:
On 12/13/2015 11:06 AM, Paul B Mahol wrote:
On 12/13/15, Mats Peterson wrote:
On Sat, 12 Dec 2015, Paul B Mahol wrote:
On 12/12/15, Mats Peterson wrote:
On Sat, 12
On Sun, Dec 13, 2015 at 11:54:32 +0100, Stefan Pöschel wrote:
> So far an AC-3 elementary stream is refered to in the PMT according to
> System A (ATSC). An E-AC-3 ES in contrast is embedded the System B (DVB) way.
Interesting, that's apparently the reason why my (DVB-)PVR didn't ever
recognize AC
On 12/13/2015 12:10 PM, Mats Peterson wrote:
On 12/13/2015 12:01 PM, Paul B Mahol wrote:
Have you provided such several test filest to others?
In this directory are three sample Matroska files with QuickTime video
that will display with the wrong palette (none at all, really) without
the p
On 12/13/2015 12:01 PM, Paul B Mahol wrote:
On 12/13/15, Mats Peterson wrote:
On 12/13/2015 11:06 AM, Paul B Mahol wrote:
On 12/13/15, Mats Peterson wrote:
On Sat, 12 Dec 2015, Paul B Mahol wrote:
On 12/12/15, Mats Peterson wrote:
On Sat, 12 Dec 2015, Michael Niedermayer wrote:
On Sat,
On 12/13/15, Mats Peterson wrote:
> On 12/13/2015 11:06 AM, Paul B Mahol wrote:
>> On 12/13/15, Mats Peterson wrote:
>>> On Sat, 12 Dec 2015, Paul B Mahol wrote:
>>>
On 12/12/15, Mats Peterson wrote:
> On Sat, 12 Dec 2015, Michael Niedermayer wrote:
>
>> On Sat, Dec 12, 2015 at
So far an AC-3 elementary stream is refered to in the PMT according to
System A (ATSC). An E-AC-3 ES in contrast is embedded the System B (DVB) way.
To fix this inconsistency, this commit changes the default E-AC-3 behaviour to
use the ATSC way, too. Furthermore a new flag is added to optionally se
On 12/13/2015 11:06 AM, Paul B Mahol wrote:
On 12/13/15, Mats Peterson wrote:
On Sat, 12 Dec 2015, Paul B Mahol wrote:
On 12/12/15, Mats Peterson wrote:
On Sat, 12 Dec 2015, Michael Niedermayer wrote:
On Sat, Dec 12, 2015 at 11:17:00AM +, Mats Peterson wrote:
Obviously that private d
On 12/13/15, Mats Peterson wrote:
> On Sat, 12 Dec 2015, Paul B Mahol wrote:
>
>> On 12/12/15, Mats Peterson wrote:
>>> On Sat, 12 Dec 2015, Michael Niedermayer wrote:
>>>
On Sat, Dec 12, 2015 at 11:17:00AM +, Mats Peterson wrote:
> Obviously that private data is cropped in some way
On Fri, Dec 04, 2015 at 09:03:05PM -0600, Rodger Combs wrote:
> This solves the problem discussed in
> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/179238.html
> by allowing AVCodec::write_header to be delayed until after packets have been
> run through required bitstream filters in or
On Sat, Oct 10, 2015 at 07:13:04PM +0200, Nicolas George wrote:
> Le nonidi 19 vendémiaire, an CCXXIV, wm4 a écrit :
> > This looks suspicious. Like some code above this does unclean tricks
> > with keeping side-data somehow referenced, instead of using proper
> > methods like creating a new AVPack
39 matches
Mail list logo
