[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

OpenDivX digest, Vol 1 #33 - 3 msgs

Send OpenDivX mailing list submissions to
	[email protected]

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
	[email protected]

You can reach the person managing the list at
	[email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenDivX digest..."

Today's Topics:

   1. Linux status? ([email protected])
   2. About Fraunhofer MP3 Codec (Zhi Zhou)
   3. mpeg4 v2 compliance (Arnaud Zanetti)


Message: 1
Date: Thu, 8 Mar 2001 14:19:01 -0500
From: [email protected]
To: [email protected]
Subject: [OpenDivX] Linux status?

I notice that the Linux version hasn't been updated for quite some time...
Is anyone developing under Linux?  If so, are you just getting the OpenDivx core
+and adding your own makefiles or automake or whatever in your cvs work dir?
I'm interested in getting started with working on the linux decore at least, and
+just don't want to duplicate too much effort ;-)
I have gotten the latest version of the decore up and running.  When will it be time to put that code back in the Linux section? (just took copying the latest core code, and a few trivial automake updates)      
                             Steve Pinkham



Message: 2
Date: Fri, 9 Mar 2001 16:11:13 +0800
From: Zhi Zhou <[email protected]>
Reply-To: [email protected]
To: "[email protected]" <[email protected]>
Organization: V2
Subject: [OpenDivX] About Fraunhofer MP3 Codec

When using Fraunhofer MP3 Codec to convert PCM to MP3, 
I set the destination WAVEFORMATEX as such:
    wfDes.wFormatTag = WAVE_FORMAT_MPEGLAYER3;
    wfDes.cbSize = 12;
    wfDes.nAvgBytesPerSec =1000;
    wfDes.nBlockAlign =1;
    wfDes.nChannels = 1;
    wfDes.nSamplesPerSec = 8000;
    wfDes.wBitsPerSample = 0;

but 8000 bytes' PCM became 817 bytes after compresion
(using acmStreamConvert()). And after decompression, 
the PCM stream is only 6336 bytes!! much shorter than
original one(8000 bytes). The qulity of is also bad. 

Anyone knows the situation??

Thanks in advance!



Message: 3
Date: Fri, 09 Mar 2001 17:58:46 +0100
From: Arnaud Zanetti <[email protected]>
To: mailing list opendivx <[email protected]>
Subject: [OpenDivX] mpeg4 v2 compliance

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<p>I've made some test about compliance with the MPEG4 V2.
<br>I first encoded a bitstream using encore0.47, then tried to decode
it using MoMuSys-FPDAM1-1.0-001220_sony (MPEG4 V2 reference implementation)
and it failed. Here is the message it gave :
<br>Complexity Estimation is DISABLED
<br>Using Resync Marker.
<br>Using the neither Data Partitioning nor RVLC.
<br>ACDC Prediction ENABLED
<br>stuffing bits not correct
<p>I then did the same, this time using encore0.48, and obtained this result
<br>Quarter Pel mode off!
<br>Complexity Estimation is DISABLED
<br>Using the neither Data Partitioning nor RVLC.
<br>Reduced Resolution Vop DISABLED
<br>ACDC Prediction ENABLED
<br>Temporal scalability Turned ON
<br>stuffing bits not correct
<p>Is encore0.48 really using temporal scalability ?
<br>Are all the informations given by the momusys decoder exact ?
<p>I also didn't managed to decode the 0.48 encoded bitstream with decore
0.48 : has the API changed between decore 0.47 and 0.48 (I saw the change
concerning the output format). ?
<p>Trying to decode a bitstream encoded by momusys with decore0.47 leads
to a crash of the decoder after 2 ou 3 frames (which look like anything
but the original).
<br>As Momusys decodes without problem the stream it previously encoded,
I don't believe OpenDivX is really MPEG4 compliant. It might even be a
single syntactic difference.
<br>So, what's the exact status of the project about MPEG4 compliance and
interoperability ?


OpenDivX mailing list
OpenD[email protected]

End of OpenDivX Digest

Reply To Poster

Local References / HOW-TO / FAQs