Re: [silviapfeiffer1 <at> gmail.com: [foms] FOMS 2009 CFP deadline extension]

On Fri, Oct 31, 2008 at 06:28:09PM +0100, Diego Biurrun wrote:
> Ouch, 2 months of delay..
> 
> On Mon, Aug 18, 2008 at 09:44:17PM +1000, Peter Ross wrote:
> > On Mon, Aug 18, 2008 at 11:24:26AM +0100, Robert Swain wrote:
> > > 2008/8/18 Måns Rullgård <mans <at> mansr.com>:
> > > >
> > > > Robert Swain wrote:
> > > >> 2008/8/18 Diego Biurrun <diego <at> biurrun.de>:

> > My QTH is Australia and I was planning to attend LCA2009. I am willing to help
> > out with a paper.
> 
> If you will attend LCA, you should definitely stop by FOMS, the FOMS
> schedule is designed to be compatible with people attending LCA.
> 
> Now Silvia has renewed my invitation, sponsorship is possible, but not
> yet sure.  If somebody else is willing and able to travel and deemed a
> better representative then I'm not going to insist that I go down under.
> But somebody should definitely attend.
> 
> So Peter, will you be there in any case?

Yes!

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)

_______________________________________________

Re: [RFC] Channel layouts

On Thu, Oct 30, 2008 at 11:34:09PM +0100, Michael Niedermayer wrote:
> On Thu, Oct 30, 2008 at 11:31:53PM +1100, Peter Ross wrote:
> > On Sun, Oct 26, 2008 at 12:06:52PM +1100, Peter Ross wrote:
> > > On Sat, Oct 25, 2008 at 11:32:46AM +0200, Michael Niedermayer wrote:
> > > > On Sat, Oct 25, 2008 at 03:34:16PM +1100, Peter Ross wrote:
> > > > > On Tue, Sep 23, 2008 at 10:43:22PM +1000, Peter Ross wrote:
> > > > > > On Sun, Sep 07, 2008 at 08:58:28PM +1000, Peter Ross wrote:
> > > > > > > On Sat, Aug 30, 2008 at 11:05:43AM +1000, Peter Ross wrote:
> > > > > > > > On Fri, Aug 29, 2008 at 04:28:00PM +1000, Peter Ross wrote:
> > > > > > > > > Hi.
> > > > > > > > > 
> > > > > > > > > This patch adds the notion of channel layouts to libavcodec.
> > > > > > > > 
> > > > > > > > Patch updated. Thanks for the feedback.
> > > > > > > 
> > > > > > > Patch updated.
> > > > > > 
> > > > > > Patch updated.
> > > > > 
> > > > > Patch updated. (See the parent post for the RIFF/WAV patch.)
> > > 
> > > Patch updated.
> > 
> > Patch updated (#7).
> 
> iam not 100% happy about the design but as we have no other suggestions
> nor patches by anyone, this is definitly a big step forward from what we
> have now so, patch ok

Thanks. IIRC, the RIFF demuxer patch still need approving.

[PATCH] H.264: decode picture timing SEI message and get field order

Hi,

I wrote a patch which implements decoding of picture timing SEI.

[Current problems]
libavcodec derives field order from POCs.

cur->top_field_first = cur->field_poc[0] < cur->field_poc[1];

It assumes BFF if two POSs are equal. This is not always correct.

And it derives AVFrame::interlaced_frame from used decoding process.

cur->interlaced_frame = FIELD_OR_MBAFF_PICTURE;

Sometimes this is not correct. Interlaced/progressive mode of post-decoding 
processes such as deinterlacing and color space conversion is not always 
same as the mode used during decoding. H.264 for example allows to encode 
an interlaced frame using a progressive algorithm. Sample: premiere-paff.ts 
(http://x264.nl/h.264.samples/premiere-paff.ts).

[Solutions]
Picture timing SEI message contains pic_struct which defines interlace/progressive
mode of post decoding processes and field order. Most streams have the SEI for 
every frame or field. My patch implements decoding of the SEI and use of pic_struct. 
Now the field order is always correct. Interlaced picture is judged interlaced. 
Field 1 repeat flags are also set.

[Limitation]
As usual, there are exceptions: badly encoded streams. Some progressive 

Re: Please clean up incoming

On Sun, Oct 26, 2008 at 12:58:38AM +0200, Ivo wrote:
> On Monday 20 October 2008 17:51, Attila Kinali wrote:
> > Please clean tell us which files should be kept and
> > which thrown away.
> 
> I uploaded some sample Atari ST and Commodore Amiga images after I added 
> those formats to the Multimedia Wiki. Mike was going to move them into 
> place, but probably forgot about it and I forgot to ping him, so I suppose 
> they are still there.
> 
> If I could get access to the incoming and samples directory, I could move 
> them myself and I am also willing to spend a day or two (or three) sorting 
> out the rest of the incoming directory.

whats the status of this? (just asking so the offer isnt missed ...)

[...]

--

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

> ... defining _GNU_SOURCE...
For the love of all that is holy, and some that is not, don't do that.
-- Luca & Mans

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

Re: [PATCH]Add RoQ regression tests - stddev improved

Michael Niedermayer wrote:
> On Fri, Oct 17, 2008 at 12:13:13PM +0000, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Michael Niedermayer <michaelni <at> gmx.at> writes:
>>
>>>> Attached is a hopefully correct version of the RoQ regression test patch, I 
>>>> added -pix_fmt yuv420p -r 25, and stddev has clearly improved.
>>> iam fine with this assuming the test does not take unreasonable amounts
>>> of time relative to the other tests.
>> The patch increases the time of "make test" by about 30%. If you tell me a
>> reasonable amount, I'll change the test accordingly and apply.
> 
> 1-2%
> 
> but it should be at least 2-3 frames

Any news on this? Carl, if you are out of time, I don't mind sending a 
new patch using the -vframes option...

-Vitor

Re: [PATCH]Add RoQ regression tests - stddev improved

Hi!

Vitor Sessak <vitor1001 <at> gmail.com> writes:

> >> The patch increases the time of "make test" by about 30%. If you tell me a
> >> reasonable amount, I'll change the test accordingly and apply.
> > 
> > 1-2%
> > 
> > but it should be at least 2-3 frames
> 
> Any news on this? Carl, if you are out of time, I don't mind sending a 
> new patch using the -vframes option...

I'm happy if you solve it: vframes has to be 15 at least, because (I think, did
not RTFS) decoder searches 15 frames for audio and fails if they are not
available, together with -s 160x128, this still increases make test time by at
least 5%, IIRC.

IMO, time of make test should not be that important, testing as many features as
possible should have precedence.

Carl Eugen

[PATCH] Improve handling of cmov usage enablement

Hi.

The attached patch enables CMOV by default on x86_64 arch, because
all x86_64 CPUs have it. It doesn't enable fast_cmov, because x86_64
includes some NetBurst-architecture CPUs from Intel, which are known
to have a slow implementation of CMOV.

The second part of the patch disables fast_cmov for the "i686" cpu
target, because that target might include NetBurst-arch CPUs.

OK to apply?

Regards,
R.

--

-- 
MPlayer http://mplayerhq.hu | Livna http://rpm.livna.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
	-- from "Collected Sayings of Muad'Dib" by the Princess Irulan

Index: configure
===================================================================
--- configure	(revision 15761)
+++ configure	(working copy)
 <at>  <at>  -1245,6 +1245,7  <at>  <at> 
     ;;
     x86_64|amd64)
         arch="x86_32"

Re: [PATCH] Improve handling of cmov usage enablement

On Sat, Nov 01, 2008 at 01:52:02PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> 
> The attached patch enables CMOV by default on x86_64 arch, because
> all x86_64 CPUs have it. It doesn't enable fast_cmov, because x86_64
> includes some NetBurst-architecture CPUs from Intel, which are known
> to have a slow implementation of CMOV.
> 
> The second part of the patch disables fast_cmov for the "i686" cpu
> target, because that target might include NetBurst-arch CPUs.
> 
> OK to apply?

Looks OK to me, but I'm no CPU wizard..

Diego

Re: [PATCH] Improve handling of cmov usage enablement

On Sat, Nov 01, 2008 at 01:52:02PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> The attached patch enables CMOV by default on x86_64 arch, because
> all x86_64 CPUs have it. It doesn't enable fast_cmov, because x86_64
> includes some NetBurst-architecture CPUs from Intel, which are known
> to have a slow implementation of CMOV.
> 
> The second part of the patch disables fast_cmov for the "i686" cpu
> target, because that target might include NetBurst-arch CPUs.
> 
> OK to apply?

Given the statements by Intel I saw, my opinion is that we should go
with "enable fast_cmov unless we are really sure it is slow" - unless it
is some really predictable condition (in which case cmov probably is a
bad idea for all CPUs) cmov is likely to be faster on all CPUs except
netburst, including future CPUs.
Or in other words: Netburst is the special case, and our configure
should treat it as such, and personally my opinion is: you bought a
crappy CPU when everybody could have told you it is stupid (and going by
my experience a lot of people have told and been ignored), now live with
it, not our problem unless it is no effort for us. Complain to Intel if
anything.

Greetings,
Reimar Döffinger

Re: Please clean up incoming

On Sat, 1 Nov 2008 11:57:11 +0100, Michael Niedermayer wrote:
>On Sun, Oct 26, 2008 at 12:58:38AM +0200, Ivo wrote:
>> On Monday 20 October 2008 17:51, Attila Kinali wrote:
>> > Please clean tell us which files should be kept and
>> > which thrown away.
>> 
>> I uploaded some sample Atari ST and Commodore Amiga images after I added 
>> those formats to the Multimedia Wiki. Mike was going to move them into 
>> place, but probably forgot about it and I forgot to ping him, so I suppose 
>> they are still there.
>> 
>> If I could get access to the incoming and samples directory, I could move 
>> them myself and I am also willing to spend a day or two (or three) sorting 
>> out the rest of the incoming directory.
>
>whats the status of this? (just asking so the offer isnt missed ...)
>
>[...]

i asked koth on irc to take a look, i believe they are in discussions.

-compn