On Fri, May 20, 2016 at 12:06:34AM +0200, Marton Balint wrote:
>
> On Thu, 19 May 2016, Nicolas George wrote:
>
> >Le tridi 23 floréal, an CCXXIV, Jan Sebechlebsky a écrit :
> >>My current idea is to create queue for each output (as Marton suggested) and
> >>process each output in separate
On Fri, May 20, 2016 at 04:27:17PM +0100, Ricardo Constantino wrote:
> On 20 May 2016 at 11:37, Michael Niedermayer wrote:
> > as one testing ffmpeg with openh264 (building at least)
> >
> > i have mixed feelings about this, it would cause me to drop further
> > testing
On Fri, May 20, 2016 at 08:04:28PM +0200, Paul B Mahol wrote:
> On 5/20/16, Michael Niedermayer wrote:
> > If acmax can be 0 then it could result in a division by 0
> > Fixes CID1351345
>
> But there is cast to double.
yes but the result (aa) is assigned to int (h) which
On 5/13/2016 6:48 AM, foo86 wrote:
> Values for unsupported frequencies > 48000 Hz are still included (parser
> will make use of them).
>
> Also convert sampling frequencies array to unsigned.
Applied.
___
ffmpeg-devel mailing list
On 5/13/2016 6:48 AM, foo86 wrote:
> Move this from separate structure field to a packet flag.
>
> Behavior should be equivalent, except that residual flag is now properly
> cleared when packet has no core frame at all.
>
> Also print a message when forcing recovery mode due to invalid residual
On 5/13/2016 6:10 PM, James Almer wrote:
> The header was never installed and the function is only used in libavformat
>
> Signed-off-by: James Almer
> ---
> libavformat/asfdec_f.c| 2 +-
> libavformat/asfdec_o.c| 2 +-
> libavformat/asfenc.c | 2 +-
>
On Fri, May 20, 2016 at 08:51:53PM -0300, James Almer wrote:
> "ffmpeg -i q4G.dts -c:a copy -f framecrc -" gave me the following
> before the patch
>
> #software: Lavf57.36.100
> #tb 0: 1/9
> #media_type 0: audio
> #codec_id 0: dts
> #sample_rate 0: 192000
> #channel_layout 0: 60f
> 0,
On 5/20/2016 8:28 PM, foo86 wrote:
> On Fri, May 20, 2016 at 04:46:31PM -0300, James Almer wrote:
>> On 5/20/2016 2:40 PM, foo86 wrote:
>>> On Fri, May 13, 2016 at 12:48:28PM +0300, foo86 wrote:
Parse core frame size directly when searching for frame end instead of
using value extracted
On Fri, May 20, 2016 at 04:46:31PM -0300, James Almer wrote:
> On 5/20/2016 2:40 PM, foo86 wrote:
> > On Fri, May 13, 2016 at 12:48:28PM +0300, foo86 wrote:
> >> Parse core frame size directly when searching for frame end instead of
> >> using value extracted from previous frame.
> >>
> >> Account
On Fri, May 20, 2016 at 09:32:43PM +0200, Paul B Mahol wrote:
> Hi,
>
> patch attached.
> sgirledec.c | 32 +++-
> 1 file changed, 7 insertions(+), 25 deletions(-)
> 72db54533a4087fed1e0ac1ebd537fe566f2ca87
>
---
libavcodec/nvenc.c | 308 +++--
1 file changed, 251 insertions(+), 57 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index d3856a4..cad554c 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -33,16 +33,31 @@
There is no point in separate structures as they have 1:1 relationship,
they are always used together and they have same lifetime.
---
libavcodec/nvenc.c | 196 -
1 file changed, 105 insertions(+), 91 deletions(-)
diff --git
Functions names and scopes are from libav. This commit basically moves
code around without changing it; it shouldn't change any functionality
except some small leak fixes on error paths.
---
libavcodec/nvenc.c | 1083 ++--
1 file changed, 622
On 5/20/2016 2:40 PM, foo86 wrote:
> On Fri, May 13, 2016 at 12:48:28PM +0300, foo86 wrote:
>> Parse core frame size directly when searching for frame end instead of
>> using value extracted from previous frame.
>>
>> Account for unused bits when calculating sync word distance for 14-bit
>>
Hi,
patch attached.
From da5353cd2d54de387bb1617c4fc58f919053bc43 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Fri, 20 May 2016 21:30:29 +0200
Subject: [PATCH] avcodec/sgirledec: simplify, no need to use reget buffer
Signed-off-by: Paul B Mahol
---
Hi,
patch attached.
From 36ea9fd3b3611d1946e3dd3f384b638fa079291e Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Fri, 20 May 2016 20:54:10 +0200
Subject: [PATCH] avcodec/aic: add frame threading support
Signed-off-by: Paul B Mahol
---
libavcodec/aic.c |
On 5/20/16, Umair Khan wrote:
> Hi,
>
> I'm working on implementing floating point support in the ALS decoder.
> In this I've to use masked LZ decompression. I've written the code for
> myself for masked lz decompression using the help from the reference
> software.
>
On 5/14/2016 3:08 PM, Michael Niedermayer wrote:
> On Sat, May 14, 2016 at 06:48:51PM +0300, foo86 wrote:
>> On Fri, May 13, 2016 at 12:00:24PM +0200, Hendrik Leppkes wrote:
>>> On Fri, May 13, 2016 at 11:48 AM, foo86 wrote:
Valid sample_fmt will be set by
On 5/20/16, Michael Niedermayer wrote:
> If acmax can be 0 then it could result in a division by 0
> Fixes CID1351345
But there is cast to double.
> Signed-off-by: Michael Niedermayer
> ---
> libavfilter/avf_ahistogram.c |2 +-
> 1 file
On 5/13/2016 6:48 AM, foo86 wrote:
> Most DTS-in-WAV streams trigger this, making debug output hard to read.
> ---
> libavcodec/dca_core.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/libavcodec/dca_core.c b/libavcodec/dca_core.c
> index f6c22ca..46825ed 100644
>
On Fri, May 13, 2016 at 12:48:28PM +0300, foo86 wrote:
> Parse core frame size directly when searching for frame end instead of
> using value extracted from previous frame.
>
> Account for unused bits when calculating sync word distance for 14-bit
> streams to avoid alias sync detection.
>
>
On 5/20/2016 10:13 AM, Christophe Gisquet wrote:
> Hi,
>
> 2016-05-20 15:09 GMT+02:00 foo86 :
>
>>> Not that the patch is not ok, but I have a few uneducated questions:
>>> 1) Given the get_bits_long(gb, k) afterwards, won't that code cause
>>> overreads for corrupted
Added more options for OpenH264 encoder
---
libavcodec/libopenh264enc.c | 60 +
1 file changed, 34 insertions(+), 26 deletions(-)
diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 24bc228..532cb5d 100644
---
If acmax can be 0 then it could result in a division by 0
Fixes CID1351345
Signed-off-by: Michael Niedermayer
---
libavfilter/avf_ahistogram.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/avf_ahistogram.c
On 20 May 2016 at 11:37, Michael Niedermayer wrote:
> as one testing ffmpeg with openh264 (building at least)
>
> i have mixed feelings about this, it would cause me to drop further
> testing with openh264 in all releases OR in git master
> because releases wont build with
bump
On 5/16/16, 2:15 PM, "ffmpeg-devel on behalf of Felt, Patrick"
wrote:
>This is a rework of the previously submitted patch to not require globals.
>I’ve also renamed variables per standard. Attached is the output of
Dana 20. 5. 2016. 15:21 osoba "Michael Niedermayer"
napisala je:
>
> On Fri, May 20, 2016 at 02:50:17PM +0200, Christophe Gisquet wrote:
> > Hi,
> >
> > 2016-05-20 2:38 GMT+02:00 Timothy Gu :
> > >> > Note how it has a list of specific violations,
bump
On 5/16/16, 9:28 AM, "ffmpeg-devel on behalf of Felt, Patrick"
wrote:
>bump
>
>On 5/12/16, 4:07 PM, "ffmpeg-devel on behalf of Felt, Patrick"
>
bump
On 5/16/16, 9:28 AM, "ffmpeg-devel on behalf of Felt, Patrick"
wrote:
>bump
>
>On 5/12/16, 4:07 PM, "ffmpeg-devel on behalf of Felt, Patrick"
>
On Fri, May 20, 2016 at 03:13:22PM +0200, Christophe Gisquet wrote:
> > This is for valid bitstreams. There is no indication of limit on maximum
> > Rice code length in the XLL spec, hence existing constant is not
> > strictly "valid" (but it always worked in practice with existing
> > encoders).
On Fri, May 20, 2016 at 02:50:17PM +0200, Christophe Gisquet wrote:
> Hi,
>
> 2016-05-20 2:38 GMT+02:00 Timothy Gu :
> >> > Note how it has a list of specific violations, instead of vague things
> >> > like
> >> > "Be excellent" that the FFmpeg one has.
> >> > Note how it
Hi,
2016-05-20 1:55 GMT+02:00 Lukasz Marek :
> Is Derek revoked to commit or what? Couldn't he just commit this patch and
> leave? :P I was a problem for some people, but I see they still have
> problems. Let people with problems go away with they problems.
Sorry if
On Fri, May 20, 2016 at 02:35:53PM +0200, Christophe Gisquet wrote:
> 2016-05-13 11:48 GMT+02:00 foo86 :
> > -unsigned int v = get_unary(gb, 1, 128);
> > +unsigned int v = get_unary(gb, 1, get_bits_left(gb));
>
> Not that the patch is not ok, but I have a few
Hi,
2016-05-18 20:40 GMT+02:00 Michael Niedermayer :
> Please state clearly if you agree to the text or if not.
> we can extend and tune it later and do another vote if there are more
> suggestions
I agree to having a CoC.
This text is a first step, so I'm ok with it,
Hi,
2016-05-20 2:38 GMT+02:00 Timothy Gu :
>> > Note how it has a list of specific violations, instead of vague things like
>> > "Be excellent" that the FFmpeg one has.
>> > Note how it has a huge section on disciplinary procedures.
[...]
> I have to agree with Kieran here.
On 5/20/16, Christophe Gisquet wrote:
> 2016-05-13 11:48 GMT+02:00 foo86 :
>> -unsigned int v = get_unary(gb, 1, 128);
>> +unsigned int v = get_unary(gb, 1, get_bits_left(gb));
>
> Not that the patch is not ok, but I have a few uneducated
2016-05-13 11:48 GMT+02:00 foo86 :
> -unsigned int v = get_unary(gb, 1, 128);
> +unsigned int v = get_unary(gb, 1, get_bits_left(gb));
Not that the patch is not ok, but I have a few uneducated questions:
1) Given the get_bits_long(gb, k) afterwards, won't that code
On 5/20/16, foo86 wrote:
> Ping.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
lgtm
___
ffmpeg-devel mailing list
Ping.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 5/5/16, Carl Eugen Hoyos wrote:
> Paul B Mahol gmail.com> writes:
>
>> >> There is clearly overread if you ignore
>> >> first two bytes.
>> >
>> > How can I reproduce the overread?
>>
>> By decoding file, looking at ffmpeg output.
>
> I did that and I don't see an overread:
avcodec_copy_context didn't handle hw_frames_ctx references correctly which
could cause crashes.
---
Changes from v1: reverted changes to avcodec_free_context
libavcodec/options.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavcodec/options.c b/libavcodec/options.c
index
On Mon, Mar 07, 2016 at 06:05:30PM +0100, Stefano Sabatini wrote:
> In particular, the slice mode API was changed in commit:
>
> commit 33c378f7b791310e4cb64b53e2bb8f3f3bded105
> Author: sijchen
> Date: Tue Nov 10 09:50:06 2015 -0800
>
> change API for slicing part for
42 matches
Mail list logo