On 6/23/17, Mike Versteeg wrote:
> Hi!
>
> For the last couple of days I have been trying to get FFmpeg to loop a
> video with audio, but both the stream_loop option and loop filter have
> a bug. Since stream_loop is the most efficient of the two (and almost
> works), that one is my favourite. Can
Its been deprecated for over 3 years.
Signed-off-by: Paul B Mahol
---
libavfilter/vf_overlay.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
index adbf633..beb61c1 100644
--- a/libavfilter/vf_overlay.c
+++ b/libavfilter/vf_overlay.c
On Mon, Jun 19, 2017 at 10:48:15PM +0100, Mark Thompson wrote:
> On 19/06/17 16:32, Michael Niedermayer wrote:
> > On Sun, Jun 18, 2017 at 11:09:23PM +0100, Mark Thompson wrote:
> >> Before this, output bitstream filters would never see EOF and
> >> therefore would not be able to flush any delayed
On Thu, Jun 22, 2017 at 11:28:00PM +0200, Marton Balint wrote:
> If flushing is not disabled, then mux.c will signal the end of the packets
> with
> an AVIO_DATA_MARKER_FLUSH_POINT, and aviobuf will be able to decide to flush
> or
> not based on the preferred minimum packet size set by the used p
Hi,
On Fri, Jun 23, 2017 at 9:16 PM, Michael Niedermayer wrote:
> On Fri, Jun 23, 2017 at 11:02:07AM -0400, Ronald S. Bultje wrote:
> > ---
> > libavfilter/x86/vf_spp.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
>
> LGTM
Pushed.
Ronald
__
Hi,
On Tue, Jun 20, 2017 at 7:13 PM, Michael Niedermayer wrote:
> On Mon, Jun 19, 2017 at 05:11:03PM +0200, James Darnley wrote:
> > Includes add/put functions
> >
> > Rounding contributed by Ronald S. Bultje
> > ---
> > libavcodec/tests/x86/dct.c| 2 +
> > libavcodec/x86/idctd
Fixes: runtime error: left shift of 1965559808 by 4 places cannot be
represented in type 'int'
Fixes: 2333/clusterfuzz-testcase-minimized-5223935677300736
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
Signed-off-by: Michael Niedermayer
---
libavcodec/hevcdec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 83130fc48f..f4114fd993 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -2419,9 +2419,9 @@ static in
libvorbis comes with pkg-config files since at least v1.0.1, way back
in 2003.
---
The previous patches weren't parsed by patchwork, and it makes less
sense to have a fallback for libvorbis since the .pc file is available
since 2003.
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Hi,
On Mon, Jun 19, 2017 at 11:11 AM, James Darnley wrote:
> They now match according to FATE, barring any further bugs with untested
> parts
> ---
> libavcodec/x86/idctdsp_init.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
LGTM.
Ronald
_
On 6/24/17, Michael Niedermayer wrote:
> Fixes: runtime error: left shift of 1965559808 by 4 places cannot be
> represented in type 'int'
> Fixes: 2333/clusterfuzz-testcase-minimized-5223935677300736
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects
On 6/24/17, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/hevcdec.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman
On Tue, Jun 20, 2017 at 07:59:26PM +0200, Paul B Mahol wrote:
> On 12/24/16, Nicolas George wrote:
> > Le quartidi 4 nivose, an CCXXV, Michael Niedermayer a ecrit :
> >> theres a change with "-af apad=pad_len=1 -shortest" (no -vframes)
> >> the file is not sharable, this change undoes the effe
On Sat, Jun 24, 2017 at 04:54:38PM +0200, Michael Niedermayer wrote:
> On Tue, Jun 20, 2017 at 07:59:26PM +0200, Paul B Mahol wrote:
> > On 12/24/16, Nicolas George wrote:
> > > Le quartidi 4 nivose, an CCXXV, Michael Niedermayer a ecrit :
> > >> theres a change with "-af apad=pad_len=1 -short
On 6/24/17, Michael Niedermayer wrote:
> On Sat, Jun 24, 2017 at 04:54:38PM +0200, Michael Niedermayer wrote:
>> On Tue, Jun 20, 2017 at 07:59:26PM +0200, Paul B Mahol wrote:
>> > On 12/24/16, Nicolas George wrote:
>> > > Le quartidi 4 nivose, an CCXXV, Michael Niedermayer a ecrit :
>> > >> there
On Sat, Jun 24, 2017 at 04:54:38PM +0200, Michael Niedermayer wrote:
> On Tue, Jun 20, 2017 at 07:59:26PM +0200, Paul B Mahol wrote:
> > On 12/24/16, Nicolas George wrote:
> > > Le quartidi 4 nivose, an CCXXV, Michael Niedermayer a ecrit :
> > >> theres a change with "-af apad=pad_len=1 -short
On Sat, Jun 24, 2017 at 05:12:34PM +0200, Paul B Mahol wrote:
> On 6/24/17, Michael Niedermayer wrote:
> > On Sat, Jun 24, 2017 at 04:54:38PM +0200, Michael Niedermayer wrote:
> >> On Tue, Jun 20, 2017 at 07:59:26PM +0200, Paul B Mahol wrote:
> >> > On 12/24/16, Nicolas George wrote:
> >> > > Le
On Sat, Jun 24, 2017 at 05:06:41PM +0200, Michael Niedermayer wrote:
> On Sat, Jun 24, 2017 at 04:54:38PM +0200, Michael Niedermayer wrote:
> > On Tue, Jun 20, 2017 at 07:59:26PM +0200, Paul B Mahol wrote:
> > > On 12/24/16, Nicolas George wrote:
> > > > Le quartidi 4 nivose, an CCXXV, Michael Nie
Le sextidi 6 messidor, an CCXXV, Paul B Mahol a écrit :
> The reverted commit breaks lot of filters and I failed to find fix,
> the only logical solution
It breaks a corner-case option of, indeed a lot of, filters. I have not
yet been able to track down the exact cause of the problem, I still have
On Fri, Jun 23, 2017 at 18:48:04 +0100, Rostislav Pehlivanov wrote:
> with the addition it'll define _GNU_SOURCE in the configure system,
Does setting _GNU_SOURCE have any implications on how other functions
work? Other than making this (and other unused functions) available.
> + check_func pthr
On Sat, Jun 24, 2017 at 17:54:50 +0200, Moritz Barsnick wrote:
> On Fri, Jun 23, 2017 at 18:48:04 +0100, Rostislav Pehlivanov wrote:
> > with the addition it'll define _GNU_SOURCE in the configure system,
>
> Does setting _GNU_SOURCE have any implications on how other functions
> work? Other than
On Fri, Jun 23, 2017 at 21:00:03 +0100, Rostislav Pehlivanov wrote:
> +#if HAVE_PTHREAD_SETNAME_NP && defined(__linux__)
> +#include
> +#endif
You're not using pthread_getname_np() on Linux, so perhaps you should
be checking for prctl() instead? And since pthread_getname_np()
apparently isn't ava
On 24/06/17 11:29, Michael Niedermayer wrote:
> On Mon, Jun 19, 2017 at 10:48:15PM +0100, Mark Thompson wrote:
>> On 19/06/17 16:32, Michael Niedermayer wrote:
>>> On Sun, Jun 18, 2017 at 11:09:23PM +0100, Mark Thompson wrote:
Before this, output bitstream filters would never see EOF and
On Sat, Jun 24, 2017, at 12:32 AM, Paul B Mahol wrote:
> Its been deprecated for over 3 years.
>
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/vf_overlay.c | 7 ---
> 1 file changed, 7 deletions(-)
Fine with me. Don't forget to remove the option from doc/filters.texi as
well.
__
Thank you Paul, sorry to hear that.
As for the issues I am having with the loop filter, please refer to
https://video.stackexchange.com/questions/21757/using-ffmpeg-loop-filter-makes-audio-disappear/21758
Mike/mobile
On Jun 24, 2017 09:14, "Paul B Mahol" wrote:
> On 6/23/17, Mike Versteeg wro
On Sat, 24 Jun 2017, Michael Niedermayer wrote:
On Thu, Jun 22, 2017 at 11:28:00PM +0200, Marton Balint wrote:
If flushing is not disabled, then mux.c will signal the end of the packets with
an AVIO_DATA_MARKER_FLUSH_POINT, and aviobuf will be able to decide to flush or
not based on the prefer
On Tue, Jun 20, 2017 at 07:56:40AM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Jun 19, 2017 at 11:11 AM, James Darnley wrote:
>
> > Created by Ronald S. Bultje
> > ---
> > libavcodec/x86/simple_idct10_template.asm | 38
> > +++
> > 1 file changed, 38 insertions(
On Mon, Jun 19, 2017 at 5:11 PM, James Darnley wrote:
> +por m1, m8, m13
> +por m1, m12
> +por m1, [blockq+ 16] ; { row[1] }[0-7]
> +por m1, [blockq+ 48] ; { row[3] }[0-7]
> +por m1, [blockq+ 80] ; { row[5] }[0-7]
> +por m1, [blockq
This is VMAF filter which requires Netflix's vmaf library installed,
but currently there is no library implementation in the Netflix's vmaf.
I will open a pull request soon to Netflix's vmaf for the library integration
code and provide a link in this thread.
After installing the Netflix's vmaf libr
On 6/24/17, Ashish Singh wrote:
> This is VMAF filter which requires Netflix's vmaf library installed,
> but currently there is no library implementation in the Netflix's vmaf.
> I will open a pull request soon to Netflix's vmaf for the library
> integration
> code and provide a link in this threa
On Mon, Jun 19, 2017 at 05:11:03PM +0200, James Darnley wrote:
> Includes add/put functions
>
> Rounding contributed by Ronald S. Bultje
> ---
> libavcodec/tests/x86/dct.c| 2 +
> libavcodec/x86/idctdsp_init.c | 23
> libavcodec/x86/simple_idct.h
sorry for this patch, I think I didn't merge it successfully.
On Sun, Jun 25, 2017 at 12:50 AM, Paul B Mahol wrote:
> On 6/24/17, Ashish Singh wrote:
> > This is VMAF filter which requires Netflix's vmaf library installed,
> > but currently there is no library implementation in the Netflix's vm
On Sat, Jun 24, 2017 at 04:25:17PM +0200, Paul B Mahol wrote:
> On 6/24/17, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/hevcdec.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
>
> lgtm
patchset applied
thx
[...]
--
Michael
This is VMAF filter which requires Netflix's vmaf library installed,
but currently there is no library implementation in the Netflix's vmaf.
I will open a pull request soon to Netflix's vmaf for the library integration
code and provide a link in this thread.
After installing the Netflix's vmaf libr
On Wed, Jun 14, 2017 at 11:01:42AM +0800, Jun Zhao wrote:
> put_bits.h | 35 +++
> 1 file changed, 35 insertions(+)
> 5481728acedf2dae1e92f972d7043033384a0ca2
> 0002-lavc-put_bits-Add-put_bits64-to-support-up-to-64-bit.patch
> From 703be162119f78e1815d1f3b23afb2
Hi, this is the pull request at Netflix's vmaf for library integration:
https://github.com/Netflix/vmaf/pull/90
On Sun, Jun 25, 2017 at 1:20 AM, Ashish Singh wrote:
> This is VMAF filter which requires Netflix's vmaf library installed,
> but currently there is no library implementation in the Ne
This is the second version of my work.
Nobody posted any benchmarks, so
the old code remains for this round too.
The proper PIC handling code is included.
Small cosmetics, e.g. using tmpY,
to separate (semantically) from the output outY.
Now the tmpX buffer is fixed at 256*sizeof(float) size
an
Hi,
On Sat, Jun 24, 2017 at 3:50 PM, Ashish Singh wrote:
> +typedef struct VMAFContext {
>
[..]
> +double curr_vmaf_score;
>
Unused.
> +uint64_t nb_frames;
>
Unused.
> +pthread_attr_t attr;
>
This is essentially unused, so might just as well pass NULL into
pthread_create().
Hi,
On Sat, Jun 24, 2017 at 3:27 PM, Michael Niedermayer wrote:
> On Mon, Jun 19, 2017 at 05:11:03PM +0200, James Darnley wrote:
> > Includes add/put functions
> >
> > Rounding contributed by Ronald S. Bultje
> > ---
> > libavcodec/tests/x86/dct.c| 2 +
> > libavcodec/x86/idctd
Hi,
On Sat, Jun 24, 2017 at 6:30 PM, Ronald S. Bultje
wrote:
> If the second, then simple is a superset of simplemmx. If the first, then
> we should remove simplemmx from the list of "supported" idcts for the
> sse2/avx functions. I have no preference (I assumed it meant the first)
>
Just to ex
This is another approach to dealing with the behavioural change
when switching to generic hwaccel. Full hardware transcoding will
not happen if no output format is specified, where this was not
true previously.
So, let's force the user to deal with this change by refusing to
run without an output
Second try.
Feedback on first proposal was lack of interest in having default behaviour
vary between hwaccels, despite their other differences.
In this patch series, I instead force the user to confront the change in
command line semantics when doing cuvid/nvenc transcoding. They will only
get fu
With generic hwaccel, it is additionally necessary to specify the
output format. If this is not done, we'll end up downloading the
frames back and then re-uploading them.
For example:
ffmpeg -y -hwaccel cuvid -hwaccel_output_format cuda \
-c:v h264_cuvid -i sample.mp4 \
-c:v h264_nv
Hi Philip,
On Sat, Jun 24, 2017 at 7:40 PM, Philip Langdale wrote:
> Feedback on first proposal was lack of interest in having default behaviour
> vary between hwaccels, despite their other differences.
I think that's because many of us - including me - don't really understand
this.
I, for on
44 matches
Mail list logo