[gst-devel] New gst-ffmpeg

[Jens Persson]

Edward Hervey wrote:
> Hehe, was expecting this one :)
>   
hey edward, almost missed this post among a ton of others ...
> * lots of excuses for not having released on uptodate gst-ffmpeg *
>   
it's a good start to feel a little bad about slacking instead of coding :P
nah, only kidding.
>   ... but ...
>
>   NO, making gst-ffmpeg compile correctly is NOT the only thing to do:
>  * We also need to run insanely big/long regression tests to make sure
> it behaves at least as 'well' as the current snapshot (add several days
> to the estimate),
>  * We need to run memory tests to make sure it doesn't leak like an 18th
> century plumbing,
>  * We need to modify completely (rewrite?) ffvideoscale to use the new
> swscale API (I'd in fact like this to be a separate plugin since it only
> depends on libswscale),
>  * Add to all of that that we need to find the optimal revision checkout
> to use (several runs of tests).
>   
of course the new release shouldn't leak and bug in other ways. perhaps 
a new versioning scheme will fix it so that we can have both the old 
release and the new shiny one at the same time, ie 0.10.x.y. rc numbers 
may not be enough if it will take some time, like weeks or even months, 
it may not be a good idea to just leave the old one in the dust if 
something comes up that must be fixed fast. so every completely new 
gst-ffmpeg will have its own revision (micro).
>   Currently we have a heavily patched mirror of ffmpeg which we use in
> gst-ffmpeg. This is becoming more of a burden than a help, adding a
> couple of days to the task of updating that mirror.
>   The current idea is in fact to store in gst-ffmpeg a revsion number
> (in configure.ac but with an override option) so that the build system
> can checkout a specific ffmpeg revision to build/use with gst-ffmpeg.
> The biggest patch in the mirror is an autotools patch, which the ffmpeg
> people have/will never accept. Their current build system is decent
> enough for us to use at is (we just want it to be able to react properly
> to 'configure'/'make'/'make dist').
>  I have detailed more this system in
> http://bugzilla.gnome.org/show_bug.cgi?id=488913
>
>  'Sahel' on IRC was also looking into it, so if you want to give a hand
> contact him or myself (or reply to this thread or the bugzilla entry).
>
>   The final goal with this move is to, when we make releases, certify
> that the given release works with the given revision of ffmpeg. And also
> allow us to more easily/frequently test ffmpeg revisions against
> gst-ffmpeg and react quicker to new codecs/features and API/ABI changes.
>   We will NOT, repeat NOT, release a gst-ffmpeg release for which we
> haven't done enough testing. Once we've switched to this new revision
> system, it should on the other hand speed up the process a lot.
>   
new gst-ffmpeg releases more often sounds nice but if it is hard to 
achieve it one release a year may be enough too. as i said before, most 
older formats seems to work just fine so i would be happy if we get one 
new release a year.
>
>   If you want this to happen fast... give us a hand.
>   Comments and help welcome as usual,
>
>   
i know that gstreamer is an open project and people are encouraged to 
help out in any way possible but i'm just a clueless (and happy :D) 
python coder so i'll probably just be getting in the way (like leo getz 
in lethal weapon). :D one day i will learn c properly though ...
>     Edward, who would like to find an excuse not to wear his 'I hate
> ffmpeg' t-shirt !
>
>   
just think of it this way: you have two options, one is to make ffmpeg 
work in gstreamer and the other is to write native gstreamer plugins for 
all formats ffmpeg supports! now do you still hate ffmpeg that much? :P

greets from chilly sweden, hmm, google should start a "google winter of 
code" too heh.
> On Sun, 2007-10-28 at 19:43 +0100, Jens Persson wrote:
>   
>> Hello folks!
>>
>> Well, tha last gst-ffmpeg is a tad dated now (released 6 dec 06) and 
>> there has been a ton of improvements in ffmpeg since then so I'm 
>> wondering if (or when) a new release is planned? I talked with David 
>> Schleef on IRC and he told me (which I already found out some time ago 
>> too :D) that you have to grab a new ffmpeg snapshot from svn and make it 
>> play nice with gstreamer. He thought it was a matter of "a few days 
>> work" so it doesn't sound that bloody hard to do. The main problem with 
>> the current one is with x264 encoded files which works terribly 
>> (unplayable) with gstreamer but works beutifully with latest mplayer rc. 
>> Most other older formats seems to work just fine though but even they 
>> will probably work even better with an uptodate ffmpeg snapshot. If I 
>> had the knowledge I would be happy to donate some time and help out with 
>> it but I suck terribly in C so I better stay out of the action, at least 
>> for now. :D
>>
>> Greets Jens
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>     
>
>
>