[FFmpeg-cvslog] r28716 - trunk/libswscale/yuv2rgb.c

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Tue, Feb 24, 2009 at 08:18:23PM +0000, Robert Swain wrote:
>> 2009/2/24 Michael Niedermayer <michaelni at gmx.at>:
>> > On Tue, Feb 24, 2009 at 03:50:28PM +0100, diego wrote:
>> >> Author: diego
>> >> Date: Tue Feb 24 15:50:28 2009
>> >> New Revision: 28716
>> >>
>> >> Log:
>> >> Remove GPL version of yuv2rgb.c that has been replaced by an LGPL substitute.
>> >
>> > It seems fate got stuck around here :)
>> >
>> > last update of fate is 5h ago ...
>> 
>> Was the intention to remove the old yuv2rgb.c 
>
>> and then move yuv2rgb2.c
>> to yuv2rgb.c?
>
> that surely would be a good idea as well ...
> what iam curious about though is what is wrong with fate, it could really
> be a little bit more verbose than 
> "Page cache generated 5 hr ago (should be updated every 15-20 minutes)"
>
> Its annoying because id like to know ASAP if any of the h264 timestamp
> related commits broke anything, regression tests are still fine and
> iam currently running the full h264 conformance bitsteram thing
>
> i mean last week roundup was gone and now fate seems stuck, if it just
> said iam out of disk space after trying revX or testing rev Y since 5hr
> that might help ...

I think there has been some kind of trouble with the server today.
I've emailed Mike, but he hasn't replied yet.

Meanwhile, I've checked the results of my FATE runs on Alpha.
Starting with r17564 or r17563 (which was not built here), the SVQ3
test [1] is crashing with a glibc error about some kind of corruption.
All other tests pass.

[1] http://fate.multimedia.cx/index.php?test_spec=143

-- 
M?ns Rullg?rd
mans at mansr.com