[Ffmpeg-devel] make test fails

[Dana Hudes]

Luca Barbato wrote:
> Dana Hudes wrote:
>   
>> I don't know what you're looking at but the page you reference says:
>>     
>
> He probably mixed up ffmpeg and mplayer...
>   
i guess so.
>   
>> I am therefore following instructions by submitting the bug report
>> (regression test failure) to the appropriate mailing list specified by
>> the lead developers. I would appreciate if people don't give me abuse
>> for following instructions. furthremore, this sort of report is
>> typically sent to mailig list of developers. That is the case with e.g.
>> postgresql. With Perl, there is a separate perl-porters list to keep
>> discussion of new language features and release progress out of the way
>> of porting issues. Speaking of which, I'm able to offer at least
>> build+regression  testing on Sun SPARC solaris 8/9/10 using gcc (the
>> sunfreeware version of gcc3.x for 8; for  9 and 10, the Sun cooltools
>> gcc4) on Ultra II,III+,IV and Niagra chipset machines including the new
>> T2000 (Niagra 4 cpu 8 core), a SunFire v490 (4 dual core Ultra IV
>> 1500MHZ), and a SunFire 15K (8 cpu Ultra III+).
>>     
>
> interesting, could you also do some benchmarks on those systems?
>   

I would be pleased to do so -- and i am pretty familiar with the Sun gcc 
and its various tuning options. If we get this all to work I can even 
build a ffmpeg binary package for each architecture/platform combination 
available (not really sure how far I'll get with solaris 8, and the 15K 
only does solaris 9 anyplace I dare compile stuff; I neglected to 
mention solaris 10 on a v440 (should be 4 Ultra III+, I think 1500MHz, 
cpu) and a sunfire 280R (2x UIII+ 900MHz). Note that other than the v440 
and T2000 everything is 10K RPM Fibre channel disks. The T2000 is 10K 
RPM SAS, the v440 10K RPM Ultra 320 SCSI though it also has a FC 
attachment to the SAN (or it will, the T2000 and v440 are newly-racked 
machines not yet quite in service).

My production need of the moment is my poor PIII x86 system running 
Linux.  That's pretty 'vanilla' and if I can't build and test there 
successfully I have little hope of something exotic like the T2000 and 
Solaris 10.

>   
>> Whether I will
>> contribute anything substantive to the project beyond QA remains to be
>> seen. I don't know that anyone is really keen on a steganography
>> addition but that might be amusing to write;
>>     
>
> Not sure if the vhook/filter system in ffmpeg is a good fit but I'd be
> interested.
>
>   
>> I'd have to do some digging
>> in the literature. I know that a professor in the computer engineering
>> dept. at Stevens Institute of Technology is working on motion
>> compression I have to see who is involved and what they're up to (if any
>> readers of this list are one of the students working on that speak up)
>> and it might be possible to bring that work in if its not already here.
>>     
>
> check the snow codec, if there is something new you could propose
> something for it...
>
>   
>> Oh as for your wikiepedia article, that's nice. Have you ever read
>> Spaf's netequitte FAQ? It predates Wikipedia by at least 10 years.
>>
>>     
>
> the one about "keep in mind that there are humans on the other side" ^^?
>
> lu
>   
Yeah that too on both ends of the conversation.
Everyone does what they can for the common good. I mostly write Perl, 
mostly security stuff (a bunch of CGI::Untaint routines for example, 
along with my HTTPD::ADS which I REALLY need to clean up and break into 
multiple modules so people can use the proxy checker independently). 
That I am an experienced real-time C programmer and that ffmpeg uses C 
rather than C++ is an avenue that may lend itself to future 
participation. Release management so that poor souls trying to just 
build and go with a stable set of features is another. Of course, 
committing code to SVN that causes regression tests to fail is a huge 
no-no in any shared project. One thing that Perl has is the CPAN smoke 
test: a community of widely diverse volunteers who nightly build the 
latest development release. The results are auto-sent to the 
perl-porters list.
Given the flack I've gotten here maybe we need a ffmpeg-porters list for 
build issues. Or the list owner could step in and say that build/porting 
issues are on-topic.