Found one small bug in NVENC implementation.
The value of rc_lookahead is initialized to -1 but the check in nvenc.c checks
for (ctx->rc_lookahead) rather than (ctx->rc_lookahead > 0).
This results in incorrect consideration that lookahead is enabled all the time.
Please review this patch which u
On 12/26/16, James Almer wrote:
> It is now bitexact with the ssse3 and sse4.1 versions of the function.
>
> Signed-off-by: James Almer
> ---
> libavcodec/lossless_videodsp.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
OK if tested.
On 11/21/16, James Almer wrote:
> On 11/17/2016 3:52 PM, James Almer wrote:
>> On 11/2/2016 4:58 PM, James Almer wrote:
>>> This will allow us to write updated stream information not available
>>> during write_header().
>>>
>>> Signed-off-by: James Almer
>>> ---
>>> libavformat/matroskaenc.c | 2
It is now bitexact with the ssse3 and sse4.1 versions of the function.
Signed-off-by: James Almer
---
libavcodec/lossless_videodsp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/lossless_videodsp.c b/libavcodec/lossless_videodsp.c
index 3491621..231c25f 10
Signed-off-by: James Almer
---
The bug fixed by the previous patch can be also reproduced using yuv422p10.
tests/fate/vcodec.mak| 3 ++-
tests/ref/vsynth/vsynth1-ffvhuff422p12median | 4
tests/ref/vsynth/vsynth2-ffvhuff422p12median | 4
tests/ref/vsy
Signed-off-by: Michael Niedermayer
---
libavformat/matroskadec.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 58731aaaba..7e74348b2a 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -323
Hi,
On Sun, Dec 25, 2016 at 2:24 PM, Henrik Gramner wrote:
> When allocating stack space with an alignment requirement that is larger
> than the current stack alignment we need to store a copy of the original
> stack pointer in order to be able to restore it later.
>
> If we chose to use another
Dear All,
with use_localtime parameter hlsenc may produce identical filenames for
different but still existing segments. It happens when
hls_segment_filename contains
syntacticaly correct but inadequate format parameters. Currently there
is no any log message when such a situaton occurs but these
25.12.2016, 13:31, "Marton Balint" :
> On Sat, 24 Dec 2016, Ganesh Ajjanagadde wrote:
>
>> 24.12.2016, 20:00, "Marton Balint" :
>>> On Thu, 22 Dec 2016, gajja...@yandex.com wrote:
>>>
From: Ganesh Ajjanagadde
Fixes Ticket 5389.
Signed-off-by: Ganesh Ajjanagadde
>>
On Fri, 23 Dec 2016, Nicolas George wrote:
Le quintidi 25 frimaire, an CCXXV, Marton Balint a écrit :
Signed-off-by: Marton Balint
---
libavfilter/af_amerge.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
LGTM (I trust you tested it), sorry for the delay.
Yes, thanks
When allocating stack space with an alignment requirement that is larger
than the current stack alignment we need to store a copy of the original
stack pointer in order to be able to restore it later.
If we chose to use another register for this purpose we should not pick
eax/rax since it can be o
On Sat, 24 Dec 2016, Ganesh Ajjanagadde wrote:
24.12.2016, 20:00, "Marton Balint" :
On Thu, 22 Dec 2016, gajja...@yandex.com wrote:
From: Ganesh Ajjanagadde
Fixes Ticket 5389.
Signed-off-by: Ganesh Ajjanagadde
---
doc/ffplay.texi | 4
ffplay.c | 10 +-
2 files changed
On 12/25/2016 1:11 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Sat, Dec 24, 2016 at 9:29 AM, Paul B Mahol wrote:
>
>> On 12/24/16, Ronald S. Bultje wrote:
>>> Hi,
>>>
>>> On Sat, Dec 24, 2016 at 6:09 AM, Paul B Mahol wrote:
>>>
On 12/24/16, Ronald S. Bultje wrote:
> Hi,
>
> On F
Hi,
On Sat, Dec 24, 2016 at 9:29 AM, Paul B Mahol wrote:
> On 12/24/16, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Sat, Dec 24, 2016 at 6:09 AM, Paul B Mahol wrote:
> >
> >> On 12/24/16, Ronald S. Bultje wrote:
> >> > Hi,
> >> >
> >> > On Fri, Dec 23, 2016 at 6:18 PM, James Almer
> wrote:
>
On Sun, Dec 25, 2016 at 11:44:07AM +0100, Nicolas George wrote:
> Le quintidi 5 nivôse, an CCXXV, Michael Niedermayer a écrit :
> > Whats your oppinion on using a explicit av_assert1() in the calling
> > code for this ? (i assume it can be done easily&cleanly)
> >
> > It would explicitly in C code
On Sun, Dec 25, 2016 at 11:34:16AM +0100, Nicolas George wrote:
> Le quintidi 5 nivôse, an CCXXV, Michael Niedermayer a écrit :
> > after one quick pass looking through this i have mainly one request
> > please seperate functions intended to be used by filters from functions
> > intended to be used
Le quintidi 5 nivôse, an CCXXV, Michael Niedermayer a écrit :
> Whats your oppinion on using a explicit av_assert1() in the calling
> code for this ? (i assume it can be done easily&cleanly)
>
> It would explicitly in C code say what is meant, while a
> "_sure" requires additional knowledge specif
Le quintidi 5 nivôse, an CCXXV, Michael Niedermayer a écrit :
> after one quick pass looking through this i have mainly one request
> please seperate functions intended to be used by filters from functions
> intended to be used by the core. Maybe by using 2 seperate headers.
I had started to do th
Le quartidi 4 nivôse, an CCXXV, Michael Niedermayer a écrit :
> My oppinion is that If we intend to have AVFilterLink public in the
> future then making it private now is a bad idea and wasted time.
Something I just remembered:
With the prospect of inter-filters threading, it is better if even ou
19 matches
Mail list logo
