On Mon, 2017-03-13 at 12:45 +0100, Diego Biurrun wrote:
> On Sat, Mar 11, 2017 at 11:33:31AM +0100, Luca Barbato wrote:
> > On 09/06/2016 17:12, Diego Biurrun wrote:
> > > From: Alexandra Hájková
> > >
> > > ---
> > > libavcodec/vorbis_parser.c | 32 +++---
> > > libavcodec/vorbisdec.c | 23
On Sun, 2017-03-12 at 17:27 +0100, Luca Barbato wrote:
> The field is expressed in 6 bits so up to 63 bits amplitudes could be
> encoded.
>
> Reported and debugged by Uoti Urpala.
But this patch doesn't actually match what was said on IRC...
> -unsigned amplitude, book_
On Sat, 2015-10-31 at 16:02 -0400, Ganesh Ajjanagadde wrote:
> On Sat, Oct 31, 2015 at 3:01 PM, Luca Barbato
> wrote:
> > On 31/10/15 19:51, Ganesh Ajjanagadde wrote:
> > > why not just use U: it is a very simple solution.
> >
> >
> > The only, simple and correct solution is to use the provided
On Thu, 2013-01-10 at 09:01 +0100, Andreas Öman wrote:
> FWIW, in my code i have an fixed size array (currently 64 items) of my
> own metadata struct.
>
>
> I then just use reordered_opaque as an index to this array and keep
> incrementing
> reordered_opaque for every new packet and let it wrap a
On Wed, 2013-01-09 at 18:42 +0100, Anton Khirnov wrote:
> When a frame is used on its own outside of lavc, "frame timestamp" still has a
> well-defined meaning. OTOH pkt_pts and pkt_dts do not.
PTS has well defined with a meaning matching approximately what
"pkt_pts" description in avcodec.h now s
On Wed, 2013-01-09 at 17:02 +0100, Hendrik Leppkes wrote:
> Personally, i also think timestamps as integers are fine, as thats how
> they are stored in files, and how most external API i ever worked with
> expects it.
Having the exponent of the double change between different timestamps in
the sam
On Wed, 2013-01-09 at 16:58 +0100, Luca Barbato wrote:
> On 09/01/13 16:46, Uoti Urpala wrote:
> > On Tue, 2013-01-08 at 15:34 +0100, Anton Khirnov wrote:
> >> mpeg-specific crap, most probably useless => remove:
> >> int8_t *qscale_table;
> >>
On Tue, 2013-01-08 at 15:34 +0100, Anton Khirnov wrote:
> mpeg-specific crap, most probably useless => remove:
> int8_t *qscale_table;
> int qstride;
> int qscale_type;
IIRC this information is required to support postprocessing MPEG2
properly at least.
> // th
On Sat, 2012-11-03 at 08:14 +0100, Anton Khirnov wrote:
> ---
> configure |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/configure b/configure
> index 9528b5d..dfe1cf1 100755
> --- a/configure
> +++ b/configure
> @@ -3903,6 +3903,6 @@ pkgconfig_generate libavutil
On Sat, 2012-10-20 at 19:07 +0100, Måns Rullgård wrote:
> Uoti Urpala writes:
>
> > On Sat, 2012-10-20 at 11:04 +0200, Reinhard Tartler wrote:
> >> notice them in our tests. This revised patch takes out the definition of
> >> ff_sqrt_tab from avcodec without breaki
On Sat, 2012-10-20 at 11:04 +0200, Reinhard Tartler wrote:
> notice them in our tests. This revised patch takes out the definition of
> ff_sqrt_tab from avcodec without breaking the binaries. Obviously, we
> get a small performance hit in the shared library case, but considering
> the circumstances
On Wed, 2012-10-10 at 11:19 +0200, Diego Biurrun wrote:
> The table is so small that the space gain is not worth the
> performance overhead of cross-library access.
> ---
> Now dropping an instance into libavformat as well, which also
> accesses the table directly.
Note that this commit message wa
rtpdec.h declares a struct field with name "free". The
libavutil/internal.h header has "#define free please_use_av_free", and
this #define affects uses of the field (apparently the rename is applied
everywhere so things still compile...).
BTW isn't including and then defining free, malloc etc as
On Sat, 2012-08-18 at 12:58 +0200, Diego Biurrun wrote:
> On Fri, Aug 17, 2012 at 07:53:46PM +0200, Anton Khirnov wrote:
> > On Fri, 17 Aug 2012 17:59:08 +0200, Diego Biurrun wrote:
> > > Adding unused parameters just to match the function pointer signature
> > > feels wrong. Why don't you add an
On Sun, 2012-08-12 at 19:54 +0300, Uoti Urpala wrote:
+if (s->avctx->codec->capabilities & CODEC_CAP_HWACCEL_VDPAU
Apparently parser code can call this with a NULL avctx->codec, crashing
in the codec->capabilities dereference. I don't know whether
On Tue, 2012-08-14 at 14:56 +0200, Hendrik Leppkes wrote:
> You should also check the profile. A lossless profile can be 8-bit
> 4:2:0, and will still fail the hardware decoder.
I didn't try to catch all cases that would fail to work with hardware.
Rather, I added a test for this case because liba
On Tue, 2012-08-14 at 14:52 +0200, Janne Grunau wrote:
> On 2012-08-12 19:54:10 +0300, Uoti Urpala wrote:
> > The h264_vdpau decoder crashed if output colorspace was not 8-bit 420.
> > Add a check to error out instead (current hardware does not support
> > other colorspaces, s
On Mon, 2012-08-13 at 11:18 +0100, Måns Rullgård wrote:
> aviad rozenhek writes:
> > #define DEFINE_AVERROR(a, b, c, d) (-(int32_t)MKTAG(a, b, c, d))
>
> That conversion is undefined, so it's no good. The correct solution is
It's never undefined, and as far as I can see it shouldn't even fall
>From 1b6400c1ad16635dc86de254d101094a8673a28d Mon Sep 17 00:00:00 2001
From: Uoti Urpala
Date: Tue, 7 Aug 2012 14:48:06 +0300
Subject: [PATCH] h264: vdpau: fix crash with unsupported colorspace
The h264_vdpau decoder crashed if output colorspace was not 8-bit 420.
Add a check to error
On Wed, 2012-08-01 at 14:36 -0700, Ronald S. Bultje wrote:
> On Wed, Aug 1, 2012 at 2:31 PM, Uoti Urpala wrote:
> > On Wed, 2012-08-01 at 21:55 +0100, Måns Rullgård wrote:
> >> If you insist on arguing, I politely request that you at least be right.
> >
> > If you g
On Wed, 2012-08-01 at 21:55 +0100, Måns Rullgård wrote:
> Uoti Urpala writes:
> > On Wed, 2012-08-01 at 21:34 +0100, Måns Rullgård wrote:
> >> It is not possible to get those semantics using the regular Windows
> >> functions.
> >
> > Of course it is, with
On Wed, 2012-08-01 at 21:49 +0100, Måns Rullgård wrote:
> Uoti Urpala writes:
>
> > On Wed, 2012-08-01 at 21:22 +0100, Måns Rullgård wrote:
> >> >>> +int snprintf(char *buffer, size_t bufsize, const char *fmt, ...)
> >
> >> >>> +if ((int)
On Wed, 2012-08-01 at 21:34 +0100, Måns Rullgård wrote:
> Uoti Urpala writes:
> >> +ret = vsnprintf(buffer, bufsize-1, fmt, ap);
> >
> > IIRC MSVC (or the C library) does not support all standard format
> > modifiers, so unless this vsnprintf comes from elsew
On Wed, 2012-08-01 at 21:22 +0100, Måns Rullgård wrote:
> >>> +int snprintf(char *buffer, size_t bufsize, const char *fmt, ...)
> >>> +if ((int)bufsize <= 0) return -1;
> If bufsize > INT_MAX, that cast has unspecified behaviour.
No, it's implementation-defined (you're probably confusing it
On Thu, 2012-07-26 at 07:32 +0200, Luca Barbato wrote:
> +int snprintf(char *buffer, size_t bufsize, const char *fmt, ...)
> +{
> +va_list ap;
> +int ret;
> +
> +if ((int)bufsize <= 0) return -1;
bufsize == 0 is valid.
> +ret = vsnprintf(buffer, bufsize-1, fmt, ap);
IIRC MSVC (or
On Sun, 2012-07-29 at 14:00 +0200, Luca Barbato wrote:
> struct f foo = bar ? (struct f){.a=field, .b=3} : MACRO;
> var stupid = foo.b;
>
> Would require you to transform it to
>
> struct f preprocessor_namespace_0 = { field };
> struct f preprocessor_namespace_1 = { 0, ..., field };
> struct f f
On Sun, 2012-07-29 at 13:04 +0100, Måns Rullgård wrote:
> I'm still missing an explanation of exactly what problem these patches
> are meant to solve.
AFAIK that the existing C->MSVC conversion script is very simple and
naive, does not do any real parsing, and only supports transforming
constructs
On Wed, 2012-07-25 at 12:46 +0100, Måns Rullgård wrote:
> Uoti Urpala writes:
> > On Wed, 2012-07-25 at 10:53 +0100, Måns Rullgård wrote:
> >> Same goes for a number of other compilers. It's unfortunate, but a
> >> small price to pay for portability.
> >
On Wed, 2012-07-25 at 00:08 +0200, Diego Biurrun wrote:
> --- a/libavcodec/bmpenc.c
> -.long_name = NULL_IF_CONFIG_SMALL("BMP image"),
> +.long_name = NULL_IF_CONFIG_SMALL("Bitmap image"),
"Bitmap image" sounds generic. "BMP" more clearly identifies a
particular format IMO.
This
On Wed, 2012-07-25 at 10:53 +0100, Måns Rullgård wrote:
> "Ronald S. Bultje" writes:
> > On Tue, Jul 24, 2012 at 7:45 PM, Loren Merritt
> > wrote:
> >> -long x, y;
> >> -uint32_t pixel;
> >> +uint32_t tmp;
> >>
> >> -for (y = 0; y < h; y++) {
> >> -for (x = 0; x < w; x++)
On Tue, 2012-07-24 at 01:48 +0100, Måns Rullgård wrote:
> Derek Buitenhuis writes:
>
> > On 23/07/2012 8:15 PM, Diego Biurrun wrote:
> >> Most people know the codec as "AAC" and not "Advanced Audio Coding".
> >> ---
> >> libavcodec/aacdec.c |2 +-
> >> 1 files changed, 1 insertions(+), 1 del
On Mon, 2012-07-23 at 20:43 -0400, Derek Buitenhuis wrote:
> On 23/07/2012 8:15 PM, Diego Biurrun wrote:
> > Most people know the codec as "AAC" and not "Advanced Audio Coding".
> > ---
> > libavcodec/aacdec.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
>
> OK. But, should we
On Mon, 2012-04-23 at 00:12 +0300, Martin Storsjö wrote:
> +if (channels <= 0) {
> +av_log(s, AV_LOG_ERROR, "Invalid number of channels %d\n", channels);
> +return AVERROR_INVALIDDATA;
> +}
Since the channel count is read with avio_rb32(), it should have a
sanity check for
On Thu, 2012-04-12 at 17:49 -0700, Dale Curtis wrote:
> Yes, it's related to find_stream_info. Investigation showed all the
> extra time inside of find_stream_info. I suspect changing
> analyze_duration would reduce the severity of the issue, but at the
> risk of impacting duration detection. Rever
On Tue, 2012-03-20 at 12:44 +, Måns Rullgård wrote:
> "Ronald S. Bultje" writes:
> > "mov"byte" , %%"REG_c" \n\t"\
> > +"cmp"end" , %%"REG_c" \n\t"\
> > +"jge1f
On Mon, 2012-03-19 at 20:55 -0700, Ronald S. Bultje wrote:
> Shouldn't avpkt->size be unsigned also?
Unsigned types cause problems for normal code. Making the type unsigned
would break tests like
"if (size_left - avpkt->size < min_left)"
If you want to support packets larger than 2 GiB, then a 64-
>From 842b43abaa197413df791a9c926e322f527edf51 Mon Sep 17 00:00:00 2001
From: Uoti Urpala
Date: Fri, 16 Mar 2012 05:42:26 +0200
Subject: [PATCH] threads: fix old frames returned after
avcodec_flush_buffers()
Calling avcodec_flush_buffers() and then avcodec_decode_video2() with
a 0-sized pac
On Sun, 2012-01-22 at 10:28 +0100, Anton Khirnov wrote:
> AVFrame.age is also a recent deprecation, but for the user apps it only
> means dropping one line, so I think we should drop it.
But isn't that line actually REQUIRED by all Libav versions until one
month ago? Meaning applications can't han
On Wed, 2012-01-18 at 06:35 -0800, Ronald S. Bultje wrote:
> On Wed, Jan 18, 2012 at 5:52 AM, Janne Grunau wrote:
> > On 2012-01-18 12:46:28 +, Måns Rullgård wrote:
> >> "Ronald S. Bultje" writes:
> >> > On Wed, Jan 18, 2012 at 2:46 AM, Janne Grunau
> >> > wrote:
> >> >> Users of libavcodec
On Sun, 2011-12-18 at 19:22 +, Måns Rullgård wrote:
> The next release will have the field marked deprecated, and the one
> after that will remove it. That's how we roll.
BTW doesn't the version check in the patch fail to match this? If you
follow this policy, the next release will probably r
On Sun, 2011-12-18 at 19:42 +0100, Janne Grunau wrote:
> On 2011-12-18 21:37:37 +0200, Uoti Urpala wrote:
> > On Sun, 2011-12-18 at 19:22 +, Måns Rullgård wrote:
> >
> > > The next release will have the field marked deprecated, and the one
> > > after that wi
On Sun, 2011-12-18 at 19:22 +, Måns Rullgård wrote:
> Uoti Urpala writes:
> > Unconditional attribute_deprecated can be used once it's appropriate
> > to expect the users to actually remove use of the deprecated symbol
> > when they see the warning.
>
> I fu
On Sun, 2011-12-18 at 19:05 +, Måns Rullgård wrote:
> Uoti Urpala writes:
>
> > Yes. It should not produce a forced warning now. Having a separate
> > method to request warnings for everything that is scheduled to be
> > changed in the (possibly distant) future w
On Sun, 2011-12-18 at 19:29 +0100, Anton Khirnov wrote:
> On Sun, 18 Dec 2011 19:53:00 +0200, Uoti Urpala
> wrote:
> > On Sun, 2011-12-18 at 17:20 +, Mans Rullgard wrote:
> > > -int age;
> > > +attribute_deprecated int age;
> >
> > IMO set
On Sun, 2011-12-18 at 19:19 +0100, Luca Barbato wrote:
> On 18/12/11 18:53, Uoti Urpala wrote:
> > On Sun, 2011-12-18 at 17:20 +, Mans Rullgard wrote:
> >> -int age;
> >> +attribute_deprecated int age;
> >
> > IMO setting attribute_deprecated im
On Sun, 2011-12-18 at 17:20 +, Mans Rullgard wrote:
> -int age;
> +attribute_deprecated int age;
IMO setting attribute_deprecated immediately is a bad idea. Unless you
want your application to break when used with libavcodec compiled
yesterday you can't remove mentions of the field imm
>From ab12550fb90253175a33770802885203fafd8435 Mon Sep 17 00:00:00 2001
From: Uoti Urpala
Date: Sun, 18 Dec 2011 16:17:07 +0200
Subject: [PATCH] tmv decoder: set correct pix_fmt
Previously the decoder only worked if the user had set avctx->pix_fmt
manually. For some reason the libavform
On Thu, 2011-12-15 at 20:29 -0800, Ronald S. Bultje wrote:
> On Thu, Dec 15, 2011 at 8:26 PM, Uoti Urpala
> wrote:
> If the caller doesn't validate it and it can be INT_MAX then
> it can
> likely also be negative. So if you want to handle that case
>
On Fri, 2011-12-16 at 02:07 +, Måns Rullgård wrote:
> > re_bit_count is the bit offset within the uint32_t. It's never >31, also
> > not before the addition. So for re_bit_count < 31 and n any value, it
> > should mostly work.
>
> 31 + INT_MAX overflows.
>
> Do we trust callers of skip_bits_l
On Mon, 2011-12-12 at 01:10 +0100, Janne Grunau wrote:
> From: Sergey Radionov
>
> On 2011-12-11 16:46:56 +0700, Sergey Radionov wrote:
> > What do you think about this variant?
>
> looks good in principle. I've fixed coding style issues and rewrote
> the commit msg. Please test.
Looks wrong to
On Sun, 2011-12-11 at 13:00 +0700, Sergey Radionov wrote:
> Don't shure that it is perfect, so review needed.
> Problem is that waiters in other threads have ho time to lock
> win32_cond->semaphore.
This problem description is rather unclear.
I assume the issue this refers to is that the pthre
On Tue, 2011-12-06 at 18:20 -0800, Ronald S. Bultje wrote:
> Hi,
>
> On Dec 6, 2011 6:06 PM, "Uoti Urpala" wrote:
> > The pthread_cond_broadcast() implementation in w32pthreads.h looks
> > suspicious - it could wake up the same thread multiple times (if it
> >
On Tue, 2011-12-06 at 22:18 +0700, Sergey Radionov wrote:
> Reason for making this patch
> is https://trac.videolan.org/vlc/ticket/5571
>
>
> Problem is that under windows, when multiple threads waiting on same
> semaphore, and when ReleaseSemaphore called, it impossible to predict
> wich thread
On Wed, 2011-11-16 at 11:31 -0500, Justin Ruggles wrote:
> +copy->internal = av_malloc(sizeof(AVCodecInternal));
A corresponding free() seems to be missing.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/l
On Tue, 2011-11-15 at 18:13 -0500, Justin Ruggles wrote:
> A new field, AVCodecContext.internal is used to hold a new struct
> AVCodecInternal, which has private fields that are not codec-specific and are
> needed only by general libavcodec functions.
> diff --git a/libavcodec/pthread.c b/libavcod
On Sun, 2011-11-13 at 17:11 -0800, Ronald S. Bultje wrote:
> 2011/11/13 Måns Rullgård :
> > been returned. What I did suggest is to allow one decode() call to
> > request a buffer which is then filled over some number of following
> > calls. The proposed API already has a provision for not retur
On Mon, 2011-11-14 at 00:51 +, Måns Rullgård wrote:
> Uoti Urpala writes:
> > If you limit the buffer-locking behavior to "reserve output space, read
> > multiple input packets, return output" then that doesn't change much in
> > the case where the calle
On Sun, 2011-11-13 at 22:47 +, Måns Rullgård wrote:
> You deliberately misconstrue what I say, as always.
You take things personally as usual, and your claims are factually
inaccurate again.
> For the benefit of others who might otherwise be confused by your
> ramblings, I did not at all sugg
On Sun, 2011-11-13 at 20:02 +, Måns Rullgård wrote:
> I guess this can be summed up as, if avcodec_decode_audio4() returned a
> frame at all, the buffer is immediately released. Allowing a decoder to
> get_buffer() in one decode() call and return the frame in a later call
> might be useful and
On Tue, 2011-10-18 at 16:35 +0100, Måns Rullgård wrote:
> Uoti Urpala writes:
>
> > On Tue, 2011-10-18 at 12:50 +0100, Måns Rullgård wrote:
> >> "Ronald S. Bultje" writes:
> >>
> >> > +int64_t dd = d > SQRT_INT
On Tue, 2011-10-18 at 12:50 +0100, Måns Rullgård wrote:
> "Ronald S. Bultje" writes:
>
> > +int64_t dd = d > SQRT_INT64_MAX ? ((d >> 1) * d) >>
> > 29 : (d * d) >> 30;
> > +int64_t ddd = d > SQRT_INT64_MAX || dd >
> > SQRT_INT64_MAX ?
> > +
On Wed, 2011-10-12 at 22:03 +0100, Måns Rullgård wrote:
> git grep 'struct AVClass' comes up blank here...
Maybe you're running it in the wrong repo or something? Or outdated one?
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.or
On Wed, 2011-10-12 at 21:41 +0100, Måns Rullgård wrote:
> > when including avutil/log.h in the code compiled as C++, g++ 4.6
>
> Libav is C, not C++.
I already reported the problem with that code on IRC earlier. It's buggy
C too. As the quoted error messages show, the code does refer to "struct
A
On Tue, 2011-10-11 at 19:00 +0100, Mans Rullgard wrote:
> This function intentionally overflows the signed range on
> the left shift. Using this type-punning avoids errors from
> the overflow checker without disabling this test globally.
> static inline av_const int sign_extend(int val, unsigned
On Mon, 2011-08-29 at 21:04 -0700, Ronald S. Bultje wrote:
> Libavcodec expects values to be set as they would be by libavformat,
> be that in practice done by mplayer or libavformat or whatever the
> demuxer-of-the-day is. It's probably underdocumented, but that doesn't
> make it any less true.
W
On Mon, 2011-08-29 at 19:48 -0700, Ronald S. Bultje wrote:
> On Mon, Aug 29, 2011 at 7:06 PM, Uoti Urpala wrote:
> > The actual problem here was that an application was using avctx->height
> > immediately after avcodec_open2(). The h264 decoder and others do not
> > set
On Mon, 2011-08-29 at 03:15 +0300, Uoti Urpala wrote:
> On Mon, 2011-08-29 at 01:13 +0200, Luca Barbato wrote:
> > Currently we are misreporting the uncropped/multiple-of-macroblocks h264
> > dimensions as the image dimensions. That is bogus and wrong.
>
> I think it'
On Mon, 2011-08-29 at 01:13 +0200, Luca Barbato wrote:
> On 8/29/11 12:59 AM, Uoti Urpala wrote:
> > So you want to delete any indication of cropping (keep cropped width
> > only)? I think the width before cropping is meaningful information.
>
> Currently we are misre
On Sun, 2011-08-28 at 23:47 +0200, Luca Barbato wrote:
> On 8/21/11 6:27 PM, Luca Barbato wrote:
> > This reverts commit b47904d158709bdec1a9d40e83d1abadf50081dc.
> >
> > coded_{width, height} overwrites width and height in avcodec_open
> > ---
> >
> > I'm not sure if the avcodec_open behaviour is
On Thu, 2011-08-25 at 08:36 +0200, madshi wrote:
> > The current code in swscale is based on how 8-bit to
> > 16-bit YUV conversions have been done earlier - basically
> > duplicating each input byte in the output (e.g. 0xf0 -> 0xf0f0,
> > 0x65 -> 0x6565). I believe this is the right thing for full
On Thu, 2011-08-25 at 02:18 +0200, Oskar Arvidsson wrote:
> The current code in swscale is based on how 8-bit to 16-bit YUV conversions
> have been done earlier - basically duplicating each input byte in the output
> (e.g. 0xf0 -> 0xf0f0, 0x65 -> 0x6565). I believe this is the right thing for
>
On Tue, 2011-08-23 at 09:53 +0200, Kostya wrote:
> On Mon, Aug 22, 2011 at 06:23:29PM +0300, Uoti Urpala wrote:
> > On Mon, 2011-08-22 at 11:43 +0200, Kostya wrote:
> > > On Sun, Aug 21, 2011 at 11:37:42PM +0300, Uoti Urpala wrote:
> > > > This doesn't work,
On Mon, 2011-08-22 at 12:53 +0100, Måns Rullgård wrote:
> Defining _BSD_SOURCE on glibc has all sorts of nasty effects, including
> replacing some standard functions with historic BSD variants of the same
> names. Just don't.
This is inaccurate. _BSD_SOURCE is enabled _by default_ in glibc, and
t
On Mon, 2011-08-22 at 11:43 +0200, Kostya wrote:
> On Sun, Aug 21, 2011 at 11:37:42PM +0300, Uoti Urpala wrote:
> > On Sat, 2011-08-20 at 18:14 +0200, Kostya Shishkov wrote:
> > > +static void wavpack_decode_flush(AVCodecContext *avctx)
> > > +{
> > > +
On Sat, 2011-08-20 at 18:14 +0200, Kostya Shishkov wrote:
> +static void wavpack_decode_flush(AVCodecContext *avctx)
> +{
> +WavpackContext *s = avctx->priv_data;
> +int i;
> +
> +for (i = 0; i < s->fdec_num; i++)
> +s->fdec[i]->samples_left = 0;
> +}
This doesn't work, playbac
On Wed, 2011-08-17 at 14:37 -0700, Ronald S. Bultje wrote:
> On Wed, Aug 17, 2011 at 2:26 PM, Uoti Urpala wrote:
> > On Tue, 2011-08-09 at 21:29 +0200, Dustin Brody wrote:
> >> Commit: 12fe75942316dd13dec42502145fd3292882f510
> >> h264: propagate error return values
On Tue, 2011-08-09 at 21:29 +0200, Dustin Brody wrote:
Module: libav
> Branch: master
> Commit: 12fe75942316dd13dec42502145fd3292882f510
>
> Author:Dustin Brody
> Committer: Ronald S. Bultje
> Date: Thu Aug 4 17:47:16 2011 -0400
>
> h264: propagate error return values for AV_LOG_ERROR
On Sat, 2011-07-16 at 23:35 +0100, Mans Rullgard wrote:
> int ff_check_alignment(void){
> static int did_fail=0;
> -DECLARE_ALIGNED(16, int, aligned);
> +LOCAL_ALIGNED_16(int, aligned);
>
> if((intptr_t)&aligned & 15){
The test below doesn't work with LOCAL_ALIGNED. If "aligne
On Wed, 2011-05-04 at 04:38 +0200, Uoti Urpala wrote:
> Commit: 0bd433a916cd8d98fce47742fbf6d0f90ec941c4
>
> Author:Uoti Urpala
> Committer: Ronald S. Bultje
> Date: Sun Apr 24 07:21:30 2011 +0300
>
> asfdec: fix assert failure on invalid files
> diff --git
On Tue, 2011-05-10 at 15:02 +0200, Vladimir Pantelic wrote:
> Uoti Urpala wrote:
> > Disabling the utils.c fallback for asf should be enough. I'm not posting
> attached are 2 patches that both solve the issue, one makes ASF cleanup
> after util.c falls back to binary search
On Sat, 2011-05-07 at 22:53 +0200, Vitor Sessak wrote:
> Order bt PTS even if we lose precision in av_rescale_rnd()
Why not use av_compare_ts()?
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On Tue, 2011-04-26 at 10:42 +0100, Måns Rullgård wrote:
> Uoti Urpala writes:
> > On Sun, 2011-04-24 at 07:05 -0400, Ronald S. Bultje wrote:
> >> On Sun, Apr 24, 2011 at 2:06 AM, Uoti Urpala
> >> wrote:
> >> > The current generic C implementation, whic
On Wed, 2011-04-27 at 11:44 +0200, Luca Barbato wrote:
> On 4/24/11 11:04 PM, Victor wrote:
> > Hi,
> >
> > This is a patch from ffmpeg which fixes a bug that hits mplayer2. On some
> > files, the audio would start several seconds after seeking. I noticed this
> > patch discussed on #ffmpeg-devel a
On Sun, 2011-04-24 at 07:05 -0400, Ronald S. Bultje wrote:
> On Sun, Apr 24, 2011 at 2:06 AM, Uoti Urpala wrote:
> > The current generic C implementation, which is always used when the
> > public header is included from other programs (either directly or
> > through intreadw
beneficial; but in any case this should be enabled at least for
amd64/x86.
>From 389ae3dd6d726731874d316c3b88f3adb4ea8d38 Mon Sep 17 00:00:00 2001
From: Uoti Urpala
Date: Sun, 24 Apr 2011 08:16:43 +0300
Subject: [PATCH] bswap.h: prefer GCC builtins to generic C
Use the built-in bswap functi
ot posting
a patch for that one as the method of disabling it is a matter of
opinion/style; I neither care what method libavformat uses for that nor
want to discuss it.
>From 510006353fcbba1bf1cd64ab26a61190ab3e4ace Mon Sep 17 00:00:00 2001
From: Uoti Urpala
Date: Sun, 24 Apr 2011 07:21:30
On Thu, 2011-04-21 at 06:47 +0200, Reinhard Tartler wrote:
> On Wed, Apr 20, 2011 at 20:06:11 (CEST), Måns Rullgård wrote:
> >> -pkgconfig_generate libavutil "Libav utility library" "$LIBAVUTIL_VERSION"
> >> +pkgconfig_generate libavutil "Libav utility library" "$LIBAVUTIL_VERSION"
> >> "$LIBM"
>
On Thu, 2011-04-14 at 10:59 +0200, Reinhard Tartler wrote:
> Breaking compatibility with released version is never a great idea.
It's questionable to what degree this is "breaking compatibility". The
data formats supported by the encoder are available through the API. The
application could check t
On Mon, 2011-04-04 at 16:56 +0200, Anton Khirnov wrote:
> On Mon, Apr 04, 2011 at 02:38:12PM +, Ronald S. Bultje wrote:
> > I believe URLContext needs a lot of work, and this is easier if it is
> > private. In addition, I believe most users don't need either one API,
> > having two is confusing
89 matches
Mail list logo
