[XviD-devel] illegal MPEG-4 Bitstream Syntax / RAW YUV input swaped

[Christoph Lampert]

Hi Andreas, welcome to the list! 


On Fri, 3 Jan 2003, Andreas Dehnhardt wrote:
> Hi everyone,
> 
> 1) illegal MPEG-4 Bitstream Syntax
> 
> I was playing around with the xvidcore-0.9.0 codec and found out the following:
> After encoding a sequence to a raw MPEG-4 bitstream, I tried to decode
> it using the standard MPEG-4 decoder (the reference ISO fpdam decoder).
> 
> The decoding failed at the second I-VOP, it complained about an illegal
> VOP_START_CODE while parsing the bitstream. This error is caused by
> FrameCodeI() in "encoder.c". There is a new VO/VOL-Header inserted into the
> bitstream (BitstreamWriteVolHeader()) for every new I-VOP. According to
> the MPEG-4 standard, this structure is illegal. 

Hm, yes, that might be a "bad habit" which XVID inherited from OpenDiVX
(and the other Windows codecs?). 
But since there are some features which can only be changed in VO/VOL
headers (qpel? GMC mode?) and since you seem to know the syntax: Can't we
somehow "define" that the sequence is finished at a certain point and a
new sequence starts with the next I-frame, including a new VO/VOL header
etc? 


> The VO/VOL-Header is only
> allowed at the start of the sequence. The VOPs (in our case, a Frame is
> equal to a VOP) are instances of one VideoObject (VO) at a given time.
> VideoObjectLayers (VOLs) are used for object based temporal and spatial
> scalability (not included in the simple profile of MPEG-4). We only have
> one VO and one VOL, so we cannot include more than one VO/VOL-Header.
> 
> I disabled the BitstreamWriteVolHeader()-call (except for the initial I-VOP).
> After this modification, the standard MPEG-4 decoder was able to decode
> the whole bitstream.
> 
> Did anyone play around with decoding the raw MPEG-4 stream using other
> decoders before?
> 
> 
> 
> 
> 2) RAW YUV input swaped
> 
> I used raw YUV data as input for the encoder. After encoding (xvid_encraw)
> and decoding (fpdam), the colors seem to be somehow "wrong". I swaped
> the order of U and V in my input YUV-file. This fixed the error. I don't
> know the "correct" order of a YUV-file. Either the encoder swaps the
> color information while reading the raw data or there is no standard
> YUV-order for such files???


The problem is not too few standards, but too many of them. 
We should finally agree on one. 

I guess your problem is related to the colorspace paramers: 

#define XVID_CSP_YV12   1  /**< YV12 colorspace (y,v,u planar) */
#define XVID_CSP_YUY2   2  /**< YUY2 colorspace (y,u,y,v packed) */
#define XVID_CSP_UYVY   3  /**< UYVY colorspace (u,y,v,y packed) */
#define XVID_CSP_I420   4  /**< I420 colorsapce (y,u,v planar) */

(from src/xvid.h)

xvid_encraw uses XVI_CSP_YV12 as input. Maybe this is wrong and I should
have used XVID_CSP_I420, because internal format of MPEG-4 is supposed to be
YUV = YCbCr ? 

I never notice these things because I don't use RGB output, but look at
YUV as greyscale... 


Anyway, change line 655 in xvid_encraw.c to 

        xframe.colorspace = XVID_CSP_I420;  

and I hope the problem will be gone...

gruel