Re: [libav-devel] [PATCH 066/115] vorbis: Convert to the new bitstream reader

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 +++--- > > >  

Re: [libav-devel] [PATCH] vorbis: Do not assume amplitude_bits to be less than 32

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_idx;

Re: [libav-devel] [PATCH] mov: detect cover art pictures by content

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

Re: [libav-devel] [EVIL/PATCH] The Evil Plan, part I

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 says.

Re: [libav-devel] [EVIL/PATCH] The Evil Plan, part I

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 at 64.

Re: [libav-devel] [EVIL/PATCH] The Evil Plan, part I

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. // those

Re: [libav-devel] [EVIL/PATCH] The Evil Plan, part I

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; int qstride; int qscale_type

Re: [libav-devel] [EVIL/PATCH] The Evil Plan, part I

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 same

Re: [libav-devel] [PATCH] configure: add lavu dependency to lavr/lavfi .pc files

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 Libav

Re: [libav-devel] [PATCH v2] avutil: reintroduce ff_sqrt_tab to restore ABI compatibility

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, I

Re: [libav-devel] [PATCH v2] avutil: reintroduce ff_sqrt_tab to restore ABI compatibility

On Sat, 2012-10-20 at 19:07 +0100, Måns Rullgård wrote: Uoti Urpala uoti.urp...@pp1.inet.fi 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 breaking the binaries

Re: [libav-devel] [PATCH] avutil: Duplicate ff_log2_tab instead of sharing it across libs

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 was

Re: [libav-devel] [PATCH] h264: vdpau: fix crash with unsupported colorspace

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 anyone has an opinion on whether

Re: [libav-devel] [PATCH 05/17] avtools: fix show_foo() signatures.

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 di...@biurrun.de wrote: Adding unused parameters just to match the function pointer signature feels wrong. Why don't

[libav-devel] struct field free renamed to please_use_av_free

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 stdlib.h and then defining free, malloc

Re: [libav-devel] [PATCH] h264: vdpau: fix crash with unsupported colorspace

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, so successful decoding

Re: [libav-devel] [PATCH] h264: vdpau: fix crash with unsupported colorspace

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

[libav-devel] [PATCH] h264: vdpau: fix crash with unsupported colorspace

From 1b6400c1ad16635dc86de254d101094a8673a28d Mon Sep 17 00:00:00 2001 From: Uoti Urpala uau@glyph.nonexistent.invalid 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

Re: [libav-devel] [PATCH] msvc: check for snprintf

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 the C

Re: [libav-devel] [PATCH] msvc: check for snprintf

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 with

Re: [libav-devel] [PATCH] msvc: check for snprintf

On Wed, 2012-08-01 at 21:34 +0100, Måns Rullgård wrote: Uoti Urpala uoti.urp...@pp1.inet.fi 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 elsewhere, you need more

Re: [libav-devel] [PATCH] msvc: check for snprintf

On Wed, 2012-08-01 at 21:49 +0100, Måns Rullgård wrote: Uoti Urpala uoti.urp...@pp1.inet.fi 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)bufsize = 0) return -1; If bufsize INT_MAX

Re: [libav-devel] [PATCH] msvc: check for snprintf

On Wed, 2012-08-01 at 21:55 +0100, Måns Rullgård wrote: Uoti Urpala uoti.urp...@pp1.inet.fi 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 enough workarounds

Re: [libav-devel] [PATCH] msvc: check for snprintf

On Wed, 2012-08-01 at 14:36 -0700, Ronald S. Bultje wrote: On Wed, Aug 1, 2012 at 2:31 PM, Uoti Urpala uoti.urp...@pp1.inet.fi 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 get to that level

Re: [libav-devel] [PATCH 2/3] lavf/utils.c: : expand AVRational literals.

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

Re: [libav-devel] [PATCH 2/7] vf_hqdn3d: simplify and optimize

On Wed, 2012-07-25 at 10:53 +0100, Måns Rullgård wrote: Ronald S. Bultje rsbul...@gmail.com writes: On Tue, Jul 24, 2012 at 7:45 PM, Loren Merritt lor...@u.washington.edu wrote: -long x, y; -uint32_t pixel; +uint32_t tmp; -for (y = 0; y h; y++) { -for (x

Re: [libav-devel] [PATCH 2/4] Improve descriptiveness of a number of codec and container long names

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 only

Re: [libav-devel] [PATCH 2/7] vf_hqdn3d: simplify and optimize

On Wed, 2012-07-25 at 12:46 +0100, Måns Rullgård wrote: Uoti Urpala uoti.urp...@pp1.inet.fi 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. What compilers are those

Re: [libav-devel] [PATCH] aac: Mention abbreviation as well in long_name

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 not change

Re: [libav-devel] [PATCH] aac: Mention abbreviation as well in long_name

On Tue, 2012-07-24 at 01:48 +0100, Måns Rullgård wrote: Derek Buitenhuis derek.buitenh...@gmail.com 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

Re: [libav-devel] [PATCH] audemux: Add a sanity check for the number of channels

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 upper

Re: [libav-devel] [PATCH 1/6] bytestream: make buf_size unsigned for init functions

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-bit

Re: [libav-devel] [PATCH 8/8] cabac: add overread protection to BRANCHLESS_GET_CABAC().

On Tue, 2012-03-20 at 12:44 +, Måns Rullgård wrote: Ronald S. Bultje rsbul...@gmail.com writes: movbyte , %%REG_c \n\t\ +cmpend , %%REG_c \n\t\ +jge1f

[libav-devel] Fix old video frames returned after avcodec_flush_buffers()

From 842b43abaa197413df791a9c926e322f527edf51 Mon Sep 17 00:00:00 2001 From: Uoti Urpala uau@glyph.nonexistent.invalid Date: Fri, 16 Mar 2012 05:42:26 +0200 Subject: [PATCH] threads: fix old frames returned after avcodec_flush_buffers() Calling avcodec_flush_buffers

Re: [libav-devel] [RFC/PATCH] The Small Bump

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

Re: [libav-devel] [PATCH 1/2] threads: change the default for threads back to 1

On Wed, 2012-01-18 at 06:35 -0800, Ronald S. Bultje wrote: On Wed, Jan 18, 2012 at 5:52 AM, Janne Grunau janne-li...@jannau.net wrote: On 2012-01-18 12:46:28 +, Måns Rullgård wrote: Ronald S. Bultje rsbul...@gmail.com writes: On Wed, Jan 18, 2012 at 2:46 AM, Janne Grunau

[libav-devel] [PATCH] fix tmv decoder pix_fmt

From ab12550fb90253175a33770802885203fafd8435 Mon Sep 17 00:00:00 2001 From: Uoti Urpala uau@glyph.nonexistent.invalid 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

Re: [libav-devel] [PATCH] avcodec: deprecate AVFrame.age

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

Re: [libav-devel] [PATCH] avcodec: deprecate AVFrame.age

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 immediately is a bad idea. Why? For reasons

Re: [libav-devel] [PATCH] avcodec: deprecate AVFrame.age

On Sun, 2011-12-18 at 19:29 +0100, Anton Khirnov wrote: On Sun, 18 Dec 2011 19:53:00 +0200, Uoti Urpala uoti.urp...@pp1.inet.fi wrote: On Sun, 2011-12-18 at 17:20 +, Mans Rullgard wrote: -int age; +attribute_deprecated int age; IMO setting attribute_deprecated

Re: [libav-devel] [PATCH] avcodec: deprecate AVFrame.age

On Sun, 2011-12-18 at 19:05 +, Måns Rullgård wrote: Uoti Urpala uoti.urp...@pp1.inet.fi 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 would be more

Re: [libav-devel] [PATCH] avcodec: deprecate AVFrame.age

On Sun, 2011-12-18 at 19:22 +, Måns Rullgård wrote: Uoti Urpala uoti.urp...@pp1.inet.fi 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 fully expect any user

Re: [libav-devel] [PATCH] avcodec: deprecate AVFrame.age

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 will remove it. That's how we roll. I

Re: [libav-devel] [PATCH] avcodec: deprecate AVFrame.age

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

Re: [libav-devel] [PATCH] get_bits: introduce safe bitreading to prevent overreads.

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_long()

Re: [libav-devel] [PATCH] get_bits: introduce safe bitreading to prevent overreads.

On Thu, 2011-12-15 at 20:29 -0800, Ronald S. Bultje wrote: On Thu, Dec 15, 2011 at 8:26 PM, Uoti Urpala uoti.urp...@pp1.inet.fi 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

Re: [libav-devel] [PATCH 1/2] w32threads: wait for the waked thread in pthread_cond_signal

On Mon, 2011-12-12 at 01:10 +0100, Janne Grunau wrote: From: Sergey Radionov rsa...@gmail.com 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

Re: [libav-devel] [PATCH 1/1] libavcodec/phtread.c: fixed deadlock under win32

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 will

Re: [libav-devel] [PATCH 1/1] libavcodec/phtread.c: fixed deadlock under win32

On Tue, 2011-12-06 at 18:20 -0800, Ronald S. Bultje wrote: Hi, On Dec 6, 2011 6:06 PM, Uoti Urpala uoti.urp...@pp1.inet.fi wrote: The pthread_cond_broadcast() implementation in w32pthreads.h looks suspicious - it could wake up the same thread multiple times (if it re-enters wait fast

Re: [libav-devel] [PATCH] avcodec: move some AVCodecContext fields to an internal struct.

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

Re: [libav-devel] [PATCH] avcodec: move some AVCodecContext fields to an internal struct.

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

Re: [libav-devel] [PATCH 3/9] Add avcodec_decode_audio4().

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

Re: [libav-devel] [PATCH 3/9] Add avcodec_decode_audio4().

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

Re: [libav-devel] [PATCH 3/9] Add avcodec_decode_audio4().

On Mon, 2011-11-14 at 00:51 +, Måns Rullgård wrote: Uoti Urpala uoti.urp...@pp1.inet.fi 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 caller can immediately provide

Re: [libav-devel] [PATCH 3/9] Add avcodec_decode_audio4().

On Sun, 2011-11-13 at 17:11 -0800, Ronald S. Bultje wrote: 2011/11/13 Måns Rullgård m...@mansr.com: 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

Re: [libav-devel] [PATCH] prevent overflow

On Tue, 2011-10-18 at 12:50 +0100, Måns Rullgård wrote: Ronald S. Bultje rsbul...@gmail.com 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 ? +

Re: [libav-devel] [PATCH] prevent overflow

On Tue, 2011-10-18 at 16:35 +0100, Måns Rullgård wrote: Uoti Urpala uoti.urp...@pp1.inet.fi writes: On Tue, 2011-10-18 at 12:50 +0100, Måns Rullgård wrote: Ronald S. Bultje rsbul...@gmail.com writes: +int64_t dd = d SQRT_INT64_MAX ? ((d 1) * d) 29 : (d

Re: [libav-devel] fix build error when using avutil/log.h with C++ code

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

Re: [libav-devel] fix build error when using avutil/log.h with C++ code

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

Re: [libav-devel] [PATCH/RFC] mathops: remove undefined behaviour from sign_extend()

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

Re: [libav-devel] [PATCH] Revert h264: Properly set coded_{width, height} when parsing H.264.

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's quite a stretch to claim

Re: [libav-devel] [PATCH] Revert h264: Properly set coded_{width, height} when parsing H.264.

On Mon, 2011-08-29 at 19:48 -0700, Ronald S. Bultje wrote: On Mon, Aug 29, 2011 at 7:06 PM, Uoti Urpala uoti.urp...@pp1.inet.fi 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 width

Re: [libav-devel] [PATCH] Revert h264: Properly set coded_{width, height} when parsing H.264.

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.

Re: [libav-devel] [PATCH] Revert h264: Properly set coded_{width, height} when parsing H.264.

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 the expected

Re: [libav-devel] [PATCH] Revert h264: Properly set coded_{width, height} when parsing H.264.

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 misreporting the uncropped/multiple

Re: [libav-devel] [RFC] M-bit to N-bit YUV conversions

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 full

Re: [libav-devel] [PATCH 1/3] WavPack decoder: implement flush function

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, playback still produces CRC error messages after

Re: [libav-devel] [PATCH 1/3] WavPack decoder: implement flush function

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) +{ +WavpackContext *s = avctx-priv_data; +int i

Re: [libav-devel] [PATCH] hyscale_fast_MMX2 segfaults on GNU/Linux due to failure to detect MAP_ANONYMOUS

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

Re: [libav-devel] [PATCH 1/3] WavPack decoder: implement flush function

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, playback still

Re: [libav-devel] [libav-commits] h264: propagate error return values for AV_LOG_ERROR-triggering events

On Tue, 2011-08-09 at 21:29 +0200, Dustin Brody wrote: Module: libav Branch: master Commit: 12fe75942316dd13dec42502145fd3292882f510 Author:Dustin Brody li...@parsoma.net Committer: Ronald S. Bultje rsbul...@gmail.com Date: Thu Aug 4 17:47:16 2011 -0400 h264: propagate error

Re: [libav-devel] [libav-commits] h264: propagate error return values for AV_LOG_ERROR-triggering events

On Wed, 2011-08-17 at 14:37 -0700, Ronald S. Bultje wrote: On Wed, Aug 17, 2011 at 2:26 PM, Uoti Urpala uoti.urp...@pp1.inet.fi wrote: On Tue, 2011-08-09 at 21:29 +0200, Dustin Brody wrote: Commit: 12fe75942316dd13dec42502145fd3292882f510 h264: propagate error return values for AV_LOG_ERROR

Re: [libav-devel] [PATCH 1/3] Use LOCAL_ALIGNED in ff_check_alignment()

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 aligned is

Re: [libav-devel] [RFC] Fix asfdec regression

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, This makes little sense

Re: [libav-devel] [libav-commits] asfdec: fix assert failure on invalid files

On Wed, 2011-05-04 at 04:38 +0200, Uoti Urpala wrote: Commit: 0bd433a916cd8d98fce47742fbf6d0f90ec941c4 Author:Uoti Urpala uoti.urpala.pp1.inet.fi Committer: Ronald S. Bultje rsbul...@gmail.com Date: Sun Apr 24 07:21:30 2011 +0300 asfdec: fix assert failure on invalid files diff

Re: [libav-devel] [PATCH] avi: try to synchronize the points in time of the starts of streams after seeking.

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 at

[libav-devel] [PATCH] Use GCC builtins in bswap.h

be 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 uau@glyph.nonexistent.invalid Date: Sun, 24 Apr 2011 08:16:43 +0300 Subject: [PATCH] bswap.h: prefer GCC builtins to generic C Use

Re: [libav-devel] [PATCH] Use GCC builtins in bswap.h

On Sun, 2011-04-24 at 07:05 -0400, Ronald S. Bultje wrote: On Sun, Apr 24, 2011 at 2:06 AM, Uoti Urpala uoti.urp...@pp1.inet.fi wrote: The current generic C implementation, which is always used when the public header is included from other programs (either directly or through intreadwrite.h

Re: [libav-devel] [PATCH] Add missing inter-library dependencies to generated .pc files

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 pkgconfig_generate

Re: [libav-devel] [PATCH] Avio cleanup II

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, in