Hi,
Thank you guys for your help, I got = it to compile. I had to just update the make to latest gmake and = gcc.
Now as far as the YUV input I did = the following with my input “xvid_encraw -t 0 -i big.yuv” = and it did not work I got a message that said “Wrong input format, I want = YUV encapsulated in PGM”. What should I use to get a file in yuv = format that xvid_encraw is happy with.
-Venkata
-----Original Message-----
From: Venkata =
Tumati
[mailto:vt35@cornell.edu]
Sent: Monday,
December 30, 2002 11:01 =
PM
To: 'xvid-devel@xvid.org<=
/font>'
Subject: irix64 & =
YUV
Hi, =
Question 1:
I just got an irix box the version of the os is =
Irix 6.5.
The processor is R12K. I think the R12k's are 32bit. When I a make in =
the build
directory i get the following error
> make -f Makefile.irix64
UX:make: ERROR: make: file `Makefile.irix64' line =
34: Must
be a separator (: or :![3D"icon_smile.gif"](3D"cid:image001.gif@01C2B2CC.E089E080")
for rules (bu39)
UX:make: ERROR: make: file `Makefile.irix64' line =
34:
Syntax error
line 34 is
# Constants which should not be modified =
CFLAGS +=3D -DLINUX <---- line 34
this does not seem to like +=3D,
Is there some changes to do when i use xvid on an =
SGI
machine.
Question2:
I have some yuv files, i dont know what type of =
yuv
sequence they are what can i do to make them yuv planer.
Thank you,
Venkata
The N by N inverse discrete transform shall conform to IEEE Standard Specification for the Implementations of 8 by 8 Inverse Discrete Cosine Transform, Std 1180-1990, December 6, 1990, with the following modifications : 1) In item (1) of subclause 3.2 of the IEEE specification, the last sentence is replaced by: "Data sets of 1 000 000 (one million) blocks each should be generated for (L=256, H=255), (L=H=5) and (L=384, H=383)." 2) The text of subclause 3.3 of the IEEE specification is replaced by : "For any pixel location, the peak error shall not exceed 2 in magnitude. There is no other accuracy requirement for this test." 3) Let F be the set of 4096 blocks Bi[y][x] (i=0..4095) defined as follows: a) Bi[0][0] = i - 2048 b) Bi[7][7] = 1 if Bi[0][0] is even, Bi[7][7] = 0 if Bi[0][0] is odd c) All other coefficients Bi[y][x] other than Bi[0][0] and Bi[7][7] are equal to 0 For each block Bi[y][x] that belongs to set F defined above, an IDCT that claims to be compliant shall output a block f[y][x] that as a peak error of 1 or less compared to the reference saturated mathematical integer-number IDCT f(x,y). In other words, | f[y][x] - f(x,y)| shall be <= 1 for all x and y. NOTE 1 Clause 2.3 Std 1180-1990 Considerations of Specifying IDCT Mismatch Errors requires the specification of periodic intra-picture coding in order to control the accumulation of mismatch errors. Every macroblock is required to be refreshed before it is coded 132 times as predictive macroblocks. Macroblocks in B-pictures (and skipped macroblocks in P-pictures) are excluded from the counting because they do not lead to the accumulation of mismatch errors. This requirement is the same as indicated in 1180-1990 for visual telephony according to ITU-T Recommendation H.261. NOTE 2 Whilst the IEEE IDCT standard mentioned above is a necessary condition for the satisfactory implementation of the IDCT function it should be understood that this is not sufficient. In particular attention is drawn to the following sentence from subclause 5.4: Where arithmetic precision is not specified, such as the calculation of the IDCT, the precision shall be sufficient so that significant errors do not occur in the final integer values.---------------------------------------------------------------- I guess the programmers checked 2). But do we also fulfill 3) ? > 4) try to agree on one idct implementation between all the various mpeg-4 > decoders (impossible, but at least xvid and ffmpeg could agree on one common > idct, maybe divx also) As 1), quality should not depend on the decoder, if it is without bounds of MPEG-4. So 5) Check if a) this happens with other encoders, too (ffmpeg? divx?) b) we really do correct rounding in Qpel MPEG-4 surely was tested against these errors, and they came up with the 132 predicted MBs rule. If this is not sufficient for us, it might very well have something to do with out implementation. gruel From xvid-devel@xvid.org Wed Jan 8 18:36:46 2003 From: xvid-devel@xvid.org (Roberto Della Pasqua) Date: Wed, 8 Jan 2003 19:36:46 +0100 Subject: [XviD-devel] please help ^_^ Message-ID: <046501c2b744$e65ba4e0$3232a8c0@pc01> This is a multi-part message in MIME format. ------=_NextPart_000_0462_01C2B74D.47A2C690 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi! I'm sorry to disturb, I like to know if I can embed the xvid mpeg4 codec into a commercial = application... Is it possible? Which kind of license I need to achieve with xvid staff? Its enough insert the xvid informations into credit and copyrght = section? Really thanks, perhaps does exist a "chief" that follow and rapresent the xdiv group? Bye bye, Robi. ------=_NextPart_000_0462_01C2B74D.47A2C690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi!
I'm sorry to disturb,
I like to know if I can embed the xvid =
mpeg4 codec=20
into a commercial application...
Is it possible?
Which kind of license I need to achieve =
with xvid=20
staff?
Its enough insert the xvid informations =
into credit=20
and copyrght section?
Really thanks,
perhaps does exist a "chief" that =
follow and=20
rapresent the xdiv group?
Bye bye,
Robi.
>Hi
>On Thursday 09 January 2003 16:41, Michael Niedermayer wrote:
>> On Thursday 09 January 2003 16:13, Christoph Lampert wrote:
>> > On Thu, 9 Jan 2003, Michael Niedermayer wrote:
>> > The reference software is correct (well, in fact the standard has been
>> > modified to be in compliance with the software. That's a clever way
>> > of debugging: leave the software as it is, instead modify the specs. )
>>
>> ok, i believe u both, ill fix ffmpeg
>ok, done
>btw i allso reproduced the IDCT qpel difference problem
>(see http://www.mplayerhq.hu/~michael/qpel-test.avi) for the video, its
>encoded with qpel / simpleidct with different constant qpel vectors in
>different areas of the image, it cant be decoded without artifacts with a
>different IDCT, allthough its a unfair test as the constant pattern with
>constant vectors will lead to a catastrophic accumulation of errors (if a
>IDCT "error" ever happens in a block, then it will very likely happen over
>and over again for the same block ...)
>
>[...]
>
>Michael
So... is it the problem I sent in XviD mailing list last October?
([XviD-devel] Quarterpel problem.)
--
Jeanson Hung
BU2, ADMtek Inc.
Phone: 03-5788879-521
--=_alternative 0012029948256CAA_=-- From xvid-devel@xvid.org Fri Jan 10 11:12:06 2003 From: xvid-devel@xvid.org (Michael Militzer) Date: Fri, 10 Jan 2003 12:12:06 +0100 Subject: [XviD-devel] Re: qpel smearing/noise problem References: