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
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 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
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
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
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 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
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
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 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
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
>>
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
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
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
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
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
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
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.
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
19 matches
Mail list logo
