On Fri, Mar 11, 2016 at 2:09 AM, Michael Niedermayer
wrote:
> On Thu, Mar 10, 2016 at 09:28:50PM -0300, Claudio Freire wrote:
>> On Thu, Mar 10, 2016 at 8:34 PM, Michael Niedermayer
>> wrote:
>> > Hi all
>> >
>> > if you fix speed regressions of the AAC encoder please backport them
>> > also to r
On 03/11/2016 05:10 AM, Mats Peterson wrote:
Forget patch 2/3 and 3/3 from the old patch set.
From the Microsoft documentation for BITMAPINFOHEADER at
https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx:
"biSize: Specifies the number of bytes required by the st
yes. for the video you pointed the B-frame occurs as 6th frame, and until
then has_b_frames is zero.So we assume a wrong delay of zero with my patch .
Is there some other way we can make sure that , for videos with small
number of frames like 5 frames etc. DTS is filled out properly. For example
i
On Thu, Mar 10, 2016 at 11:30 PM, James Almer wrote:
> On 3/11/2016 1:16 AM, Ganesh Ajjanagadde wrote:
>> void av_bmg_get(AVLFG *lfg, double out[2])
>> {
>> -double x1, x2, w;
>> -
>> -do {
>> -x1 = 2.0 / UINT_MAX * av_lfg_get(lfg) - 1.0;
>> -x2 = 2.0 / UINT_MAX * av_lfg_
On 03/11/2016 05:10 AM, Mats Peterson wrote:
Forget patch 2/3 and 3/3 from the old patch set.
From the Microsoft documentation for BITMAPINFOHEADER at
https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx:
"biSize: Specifies the number of bytes required by the st
On 3/11/2016 1:16 AM, Ganesh Ajjanagadde wrote:
> void av_bmg_get(AVLFG *lfg, double out[2])
> {
> -double x1, x2, w;
> -
> -do {
> -x1 = 2.0 / UINT_MAX * av_lfg_get(lfg) - 1.0;
> -x2 = 2.0 / UINT_MAX * av_lfg_get(lfg) - 1.0;
> -w = x1 * x1 + x2 * x2;
> -} whi
Code taken from the Julia project, licensed under MIT:
https://github.com/JuliaLang/julia/blob/master/base/random.jl, in turn
derived from: "The Ziggurat Method for generating random variables" - Marsaglia
and Tsang.
Paper and reference code: http://www.jstatsoft.org/v05/i08/. This is
well known
On 03/11/2016 05:10 AM, Mats Peterson wrote:
Forget patch 2/3 and 3/3 from the old patch set.
From the Microsoft documentation for BITMAPINFOHEADER at
https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx:
"biSize: Specifies the number of bytes required by the st
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 11be9dcbcf9831738b444dcd5618a56e483f9b65 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Fri, 11 Mar 2016 05:04:40 +0100
Subject: [PATCH 3/3] lavf/avi.h: Add necessary stream header and index flags
---
libavformat/avi.h |6 +-
Here's an interesting one. Windows Media Player won't make any palette
changes without the xxpc chunks beeing indexed.
Fixing the logic for reading and seeking with xxpc chunks in the demuxer
is a future task. Now the muxing of video with xxpc chunks works
properly at least.
Try playing the
Forget patch 2/3 and 3/3 from the old patch set.
From the Microsoft documentation for BITMAPINFOHEADER at
https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx:
"biSize: Specifies the number of bytes required by the structure. This
value does not include the size of
On Thu, Mar 10, 2016 at 3:12 AM, Reimar Döffinger
wrote:
> On 10.03.2016, at 00:49, Ganesh Ajjanagadde wrote:
>
>> There is no reason for computing cbrtf at runtime; we have a table for
>> this.
>>
>> Cruft needed due to the build system, the people who still like using
>> hardcoded tables and ne
On Thu, Mar 10, 2016 at 2:46 AM, Hendrik Leppkes wrote:
> On Thu, Mar 10, 2016 at 12:49 AM, Ganesh Ajjanagadde
> wrote:
>> There is no reason for computing cbrtf at runtime; we have a table for
>> this.
>>
>> Cruft needed due to the build system, the people who still like using
>> hardcoded tabl
On Thu, Mar 10, 2016 at 11:21 AM, Rostislav Pehlivanov
wrote:
> On 10 March 2016 at 01:55, Ganesh Ajjanagadde wrote:
>>
>>
>> In fact, I personally have no idea why it is absolutely critical that
>> a Hamming window is used, see 0cfdaf45c4 where Welch was used
>> previously. At a first glance I t
On Thu, Mar 10, 2016 at 4:10 PM, Benoit Fouet wrote:
> Hi,
>
> Le 04/03/2016 04:06, Ganesh Ajjanagadde a écrit :
>>
>> No idea why in commit 01ecb7172b684f1c4b3e748f95c5a9a494ca36ec the
>> checks were removed; this can lead to NULL pointer dereferences. This
>> effectively reverts that portion of
On Thu, Mar 10, 2016 at 8:56 AM, Ronald S. Bultje wrote:
> Hi,
>
> On Thu, Mar 10, 2016 at 2:37 AM, Reimar Döffinger
> wrote:
>
>> On 10.03.2016, at 03:06, Ganesh Ajjanagadde wrote:
>>
>> > On Wed, Mar 9, 2016 at 2:16 AM, Reimar Döffinger
>> > wrote:
>> >> On 08.03.2016, at 04:48, Ganesh Ajjana
On Thu, Mar 10, 2016 at 09:28:50PM -0300, Claudio Freire wrote:
> On Thu, Mar 10, 2016 at 8:34 PM, Michael Niedermayer
> wrote:
> > Hi all
> >
> > if you fix speed regressions of the AAC encoder please backport them
> > also to release/3.0
> >
> > Thanks
>
> Even if that implies much bigger chang
On Thu, Mar 10, 2016 at 08:32:55AM +0100, Mats Peterson wrote:
> Respect "ignore_extradata", for what it's worth.
>
> Mats
>
> --
> Mats Peterson
> http://matsp888.no-ip.org/~mats/
> riffenc.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
> 441410e9518041c02d02776df5
On 3/10/2016 9:28 PM, Claudio Freire wrote:
> On Thu, Mar 10, 2016 at 8:34 PM, Michael Niedermayer
> wrote:
>> Hi all
>>
>> if you fix speed regressions of the AAC encoder please backport them
>> also to release/3.0
>>
>> Thanks
>
> Even if that implies much bigger changes? (like the one I commen
On Thu, Mar 10, 2016 at 8:34 PM, Michael Niedermayer
wrote:
> Hi all
>
> if you fix speed regressions of the AAC encoder please backport them
> also to release/3.0
>
> Thanks
Even if that implies much bigger changes? (like the one I commented
about aacpsy allocation)
_
Hi all
if you fix speed regressions of the AAC encoder please backport them
also to release/3.0
Thanks
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Democracy is the form of government in which you can choose your dictator
signature.asc
Description: Digital signa
>>> Thomas Mundt wrote:
>> This new patch adds x86 SIMD support up to 12 bit. Please comment.
>
> Not much use I guess, but on sse2 8 bit content it tests OK = faster +
> md5sum the same as without the patch.
>
> Are you considering going further with this?
>
> Being sharper than yadif/preserving
On Fri, Mar 11, 2016 at 2:52 AM, Ronald S. Bultje wrote:
> Hi,
>
> On Thu, Mar 10, 2016 at 2:28 PM, Reimar Döffinger
> wrote:
>
>> On 10.03.2016, at 12:01, Ismail Donmez wrote:
>>
>> > On Thu, Mar 10, 2016 at 12:04 PM, wm4 wrote:
>> >> On Thu, 10 Mar 2016 16:53:12 +0700
>> >> Muhammad Faiz wro
mehmet ozisik gmail.com> writes:
> I was looking for a problem which was posted before which I
> have encountered while building ffmped for android in cygwin
> in windows environment.
How can I reproduce the issue?
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/94091
Carl Eugen
_
On Thu, Mar 10, 2016 at 17:13:12 -0500, Aaron Boxer wrote:
> Does FFMpeg support OpenJPEG version 2.x ?
Since January, yes:
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-December/185794.html
> with same CLI and same name for binaries.
ffmpeg doesn't use cli, it uses libraries, APIs and ABIs.
M
Hello,
Does FFMpeg support OpenJPEG version 2.x ?
I have made a fork of OpenJPEG that improves performance.
How can I make FFMpeg use my fork? It is a drop-in replacement for
OpenJPEG,
with same CLI and same name for binaries.
Thanks,
Aaron
___
ffmpeg
Hi,
I was looking for a problem which was posted before which I have
encountered while building ffmped for android in cygwin in windows
environment.
Solution patch seems attached to
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090717/2d2a2e9c/attachment.patch
But the attachment
On Thu, Mar 10, 2016 at 06:12:57PM +0100, Gerion Entrup wrote:
[...]
> > - an USF demuxer which extracts the timing and text (with its markup) of
> > every event, and put them into an AVPacket
> >
> > - introduce an USF codec and write a decoder that will transform the
> > xml-like markup into
On Wed, Dec 09, 2015 at 03:18:53PM +0100, Michael Niedermayer wrote:
> From: Michael Niedermayer
>
> This should theoretically improve the randomness slightly
>
> Signed-off-by: Michael Niedermayer
> ---
> libavutil/random_seed.c |7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
Hi,
Le 04/03/2016 04:06, Ganesh Ajjanagadde a écrit :
No idea why in commit 01ecb7172b684f1c4b3e748f95c5a9a494ca36ec the
checks were removed; this can lead to NULL pointer dereferences. This
effectively reverts that portion of the commit.
Signed-off-by: Ganesh Ajjanagadde
---
libavcodec/psym
Le primidi 21 ventôse, an CCXXIV, Derek Buitenhuis a écrit :
> You're not going to find an XML library that is not annoying/hard to use
> because XML is annoying/hard to use correctly.
That is true, but fortunately, most real-world files in normal formats based
on XML do not use the hard features
On Donnerstag, 10. März 2016 20:20:20 CET Derek Buitenhuis wrote:
> On 3/10/2016 8:11 PM, wm4 wrote:
> > Since XML libraries are apparently always broken, bloated, insecure, and
> > hard to use, that has always been a point of contention. Although it
> > would be the right approach.
>
> You're not
On 3/10/2016 8:11 PM, wm4 wrote:
> Since XML libraries are apparently always broken, bloated, insecure, and
> hard to use, that has always been a point of contention. Although it
> would be the right approach.
You're not going to find an XML library that is not annoying/hard to use
because XML is
On Tue, Dec 01, 2015 at 05:59:36PM -0500, Martin Cracauer wrote:
> [bug submit webpage seems to be down, sending directly]
>
> Trying to make heads and tails out of DTS 6.1 I can across this typo.
>
> I also noticed that this wiki page is incorrect or misleading, the
> channel order for 6.1 given
On Thu, 10 Mar 2016 18:12:57 +0100
Gerion Entrup wrote:
> On Dienstag, 8. März 2016 20:42:39 CET Clément Bœsch wrote:
> > On Tue, Mar 08, 2016 at 06:21:12PM +0100, Gerion Entrup wrote:
> > > Hello,
> > >
> >
> > Hi,
> >
> > > my own ideas seems not to be suitable for GSoC, so I looked ag
On Thu, 10 Mar 2016 20:34:57 +0100 (CET)
Marton Balint wrote:
> On Thu, 10 Mar 2016, wm4 wrote:
>
> > On Wed, 9 Mar 2016 23:02:14 +0100 (CET)
> > Marton Balint wrote:
> >
>
> [...]
>
> > Anyway, with just an audio track, adjusting start_time is rather
> > inoffensive.
> >
> > If there's a v
Hi,
On Thu, Mar 10, 2016 at 2:28 PM, Reimar Döffinger
wrote:
> On 10.03.2016, at 12:01, Ismail Donmez wrote:
>
> > On Thu, Mar 10, 2016 at 12:04 PM, wm4 wrote:
> >> On Thu, 10 Mar 2016 16:53:12 +0700
> >> Muhammad Faiz wrote:
> >>
> >>> I use intrinsic because writing asm using nasm or inline
On Thu, 10 Mar 2016, wm4 wrote:
On Wed, 9 Mar 2016 23:02:14 +0100 (CET)
Marton Balint wrote:
[...]
Anyway, with just an audio track, adjusting start_time is rather
inoffensive.
If there's a video track, it becomes complicated. The audio packets
(after applying delay skipping) will not st
On 10.03.2016, at 12:01, Ismail Donmez wrote:
> On Thu, Mar 10, 2016 at 12:04 PM, wm4 wrote:
>> On Thu, 10 Mar 2016 16:53:12 +0700
>> Muhammad Faiz wrote:
>>
>>> I use intrinsic because writing asm using nasm or inline asm
>>> is difficult task for me.
>>>
>>> [PATCH 1/3] configure: add x86 i
On 10/03/2016 19:14:10 CET, Michael Niedermayer wrote:
On Tue, Feb 09, 2016 at 09:12:53PM +0100, Paul B Mahol wrote:
On 1/20/16, Vittorio Gambaletta (VittGam) wrote:
> With this commit it is possible to use vf_overlay to center a video over
> a black background, without having to know the video
On Thu, Mar 10, 2016 at 12:01 PM, Ismail Donmez wrote:
> On Thu, Mar 10, 2016 at 12:04 PM, wm4 wrote:
>> We generally don't accept intrinsic in ffmpeg.
>
> Given this policy has roots from gcc 2.x times, it might be a good
> idea to discuss it again in the context of gcc5 and clang 3.8 and
> late
On Mon, Sep 21, 2015 at 6:41 AM, Alex Smith wrote:
> From: Alex Smith
>
> Binutils will always strip the relocation information from executable
> files even if it needs it (dynamicbase/ASLR). We can work around this
> by using the pic-executable flag combined with setting the correct entry
> poi
On Thu, Jan 28, 2016 at 09:07:51PM -0600, Rodger Combs wrote:
> OSX's ld's -Wl,-dead_strip is applied before symbols are resolved, so if the
> check functions aren't called, they're stripped out and the test is useless.
> This calls the functions, so they won't be stripped.
> ---
> configure | 6 +
On Thu, Jan 28, 2016 at 10:42:12AM -0800, Ram Natarajan wrote:
> Folks,
> This patch makes dashenc.c handle vp8/vp9 video codecs and vorbis codec for
> audio. The current webm_chunk and webm_dash_manifest is a two stage process
> and not really suitable for realti
> me "live" dash mpd creation.
> I
On Tue, Feb 09, 2016 at 09:12:53PM +0100, Paul B Mahol wrote:
> On 1/20/16, Vittorio Gambaletta (VittGam) wrote:
> > With this commit it is possible to use vf_overlay to center a video over
> > a black background, without having to know the video framerate in advance
> > and set it as parameter to
Michael Niedermayer niedermayer.cc> writes:
> > movenc.c |6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> > 16f1e8ed7a98e27567c5d0c77f366aab8cf64ce2 patchmovhelp.diff
>
> LGTM
Patch applied.
Thank you, Carl Eugen
___
ffmpeg-dev
On Thu, Mar 10, 2016 at 05:32:33PM +0100, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes ticket #5323 for me.
>
> Please comment, Carl Eugen
> movenc.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
> 16f1e8ed7a98e27567c5d0c77f366aab8cf64ce2 patchmovhelp.diff
LGTM
t
On Dienstag, 8. März 2016 20:42:39 CET Clément Bœsch wrote:
> On Tue, Mar 08, 2016 at 06:21:12PM +0100, Gerion Entrup wrote:
> > Hello,
> >
>
> Hi,
>
> > my own ideas seems not to be suitable for GSoC, so I looked again on the
> > ideas page,
> > because I have high interest to do something for
Hello,
I've tried to implement the USF demuxer and decoder. This work is heavily based
on the SAMI demuxer and decoder. It only supports the very basic features.
Supporting more features based on this code would be very hard. I think, it
would
be better to use an external xmllib.
I've not confi
Hi!
Attached patch fixes ticket #5323 for me.
Please comment, Carl Eugen
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index cb125d8..9af44e3 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -83,9 +83,9 @@ static const AVOption options[] = {
{ "fragment_index", "Fra
Thomas Mundt wrote:
This new patch adds x86 SIMD support up to 12 bit. Please comment.
Not much use I guess, but on sse2 8 bit content it tests OK = faster +
md5sum the same as without the patch.
Are you considering going further with this?
Being sharper than yadif/preserving weave is nice, b
On 10 March 2016 at 01:55, Ganesh Ajjanagadde wrote:
>
>
> In fact, I personally have no idea why it is absolutely critical that
> a Hamming window is used, see 0cfdaf45c4 where Welch was used
> previously. At a first glance I think one can find a window that works
> and avoids libm, e.g Parzen or
Hi Reimar,
Will send in a new patch with the improvements for review :-).
Thank you,
Naga
On Wed, Mar 9, 2016 at 11:05 AM, Reimar Döffinger
wrote:
> On Wed, Mar 09, 2016 at 10:27:29AM -0800, NagaChaitanya Vellanki wrote:
> > On Tue, Mar 8, 2016 at 5:33 PM, James Almer wrote:
> >
> > > On 3/8/2
Hi!
While debugging ticket #5312, I realized that I included the
track number in the Canopus essence element.
Please comment, Carl Eugen
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 4dede6f..f1495e6 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -283,7 +283,7 @
Hi!
Attached patch fixes ticket #5312 here.
The OP claims that the file plays fine with Mainconcept softare,
afaict the track number of the video track in the mxf header
(0x15010800) does not match the track number of the video frames
(0x15010500 == 352388352).
Please comment, Carl Eugen
diff
Hi,
On Thu, Mar 10, 2016 at 2:37 AM, Reimar Döffinger
wrote:
> On 10.03.2016, at 03:06, Ganesh Ajjanagadde wrote:
>
> > On Wed, Mar 9, 2016 at 2:16 AM, Reimar Döffinger
> > wrote:
> >> On 08.03.2016, at 04:48, Ganesh Ajjanagadde wrote:
> >>
> >>> +nzl += expf(logf(s / ethr
Hi,
On Thu, Mar 10, 2016 at 6:01 AM, Ismail Donmez wrote:
> On Thu, Mar 10, 2016 at 12:04 PM, wm4 wrote:
> > On Thu, 10 Mar 2016 16:53:12 +0700
> > Muhammad Faiz wrote:
> >
> >> I use intrinsic because writing asm using nasm or inline asm
> >> is difficult task for me.
> >>
> >> [PATCH 1/3] co
Hi,
On Thu, Mar 10, 2016 at 4:53 AM, Muhammad Faiz wrote:
> Signed-off-by: Muhammad Faiz
> ---
> configure | 42 ++
> libavutil/x86/intrinsic.h | 58
> +++
> 2 files changed, 100 insertions(+)
> create
On Tue, Mar 08, 2016 at 09:29:51PM +0100, Marton Balint wrote:
> Signed-off-by: Marton Balint
> ---
> tests/fate-run.sh | 30 ++
> tests/fate/gapless.mak| 20 -
> tests/ref/fate/gapless2-ipod-aac1 | 86
> +++
> t
On Thu, Mar 10, 2016 at 12:04 PM, wm4 wrote:
> On Thu, 10 Mar 2016 16:53:12 +0700
> Muhammad Faiz wrote:
>
>> I use intrinsic because writing asm using nasm or inline asm
>> is difficult task for me.
>>
>> [PATCH 1/3] configure: add x86 intrinsic support
>> [PATCH 2/3] avfilter/avf_showcqt: cqt_c
On Thu, Mar 10, 2016 at 5:04 PM, wm4 wrote:
> On Thu, 10 Mar 2016 16:53:12 +0700
> Muhammad Faiz wrote:
>
>> I use intrinsic because writing asm using nasm or inline asm
>> is difficult task for me.
>>
>> [PATCH 1/3] configure: add x86 intrinsic support
>> [PATCH 2/3] avfilter/avf_showcqt: cqt_ca
On Thu, Mar 10, 2016 at 5:18 PM, Hendrik Leppkes wrote:
> On Thu, Mar 10, 2016 at 11:08 AM, Muhammad Faiz wrote:
>> On Thu, Mar 10, 2016 at 5:01 PM, Hendrik Leppkes wrote:
>>> On Thu, Mar 10, 2016 at 10:53 AM, Muhammad Faiz wrote:
I use intrinsic because writing asm using nasm or inline as
On Thu, 10 Mar 2016 16:53:12 +0700
Muhammad Faiz wrote:
> I use intrinsic because writing asm using nasm or inline asm
> is difficult task for me.
>
> [PATCH 1/3] configure: add x86 intrinsic support
> [PATCH 2/3] avfilter/avf_showcqt: cqt_calc x86 optimization
> [PATCH 3/3] avfilter/avf_showcqt
On Thu, Mar 10, 2016 at 11:08 AM, Muhammad Faiz wrote:
> On Thu, Mar 10, 2016 at 5:01 PM, Hendrik Leppkes wrote:
>> On Thu, Mar 10, 2016 at 10:53 AM, Muhammad Faiz wrote:
>>> I use intrinsic because writing asm using nasm or inline asm
>>> is difficult task for me.
>>>
>>
>> We have intentionall
use sse/sse2 intrinsic
bitexact on x86_64
bar_time:
rgb24: 12.601s 6.492s
yuv444p: 14.495s 5.661s
yuv422p: 10.514s 3.953s
yuv420p: 8.795s 3.256s
Signed-off-by: Muhammad Faiz
---
libavfilter/avf_showcqt.c | 20 ++-
libavfilter/avf_showcqt.h | 2 +
libavfilter/x86/avf_showcqt
On Thu, Mar 10, 2016 at 5:01 PM, Hendrik Leppkes wrote:
> On Thu, Mar 10, 2016 at 10:53 AM, Muhammad Faiz wrote:
>> I use intrinsic because writing asm using nasm or inline asm
>> is difficult task for me.
>>
>
> We have intentionally avoided intrinsics so far, because the result is
> extremely c
On Thu, Mar 10, 2016 at 10:53 AM, Muhammad Faiz wrote:
> I use intrinsic because writing asm using nasm or inline asm
> is difficult task for me.
>
We have intentionally avoided intrinsics so far, because the result is
extremely compiler dependent, and I don't think we should just start
adding th
use intrinsic
cqt_time:
plain = 3.286 s
SSE = 1.725 s
SSE3 = 1.692 s
AVX = 1.399 s
Signed-off-by: Muhammad Faiz
---
libavfilter/avf_showcqt.c | 7 +
libavfilter/avf_showcqt.h | 4 +
libavfilter/x86/Makefile | 1 +
libavfilter/x86/avf_showcqt.c | 289 ++
Signed-off-by: Muhammad Faiz
---
configure | 42 ++
libavutil/x86/intrinsic.h | 58 +++
2 files changed, 100 insertions(+)
create mode 100644 libavutil/x86/intrinsic.h
diff --git a/configure b/configure
I use intrinsic because writing asm using nasm or inline asm
is difficult task for me.
[PATCH 1/3] configure: add x86 intrinsic support
[PATCH 2/3] avfilter/avf_showcqt: cqt_calc x86 optimization
[PATCH 3/3] avfilter/avf_showcqt: draw_bar x86 optimization
Thank's
On Wed, Mar 09, 2016 at 15:56:53 -0800, Sergey Volk wrote:
> -if (fmt_ctx->iformat->flags & AVFMT_SHOW_IDS) print_fmt("id",
> "0x%x", stream->id);
> +#if FF_API_OLD_INT32_STREAM_ID
> +#define STREAM_ID_FORMAT "0x%x"
> +#else
> +#define STREAM_ID_FORMAT "0x%"PRIx64
> +#endif
> +if (fmt_c
Tomas Härdin codemill.se> writes:
> > Attached patch fixes ticket #5316 here.
> > I unfortunately have no idea what the hunk in mxf_read_header()
> > does, decoding works fine without it.
>
> Strange. Why was mxf_canopus_essence_element_key added then?
> Pushing without it is fine if it fixes
Thanks for the patch.
Le decadi 20 ventôse, an CCXXIV, Sergey Volk a écrit :
> I have also bumped the major version to 58 locally in version.h, and
> re-ran make with the stream id being int64_t and fixed all new
> warnings that showed up (only saw new warnings related to the
> incorrect format be
On 10.03.2016, at 00:49, Ganesh Ajjanagadde wrote:
> There is no reason for computing cbrtf at runtime; we have a table for
> this.
>
> Cruft needed due to the build system, the people who still like using
> hardcoded tables and need for single cbrt_tab across the code.
Could you please explain
On Wed, 9 Mar 2016 23:02:14 +0100 (CET)
Marton Balint wrote:
> On Wed, 9 Mar 2016, wm4 wrote:
> > On Tue, 8 Mar 2016 23:44:13 +0100 (CET)
> > Marton Balint wrote:
> >
> >> On Tue, 8 Mar 2016, Hendrik Leppkes wrote:
> >>
> >> > On Tue, Mar 8, 2016 at 10:54 PM, Marton Balint wrote:
> >> >
75 matches
Mail list logo
