Re: [PATCH] libavfilter-soc: implement pad filter

Sorry for the slow reply.

On date Thursday 2009-09-17 02:21:59 +0200, Michael Niedermayer encoded:
[...]
> > Now I'm posting other patches, what I'd like to discuss are these two
> > points:
> > 
> > * I tried both to put the information required for padding (x, y, h,
> >   w, exp_h, exp_w) in the link and pass it in the get_video_buffer()
> >   params, they're pretty equivalent but the second method (as in the
> >   patch) seems more flexible, as the information is not stored
> >   statically in the links, so it doesn't need a reconfiguration when
> >   changing it.  
> 
> yes
> 
> 
> >   (BTW maybe we can as well remove w/h from the link,
> >   that should make simpler to implement variable size filters, I still
> >   have to experiment with this).
> 
> maybe
> 
> > 
> > * I tinkered about the vflip problem much time, and I could'nt find some 
> >   way to keep the previous behavior with the new system.
> >   The new system assumes that the position of the area to pad
> >   (referred by the x/y params in the picref) needs to be invariant
> >   when passing a picref to the next filter.
> >   That's because the pad filter expects this:

Re: [PATCH] Prefer "loglevel" over "logging level number or string" for loglevel.argname

On date Tuesday 2009-09-29 00:47:13 +0200, Stefano Sabatini encoded:
> On date Sunday 2009-09-27 01:42:36 +0200, Stefano Sabatini encoded:
> > Hi, that's almost a bikeshed but I believe this is both more
> > esthetically pleasant and more clear:
> > 
> > -h                  show help
> > -version            show version
> > -L                  show license
> > -formats            show available formats, codecs, protocols, ...
> > -loglevel loglevel  set libav* logging level
> > -n                  enable no-launch mode
> > -d                  enable debug mode
> > -f configfile       use configfile instead of /etc/ffserver.conf
> > 
> > rather than:
> > 
> > -h                  show help
> > -version            show version
> > -L                  show license
> > -formats            show available formats, codecs, protocols, ...
> > -loglevel logging level number or string set libav* logging level
> > -n                  enable no-launch mode
> > -d                  enable debug mode
> > -f configfile       use configfile instead of /etc/ffserver.conf
> > 
> > loglevel meaning is explained in the man page, and to make it
> > eye-parsable it should be rendered as a single token, alternatively we
> > could use:
> > logging_level_number_or_string
> > logging_level

[PATCH] Fix configure on OS X 10.6

Hi,

uname -m on 10.6 returns i386 on 10.6 (unless you use a 64-bit kernel  
which is you don't by default), but gcc now defaults to producing  
x86_64 code on 10.6 if you have a CPU capable of running it regardless.

Thus, this moves the compile check for x86_64 to also be run if a 32- 
bit arch is detected.

commit f6deb9f89cd1448883b9ede5cf3fab758c4edfbc
Author: David Conrad <lessen42 <at> gmail.com>
Date:   Wed Sep 30 19:55:30 2009 -0400

    Check whether 32-bit x86 is really 64-bit
    Fixes configure on OS X 10.6

diff --git a/configure b/configure
index 4e24df0..6b94ef9 100755
--- a/configure
+++ b/configure
 <at>  <at>  -1828,15 +1828,18  <at>  <at>  case "$arch" in
         enable cmov
         enable fast_cmov
         enable fast_unaligned
-        check_cc <<EOF && enable fast_64bit && subarch="x86_64" && spic=$shared
-        int test[sizeof(char*) - 7];
-EOF
     ;;

Re: [PATCH] libavfilter-soc: implement pad filter

On Thu, Oct 01, 2009 at 01:00:16AM +0200, Stefano Sabatini wrote:
> Sorry for the slow reply.
[...]
> 2) the buffer obtained by the pad filter with get_video_buffer() is
> inverted and passed to the previous filter, as Vitor and IIUC Michael
> proposed (check the patch: fix-vflip-logic+vitor.patch).
> 
> Consider the filterchain: "crop=0:0:WIDTH:100, vflip"
> 
> In this scenario the crop filter will take the top 100 lines of the
> image in input.
> 
> 
> This is the picref received in input by vflip.c:get_video_buffer():
> 
>   [fig. 4]
> 
>  O----------+
>  | crop     |
>  |  area    |
>  |          |
>  v          |
>  +----------+
>  |          |
>  |          |
>  |          |
>  |          |
>  |          | 
>  |          |
>  +----------+

Re: [PATCH] Fix configure on OS X 10.6

On Sep 30, 2009, at 8:06 PM, David Conrad wrote:

> Hi,
>
> uname -m on 10.6 returns i386 on 10.6 (unless you use a 64-bit  
> kernel which is you don't by default), but gcc now defaults to  
> producing x86_64 code on 10.6 if you have a CPU capable of running  
> it regardless.
>
> Thus, this moves the compile check for x86_64 to also be run if a 32- 
> bit arch is detected.

Merging the x86_32 and x86_64 sections is a bit better; cmov and  
fast_cmov were being disabled previously.

commit 456a5bc279cd658e348bec4e84e673b3a4b62a8b
Author: David Conrad <lessen42 <at> gmail.com>
Date:   Wed Sep 30 19:55:30 2009 -0400

    Check whether 32-bit x86 is really 64-bit
    Fixes configure on OS X 10.6

diff --git a/configure b/configure
index 4e24df0..ab71cb3 100755
--- a/configure
+++ b/configure
 <at>  <at>  -1817,20 +1817,17  <at>  <at>  case "$arch" in
         enable fast_64bit

Re: Does FFMPEG support FMO in H.264 ?

Hi,
I attached forman qcif using FMO dispersed with 8 slices. I encoded and
decoded with JM 9.8.
but I can't decode it with ffmpeg.

This is my configuration in JM 9.8 when I encode foreman_qcif.yuv

The FMO related parameters in the config file have been modified.
InputFile  = "E:\foreman_qcif.yuv"
FramesToBeEncoded  = 2
num_slice_groups_minus1  = 7
slice_group_map_type  = 2
SliceGroupConfigFileName  = "E:\foreman_qcif.cfg"
RateControlEnable  = 1
Bitrate  = 32000

Regards,

Huy

On Thu, Oct 1, 2009 at 1:16 AM, compn <tempn <at> twmi.rr.com> wrote:

> On Thu, 1 Oct 2009 00:59:33 +0900, Nhat Huy wrote:
> >Hi,
> >When I'm looking for in h264.c, I saw this code:
> >Does FFMPEG support FMO in H.264 ?
> >Best regards,
> >Huy
>
> do you have an FMO sample you could share with us?

Re: Indeo5 beta sample: a bug in the AVI demuxer?

On Thu, Oct 01, 2009 at 12:17:12AM +0200, Michael Niedermayer wrote:
[...]
> 
> PS: this is one of the more weird AVIs ive seen, it should be kept on mphq!

It's Russian ;) And I have a whole CD of them.

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

Re: [PATCH] mp3 muxer: write all metadata

Hi,

On 9/30/09 12:02 AM, Anton Khirnov wrote:
 > [...]
 >
> diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c
> index feccaf7..6663c6a 100644
> --- a/libavformat/id3v2.c
> +++ b/libavformat/id3v2.c
>  <at>  <at>  -244,3 +244,22  <at>  <at>  const AVMetadataConv ff_id3v2_metadata_conv[] = {
>       { "TSOT", "titlesort"},
>       { 0 }
>   };
> +
> +const char ff_id3v2_tags[][4] = {
> +   { 'T', 'A', 'L', 'B'}, { 'T', 'B', 'P', 'M'}, { 'T', 'C', 'O', 'M'},
> +   { 'T', 'C', 'O', 'N'}, { 'T', 'C', 'O', 'P'}, { 'T', 'D', 'E', 'N'},
> +   { 'T', 'D', 'L', 'Y'}, { 'T', 'D', 'O', 'R'}, { 'T', 'D', 'R', 'C'},
> +   { 'T', 'D', 'R', 'L'}, { 'T', 'D', 'T', 'G'}, { 'T', 'E', 'N', 'C'},
> +   { 'T', 'E', 'X', 'T'}, { 'T', 'F', 'L', 'T'}, { 'T', 'I', 'P', 'L'},
> +   { 'T', 'I', 'T', '1'}, { 'T', 'I', 'T', '2'}, { 'T', 'I', 'T', '3'},
> +   { 'T', 'K', 'E', 'Y'}, { 'T', 'L', 'A', 'N'}, { 'T', 'L', 'E', 'N'},
> +   { 'T', 'M', 'C', 'L'}, { 'T', 'M', 'E', 'D'}, { 'T', 'M', 'O', 'O'},
> +   { 'T', 'O', 'A', 'L'}, { 'T', 'O', 'F', 'N'}, { 'T', 'O', 'L', 'Y'},
> +   { 'T', 'O', 'P', 'E'}, { 'T', 'O', 'W', 'N'}, { 'T', 'P', 'E', '1'},
> +   { 'T', 'P', 'E', '2'}, { 'T', 'P', 'E', '3'}, { 'T', 'P', 'E', '4'},
> +   { 'T', 'P', 'O', 'S'}, { 'T', 'P', 'R', 'O'}, { 'T', 'P', 'U', 'B'},
> +   { 'T', 'R', 'C', 'K'}, { 'T', 'R', 'S', 'N'}, { 'T', 'R', 'S', 'O'},
> +   { 'T', 'S', 'O', 'A'}, { 'T', 'S', 'O', 'P'}, { 'T', 'S', 'O', 'T'},
> +   { 'T', 'S', 'R', 'C'}, { 'T', 'S', 'S', 'E'}, { 'T', 'S', 'S', 'T'},

Re: [PATCH] id3v2: read TXXX frames

On Tue, Sep 29, 2009 at 02:21:42PM +0200, Michael Niedermayer wrote:
> 
> that is obfuscated
> 
better now?

Anton Khirnov

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

Re: [PATCH] speex in ogg muxer

On Sep 5, 2009, at 8:20 PM, Justin Ruggles wrote:

> Justin Ruggles wrote:
>
>> Justin Ruggles wrote:
>>
>>> Justin Ruggles wrote:
>>>
>>>> Justin Ruggles wrote:
>>>>
>>>>> Justin Ruggles wrote:
>>>>>
>>>>> Now I think I know what is going wrong, and there is nothing we  
>>>>> can do
>>>>> about it I think.  speexenc does some weird things with granule
>>>>> positions.  It starts out for a long time with granulepos=0 even  
>>>>> though
>>>>> it is encoding audio, then when it starts writing granule  
>>>>> positions it
>>>>> is not always in sync with the start of the stream.  Below is a  
>>>>> little
>>>>> snippet from a comparison of an original spx file to a copied  
>>>>> spx file.
>>>>> Each packet should be 320 samples.
>>>>>
>>>>> [...]
>>>> So... I figured it out, but you may not want to know the answer. ;)
>>>>
>>>> The granulepos of the first packet is supposed to be interpreted as
>>>> smaller than the full frame size by calculating what the