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 easier usage (the Us
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 ea2
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:
> What do I miss?
Ping.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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
ffmpeg-devel@ffmpeg.org
http:
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 cause
overreads for corr
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 questions:
> 1) Given the get_bits_long(gb, k) afte
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. I believe that as a com
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, but hoping it will be impr
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 uneducated questions:
> 1) Giv
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 you felt ganged up on previou
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 bitstreams?
>
> This will cause overread, but that should not be a problem for checked
>
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 has a huge section on di
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). R
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"
> wrote:
>
>>I hang my head in shame. I neglected to notice that time wasn’t already
>>included and so I had to modify the patch. Apologies for
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"
> wrote:
>
>>I hang my head in shame. I neglected to notice that time wasn’t already
>>included and so I had to modify the patch. Apologies for
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, instead of vague
things like
> > >> > "Be excellen
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 git
>format-patch (let me know if I should just paste contents into the
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 git master of openh264 a
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 b/libavfilter/avf_ahistogram.c
index a716a96..ff94ad4
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
--- a/libavcodec/libop
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 bitstreams?
>>
>> This will
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.
>
> Pars
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 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 changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
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 dcadec_decode_frame() based on strea
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.
Although, I'm not yet sure if an implementation of masked LZ is
already t
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.
> Although, I'm not yet sure if
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 | 7 +--
1 file changed, 5 insertio
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
---
libavcodec/sgirledec.c | 32 +++-
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
>> streams
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 insert
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 a/libavcodec/nvenc.
---
libavcodec/nvenc.c | 187 ++---
1 file changed, 50 insertions(+), 137 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 19312dc..d3856a4 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -27,6 +27,7 @@
#include
---
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 @@
#include
On 5/20/16, Christophe Gisquet wrote:
> 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 pr
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
> 0001-avcodec-sgirledec-simplify-no-need-to-use-reget-bu
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 f
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/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 +-
> libavformat/avienc.c |
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: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
ffmpeg-devel@ffmpeg.
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 is undefined
behavior (i
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 with openh264 in all releas
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 thread
46 matches
Mail list logo
