[FFmpeg-devel] [PATCH] NVENC: Update check for Lookahead

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/lossless_videodsp: fix output of add_hfyu_left_pred_int16_c()

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.

Re: [FFmpeg-devel] [PATCH 1/2] avformat/matroskaenc: postpone writing the Tracks master

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 >>>

[FFmpeg-devel] [PATCH 1/2] avcodec/lossless_videodsp: fix output of add_hfyu_left_pred_int16_c()

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

[FFmpeg-devel] [PATCH 2/2] fate: add yuv422p12 median prediction ffhuff test

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

[FFmpeg-devel] [PATCH] avformat/matroskadec: Fix OOM on long streams

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 +++

Re: [FFmpeg-devel] [libav-devel] [PATCH] x86inc: Avoid using eax/rax for storing the stack pointer

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

[FFmpeg-devel] [PATCH] avformat/hlsenc: detecting duplicated segment filenames

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

Re: [FFmpeg-devel] [PATCH] ffplay: add startup volume option

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

Re: [FFmpeg-devel] [PATCH 1/2] avfilter/af_amerge: properly handle unknown input layouts

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

[FFmpeg-devel] [PATCH] x86inc: Avoid using eax/rax for storing the stack pointer

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

Re: [FFmpeg-devel] [PATCH] ffplay: add startup volume option

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  ---  

Re: [FFmpeg-devel] [PATCH] avcodec/magicyuv: add SIMD for median of 10bits

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

Re: [FFmpeg-devel] [PATCH] avcodec/magicyuv: add SIMD for median of 10bits

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: > >>

Re: [FFmpeg-devel] [PATCH 08/17] lavfi: add helpers to consume frames from link FIFOs.

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) > > > > It would explicitly in C code say

Re: [FFmpeg-devel] lavfi: introduce a new way of designing filters

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

Re: [FFmpeg-devel] [PATCH 08/17] lavfi: add helpers to consume frames from link FIFOs.

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) > > It would explicitly in C code say what is meant, while a > "_sure" requires additional knowledge specific to

Re: [FFmpeg-devel] lavfi: introduce a new way of designing filters

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

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

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