Hi,
I am trying to encode an 8-bit 4K video at 3Mbps by using ffmpeg + x264 and
I see a considerable difference in speed when I use ffmpeg and pipe the
output to x264 (by using linux pipes), and when I use libx264. The speed
difference is nearly 2X with the encoding being considerably faster when
u
Carl Eugen Hoyos ag.or.at> writes:
> Attached patch makes the output of the mkv muxer more
> similar to what mkvmerge does.
> May fix ticket #5332.
Ping, I can confirm that the patch fixes ticket #5332.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpe
ping please?
On Tue, Mar 8, 2016 at 2:48 PM, Ismail Donmez wrote:
> This fixes cross-build on Linux with mingw-w64. Patch attached. This
> will not break MSVC because Windows is case-insensitive unlike Linux.
>
> Please review.
>
> Regards,
> ismail
___
W dniu 01.01.2016 o 15:19, Michael Niedermayer pisze:
(...)
Also ill likely make another round of point releases from the
2.8/2.7/2.6/2.5 branches soon, that is if someone wants to backport
something or fix and backport ...
I know it's a bit late but could you backport fixes for #4841, #4849,
This allows avformat_find_stream_info to finish without opening a decoder in
more cases.
Since decoders still export some information that the corresponding parsers
don't, this causes some fields to be unset in ffprobe output where the
decoder would previously have only been called in avformat_fin
Przemysław Sobala grupawp.pl> writes:
> I know it's a bit late but could you backport fixes for
> #4841, #4849, #5121, #5267
None of these were reported as regresions and I don't think
any of them describe a security issue.
Generally, backports should be held to a minimum to avoid
issues like
On Tue, Mar 15, 2016 at 2:40 PM, Carl Eugen Hoyos wrote:
> Przemysław Sobala grupawp.pl> writes:
>
>> I know it's a bit late but could you backport fixes for
>> #4841, #4849, #5121, #5267
>
> None of these were reported as regresions and I don't think
> any of them describe a security issue.
> Ge
W dniu 15.03.2016 o 14:40, Carl Eugen Hoyos pisze:
Przemysław Sobala grupawp.pl> writes:
I know it's a bit late but could you backport fixes for
#4841, #4849, #5121, #5267
None of these were reported as regresions and I don't think
any of them describe a security issue.
Generally, backports
On 3/15/2016 8:58 AM, Pradeep Ramachandran wrote:
> Has anyone else experienced such a stark difference in speed? Are the
> limits of linux pipes the reason for this difference, or is there something
> else going on here?
First: This is probably the wrong list.
Second: Did you expect piping a ver
On 3/15/2016 4:46 AM, Ganesh Ajjanagadde wrote:
> Concretely, it is nearly as fast as av_lfg_get (which only returns 32 bits),
> and has a much smaller cache (128 bits). Thus, the timings should also
> be more stable.
>
> This is needed because av_lfg_get<<32 | av_lfg_get is far slower, and
> like
>>>James Almer schrieb am So, 13.3.2016:
> Since you adapted quite a bit of this code from yadif simd, the copyright
> header should reflect that.
Agreed. I´ll send a patch...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mail
Hi,
On Tue, Mar 15, 2016 at 10:29 AM, Derek Buitenhuis <
derek.buitenh...@gmail.com> wrote:
> On 3/15/2016 4:46 AM, Ganesh Ajjanagadde wrote:
> > Concretely, it is nearly as fast as av_lfg_get (which only returns 32
> bits),
> > and has a much smaller cache (128 bits). Thus, the timings should al
On 3/15/2016 2:56 PM, Ronald S. Bultje wrote:
> Might be related to aacenc? But yes, we need to know overall speed gain of
> some useful end user feature before/after this.
[13:42] <@atomnuker> well, AAC just requires the random numbers to be only
somewhat random
[13:43] <@atomnuker> you could pr
Signed-off-by: Thomas Mundt
---
libavfilter/x86/vf_bwdif.asm | 4
1 file changed, 4 insertions(+)
diff --git a/libavfilter/x86/vf_bwdif.asm b/libavfilter/x86/vf_bwdif.asm
index 11aa025..147b7c6 100644
--- a/libavfilter/x86/vf_bwdif.asm
+++ b/libavfilter/x86/vf_bwdif.asm
@@ -3,6 +3,10 @@
;*
On Mon, Mar 14, 2016 at 08:42:32PM -0400, Ganesh Ajjanagadde wrote:
> On Sun, Mar 13, 2016 at 11:08 PM, Michael Niedermayer
> wrote:
> > On Sun, Mar 13, 2016 at 07:12:50PM -0400, Ganesh Ajjanagadde wrote:
> >> This is based on the relatively well known xorshift128+ of Sebastiano
> >> Vigna (https:
On date Tuesday 2016-03-08 19:45:52 +0100, Stefano Sabatini encoded:
> On date Sunday 2016-02-28 21:41:32 +0100, Martin Vignali encoded:
> > 2016-02-23 20:08 GMT+01:00 Martin Vignali :
> [...]
> > Hello,
> >
> > New patch attached, with the timecode incrementation inside segment_end()
> > Use this
On Tue, Mar 15, 2016 at 08:36:41AM -0500, Rodger Combs wrote:
> This allows avformat_find_stream_info to finish without opening a decoder in
> more cases.
>
> Since decoders still export some information that the corresponding parsers
> don't, this causes some fields to be unset in ffprobe output
On Tue, 15 Mar 2016, Rodger Combs wrote:
This allows avformat_find_stream_info to finish without opening a decoder in
more cases.
That may be a good thing, but it still removes existing functionality.
Would it be too much work to introduce avformat_find_stream_info2 with an
additional flags
Fixes ticket #5318.
Signed-off-by: Marton Balint
---
libavformat/segment.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index ccedd04..70590b4 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -256,7 +256,1
On Tue, Mar 15, 2016 at 06:49:18PM +0100, Marton Balint wrote:
> On Tue, 15 Mar 2016, Rodger Combs wrote:
>
> >This allows avformat_find_stream_info to finish without opening a decoder in
> >more cases.
>
> That may be a good thing, but it still removes existing
> functionality. Would it be too m
On Tue, Mar 15, 2016 at 02:44:07PM +0100, Hendrik Leppkes wrote:
> On Tue, Mar 15, 2016 at 2:40 PM, Carl Eugen Hoyos wrote:
> > Przemysław Sobala grupawp.pl> writes:
> >
> >> I know it's a bit late but could you backport fixes for
> >> #4841, #4849, #5121, #5267
> >
> > None of these were reporte
On Tue, Mar 15, 2016 at 02:24:10PM +0100, Przemysław Sobala wrote:
> W dniu 01.01.2016 o 15:19, Michael Niedermayer pisze:
> (...)
> >
> >Also ill likely make another round of point releases from the
> >2.8/2.7/2.6/2.5 branches soon, that is if someone wants to backport
> >something or fix and back
On Tue, Mar 08, 2016 at 02:48:04PM +0200, Ismail Donmez wrote:
> This fixes cross-build on Linux with mingw-w64. Patch attached. This
> will not break MSVC because Windows is case-insensitive unlike Linux.
>
> Please review.
I see this:
libavformat/tls_schannel.c:#include
libavformat/tls_securet
On 3/15/2016 7:26 PM, Reimar Döffinger wrote:
> I see this:
> libavformat/tls_schannel.c:#include
> libavformat/tls_securetransport.c:#include
>
> Are those different headers?
Consider that one is for OS X native TLS, and one is for
Windows native TLS.
- Derek
_
On Tue, Mar 15, 2016 at 07:32:35PM +, Derek Buitenhuis wrote:
> On 3/15/2016 7:26 PM, Reimar Döffinger wrote:
> > I see this:
> > libavformat/tls_schannel.c:#include
> > libavformat/tls_securetransport.c:#include
> >
> > Are those different headers?
>
> Consider that one is for OS X native
On Tue, Mar 15, 2016 at 8:33 PM, Reimar Döffinger
wrote:
> On Tue, Mar 15, 2016 at 07:32:35PM +, Derek Buitenhuis wrote:
>> On 3/15/2016 7:26 PM, Reimar Döffinger wrote:
>> > I see this:
>> > libavformat/tls_schannel.c:#include
>> > libavformat/tls_securetransport.c:#include
>> >
>> > Are th
Hi,
El Mon, Mar 14, 2016 at 08:42:32PM -0400, Ganesh Ajjanagadde escribio:
> On Sun, Mar 13, 2016 at 11:08 PM, Michael Niedermayer
> wrote:
> > On Sun, Mar 13, 2016 at 07:12:50PM -0400, Ganesh Ajjanagadde wrote:
> >> This is based on the relatively well known xorshift128+ of Sebastiano
> >> Vigna
On Tue, Mar 15, 2016 at 05:10:57PM -0300, Daniel Serpell wrote:
> Hi,
>
> El Mon, Mar 14, 2016 at 08:42:32PM -0400, Ganesh Ajjanagadde escribio:
> > On Sun, Mar 13, 2016 at 11:08 PM, Michael Niedermayer
> > wrote:
> > > On Sun, Mar 13, 2016 at 07:12:50PM -0400, Ganesh Ajjanagadde wrote:
> > >> Th
On Mon, Mar 14, 2016 at 12:22:35PM +0100, Hendrik Leppkes wrote:
> Fixes issue 5248
> ---
> libavformat/hls.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
probably ok
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Modern terrori
On 3/14/2016 11:22 AM, Hendrik Leppkes wrote:
> This reverts commit 9f9ed79d4cb40e5d9093899f8a79086ff23da844.
>
> The hlsopts member was never set anywhere and always NULL, furthermore
> the HLS demuxer needs to retrieve the proper options from the underlying
> http protocol (cookies, user-agent,
On Mon, Mar 14, 2016 at 12:22:34PM +0100, Hendrik Leppkes wrote:
> This avoids directly accessing the void opaque type.
> ---
> libavformat/hls.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
this and the revert should be ok (merged or non merged, whatever is
preferred)
independa
On Tue, Mar 15, 2016 at 10:06 PM, Derek Buitenhuis
wrote:
> On 3/14/2016 11:22 AM, Hendrik Leppkes wrote:
>> This reverts commit 9f9ed79d4cb40e5d9093899f8a79086ff23da844.
>>
>> The hlsopts member was never set anywhere and always NULL, furthermore
>> the HLS demuxer needs to retrieve the proper op
On Tue, Mar 15, 2016 at 12:10 PM, Michael Niedermayer
wrote:
> On Mon, Mar 14, 2016 at 08:42:32PM -0400, Ganesh Ajjanagadde wrote:
>> On Sun, Mar 13, 2016 at 11:08 PM, Michael Niedermayer
>> wrote:
>> > On Sun, Mar 13, 2016 at 07:12:50PM -0400, Ganesh Ajjanagadde wrote:
>> >> This is based on the
On Tue, Mar 15, 2016 at 10:29 AM, Derek Buitenhuis
wrote:
> On 3/15/2016 4:46 AM, Ganesh Ajjanagadde wrote:
>> Concretely, it is nearly as fast as av_lfg_get (which only returns 32 bits),
>> and has a much smaller cache (128 bits). Thus, the timings should also
>> be more stable.
>>
>> This is nee
On Tue, Mar 15, 2016 at 12:47:00AM -0400, Ganesh Ajjanagadde wrote:
[...]
> +static inline double ziggurat(AVRAND64 *rng)
> +{
> +while (1) {
> +int64_t rabs;
> +double x;
> +uint8_t idx;
> +uint64_t r = av_rand64_get(rng) & 0x000f;
> +rabs =
> > >
> > > check tests/fate/seek.mak
> > > also you can pass parameters to seek-test see fate-seek-cache-pipe
> > > i dont know if there is anything else special needed for this
> > >
> > Thanks Michael, I looked at this some more, and there's one thing that I'm
> > still
> > missing - where do
On Tue, Mar 15, 2016 at 10:59 AM, Derek Buitenhuis
wrote:
> On 3/15/2016 2:56 PM, Ronald S. Bultje wrote:
>> Might be related to aacenc? But yes, we need to know overall speed gain of
>> some useful end user feature before/after this.
>
> [13:42] <@atomnuker> well, AAC just requires the random num
On 3/15/2016 10:26 PM, Ganesh Ajjanagadde wrote:
> If one wants good Gaussian samples, then yes, I need a 64 bit rng.
> Please also note that I can use av_lfg_get, it does not result in
> slowdown, since speed benefits here come from the ziggurat algo.
> Concretely, it is 82 cycles vs 81 cycles; to
> On Feb 27, 2016, at 10:24 PM, Michael Niedermayer
> wrote:
>
> On Thu, Feb 04, 2016 at 04:45:09PM +, Carl Eugen Hoyos wrote:
>> Syed Andaleeb Roomy gmail.com> writes:
>>
>>> I worked on the attached patch to enable timecode tracks in MP4 files
>>> written by ffmpeg. Could someone please
Hello,
I want to try and use the libavfilter API to overlay bitmap subtitles on
video from a realtime source. This seems difficult/impossible to do with
the current API hence asking on the main devel list.
Some questions:
1: How do I know the end to end latency of the pipeline? Is it fixed, does
Yeah, I was using Gmail web interface, it does that. I'll try attaching the
patch file next time.
On Thu, Mar 10, 2016 at 1:23 AM, Moritz Barsnick wrote:
> On Wed, Mar 09, 2016 at 15:56:53 -0800, Sergey Volk wrote:
> > -if (fmt_ctx->iformat->flags & AVFMT_SHOW_IDS) print_fmt("id",
> > "0
Thanks for the comments, I'll update my next patch to take that into
account.
But first I wanted to discuss your second point (regarding int64_t/uint64_t
choice).
I have actually looked at all places that use AVStream::id (34 files under
libavformat/ + a few more files outside it). There are a few
On Tue, Mar 15, 2016 at 11:37:30PM +, Derek Buitenhuis wrote:
> On 3/15/2016 10:26 PM, Ganesh Ajjanagadde wrote:
> > If one wants good Gaussian samples, then yes, I need a 64 bit rng.
> > Please also note that I can use av_lfg_get, it does not result in
> > slowdown, since speed benefits here c
On Tue, Mar 15, 2016 at 11:37:30PM +, Derek Buitenhuis wrote:
> On 3/15/2016 10:26 PM, Ganesh Ajjanagadde wrote:
> > If one wants good Gaussian samples, then yes, I need a 64 bit rng.
> > Please also note that I can use av_lfg_get, it does not result in
> > slowdown, since speed benefits here c
On Wed, Mar 16, 2016 at 02:18:54AM +0100, Michael Niedermayer wrote:
> On Tue, Mar 15, 2016 at 11:37:30PM +, Derek Buitenhuis wrote:
> > On 3/15/2016 10:26 PM, Ganesh Ajjanagadde wrote:
> > > If one wants good Gaussian samples, then yes, I need a 64 bit rng.
> > > Please also note that I can us
On 15 March 2016 at 23:21, Ganesh Ajjanagadde wrote:
> On Tue, Mar 15, 2016 at 10:59 AM, Derek Buitenhuis
> wrote:
> > On 3/15/2016 2:56 PM, Ronald S. Bultje wrote:
> >> Might be related to aacenc? But yes, we need to know overall speed gain
> of
> >> some useful end user feature before/after th
On Tue, Mar 15, 2016 at 10:57:02PM +, Eran Kornblau wrote:
> > > >
> > > > check tests/fate/seek.mak
> > > > also you can pass parameters to seek-test see fate-seek-cache-pipe
> > > > i dont know if there is anything else special needed for this
> > > >
> > > Thanks Michael, I looked at this s
On 3/15/2016 12:04 PM, Thomas Mundt wrote:
> Signed-off-by: Thomas Mundt
> ---
> libavfilter/x86/vf_bwdif.asm | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavfilter/x86/vf_bwdif.asm b/libavfilter/x86/vf_bwdif.asm
> index 11aa025..147b7c6 100644
> --- a/libavfilter/x86/vf_bwdif.
You say the libav commits are merged every day. This commit was posted
February 22, that's quite a while ago. What is it that causes this delay?
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.o
On 03/16/2016 04:45 AM, Mats Peterson wrote:
You say the libav commits are merged every day. This commit was posted
February 22, that's quite a while ago. What is it that causes this delay?
Mats
This is a super-simple patch, at that.
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
_
On Tue, Mar 15, 2016 at 9:51 PM, Hendrik Leppkes wrote:
> On Tue, Mar 15, 2016 at 8:33 PM, Reimar Döffinger
> wrote:
>> On Tue, Mar 15, 2016 at 07:32:35PM +, Derek Buitenhuis wrote:
>>> On 3/15/2016 7:26 PM, Reimar Döffinger wrote:
>>> > I see this:
>>> > libavformat/tls_schannel.c:#include
On 03/16/2016 04:48 AM, Mats Peterson wrote:
On 03/16/2016 04:45 AM, Mats Peterson wrote:
You say the libav commits are merged every day. This commit was posted
February 22, that's quite a while ago. What is it that causes this delay?
Mats
This is a super-simple patch, at that.
Mats
Onc
52 matches
Mail list logo
