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.
> With no flag, you could still check that "ex_par_width",
> "ex_par_height", and "ex_par" are all three zero, but I fear that
> might be fragile. Some check like that has evidently broken once.
Uhm, I'll take in account this objection, but _at this moment_ I don't
see clearly how having this flag can solve this specific problem:
export_attributes are supposed to solve another problem, AFAIK (I've not
written the original code). It was a side effect of how export profiles
support was originally implemented.
> > I'm interested to this patch, but unfortunately I'm facing an issue on
> > import layer (the infamous directory mode thing), so I can't work on this
> > quickly. Feel free to post the patch above on this thread if you like.
> 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.
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
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}
the key idea for new export profile code it's to let the things happens
trasparently as much as is possible :)
(this reminds me that I should add more docs for this code)
best regards,
--
Francesco Romani - Ikitt ['people always complain, no matther what you do']
IM contact: (email-me, I have antispam default deny!) icq://27-83-87-867
some known bugs: http://www.transcoding.org/cgi-bin/transcode?Bug_Showcase
