I cc'd the maintainer on this, he forgot a few header files, the divx4.h is especially needed so mplayer can use this codec. I'm sure he won't mind as it's a simple fix!
Responsible Changed From-To: freebsd-ports->lioux I'll handle this
Amar Takhar wrote: >>Number: 40799 >>Category: ports >>Synopsis: fix: graphics/xvid >>Confidential: no >>Severity: non-critical >>Priority: low >>Responsible: freebsd-ports >>State: open >>Quarter: >>Keywords: >>Date-Required: >>Class: change-request >>Submitter-Id: current-users >>Arrival-Date: Fri Jul 19 19:10:03 PDT 2002 >>Closed-Date: >>Last-Modified: >>Originator: Amar Takhar >>Release: FreeBSD 4.6-STABLE i386 >>Organization: >>Environment: > > >>Description: > > > I cc'd the maintainer on this, he forgot a few header files, the divx4.h is > especially needed so mplayer can use this codec. I'm sure he won't mind as it's > a simple fix! My understanding of things is that applications should only use xvid.h, as it is the interface to the xvid API and all the other headers are for internal use only. Care to give some details regarding how those headers are useful to mplayer? Regards, -- Michael Nottebrock "The circumstance ends uglily in the cruel result." - Babelfish
On 2002-07-23 00:26 +0200, Michael Nottebrock wrote: > My understanding of things is that applications should only use xvid.h, > as it is the interface to the xvid API and all the other headers are for > internal use only. Care to give some details regarding how those headers > are useful to mplayer? > In vd_xvid.c of the mplayer cvs tree, it has: DEC_PICTURE d4_pic; That structure is only located in divx4.h, i was a bit hasty it seems on adding encoder.h/decoder.h, but i figured since it would not cause any compatibility errors it was better to include them incase any future programs needed them. In retrospect it's probably better to leave them out until they are needed by any programs. amar.
Amar Takhar wrote: > On 2002-07-23 00:26 +0200, Michael Nottebrock wrote: > > >>My understanding of things is that applications should only use xvid.h, >>as it is the interface to the xvid API and all the other headers are for >>internal use only. Care to give some details regarding how those headers >>are useful to mplayer? >> > > > In vd_xvid.c of the mplayer cvs tree, it has: > > DEC_PICTURE d4_pic; > > That structure is only located in divx4.h, i was a bit hasty it seems on adding > encoder.h/decoder.h, but i figured since it would not cause any compatibility > errors it was better to include them incase any future programs needed them. In > retrospect it's probably better to leave them out until they are needed by any > programs. When you're mucking around with CVS versions, expect trouble. :) I still think that leaving xvid.h as the only installed include of the port is the right thing to do. mplayer's support for xvid is kinda floating and I'm quite sure they'll throw everything over again before the next release (as might the xvid-guys), but I'll keep that possible future interaction of the mplayer & xvid ports in mind when update time comes. Regards, -- Michael Nottebrock "The circumstance ends uglily in the cruel result." - Babelfish
On 2002-07-23 01:29 +0200, Michael Nottebrock wrote: > When you're mucking around with CVS versions, expect trouble. :) Heh, well, some people like to live dangerously, like the mplayer developers, they're always adding new features/fixes in the CVS version, and only release a stable version when they're completely happy, some of us are a bit impatient, i guess :) > I still think that leaving xvid.h as the only installed include of the > port is the right thing to do. mplayer's support for xvid is kinda > floating and I'm quite sure they'll throw everything over again before > the next release (as might the xvid-guys), but I'll keep that possible > future interaction of the mplayer & xvid ports in mind when update time > comes. Well, the thing is i submitted an mplayer-cvs port, i tried the xvid support out, it's beautiful and works without a hitch, uses far less cpu/resources than the divx 3.11/4/5 codecs did. Can we just throw the divx4.h in for now temp, so people can install the port without having to install that header manually? I'll make sure to bring this up with the mplayer developers about cutting the header out, and if they do in the future, i'll make sure to request the removal of it from the port. amar.
Amar Takhar wrote: > Well, the thing is i submitted an mplayer-cvs port Ah, why didn't you say so in the first place. :) I approve of adding divx4.h then. Cheers, -- Michael Nottebrock "The circumstance ends uglily in the cruel result." - Babelfish
On Tue, Jul 23, 2002 at 03:18:26AM +0200, Michael Nottebrock wrote: > Amar Takhar wrote: > > > Well, the thing is i submitted an mplayer-cvs port > > Ah, why didn't you say so in the first place. :) I approve of adding > divx4.h then. Hi, Sorry I didn't speak 1st, I propose a compromise. Instead of installing divx4.h as PREFIX/include/divx4.h, install it as PREFIX/include/xvid/divx4.h. I'm proposing this because divx4.h is far too much a generic name. It might conflict with another program pretty easily. This will require a patch in mplayer port but we can easily slide that in. What about trying to convince both xVid's and mplayer's developers about this? So that it's in their CVS for the next release? -- Mario S F Ferreira - DF - Brazil - "I guess this is a signature." Computer Science Undergraduate | FreeBSD Committer | CS Developer flames to beloved devnull@someotherworldbeloworabove.org feature, n: a documented bug | bug, n: an undocumented feature
On 2002-07-23 00:14 -0300, Mario Sergio Fujikawa Ferreira wrote: > > Hi, > > Sorry I didn't speak 1st, I propose a compromise. > Instead of installing divx4.h as PREFIX/include/divx4.h, install > it as PREFIX/include/xvid/divx4.h. > I'm proposing this because divx4.h is far too much a generic > name. It might conflict with another program pretty easily. This will > require a patch in mplayer port but we can easily slide that in. > What about trying to convince both xVid's and mplayer's > developers about this? So that it's in their CVS for the next release? I thought about that too, i checked the other divx ports and all of them already install into their own directories in include/*/, those headers are expected to be there for programs that use them. For XviD it seems they're expected to be in include/* i think the idea behind this was that xvid.h is a pretty unique name so it was unnessicary for it to be in it's own directory. Are you talking about just moving the divx4.h into include/xvid/*, and leaving xvid.h in include/*? If so, i think that is a good idea, i should have thought of it earlier :) amar.
Mario Sergio Fujikawa Ferreira wrote: > Sorry I didn't speak 1st, I propose a compromise. > Instead of installing divx4.h as PREFIX/include/divx4.h, install > it as PREFIX/include/xvid/divx4.h. > I'm proposing this because divx4.h is far too much a generic > name. It might conflict with another program pretty easily. This will > require a patch in mplayer port but we can easily slide that in. It shouldn't conflict with anything, but being careful does not hurt. > What about trying to convince both xVid's and mplayer's > developers about this? So that it's in their CVS for the next release? divx4.h is basically bandaid. It replaces the old decore.h/encore.h includefiles which came with opendivx and would conflict with divx4linux' includes. IMHO, the right thing for mplayer would be to use xvid's native API, thus getting rid of the dependency on the old opendivx-includes. Regards, -- Michael Nottebrock "The circumstance ends uglily in the cruel result." - Babelfish
State Changed From-To: open->closed Committed, thanks!