In article <[EMAIL PROTECTED]>,
Francesco Romani <[EMAIL PROTECTED]> writes:
> On Mon, 5 Jun 2006 13:36:02 +0000 (UTC)
> [EMAIL PROTECTED] (Frederick Bruckman) wrote:
>
>> > The whole EXPORT_ATTRIBUTE thing it's supposed to go away with Old Module
>> > Style export modules when new one are ready, since new export profile code
>> > uses a brand new, (hopefully!) better and smarter approach.
>> Still, user supplied "--export_par" will have to set some flag,
>> right?
>
> Uhm, the idea is to drop this stuff too.
Oh, that would be fine, then.
>> OK. I'll do that in a seperate email, trimming the update for the
>> xvid4 import module, as that's now gone in CVS. <sniff>
>
> Well, I don't remember a xvid4 _import_ module in CVS since I've started to
> hack transcode, and maybe even before :)
> Old import module (as found in 1.0.x branch) was based on _old_ xvid code
> (0.9.x branch), this was one of main reason for dropping it.
Well, I did an update to xvid4. I wasn't really happy with xvid
on the whole, though, because the encodes were unusable to me
(which problem is now solved), so I didn't make a fuss about the
import module being removed.
> Anyway, if you want XviD import module back there is no theoretical stoppers,
> just start another thread here on -devel and we can discuss this argument
> (I don't have personally any objection to let XviD import back in, and
> I think nobody else has :) )
> But please take in mind that
> 1) import_ffmpeg already provides xvid/mpeg4 decoding facilities (so xvid
> import CAN BE viewed as duplicate in some sense and
My motivation in developing that patch was that I began to suspect
that artifacts I was seeing were introduced by the import module,
and not the export module. It turns out, there were bugs in ffmpeg's
lavc that produced unsightly artifacts with bright text on a black
background. The bug had in fact been documented and fixed, so all I
had to do was to update ffmpeg.
> 2) we (as dev team) lacks manpower, so we are more inclined to add support
> for things that we actively use or that are supported by someone. That
> just means that help (even little, like taking care of one or two modules) is
> *very* appreciated ;)
> 3) we're switching module API (see the NMS story on transcode-devel archives)
> so it's better, if feasible, to provide patches/code conforming new API.
>
>> > Just a more word regarding profile support for xvid: if you mean
>> > transcode's export_prof(ile) support, don't worry about it since profile
>> > handling is going to change deeply in (hopefully) near future.
>> I'll wait for that, then.
>
> new code it's already avalaible in CVS, but still lacks proper testing (time!
> time! TIME! :( ). Take a look (if you want to do so, of course ;) ) to
> src/export_profile.{h,c}
I will take a look at that.
Kind regards,
Frederick
