Re: [RFC] Releases

On Mon, May 31, 2010 at 10:56:05PM +0000, Carl Eugen Hoyos wrote:
> Michael Niedermayer <michaelni <at> gmx.at> writes:
> 
> > wmv3 and theora are no audio codecs,
> 
> There is a wmv3 (vc1) test in FATE, but it does not work correctly, imo.

kostya?

[...]

--

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel <at> mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

Re: [PATCH] Make MMX2 put_no_rnd_pixels _x2 and _y2 bitexact

On May 28, 2010, at 9:21 PM, Michael Niedermayer wrote:

> On Fri, May 28, 2010 at 06:49:57PM -0400, David Conrad wrote:
>> On May 28, 2010, at 6:34 PM, Stefan Gehrer wrote:
>> 
>>> On 05/29/2010 12:27 AM, David Conrad wrote:
>>>> On May 28, 2010, at 6:25 PM, Stefan Gehrer wrote:
>>>> 
>>>>> On 05/28/2010 11:49 PM, David Conrad wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> The mmx2/3dnow put_no_rnd functions don't always round correctly, since they compensate for the
+1 in pavgb by subtracting 1 from one of the inputs. This causes our theora decoder to not be bitexact to
libtheora, though I haven't found any real source where the error accumulates enough to be visible.
>>>>>> 
>>>>>> This fixes it by using the property that (a+b)>>1 is equivalent to ~(~a+~b+1)>>1. This makes these
functions 5 cycles slower on my penryn, but on my atom the additional instructions appear to be free
probably due to load stalls.
>>>>> 
>>>>> Wouldn't it be worth creating new bitexact functions, but still
>>>>> override them with the old/faster ones if BITEXACT is not set?
>>>> 
>>>> The problem is that theora must always be bitexact,
>>> 
>>> Why is that? If I don't see the difference I would think
>>> I can decode it with deviation.
>> 
>> Same reason H.264 must be: it's part of the spec.
> 
> and MC in mpeg4 asp which is using these functions

Re: [PATCH] Make MMX2 put_no_rnd_pixels _x2 and _y2 bitexact

On May 30, 2010, at 12:39 PM, Michael Niedermayer wrote:

> On Fri, May 28, 2010 at 06:27:41PM -0400, David Conrad wrote:
>> On May 28, 2010, at 6:25 PM, Stefan Gehrer wrote:
>> 
>>> On 05/28/2010 11:49 PM, David Conrad wrote:
>>>> Hi,
>>>> 
>>>> The mmx2/3dnow put_no_rnd functions don't always round correctly, since they compensate for the +1
in pavgb by subtracting 1 from one of the inputs. This causes our theora decoder to not be bitexact to
libtheora, though I haven't found any real source where the error accumulates enough to be visible.
>>>> 
>>>> This fixes it by using the property that (a+b)>>1 is equivalent to ~(~a+~b+1)>>1. This makes these
functions 5 cycles slower on my penryn, but on my atom the additional instructions appear to be free
probably due to load stalls.
>>> 
>>> Wouldn't it be worth creating new bitexact functions, but still
>>> override them with the old/faster ones if BITEXACT is not set?
>> 
>> The problem is that theora must always be bitexact, and codecs can't set the bitexact flag themselves.
> 
> if you still want it, you could change the used functions under
> if(codec_id == CODEC_ID_THEORA)

Like so?

commit 01049d1c24d450a9247acec6f0f52a9db9ffa55b
Author: David Conrad <lessen42 <at> gmail.com>

Re: [PATCH] Ignore bad mapping in AAC (issue 1882)

On Mon, May 31, 2010 at 10:11 AM, Cyril Russo
<stage.nexvision <at> laposte.net> wrote:
[snip]
>>>
>>> Do you mean get_che top part:
>>>
>>>    if (ac->tag_che_map[type][elem_id]) {
>>>        return ac->tag_che_map[type][elem_id];
>>>    }
>>> is changed to (pseudo code):
>>>    if (ac->tag_che_map[type][elem_id]) {
>>>        if (ac->tags_mapped == tags_per_config[ac->m4ac.chan_config]) {
>>>            return ac->tag_che_map[type][elem_id];
>>>        } else {
>>>            ac->tag_che_map[type][elem_id + 1] = ac->che[type][elem_id];
>>>            ac->tags_mapped++;
>>>            return ac->tag_che_map[type][elem_id + 1];
>>>        }
>>>    }
>>>
>>
>> I don't think this would work for your SCE[0] CPE[0] CPE[0] LFE[0]
>> case because then both CPEs would be mapped to elem_id + 1 = 0 + 1 =
>> 1.
>>
>> I rather mean to have an option in the context and avcodec.h exposed
>> to the user to toggle a completely different (and naive) mapping mode.
>> The mode would bypass the main code of get_che () and rather keep a
>> count of the number of syntax elements of a particular type that have
>> been encountered thus far. I think Alex is thinking the same but I

Re: [RFC] Releases

On Mon, May 31, 2010 at 2:07 PM, Reinhard Tartler <siretart <at> tauware.de> wrote:
> On Mo, Mai 31, 2010 at 19:19:38 (CEST), Ronald S. Bultje wrote:
>
>> On Mon, May 31, 2010 at 11:34 AM, Reinhard Tartler <siretart <at> tauware.de> wrote:
>>> On Mo, Mai 31, 2010 at 17:10:18 (CEST), Ronald S. Bultje wrote:
>>>> Back to FFmpeg. Michael (and many others) would like releases out,
>>>> and hate the classical caricature of releases, because we want
>>>> features for end users (that's anyone that uses an application that
>>>> uses FFmpeg). Now, for example, we'd like users to have vp8 decoding
>>>> support (let's leave the licensing issue aside for a second). In the
>>>> past, that might've been any other codec. That is the veyr point of
>>>> our existence. Running out the next 0.5.x doesn't help achieve this
>>>> purpose, which is why we care less about it.
>>>>
>>>> We'd like a release system that achieves the purpose of getting the
>>>> next big-format decoder to as many end users as possible in the
>>>> least amount of time. Can we think of a release system that achieves
>>>> this?
>>>
>>> I see no problem in backporting features like libvpx support to
>>> ffmpeg-0.5, since it has little potential for regressions.
>>
>> What about (AAC/)SBR? (AAC/)PS? I'm not sure what else is missing but
>> I think WMAVoice, Sipro are also not part of 0.5.x. MMS-TCP?
>>
>> More generally, I'm trying to ask how much you're willing to backport
>> (assuming you do releases, which I'm very much in favour of).
>
> I have always considered any backport nominations by the corresponding
> and responsible maintainer.

Re: [PATCH] MPEG-4 Parametric Stereo decoder

On Sat, May 29, 2010 at 2:16 PM, Vitor Sessak <vitor1001 <at> gmail.com> wrote:
> On 05/29/2010 07:30 PM, Alex Converse wrote:
>> On Sun, May 23, 2010 at 10:29 AM, Vitor Sessak<vitor1001 <at> gmail.com>
>>  wrote:
>>> On 05/20/2010 07:51 PM, Alex Converse wrote:
[...]
>>>> +static int ps_extension(GetBitContext *gb, PSContext *ps, int
>>>> ps_extension_id)
>>>> +{
>>>> +    int e;
>>>> +    int count = get_bits_count(gb);
>>>> +    if (!ps_extension_id) {
>>>> +        ps->enable_ipdopd = get_bits1(gb);
>>>> +        if (ps->enable_ipdopd) {
>>>> +            for (e = 0; e<  ps->num_env; e++) {
>>>> +                int dt = get_bits1(gb);
>>>> +                ipd_data(gb, ps, e, dt);
>>>> +                dt = get_bits1(gb);
>>>> +                opd_data(gb, ps, e, dt);
>>>> +            }
>>>> +        }
>>>> +        skip_bits1(gb);      //reserved_ps
>>>> +    }
>>>> +    return get_bits_count(gb) - count;
>>>> +}
>>>
>>> if (ps_extension_id)
>>>    return 0;
>
> If you prefer without this change, please say so. Or have you simply forgot

Re: [RFC] Releases

On Tue, Jun 01, 2010 at 01:51:37AM +0200, Michael Niedermayer wrote:
> On Mon, May 31, 2010 at 10:56:05PM +0000, Carl Eugen Hoyos wrote:
> > Michael Niedermayer <michaelni <at> gmx.at> writes:
> > 
> > > wmv3 and theora are no audio codecs,
> > 
> > There is a wmv3 (vc1) test in FATE, but it does not work correctly, imo.
> 
> kostya?

IIRC, Carl complained about it already in cvslog: fot FATE test sample
S00040.vc1 FFplay plays all 15 frames while FFmpeg decodes only two.
Since it's raw video, I suspect that the reason may lie outside VC-1 
parser.

> [...]
> 
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Re: [PATCH] Ignore bad mapping in AAC (issue 1882)

On 1 June 2010 02:23, Alex Converse <alex.converse <at> gmail.com> wrote:
> CCEs require correct target element tags. I don't know how to even
> make sense of a CCE in a context where all tags are the same.

We either disable CCE processing or plough ahead as if everything is
fine, I suppose.

> What do people think of the attached approach?

Looks good to me but I think you missed a err_printed = 1; or so.

Best regards,
Rob

Re: [PATCH] RTP H.264 / AVC support

Luca Abeni wrote:
> On 05/30/2010 08:41 PM, Howard Chu wrote:
>> Only 3 lines of code in rtpenc.c were copied literally from h264.c.
>
> Regarding the previous patch you are mentioning: yes, maybe only 3 lines
> are literally copied. But then look at the modifications you introduced
> to ff_rtp_send_h264(), and compare them with libavcodec/h264.c:decode_nal_units()
> (around line 2768 and following...).
>
> Moreover, the code introduced in ff_rtp_send_h264() and in sdp.c:extradata2psets()
> did the same thing (split an "AVC format" frame in NALs) using slightly
> different code (compare "len = (len<<  8) | *r++;" with "nalsize = AV_RB16(r);").
>
> Regarding the new patch: as I said, I do not think this
> ff_avc_parse_nal_units_inplace() is the correct thing to simplify the code.
> (moreover, I am still convinced that this function does the same things
> done by the h264.c code I mentioned above).

OK, this set of patches consolidates the code using a callback function.

--

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Index: libavcodec/h264.c
===================================================================
--- libavcodec/h264.c	(revision 23363)

Re: [PATCH] Declare the url_write buffer parameter as const

On Tue, 1 Jun 2010, Michael Niedermayer wrote:

> On Mon, May 31, 2010 at 11:47:35PM +0300, Martin Storsjö wrote:
> > Hi,
> > 
> > This adds const correctness to the url_write function and all the 
> > protocols implementing it. Additionally, this fixes a warning in the RTSP 
> > code.
> > 
> > // Martin
> >  avio.c      |    2 +-
> >  avio.h      |    4 ++--
> >  file.c      |    2 +-
> >  gopher.c    |    2 +-
> >  http.c      |    4 ++--
> >  librtmp.c   |    2 +-
> >  rtmpproto.c |    2 +-
> >  rtpproto.c  |    2 +-
> >  tcp.c       |    2 +-
> >  udp.c       |    2 +-
> >  10 files changed, 12 insertions(+), 12 deletions(-)
> > 89c902a97df17047b4eb02f51810de6e793eea1d  0001-Declare-the-url_write-buffer-parameter-as-const.patch
> > From 7cb2d7f7c4ee25ca10eaeee0ef70d8fcd848a0eb Mon Sep 17 00:00:00 2001
> > From: Martin Storsjo <martin <at> martin.st>
> > Date: Mon, 31 May 2010 23:36:32 +0300
> > Subject: [PATCH] Declare the url_write buffer parameter as const
> 
> should be ok

Applied, thanks.