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

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Tue, Feb 24, 2009 at 09:40:56PM +0000, M?ns Rullg?rd wrote:
>> 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.
>
> should be fixed

Confirmed.

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