Re: [PATCH] RTP depacketizer for QCELP

Hi

On 11/29/2010 02:19 PM, Martin Storsjö wrote:
> [..]
> I refactored this a bit, making both this code path and the old one much 
> cleaner, see attached. The actual depacketizer is unchanged from the 
> previous patchset.
> 
> // Martin
>[..]
>+struct InterleavePacket {
>+    int pos;
>+    int size;
>+    /* The largest frame is 35 bytes, only 10 frames are allowed per
>+     * packet, and we return the first one immediately, so allocate
>+     * space for 9 frames */
>+    uint8_t data[35*9];
>+};
>+
>+struct PayloadContext {
>+    int interleave_size;
>+    int interleave_index;
>+    struct InterleavePacket group[6];
>+    int group_finished;
>+
>+    /* The maximum packet size, 10 frames of 35 bytes each, and one
>+     * packet header byte. */
>+    uint8_t  next_data[1 + 35*10];
>+    int      next_size;
>+    uint32_t next_timestamp;

Re: [PATCH] Port gradfun to libavfilter (GCI)

On Mon, Nov 29, 2010 at 9:48 PM, Nolan L <nol888 <at> gmail.com> wrote:
>
> Here is the resulting patch from the first round of feedback.
>

Pushing a third revision of the code, addressing missing documentation
(mostly) and slight code changes related to confusing macros.

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

Re: [PATCH] Windows Television (.wtv) demuxer

On Sat, Nov 27, 2010 at 08:20:18PM +1100, Peter Ross wrote:
> Bump. Minor patch update:
>     Support MPEG Layer 1/2/3 (MPEG1WAVEFORMATEX)
>     Associate some names with the unknown GUIDs
> 
> On Sat, Nov 13, 2010 at 03:05:49PM +1100, Peter Ross wrote:
> > Updated patch set. Improvements:
> >     demuxer now ignores unsupported streams
> >     placeholder streams are also ignored
> >     use metadata 'language' tag
> >     added AC3 GUID
> 
> -- Peter
> (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)

[...]
> +static int find_stream_index(AVFormatContext *s, int id)
> +{
> +    int i;
> +    for (i = 0; i < s->nb_streams; i++) {
> +        if (s->streams[i]->id == id)
> +            return i;
> +    }
> +    return -1;
> +}

can be factored with   get_sindex() of gxf.c

otherwise this looks ok if tested (also with trashed streams & valgrind)

Re: [PATCH 6/6] Add rotate90 filter.

On Tue, Nov 30, 2010 at 11:31:54PM +0100, Stefano Sabatini wrote:
> On date Tuesday 2010-11-23 22:34:01 -0200, Ramiro Polla encoded:
> > On Tue, Nov 23, 2010 at 10:26 PM, Stefano Sabatini
> > <stefano.sabatini-lala <at> poste.it> wrote:
> > > On date Tuesday 2010-11-23 18:46:17 -0500, Ronald S. Bultje encoded:
> > >> On Tue, Nov 23, 2010 at 6:34 PM, Stefano Sabatini
> > >> <stefano.sabatini-lala <at> poste.it> wrote:
> > >> > On date Tuesday 2010-11-23 15:18:14 -0800, Baptiste Coudurier encoded:
> > >> >> On 11/23/2010 12:29 PM, Stefano Sabatini wrote:
> > >> > [...]
> > >> >> What's wrong with the rotate filter ?
> > >> >
> > >> > overkill for just rotating by 90 degrees (and slower).
> > >>
> > >> So integrate this as an optimization in that filter.
> > >
> > > That's actually a good idea, but I was thinking about the rotate
> > > filter like something a bit more general, which should take:
> > > angle_expr:output_size:padding_color
> > >
> > > the rotate90 is just simpler and does what the 95% of the users need
> > > (and I want to take some time to actually study the algorithms for
> > > spatial transform of that kind), that's why I thought that having two
> > > separate filters may be a good idea, and would let us to deliver the
> > > simple filter *now*.
> > 
> > Why the rush? An optimization to the rotate filter seems like a better
> > path to me too.
> 
> It's still overkill if you just want to rotate by 90 degrees (which is

Re: [PATCH] yadif sse2/ssse3

On Tue, Nov 30, 2010 at 09:33:27AM +0100, Luca Barbato wrote:
> On 11/30/2010 05:52 AM, Baptiste Coudurier wrote:
> > Hi Michael,
> > 
> > On 11/29/10 4:46 PM, Michael Niedermayer wrote:
> >> On Sat, Nov 20, 2010 at 06:32:39PM -0800, Baptiste Coudurier wrote:
> >>> Hi guys,
> >>>
> >>> $subject.
> >> [...]
> >>     > +#if HAVE_SSE
> >>> +    DECLARE_ALIGNED(16, uint8_t, tmp0[16]);
> >>> +    DECLARE_ALIGNED(16, uint8_t, tmp1[16]);
> >>> +    DECLARE_ALIGNED(16, uint8_t, tmp2[16]);
> >>> +    DECLARE_ALIGNED(16, uint8_t, tmp3[16]);
> >>> +#else
> >>>      uint64_t tmp0, tmp1, tmp2, tmp3;
> >>> +#endif
> >>
> >> This seems unneeded (align always should be fine)
> > 
> > I'm not sure I understand, do you mean I should remove the DECLARE_ALIGNED ?
> > 
> 
> remove the ifdef and keep the same var declaration (aligned) probably.

yes

[...]
--

-- 

Re: [PATCH] Port gradfun to libavfilter (GCI)

On date Tuesday 2010-11-30 19:27:14 -0500, Nolan L encoded:
> On Mon, Nov 29, 2010 at 9:48 PM, Nolan L <nol888 <at> gmail.com> wrote:
> >
> > Here is the resulting patch from the first round of feedback.
> >
> 
> Pushing a third revision of the code, addressing missing documentation
> (mostly) and slight code changes related to confusing macros.

> diff --git a/doc/filters.texi b/doc/filters.texi
> index 1cba2d6..f266ff0 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
>  <at>  <at>  -333,6 +333,32  <at>  <at>  frei0r=perspective:0.2/0.2:0.8/0.2
>  For more information see:
>   <at> url{http://piksel.org/frei0r}
>  
> + <at> section gradfun
> +
> +Fix the banding artifacts that are sometimes introduced into nearly flat
> +regions by truncation to 8bit colordepth.
> +Interpolates the gradients that should go where the bands are, and
> +dithers them.
> +
> +The filter takes two optional parameters, separated by ':',
> +" <at> var{strength}: <at> var{radius}"
> +
> + <at> var{strength} is the maximum amount by which the filter will change
> +any one pixel. Also the threshold for detecting nearly flat
> +regions (default: 1.2).

Re: [PATCH] Add missing overflow checks in av_image_fill_pointers() and av_image_fill_linesizes().

On Fri, Nov 26, 2010 at 04:23:47PM +0100, Stefano Sabatini wrote:
> ---
>  libavcore/imgutils.c |   17 ++++++++++++++++-
>  1 files changed, 16 insertions(+), 1 deletions(-)
> 
> diff --git a/libavcore/imgutils.c b/libavcore/imgutils.c
> index 554639f..a2adaa6 100644
> --- a/libavcore/imgutils.c
> +++ b/libavcore/imgutils.c
>  <at>  <at>  -71,6 +71,8  <at>  <at>  int av_image_fill_linesizes(int linesizes[4], enum PixelFormat pix_fmt, int widt
>          return AVERROR(EINVAL);
>  
>      if (desc->flags & PIX_FMT_BITSTREAM) {
> +        if (width > (INT_MAX -7) / (desc->comp[0].step_minus1+1))
> +            return AVERROR(EINVAL);
>          linesizes[0] = (width * (desc->comp[0].step_minus1+1) + 7) >> 3;
>          return 0;
>      }
>  <at>  <at>  -78,7 +80,10  <at>  <at>  int av_image_fill_linesizes(int linesizes[4], enum PixelFormat pix_fmt, int widt
>      av_image_fill_max_pixsteps(max_step, max_step_comp, desc);
>      for (i = 0; i < 4; i++) {
>          int s = (max_step_comp[i] == 1 || max_step_comp[i] == 2) ? desc->log2_chroma_w : 0;
> -        linesizes[i] = max_step[i] * (((width + (1 << s) - 1)) >> s);
> +        int shifted_w = ((width + (1 << s) - 1)) >> s;
> +        if (max_step[i] > SIZE_MAX / shifted_w)

SIZE_MAX ?

[...]

Re: [PATCH] improve yuv422p to rgb in libswscale

On Tue, Nov 30, 2010 at 04:07:20AM -0800, Baptiste Coudurier wrote:
> Hi
> 
> $subject, use full vertical data when convert 422p, improve quality a lot.
> 
> -- 
> Baptiste COUDURIER
> Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
> FFmpeg maintainer                                  http://www.ffmpeg.org

>  x86/yuv2rgb_template.c |   25 ++++-------
>  yuv2rgb.c              |  109 ++++++-------------------------------------------
>  2 files changed, 26 insertions(+), 108 deletions(-)
> 16f384c9b114c76572a539511c42267ce2942c67  yuv422p_to_rgb.patch

this looks like it would make 420p->rgb quite a bit slower.
If so thats a problem.
making 422p->rgb slower isnt a real problem as it can be changed to 420p
by manipulating linesizes

[...]
--

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.

_______________________________________________

Re: [PATCH] improve yuv422p to rgb in libswscale

On 11/30/2010 05:13 PM, Michael Niedermayer wrote:
> On Tue, Nov 30, 2010 at 04:07:20AM -0800, Baptiste Coudurier wrote:
>> Hi
>>
>> $subject, use full vertical data when convert 422p, improve quality a lot.
>>
>> --
>> Baptiste COUDURIER
>> Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
>> FFmpeg maintainer                                  http://www.ffmpeg.org
>
>>   x86/yuv2rgb_template.c |   25 ++++-------
>>   yuv2rgb.c              |  109 ++++++-------------------------------------------
>>   2 files changed, 26 insertions(+), 108 deletions(-)
>> 16f384c9b114c76572a539511c42267ce2942c67  yuv422p_to_rgb.patch
>
> this looks like it would make 420p->rgb quite a bit slower.

Do you think changing >>1 to >>vshift would make is quite a bit slower ?

> If so thats a problem.
> making 422p->rgb slower isnt a real problem as it can be changed to 420p
> by manipulating linesizes

That's what I want to avoid, this produces crap.

--

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org

Re: PATCH: fix crash <at> deinterlace.asm missing .text section

On Sun, Nov 28, 2010 at 10:15:39PM +0800, avcoder wrote:
> Dear:
> 
> the yasm version's deinterlace forgets the .text section, all codes are
> compiled into data section currently, it will cause exception at runtime.
> 
> the following tiny patch fixes this issue
> 
> diff --git a/libavcodec/x86/deinterlace.asm b/libavcodec/x86/deinterlace.asm
> index 5db9464..76a096e 100644
> --- a/libavcodec/x86/deinterlace.asm
> +++ b/libavcodec/x86/deinterlace.asm
>  <at>  <at>  -27,6 +27,8  <at>  <at>  SECTION_RODATA
> 
>  cextern pw_4
> 
> +SECTION .text
> +
>  %macro DEINTERLACE 1
>  %ifidn %1, inplace
>  ;void ff_deinterlace_line_inplace_mmx(const uint8_t *lum_m4, const uint8_t
> *lum_m3, const uint8_t *lum_m2, const uint8_t *lum_m1, const uint8_t *lum,
>  int size)
> 
> 
> -- 
> -----------------------------------------------------------------------------------------
> My key fingerprint: d1:03:f5:32:26:ff:d7:3c:e4:42:e3:51:ec:92:78:b2

>  deinterlace.asm |    2 ++