On Fri, Jul 8, 2016 at 2:25 AM, Michael Niedermayer
wrote:
> On Thu, Jul 07, 2016 at 08:21:17PM +0200, Hendrik Leppkes wrote:
>> Reading it from any other position would result in a wrong size being
>> read, instead fallback to the re-sync mechanic in the else clause.
>> ---
>> libavcodec/h2645_p
On Thu, Jul 07, 2016 at 11:02:30PM -0300, James Almer wrote:
> On 7/7/2016 10:55 PM, Michael Niedermayer wrote:
> > On Wed, Jul 06, 2016 at 08:25:26PM -0300, James Almer wrote:
> >> While not enforced, RFC 5334 mentions that the .ogg extension should
> >> be used for Vorbis audio files only.
> >>
>
From: Sami Hult
This is an updated patch, that removes a debug-purposed printf that I
accidentally left.
Changes metadata filter to accept general urls as file argument without
breaking former behaviour. As a byproduct, it also allows for writing to
file "-" if specified as "file:-".
Example:
On Thu, Jul 07, 2016 at 03:13:53PM +0100, Josh de Kock wrote:
> Hi,
>
> On Thu, Jul 7, 2016, at 10:47 AM, Carl Eugen Hoyos wrote:
> > Josh de Kock itanimul.li> writes:
> >
> > > +ret = openmpt_could_open_propability(
> >
> > I don't know anything about openmpt but what was
> > wrong with t
On Wed, Jul 06, 2016 at 04:48:30PM -0700, Carlos Fernandez Sanz wrote:
> Hi,
>
> Apologies for resending - gmail sent the first attempt as a binary attachment.
fatal: corrupt patch at line 14
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch
Le tridi 13 messidor, an CCXXIV, Josh de Kock a écrit :
> +static int probe_openmpt(AVProbeData *p)
> +{
> +double ret;
> +FILE *file;
> +
> +if(!p->filename)
> +return 0;
> +
> +file = fopen(p->filename, "rb");
> +if (!file)
> +return AVERROR(errno);
> +
> +
Hello Nicolas,
On 07/07/2016 08:00 PM, Nicolas George wrote:
If your worker thread is blocked on an I/O operation when the application
tries to close the muxer, it will send the corresponding messages and call
pthread_join(). Since the worker thread is still blocked in the I/O
operation, it wil
Reading it from any other position would result in a wrong size being
read, instead fallback to the re-sync mechanic in the else clause.
---
libavcodec/h2645_parse.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 99
We know the maximum size of an AnnexB NAL, signaling it as the maximum
NAL size allows ff_h2645_extract_rbsp to determine the correct size.
---
libavcodec/h2645_parse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 26f
Hi all,
metadata filter seems to output null-terminated strings (i.e.
"frame:14\n\0pts:9\n\0"), which I noticed first when trying to regex-match
them. Is this intended behavior and if it is, what is the rationale?
Sami
--
Mannilantie 37 B 11, 04400 58, tel. +358-46-539-6617
Let me rephrase: avio_put_str, which in my patch is used instead of
(forbidden) printf, outputs the terminating null-character with the string.
On 8 July 2016 at 13:12, Sami Hult wrote:
> Hi all,
>
> metadata filter seems to output null-terminated strings (i.e.
> "frame:14\n\0pts:9\n\0"), which
On 7/8/16, sami.h...@gmail.com wrote:
> From: Sami Hult
>
> This is an updated patch, that removes a debug-purposed printf that I
> accidentally left.
>
> Changes metadata filter to accept general urls as file argument without
> breaking former behaviour. As a byproduct, it also allows for writin
Hi,
On 07/07/2016 17:43, Matthieu Bouron wrote:
[...]
0001-lavc-add-mediacodec-hwaccel-support.patch
From 9bb86990f0f7a26d25878a771f5977ae83d14769 Mon Sep 17 00:00:00 2001
From: Matthieu Bouron
Date: Fri, 11 Mar 2016 17:21:04 +0100
Subject: [PATCH] lavc: add mediacodec hwaccel support
---
On Fri, Jul 8, 2016 at 12:33 PM, Sami Hult wrote:
> Let me rephrase: avio_put_str, which in my patch is used instead of
> (forbidden) printf, outputs the terminating null-character with the string.
>
avio_put_str is intentionally designed to write the null-character as
termination as well, since
A later patch to configure to make sure it was defined, so the breakage
stopped. The patch for the configure option and the code should have been
atomic, IMNSHO.
On Thu, Jul 7, 2016 at 8:42 PM, Michael Niedermayer
wrote:
> On Thu, Jun 30, 2016 at 03:36:31PM +0200, Michael Niedermayer wrote:
> >
On Fri, Jul 08, 2016 at 11:27:25AM +0200, Hendrik Leppkes wrote:
> Reading it from any other position would result in a wrong size being
> read, instead fallback to the re-sync mechanic in the else clause.
> ---
> libavcodec/h2645_parse.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
On 8 July 2016 at 14:18, Hendrik Leppkes wrote:
> On Fri, Jul 8, 2016 at 12:33 PM, Sami Hult wrote:
> > Let me rephrase: avio_put_str, which in my patch is used instead of
> > (forbidden) printf, outputs the terminating null-character with the
> string.
> >
>
> avio_put_str is intentionally desi
From: Sami Hult
This is an - once again - updated patch, that uses avio_write instead
of avio_puts to stream clean text output without null characters. Works
now for me as intended.
Changes metadata filter to accept general urls as file argument without
breaking former behaviour. As a byproduct,
On Fri, Jul 08, 2016 at 01:21:48PM +0200, Benoit Fouet wrote:
> Hi,
>
> On 07/07/2016 17:43, Matthieu Bouron wrote:
>
> [...]
>
> >
> > 0001-lavc-add-mediacodec-hwaccel-support.patch
> >
> >
> > From 9bb86990f0f7a26d25878a771f5977ae83d14769 Mon Sep 17 00:00:00 2001
> > From: Matthieu Bouron
On Fri, Jul 8, 2016 at 2:05 PM, Michael Niedermayer
wrote:
> On Fri, Jul 08, 2016 at 11:27:25AM +0200, Hendrik Leppkes wrote:
>> Reading it from any other position would result in a wrong size being
>> read, instead fallback to the re-sync mechanic in the else clause.
>> ---
>> libavcodec/h2645_p
On 08/07/2016 15:40, Matthieu Bouron wrote:
On Fri, Jul 08, 2016 at 01:21:48PM +0200, Benoit Fouet wrote:
Hi,
On 07/07/2016 17:43, Matthieu Bouron wrote:
[...]
0001-lavc-add-mediacodec-hwaccel-support.patch
From 9bb86990f0f7a26d25878a771f5977ae83d14769 Mon Sep 17 00:00:00 2001
From: Ma
On 7/8/2016 4:22 AM, Michael Niedermayer wrote:
> On Thu, Jul 07, 2016 at 11:02:30PM -0300, James Almer wrote:
>> On 7/7/2016 10:55 PM, Michael Niedermayer wrote:
>>> On Wed, Jul 06, 2016 at 08:25:26PM -0300, James Almer wrote:
While not enforced, RFC 5334 mentions that the .ogg extension shou
My fellow members of the FFmpeg multimedia community,
As it is now customary, I'd like to invite you to VideoLAN Dev Days
2016, on the 1st week-end of September: 2-4 September 2016, in Berlin.
This 8th edition of VDD is a bit special, as it collocated within QtCon,
a larger open source confere
Hello!
On 06/30/2016 02:49 AM, Josh de Kock wrote:
Fixes ticket #5623
TODO: bump lavf minor
(I am one of the libopenmpt maintainers)
We have been following the ffmpeg libopenmpt demuxer patches and we
already gave feedback at https://bugs.openmpt.org/view.php?id=817 (for
reference).
I'm
On Fri, Jul 08, 2016 at 04:37:30PM +0200, Benoit Fouet wrote:
>
>
> On 08/07/2016 15:40, Matthieu Bouron wrote:
> > On Fri, Jul 08, 2016 at 01:21:48PM +0200, Benoit Fouet wrote:
> > > Hi,
> > >
> > > On 07/07/2016 17:43, Matthieu Bouron wrote:
> > >
> > > [...]
> > >
> > > > 0001-lavc-add-medi
On Fri, Jul 01, 2016 at 01:23:48AM +0700, Muhammad Faiz wrote:
> On Thu, Jun 30, 2016 at 2:23 PM, Paul B Mahol wrote:
> > On 6/29/16, Muhammad Faiz wrote:
> >> On Tue, Jun 28, 2016 at 5:45 PM, Michael Niedermayer
> >> wrote:
> >>> On Tue, Jun 28, 2016 at 04:07:31PM +0700, Muhammad Faiz wrote:
>
OK where do we find the "Nvidia CUVID decoder" library, is it this?
https://1f0.de/lav-cuvid/
On 6/10/16, Timo Rothenpieler wrote:
> ---
> Changelog | 2 +
> MAINTAINERS| 1 +
> configure | 34 +++
> libavcodec/Makefile| 5 +
> libavcodec/allcode
On Sun, Jul 03, 2016 at 12:33:31AM +0200, Marton Balint wrote:
> Otherwise the stream failed with EAGAIN.
>
> Signed-off-by: Marton Balint
> ---
> ffmpeg.c | 4
> 1 file changed, 4 insertions(+)
i think this is ok
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC78704
Le primidi 21 messidor, an CCXXIV, Jan Sebechlebsky a écrit :
> I actually thought about this and maybe I am still missing something, but
> how is this different from the situation without FIFO muxer?
It is not, which is exactly the answer you do not want when people ask what
your program is good
[ Trimming people I know are on the list from the Cc. ]
Le primidi 21 messidor, an CCXXIV, Jörn Heusipp a écrit :
> (I am one of the libopenmpt maintainers)
> We have been following the ffmpeg libopenmpt demuxer patches and we already
> gave feedback at https://bugs.openmpt.org/view.php?id=817 (fo
On Fri, Jul 8, 2016 at 9:26 PM, Roger Pack wrote:
> OK where do we find the "Nvidia CUVID decoder" library, is it this?
>
> https://1f0.de/lav-cuvid/
>
Please don't top post. And no, thats not it, its just another
implementaiton using the library.
The headers and libraries are part of the NVIDIA
On Sun, Jul 03, 2016 at 12:33:32AM +0200, Marton Balint wrote:
> av_seek_frame to start time can fail and it can also seek after the start of
> the stream...
>
> Signed-off-by: Marton Balint
> ---
> ffmpeg.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
have you tested this with -ss ?
On Fri, 8 Jul 2016, Nicolas George wrote:
Le primidi 21 messidor, an CCXXIV, Jan Sebechlebsky a écrit :
I actually thought about this and maybe I am still missing something, but
how is this different from the situation without FIFO muxer?
It is not, which is exactly the answer you do not wan
checkasm --bench, 10k runs, for *_add_${bpc}_${sub_idct}_${opt}, shows
that it's about 1.65x as fast as the AVX version for the full IDCT, and
similar speedups for the sub-IDCTs:
nop: 24.6
vp9_inv_dct_dct_16x16_add_8_1_c: 6444.8
vp9_inv_dct_dct_16x16_add_8_1_sse2: 638.6
vp9_inv_dct_dct_16x16_add_8
On Fri, Jul 08, 2016 at 04:40:28PM -0400, Ronald S. Bultje wrote:
> checkasm --bench, 10k runs, for *_add_${bpc}_${sub_idct}_${opt}, shows
> that it's about 1.65x as fast as the AVX version for the full IDCT, and
> similar speedups for the sub-IDCTs:
>
> nop: 24.6
> vp9_inv_dct_dct_16x16_add_8_1_c
checkasm --bench, 10k runs, for *_add_${bpc}_${sub_idct}_${opt}, shows
that it's about 1.65x as fast as the AVX version for the full IDCT, and
similar speedups for the sub-IDCTs:
nop: 24.6
vp9_inv_dct_dct_16x16_add_8_1_c: 6444.8
vp9_inv_dct_dct_16x16_add_8_1_sse2: 638.6
vp9_inv_dct_dct_16x16_add_8
add update document of patch
support split hls segment at duration set by hls_time
Signed-off-by: LiuQi
---
doc/muxers.texi | 6 ++
libavformat/hlsenc.c | 4 +++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index c2ca0ba..d416c42 100
On 07/08/2016 10:39 PM, Marton Balint wrote:
On Fri, 8 Jul 2016, Nicolas George wrote:
Le primidi 21 messidor, an CCXXIV, Jan Sebechlebsky a écrit :
I actually thought about this and maybe I am still missing
something, but
how is this different from the situation without FIFO muxer?
It i
On Thu, Jun 23, 2016 at 06:07:01PM +0100, Rostislav Pehlivanov wrote:
> Still much left to optimize, but it provides a significant performance
> improvement - 10% for 300Mbps (1080p30), 25% for 1.5Gbps (4k 60fps) in
> comparison with the default implementation.
LGTM
thanks
[...]
--
Michael
39 matches
Mail list logo
