[XviD-devel] Help needed again
Deepu Alexander
xvid-devel@xvid.org
Wed, 16 Oct 2002 19:23:55 +0200 (SAST)
Hello ,
I got around decompressing a video I compressed using xvid_enc. I am encoding
in RGB24 format. At the decompressor side , I write the files to ppm format.
The picture I get is upside down , and I get a bluish image. I was wondering if
anyone knows why I am getting this and what is the bug I probably have.
Thanks
Deepu.
Quoting xvid-devel-request@xvid.org:
> Send XviD-devel mailing list submissions to
> xvid-devel@xvid.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://list.xvid.org/mailman/listinfo/xvid-devel
> or, via email, send a message with subject or body 'help' to
> xvid-devel-request@xvid.org
>
> You can reach the person managing the list at
> xvid-devel-admin@xvid.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of XviD-devel digest..."
>
>
> Today's Topics:
>
> 1. Help needed (Deepu Alexander)
> 2. Re: colorspaces (peter ross)
> 3. Re: Help needed (peter ross)
> 4. Re: colorspaces (Michael Militzer)
> 5. Re: [RFC] A solution to avoid API incompatibilities. (Edouard
> Gomez)
> 6. Re: [RFC] A solution to avoid API incompatibilities.
> (ChristianHJW)
> 7. Re: Re: vfw 2pass stats (Marco Al)
> 8. Re: [RFC] A solution to avoid API incompatibilities.
> (alex@foogod.com)
> 9. Re: [RFC] A solution to avoid API incompatibilities.
> (alex@foogod.com)
>
> --__--__--
>
> Message: 1
> From: "Deepu Alexander" <s9924919@student.up.ac.za>
> To: <xvid-devel@xvid.org>
> Date: Tue, 15 Oct 2002 14:17:58 +0200
> Subject: [XviD-devel] Help needed
> Reply-To: xvid-devel@xvid.org
>
> This is a multi-part message in MIME format.
>
> ------=_NextPart_000_005E_01C27455.A96054A0
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> Hello...
>
> I am student trying to do MPEG 4 compression and streaming for my =
> project and I was looking at the xvid code. I got around to compressing
> =
> the frames into a file . Now if I need to view it let us say Windows =
> Media Player , I presume I would need to attach an header file or =
> something like that ( eg: avi header , or asf ), which I am not sure on
> =
> how to do.? I would be very grateful if someone could help me out on =
> what to do. I am trying to do this in Windows.
>
> Thanks=20
>
> Deepu
>
> ------=_NextPart_000_005E_01C27455.A96054A0
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META http-equiv=3DContent-Type content=3D"text/html; =
> charset=3Diso-8859-1">
> <META content=3D"MSHTML 6.00.2719.2200" name=3DGENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY bgColor=3D#ffffff>
> <DIV><FONT face=3DArial size=3D2>Hello...</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT> </DIV>
> <DIV><FONT face=3DArial size=3D2>I am student trying to do MPEG 4 =
> compression and=20
> streaming for my project and I was looking at the xvid code.
> =
> I =20
> got around to compressing the frames into a file . Now if I need to view
> =
> it let=20
> us say Windows Media Player , I presume I would need to attach an header
> =
> file or=20
> something like that ( eg: avi header , or asf ), which I am not sure on
> =
> how to=20
> do.? I would be very grateful if someone could help me out on what to =
> do. I am=20
> trying to do this in Windows.</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT> </DIV>
> <DIV><FONT face=3DArial size=3D2>Thanks </FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT> </DIV>
> <DIV><FONT face=3DArial size=3D2>Deepu</FONT></DIV></BODY></HTML>
>
> ------=_NextPart_000_005E_01C27455.A96054A0--
>
>
> --__--__--
>
> Message: 2
> From: "peter ross" <suxen_drol@hotmail.com>
> To: xvid-devel@xvid.org
> Subject: Re: [XviD-devel] colorspaces
> Date: Tue, 15 Oct 2002 22:57:41 +1000
> Reply-To: xvid-devel@xvid.org
>
> hello,
>
> >well, I guess we have two options: a) pad out chroma b) skip last line
> for
> >odd heights (not really correct but simple...)
>
> i will have a think about a padding implementation.
> (not just height, but width also).
>
> >MVs can direct outside the "real" image dimension (so into the extended
>
> >edge
> >area), right? This means that MVs can also point to the not initialised
>
> >half
> >filled border MBs, right again? setedges fills out _only_ the edge area
> but
> >not potentially half filled MBs. Moreover we have to dct/quantize/code
>
> during the encoding, the "get_range" function restricts the size
> of the mv to within the image-width+edge_size.
>
> for decoding we will need a proper macroblock padding.
>
> >half-filled MBs, so if they are not fully filled, they are hard to
> code
> >(means wasting lots of bits). So they should be filled and there should
> be
> >something mentioned in the specs about this (I suppose the same should
> be
> >done as as for the edge areas? well, seems like I really have to look
> into
> >the specs now...)
>
> iam a bit ensure about the setedges regarding.
>
> -- pete
>
> _________________________________________________________________
> Send and receive Hotmail on your mobile device: http://mobile.msn.com
>
>
> --__--__--
>
> Message: 3
> From: "peter ross" <suxen_drol@hotmail.com>
> To: xvid-devel@xvid.org
> Subject: Re: [XviD-devel] Help needed
> Date: Tue, 15 Oct 2002 23:15:39 +1000
> Reply-To: xvid-devel@xvid.org
>
> >Hello...
>
> howdy
>
> >I am student trying to do MPEG 4 compression and streaming for my
> project
> >and I was looking at the xvid code. I got around to compressing the
> frames
> >into a file . Now if I need to view it let us say Windows Media Player
> , I
> >presume I would need to attach an header file or something like that (
> eg:
> >avi header , or asf ), which I am not sure on how to do.? I would be
> very
> >grateful if someone could help me out on what to do. I am trying to do
> this
> >in Windows.
>
> there are libraries available to read/write avi (and asf...) files.
> there is currently no "raw mpeg4 bitstream -> avi convertor", though
> i believe gruel was planning to write one.
>
> playback of mpeg-4 avi's within windows-media-player requires a
> mpeg-4 decoder filter. there are several available: xvid dshow, ffdshow
> (ffmpeg), divx5, etc.
>
> there's also tools at the mpeg4ip project (sourceforge.net) which
> converts raw mpeg4 bitstreams into .mp4 files. mp4 files are viewable
> in most commerical mpeg-4 players (quicktime, envivio, etc.).
>
> -- pete
>
> _________________________________________________________________
> MSN Photos is the easiest way to share and print your photos:
> http://photos.msn.com/support/worldwide.aspx
>
>
> --__--__--
>
> Message: 4
> From: "Michael Militzer" <michael@xvid.org>
> To: <xvid-devel@xvid.org>
> Subject: Re: [XviD-devel] colorspaces
> Date: Tue, 15 Oct 2002 15:52:03 +0200
> Reply-To: xvid-devel@xvid.org
>
> Hi,
>
> > >well, I guess we have two options: a) pad out chroma b) skip last
> line
> for
> > >odd heights (not really correct but simple...)
> >
> > i will have a think about a padding implementation.
> > (not just height, but width also).
>
> good
>
> > >MVs can direct outside the "real" image dimension (so into the
> extended
> > >edge
> > >area), right? This means that MVs can also point to the not
> initialised
> > >half
> > >filled border MBs, right again? setedges fills out _only_ the edge
> area
> but
> > >not potentially half filled MBs. Moreover we have to
> dct/quantize/code
> >
> > during the encoding, the "get_range" function restricts the size
> > of the mv to within the image-width+edge_size.
>
> iirc, it's mb_width*16+edge_size. Since mb_width is rounded up when
> width is
> not divisable by 16, MVs can also point to (probably half-filled)
> border
> MBs. This is no problem currently because XVID does not support input
> image
> dimensions not being multiples of 16 but it can one in the future...
>
> > for decoding we will need a proper macroblock padding.
> >
> > >half-filled MBs, so if they are not fully filled, they are hard to
> code
> > >(means wasting lots of bits). So they should be filled and there
> should
> be
> > >something mentioned in the specs about this (I suppose the same
> should be
> > >done as as for the edge areas? well, seems like I really have to
> look
> into
> > >the specs now...)
> >
> > iam a bit ensure about the setedges regarding.
>
> at the moment, set_edges for example really only fills the area outside
> mb_width*16 at the right image border (src_ptr + edged_width -
> EDGE_SIZE).
> Memory not filled by the colorspace code (the border MBs) currently
> remain
> unitialised (if I didn't miss something)...
>
> Michael
>
>
> --__--__--
>
> Message: 5
> Date: Tue, 15 Oct 2002 18:45:16 +0200
> From: Edouard Gomez <ed.gomez@wanadoo.fr>
> To: xvid-devel@xvid.org
> Subject: Re: [XviD-devel] [RFC] A solution to avoid API
> incompatibilities.
> Reply-To: xvid-devel@xvid.org
>
> peter ross (suxen_drol@hotmail.com) wrote:
> > here what i'd like to see have.
> >
> > 1. the uci api is complete and released.
> > 2. xvid adopts uci as a frontend.
> > 3. all applications on the unix platform uses uci to access xvid
> > ...
> > 4. the vfw and directshow frontends are adopted to use uci, instead
> > of the native xvid api.
> > 5. xvid drops the native api and implements uci natively.
> >
>
> Nice plan but we could implement ascii argument passing before the uci
> standard is finnished. That's the force of this approach, backward
> compatibility is a no cost work.
>
> Btw your plan to integrate uci support natively is nice :-)
>
> --
> Edouard Gomez
>
> --__--__--
>
> Message: 6
> To: xvid-devel@xvid.org
> From: "ChristianHJW" <christianhjw@users.sourceforge.net>
> Date: Tue, 15 Oct 2002 19:24:58 +0200
> Subject: [XviD-devel] Re: [RFC] A solution to avoid API
> incompatibilities.
> Reply-To: xvid-devel@xvid.org
>
>
> "peter ross" <suxen_drol@hotmail.com> wrote in message
> news:F76dUSFem6fBh82GCUD00025354@hotmail.com...
> > here what i'd like to see have.
> > 1. the uci api is complete and released.
> > 2. xvid adopts uci as a frontend.
> > 3. all applications on the unix platform uses uci to access xvid
> > 4. the vfw and directshow frontends are adopted to use uci, instead
> > of the native xvid api.
> > 5. xvid drops the native api and implements uci natively.
> > -- pete
>
> Pete, i forwarded your email to uci-devel@lists.sourceforge.net so
> that
> Alex is aware ofyour interest in using UCI as a future API for XviD.
>
> For those interested, browse http://uci.sourceforge.net to learn more
> about
> it.
>
> There is one thing i'd like to clarify in this respect :
>
> While there is a good cooperation between the founder of UCI, Alex
> 'Foogod'
> Stewart, and the MCF team, both projects are in no form related and
> completely independant. Sure, the MCF team is currently checking if we
> could
> drop our self made transor API in favour of UCI, making things much
> easier
> for us. But we cant live with a codec only solution, so maybe we have
> to
> make some extensions to it to be able to handle not only codecs, but
> also
> other formats ( like a 'UFI' , being based on UCI ). In any case it
> would be
> great if you guys could decide to use UCI for XviD, because this was a
> proof
> for the real opensource spirit here in this project, unlike other well
> known
> projects, where people seem to be caught by the 'not-invented-here'
> syndrome
> ... :-) !!
>
> ChristianHJW
>
> Sites : http://mcf.sourceforge.net
> http://sf.net/projects/mcf
> MCF mailing lists : news://news.gmane.org
> gmane.comp.video.mcf.general
> gmane.comp.video.mcf.devel
> gmane.comp.video.mcf.mplayer
> gmane.comp.video.mcf.announce
> gmane.comp.video.mcf.mpc
> gmane.comp.video.uci.devel
> Soon : www.corecodec.com
>
>
>
>
>
> --__--__--
>
> Message: 7
> From: "Marco Al" <m.f.al@student.utwente.nl>
> To: <xvid-devel@xvid.org>
> Subject: Re: [XviD-devel] Re: vfw 2pass stats
> Date: Tue, 15 Oct 2002 22:34:28 +0200
> Reply-To: xvid-devel@xvid.org
>
> Marco Al wrote:
> > Marc FD wrote:
> >
> >> Maybe i'm wrong, but wouldn't be better to make ONLY a vbr mode in
> the core.
> >> Not a scaler, only the stuff we need to encode vbr like (x-pass).
> >
> > You can do scaling in vfw. If you wanted to do something a little
> more
> > sophisticated like using the R-D curve, which is only known to core in
> the
> > second pass because of the reasons Michael mentioned, to determine the
> number
> > of bits for a given frame you will have to do it in core though.
>
> I just noticed Zhihai He et al just recently published a paper on 2
> pass
> encoding using the per frame R-D curves from the previous pass (this
> could be
> done outside core). Considering the almost complete lack of research on
> 2 pass
> encoding this should be interesting to a couple of people here.
>
> The paper is titled "Optimal bit allocation for low bit rate video
> streaming
> applications". It is in the proceedings of ICIP-2002.
>
> Marco
>
>
> --__--__--
>
> Message: 8
> Date: Tue, 15 Oct 2002 17:29:58 -0700
> From: alex@foogod.com
> To: xvid-devel@xvid.org
> Subject: Re: [XviD-devel] [RFC] A solution to avoid API
> incompatibilities.
> Reply-To: xvid-devel@xvid.org
>
> On Tue, Oct 15, 2002 at 07:01:52PM +1000, peter ross wrote:
> > here what i'd like to see have.
> >
> > 1. the uci api is complete and released.
>
> I'm working on it :)
>
> Just so people know, work is progressing on UCI.. the spec isn't quite
> finished
> (so we're still open to input from folks) but I am in the process of
> writing up
> a basic UCI library base to get in CVS for people to play with and
> experiment
> on, and expect to have that available soon. (those interested should
> keep an
> eye on the UCI-devel list for updates)
>
> > 2. xvid adopts uci as a frontend.
> > 3. all applications on the unix platform uses uci to access xvid
> > ...
> > 4. the vfw and directshow frontends are adopted to use uci, instead
> > of the native xvid api.
> > 5. xvid drops the native api and implements uci natively.
>
> This sounds like a really good plan to me :). The plan for UCI, BTW, is
> to
> eventually have generiric VfW and Dshow wrappers for UCI under windows
> anyway
> (so any UCI codec can also be usable through the VfW or Dshow interface
> too),
> but we're concentrating on building the UCI spec and core interface and
> getting
> it working cross-platform first, so the first stage probably won't
> include this
> in UCI itself.
>
> Since you guys are considering doing a VfW-on-top-of-UCI wrapper as part
> of
> XviD (which makes sense for the interim where UCI doesn't have one
> itself), It
> might be handy to use XviD's UCI-VfW wrapper down the line as a basis
> for the
> more generalized UCI-VfW stuff, if folks would be willing. That would
> potentially save some duplicated effort..
>
> I have to say it's very encouraging to see the support that UCI is
> gathering
> out there.. (and support from XviD folks means a lot)
>
> -alex
>
> --__--__--
>
> Message: 9
> Date: Tue, 15 Oct 2002 17:56:17 -0700
> From: alex@foogod.com
> To: xvid-devel@xvid.org
> Subject: Re: [XviD-devel] [RFC] A solution to avoid API
> incompatibilities.
> Reply-To: xvid-devel@xvid.org
>
> On Tue, Oct 15, 2002 at 06:45:16PM +0200, Edouard Gomez wrote:
> > Nice plan but we could implement ascii argument passing before the
> uci
> > standard is finnished. That's the force of this approach,
> backward
> > compatibility is a no cost work.
>
> Actually, please note that UCI doesn't currently use a scheme quite like
> what
> you proposed.. In UCI, the parameter values are not all passed as
> strings
> (there's several common native types which can be chosen based on the
> needs of
> the parameter).
>
> I would reccomend holding off on changing XviD's current interface in
> this
> direction as the UCI specs are currently still a bit in flux, so you may
> end up
> going a direction which later turns out to be different from what UCI
> ends up
> actually using..
>
> In particular, I've been considering changing the UCI specs for
> parameter
> passing to make things somewhat easier for codec developers anyway. The
> idea
> I've been toying with is enabling codecs to tell UCI how to "map" their
> parameters onto existing binary structures, so the only thing needed to
> convert
> an existing interface to UCI would be to define a structure which tells
> where
> all the parameters go.
>
> I'm still considering the potential ramifications of this approach,
> though
> (particularly cross-platform). (if people have thoughts, please feel
> free to
> contribute to the UCI-Devel list)
>
> -alex
>
> PS: UCI web site/maillists/etc can be found at
> http://uci.sourceforge.net/
>
>
> --__--__--
>
> _______________________________________________
> XviD-devel mailing list
> XviD-devel@xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel
>
>
> End of XviD-devel Digest
>
>