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 our own filters do not access links directly, because then it is only necessary to add synchronization in the helper functions. What about moving the definition in its own header? For compatibility at the beginning, this header can be included by avfilter.h, but then it can either be made private or stay there to be included by the parts of the code that really need it. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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 that with the name of the functions: The ff_link_* functions are meant to be used by filters. Now, I realize I would like to rename them ff_inlink_* for the ones in this patch series, that are used by the filters on their input links, and call ff_outlink_* the ones for their output links. The *_to_filter functions are the implementation of the default activate callback, i.e. the callback that wraps the current filter_frame / request_frame callbacks. This is not entirely consistent, I should probably make a few cosmetic patches to rename them and group them. I suppose you have no objection to having functions meant for filters used by the core too if they fit the need exactly? Do you have a suggested name for a separate header? > People writing filters need to know which functions they can use and > which they dont need to know of As for that, I also intend to rewrite most of doc/filter_design.txt once I have a reasonably clear view of the final shape, i.e. when at least a few filters are written in the new design. A lot of it is long obsolete anyway. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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&cleanly) > > It would explicitly in C code say what is meant, while a > "_sure" requires additional knowledge specific to lavfi You mean, in the caller, instead of: ret = ff_link_consume_frame_sure(link, &frame); write: ret = ff_link_consume_frame(link, &frame); av_assert1(ret >= 0); Well, it loses us the property that ff_link_consume_frame_sure() cannot fail at all (ff_link_consume_samples_sure() can, because it allocates memory) and thus do not require getting the return value at all. But I was not sure I wanted to make this a promise anyway. Also, it adds extra tests: one in the code, one in consume() instead of just one in the code (not counting the asserts, only present in debug builds). But that is just my premature optimizer side talking. Apart from that I am ok with it. It just requires documentation that this is the recommended idiom. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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 used by the core. Maybe by using 2 seperate headers. > > I had started to do that with the name of the functions: > > The ff_link_* functions are meant to be used by filters. Now, I realize > I would like to rename them ff_inlink_* for the ones in this patch > series, that are used by the filters on their input links, and call > ff_outlink_* the ones for their output links. > > The *_to_filter functions are the implementation of the default activate > callback, i.e. the callback that wraps the current filter_frame / > request_frame callbacks. This is not entirely consistent, I should > probably make a few cosmetic patches to rename them and group them. > > I suppose you have no objection to having functions meant for filters > used by the core too if they fit the need exactly? no objection > > Do you have a suggested name for a separate header? hmm, maybe core.h or lavfi_core.h and filters.h maybe spliting it up into more headers will make sense, i dont know [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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&cleanly) > > > > It would explicitly in C code say what is meant, while a > > "_sure" requires additional knowledge specific to lavfi > > You mean, in the caller, instead of: > > ret = ff_link_consume_frame_sure(link, &frame); > > write: > > ret = ff_link_consume_frame(link, &frame); > av_assert1(ret >= 0); yes, something like that (or a av_assert1(ret != AVERROR_OUT_OF_FUEL) > > Well, it loses us the property that ff_link_consume_frame_sure() cannot > fail at all (ff_link_consume_samples_sure() can, because it allocates > memory) and thus do not require getting the return value at all. But I > was not sure I wanted to make this a promise anyway. > > Also, it adds extra tests: one in the code, one in consume() instead of > just one in the code (not counting the asserts, only present in debug > builds). But that is just my premature optimizer side talking. its premature too but if we have expensive checks we could cache the result in the link [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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:
> >> > Hi,
> >> >
> >> > On Fri, Dec 23, 2016 at 6:18 PM, James Almer
> wrote:
> >> >
> >> >> On 12/23/2016 8:00 PM, Ronald S. Bultje wrote:
> >> >> > Hi,
> >> >> >
> >> >> > On Fri, Dec 23, 2016 at 12:32 PM, Paul B Mahol
> >> wrote:
> >> >> >
> >> >> >> diff --git a/libavcodec/lossless_videodsp.h
> b/libavcodec/lossless_
> >> >> >> videodsp.h
> >> >> >>
> >> >> > [..]
> >> >> >
> >> >> >> @@ -32,6 +32,7 @@ typedef struct LLVidDSPContext {
> >> >> >>
> >> >> > [..]
> >> >> >
> >> >> >> +void (*add_magy_median_pred_int16)(uint16_t *dst, const
> >> uint16_t
> >> >> >> *top, const uint16_t *diff, unsigned mask, int w, int *left, int
> >> >> *left_top);
> >> >> >>
> >> >> >
> >> >> > That seems wrong. Why would you add a magicuv-specific function to
> >> >> > losslessdsp-context which is intended for functions shared between
> >> many
> >> >> > (not just one) lossless codecs? You probably want a new dsp for
> >> magicyuv
> >> >> > specifically.
> >> >> >
> >> >> > I know this is tedious, but we're very specifically trying to
> prevent
> >> >> > dsputil from ever happening again.
> >> >> >
> >> >> > Ronald
> >> >>
> >> >> Some functions in this dsp are used only by huffyuv. Only one is used
> >> >> by
> >> >> both huffyuv and magicyuv.
> >> >> To properly apply what you mention, it would need to be split in two,
> >> >> huffyuvdsp and lldsp, then this new function added to a new dsp
> called
> >> >> magicyuvdsp.
> >> >
> >> >
> >> > That would be even better, yes.
> >>
> >> What about yasm code?
> >>
> >> I wanted that to be commented.
> >
> >
> > It's like dithering, it uses the immediately adjacent pixel in the next
> > loop iteration, can you really simd this effectively?
>
> Apparently, and someone is making money from it.
The parallelizable portion of it is the top-topleft, and you seem to do
that already. Other than that, I don't see much to be done. You can
probably use some mmxext instructions like pshufw to make life easier, but
I think you'll always be limited by the inherent limitation.
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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 12/24/16, Ronald S. Bultje wrote:
> Hi,
>
> On Fri, Dec 23, 2016 at 6:18 PM, James Almer
>> wrote:
>
>> On 12/23/2016 8:00 PM, Ronald S. Bultje wrote:
>>> Hi,
>>>
>>> On Fri, Dec 23, 2016 at 12:32 PM, Paul B Mahol
wrote:
>>>
diff --git a/libavcodec/lossless_videodsp.h
>> b/libavcodec/lossless_
videodsp.h
>>> [..]
>>>
@@ -32,6 +32,7 @@ typedef struct LLVidDSPContext {
>>> [..]
>>>
+void (*add_magy_median_pred_int16)(uint16_t *dst, const
uint16_t
*top, const uint16_t *diff, unsigned mask, int w, int *left, int
>> *left_top);
>>>
>>> That seems wrong. Why would you add a magicuv-specific function to
>>> losslessdsp-context which is intended for functions shared between
many
>>> (not just one) lossless codecs? You probably want a new dsp for
magicyuv
>>> specifically.
>>>
>>> I know this is tedious, but we're very specifically trying to
>> prevent
>>> dsputil from ever happening again.
>>>
>>> Ronald
>>
>> Some functions in this dsp are used only by huffyuv. Only one is used
>> by
>> both huffyuv and magicyuv.
>> To properly apply what you mention, it would need to be split in two,
>> huffyuvdsp and lldsp, then this new function added to a new dsp
>> called
>> magicyuvdsp.
>
>
> That would be even better, yes.
What about yasm code?
I wanted that to be commented.
>>>
>>>
>>> It's like dithering, it uses the immediately adjacent pixel in the next
>>> loop iteration, can you really simd this effectively?
>>
>> Apparently, and someone is making money from it.
>
>
> The parallelizable portion of it is the top-topleft, and you seem to do
> that already. Other than that, I don't see much to be done. You can
> probably use some mmxext instructions like pshufw to make life easier, but
> I think you'll always be limited by the inherent limitation.
>
> Ronald
He can turn the movq + psrlq + psllq + por at the end of the loop into two
movq + palignr for an ssse3 version of the function (still using mmx regs),
but not much more than that i guess.
And even that will probably not make a noticeable difference, assuming it's
actually faster.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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
---
doc/ffplay.texi | 4
ffplay.c | 10 +-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/doc/ffplay.texi b/doc/ffplay.texi
index 073b457256..378a229d67 100644
--- a/doc/ffplay.texi
+++ b/doc/ffplay.texi
@@ -62,6 +62,10 @@ see @ref{time duration syntax,,the Time duration section in
the ffmpeg-utils(1)
Seek by bytes.
@item -nodisp
Disable graphical display.
+@item -volume
+Set the startup volume. 0 means silence, 100 means no volume reduction or
+amplification. Negative values are treated as 0, values above 100 are treated
+as 100.
@item -f @var{fmt}
Force format.
@item -window_title @var{title}
diff --git a/ffplay.c b/ffplay.c
index 911fd7f947..de603c0a27 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -322,6 +322,7 @@ static int subtitle_disable;
static const char* wanted_stream_spec[AVMEDIA_TYPE_NB] = {0};
static int seek_by_bytes = -1;
static int display_disable;
+static int startup_volume = 100;
static int show_status = 1;
static int av_sync_type = AV_SYNC_AUDIO_MASTER;
static int64_t start_time = AV_NOPTS_VALUE;
@@ -3105,7 +3106,13 @@ static VideoState *stream_open(const char *filename,
AVInputFormat *iformat)
init_clock(&is->audclk, &is->audioq.serial);
init_clock(&is->extclk, &is->extclk.serial);
is->audio_clock_serial = -1;
- is->audio_volume = SDL_MIX_MAXVOLUME;
+ if (startup_volume < 0)
+ av_log(NULL, AV_LOG_WARNING, "-volume=%d < 0, setting to 0\n",
startup_volume);
+ if (startup_volume > 100)
+ av_log(NULL, AV_LOG_WARNING, "-volume=%d > 100, setting to 100\n",
startup_volume);
+ startup_volume = av_clip(startup_volume, 0, 100);
+ startup_volume = av_clip(SDL_MIX_MAXVOLUME * startup_volume / 100.0, 0,
SDL_MIX_MAXVOLUME);
Any reason you use 100.0 here instead of a simple integer (100)?
Nothing really, I assumed (incorrectly) that double to int cast does rounding
instead of truncation,
which happens with integer division.
On the other hand, the difference here between rounding and truncation is < 1%.
Whatever you prefer, i.e can lrint it to get better rounding, or change to 100
and not bother.
I'd simply use 100 and not bother.
Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[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 overwritten as a return value. --- libavutil/x86/x86inc.asm | 7 +++ 1 file changed, 7 insertions(+) diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm index b2e9c60..128ddc1 100644 --- a/libavutil/x86/x86inc.asm +++ b/libavutil/x86/x86inc.asm @@ -385,7 +385,14 @@ DECLARE_REG_TMP_SIZE 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14 %ifnum %1 %if %1 != 0 && required_stack_alignment > STACK_ALIGNMENT %if %1 > 0 +; Reserve an additional register for storing the original stack pointer, but avoid using +; eax/rax for this purpose since it can potentially get overwritten as a return value. %assign regs_used (regs_used + 1) +%if ARCH_X86_64 && regs_used == 7 +%assign regs_used 8 +%elif ARCH_X86_64 == 0 && regs_used == 1 +%assign regs_used 2 +%endif %endif %if ARCH_X86_64 && regs_used < 5 + UNIX64 * 3 ; Ensure that we don't clobber any registers containing arguments. For UNIX64 we also preserve r6 (rax) -- 2.7.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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 delay. Yes, thanks, pushed. Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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 5389.
Signed-off-by: Ganesh Ajjanagadde
---
doc/ffplay.texi | 4
ffplay.c | 10 +-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/doc/ffplay.texi b/doc/ffplay.texi
index 073b457256..378a229d67 100644
--- a/doc/ffplay.texi
+++ b/doc/ffplay.texi
@@ -62,6 +62,10 @@ see @ref{time duration syntax,,the Time duration
section in the ffmpeg-utils(1)
Seek by bytes.
@item -nodisp
Disable graphical display.
+@item -volume
+Set the startup volume. 0 means silence, 100 means no volume reduction
or
+amplification. Negative values are treated as 0, values above 100 are
treated
+as 100.
@item -f @var{fmt}
Force format.
@item -window_title @var{title}
diff --git a/ffplay.c b/ffplay.c
index 911fd7f947..de603c0a27 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -322,6 +322,7 @@ static int subtitle_disable;
static const char* wanted_stream_spec[AVMEDIA_TYPE_NB] = {0};
static int seek_by_bytes = -1;
static int display_disable;
+static int startup_volume = 100;
static int show_status = 1;
static int av_sync_type = AV_SYNC_AUDIO_MASTER;
static int64_t start_time = AV_NOPTS_VALUE;
@@ -3105,7 +3106,13 @@ static VideoState *stream_open(const char
*filename, AVInputFormat *iformat)
init_clock(&is->audclk, &is->audioq.serial);
init_clock(&is->extclk, &is->extclk.serial);
is->audio_clock_serial = -1;
- is->audio_volume = SDL_MIX_MAXVOLUME;
+ if (startup_volume < 0)
+ av_log(NULL, AV_LOG_WARNING, "-volume=%d < 0, setting to 0\n",
startup_volume);
+ if (startup_volume > 100)
+ av_log(NULL, AV_LOG_WARNING, "-volume=%d > 100, setting to 100\n",
startup_volume);
+ startup_volume = av_clip(startup_volume, 0, 100);
+ startup_volume = av_clip(SDL_MIX_MAXVOLUME * startup_volume / 100.0,
0, SDL_MIX_MAXVOLUME);
>>>
>>> Any reason you use 100.0 here instead of a simple integer (100)?
>>
>> Nothing really, I assumed (incorrectly) that double to int cast does
>> rounding instead of truncation,
>> which happens with integer division.
>> On the other hand, the difference here between rounding and truncation is <
>> 1%.
>> Whatever you prefer, i.e can lrint it to get better rounding, or change to
>> 100 and not bother.
>
> I'd simply use 100 and not bother.
Pushed, thanks.
>
> Thanks,
> Marton
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[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 these cases should
be avoided in most times. This patch generate warning log messages in these
cases.
best regards,
bb
>From 7055e0b0bec3fee61373dd446bcab24d15117b7e Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Mon, 26 Dec 2016 02:00:49 +0100
Subject: [PATCH] avformat/hlsenc: detecting duplicated segment filenames
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 cases should
be avoided in most times. This patch generate warning messages in these
cases.
Signed-off-by: Bela Bodecs
---
libavformat/hlsenc.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index acf3a30..11ec3b8 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -653,6 +653,38 @@ fail:
return ret;
}
+static HLSSegment * find_segment_by_filename(HLSSegment * segment, const char * filename)
+{
+/* filename may contain rel/abs path, but segments store only basename */
+char *p, *dirname, *path;
+int path_size;
+HLSSegment *ret_segment = NULL;
+dirname = av_strdup(filename);
+if (!dirname)
+return NULL;
+p = (char *)av_basename(dirname); // av_dirname would return . in case of no dir
+*p = '\0'; // maybe empty
+
+while (segment) {
+path_size = strlen(dirname) + strlen(segment->filename) + 1;
+path = av_malloc(path_size);
+if (!path)
+goto end;
+av_strlcpy(path, dirname, path_size);
+av_strlcat(path, segment->filename, path_size);
+if (!strcmp(path,filename)) {
+ret_segment = segment;
+av_free(path);
+goto end;
+}
+av_free(path);
+segment = segment->next;
+}
+end:
+av_free(dirname);
+return ret_segment;
+}
+
static int hls_start(AVFormatContext *s)
{
HLSContext *c = s->priv_data;
@@ -685,6 +717,8 @@ static int hls_start(AVFormatContext *s)
av_log(oc, AV_LOG_ERROR, "Could not get segment filename with use_localtime\n");
return AVERROR(EINVAL);
}
+if (find_segment_by_filename(c->segments, oc->filename) || find_segment_by_filename(c->old_segments, oc->filename))
+av_log(c, AV_LOG_WARNING, "Duplicated segment filename detected: %s\n",oc->filename);
if (c->use_localtime_mkdir) {
const char *dir;
--
2.5.3.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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 chose to use another register for this purpose we should not pick > eax/rax since it can be overwritten as a return value. > --- > libavutil/x86/x86inc.asm | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm > index b2e9c60..128ddc1 100644 > --- a/libavutil/x86/x86inc.asm > +++ b/libavutil/x86/x86inc.asm > @@ -385,7 +385,14 @@ DECLARE_REG_TMP_SIZE 0,1,2,3,4,5,6,7,8,9,10,11,12, > 13,14 > %ifnum %1 > %if %1 != 0 && required_stack_alignment > STACK_ALIGNMENT > %if %1 > 0 > +; Reserve an additional register for storing the original > stack pointer, but avoid using > +; eax/rax for this purpose since it can potentially get > overwritten as a return value. > %assign regs_used (regs_used + 1) > +%if ARCH_X86_64 && regs_used == 7 > +%assign regs_used 8 > +%elif ARCH_X86_64 == 0 && regs_used == 1 > +%assign regs_used 2 > +%endif > %endif > %if ARCH_X86_64 && regs_used < 5 + UNIX64 * 3 > ; Ensure that we don't clobber any registers containing > arguments. For UNIX64 we also preserve r6 (rax) > -- > 2.7.4 I know I'm terribly nitpicking here for the limited scope of the comment, but this only matters for functions that have a return value. Do you think it makes sense to allow functions to opt out of this requirement if they explicitly state to not have a return value? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[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
+++ b/libavformat/matroskadec.c
@@ -3234,9 +3234,11 @@ static int matroska_parse_block(MatroskaDemuxContext
*matroska, uint8_t *data,
if (track->type == MATROSKA_TRACK_TYPE_SUBTITLE &&
timecode < track->end_timecode)
is_keyframe = 0; /* overlapping subtitles are not key frame */
-if (is_keyframe)
+if (is_keyframe) {
+ff_reduce_index(matroska->ctx, st->index);
av_add_index_entry(st, cluster_pos, timecode, 0, 0,
AVINDEX_KEYFRAME);
+}
}
if (matroska->skip_to_keyframe &&
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[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 tests/ref/vsynth/vsynth3-ffvhuff422p12median | 4 tests/ref/vsynth/vsynth_lena-ffvhuff422p12median | 4 5 files changed, 18 insertions(+), 1 deletion(-) create mode 100644 tests/ref/vsynth/vsynth1-ffvhuff422p12median create mode 100644 tests/ref/vsynth/vsynth2-ffvhuff422p12median create mode 100644 tests/ref/vsynth/vsynth3-ffvhuff422p12median create mode 100644 tests/ref/vsynth/vsynth_lena-ffvhuff422p12median diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak index a51f16c..b2ab09d 100644 --- a/tests/fate/vcodec.mak +++ b/tests/fate/vcodec.mak @@ -163,10 +163,11 @@ fate-vsynth%-ffv1-v3-rgb48: ENCOPTS = -level 3 -pix_fmt rgb48 -strict -2 \ -sws_flags neighbor+bitexact fate-vsynth%-ffv1-v3-rgb48: DECOPTS = -sws_flags neighbor+bitexact -FATE_VCODEC-$(call ENCDEC, FFVHUFF, AVI) += ffvhuff ffvhuff444 ffvhuff420p12 ffvhuff422p10left ffvhuff444p16 +FATE_VCODEC-$(call ENCDEC, FFVHUFF, AVI) += ffvhuff ffvhuff444 ffvhuff420p12 ffvhuff422p10left ffvhuff422p12median ffvhuff444p16 fate-vsynth%-ffvhuff444: ENCOPTS = -vcodec ffvhuff -pix_fmt yuv444p fate-vsynth%-ffvhuff420p12: ENCOPTS = -vcodec ffvhuff -pix_fmt yuv420p12le fate-vsynth%-ffvhuff422p10left: ENCOPTS = -vcodec ffvhuff -pix_fmt yuv422p10le -pred left +fate-vsynth%-ffvhuff422p12median:ENCOPTS = -vcodec ffvhuff -pix_fmt yuv422p12le -pred median fate-vsynth%-ffvhuff444p16: ENCOPTS = -vcodec ffvhuff -pix_fmt yuv444p16le -pred plane FATE_VCODEC-$(call ENCDEC, FLASHSV, FLV) += flashsv diff --git a/tests/ref/vsynth/vsynth1-ffvhuff422p12median b/tests/ref/vsynth/vsynth1-ffvhuff422p12median new file mode 100644 index 000..00fbb42 --- /dev/null +++ b/tests/ref/vsynth/vsynth1-ffvhuff422p12median @@ -0,0 +1,4 @@ +ec0bfc1827c605744343f9a43950e52d *tests/data/fate/vsynth1-ffvhuff422p12median.avi +16377468 tests/data/fate/vsynth1-ffvhuff422p12median.avi +30158648597626fcd62e4d484ab3c91f *tests/data/fate/vsynth1-ffvhuff422p12median.out.rawvideo +stddev:1.84 PSNR: 42.80 MAXDIFF: 29 bytes: 7603200/ 7603200 diff --git a/tests/ref/vsynth/vsynth2-ffvhuff422p12median b/tests/ref/vsynth/vsynth2-ffvhuff422p12median new file mode 100644 index 000..6e28101 --- /dev/null +++ b/tests/ref/vsynth/vsynth2-ffvhuff422p12median @@ -0,0 +1,4 @@ +7f5d06ee194e0d11af7c074513713a9e *tests/data/fate/vsynth2-ffvhuff422p12median.avi +12300372 tests/data/fate/vsynth2-ffvhuff422p12median.avi +a2a42106efee207fd76b32908d05bd5c *tests/data/fate/vsynth2-ffvhuff422p12median.out.rawvideo +stddev:0.39 PSNR: 56.23 MAXDIFF:9 bytes: 7603200/ 7603200 diff --git a/tests/ref/vsynth/vsynth3-ffvhuff422p12median b/tests/ref/vsynth/vsynth3-ffvhuff422p12median new file mode 100644 index 000..6203520 --- /dev/null +++ b/tests/ref/vsynth/vsynth3-ffvhuff422p12median @@ -0,0 +1,4 @@ +f150723812124a617abeeb162c0cc106 *tests/data/fate/vsynth3-ffvhuff422p12median.avi +203188 tests/data/fate/vsynth3-ffvhuff422p12median.avi +975a9ed50959f5997874c8b2860519a3 *tests/data/fate/vsynth3-ffvhuff422p12median.out.rawvideo +stddev:2.12 PSNR: 41.59 MAXDIFF: 26 bytes:86700/86700 diff --git a/tests/ref/vsynth/vsynth_lena-ffvhuff422p12median b/tests/ref/vsynth/vsynth_lena-ffvhuff422p12median new file mode 100644 index 000..65b20a5 --- /dev/null +++ b/tests/ref/vsynth/vsynth_lena-ffvhuff422p12median @@ -0,0 +1,4 @@ +8366a0f7a1b87774d5b1fdfdcf9ced73 *tests/data/fate/vsynth_lena-ffvhuff422p12median.avi +12182440 tests/data/fate/vsynth_lena-ffvhuff422p12median.avi +5f581c9df94c98eca3297c33eb8271e7 *tests/data/fate/vsynth_lena-ffvhuff422p12median.out.rawvideo +stddev:0.33 PSNR: 57.53 MAXDIFF:6 bytes: 7603200/ 7603200 -- 2.10.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[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 3491621..231c25f 100644 --- a/libavcodec/lossless_videodsp.c +++ b/libavcodec/lossless_videodsp.c @@ -100,15 +100,15 @@ static int add_hfyu_left_pred_int16_c(uint16_t *dst, const uint16_t *src, unsign for(i=0; ihttp://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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 >>> --- >>> libavformat/matroskaenc.c | 20 +++- >>> 1 file changed, 15 insertions(+), 5 deletions(-) >>> >> >> Ping for patchset. Will be pushing it soon otherwise. > > Pushed. This made regression, ticket #5977. Thank's ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[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 updates this check. Thanks Ruta --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- 0001-NVENC-Update-check-for-Lookahead.patch Description: 0001-NVENC-Update-check-for-Lookahead.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
