[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Opendivx digest, Vol 1 #15 - 8 msgs
Send Opendivx mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.projectmayo.com/mailman/listinfo/opendivx
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. Message replies in digest mode (Bez)
2. RE: Mpeg2 -> Mpeg4 (Nick Feamster)
3. Re: Mpeg2 -> Mpeg4 (Thomas Hargrove)
4. divx, the scope (ridaas syncprodz.com)
5. Re: NASM (Isaac Cruz Ballesteros)
6. x86 assembler portability (John Funnell)
7. decore/encore API change requests (Arpi)
8. unsubscribing (Calvin Redding)
--__--__--
Message: 1
Date: Thu, 01 Feb 2001 20:07:26 -0800
From: Bez <[email protected]>
To: <[email protected]>
Subject: [Opendivx] Message replies in digest mode
Hi all. Just a quick reminder: when you quote someone's previous message in
your reply, please keep those quotes to a minimum. Do not quote their entire
message.
The members of the list who are reading in digest mode have to scroll
through the same message 10 times when 10 people respond and quote the whole
thing. :-)
Cheers.
:bez
--__--__--
Message: 2
Date: Thu, 1 Feb 2001 23:30:08 -0500 (EST)
From: Nick Feamster <[email protected]>
To: Brian Smith <[email protected]>
Cc: <[email protected]>
Subject: RE: [Opendivx] Mpeg2 -> Mpeg4
The main difference is that MPEG-4 is object-based, while
MPEG-2 is frame based. Both use similar block-matching tecniques and
transforms.
Nick
On Thu, 1 Feb 2001, Brian Smith wrote:
> Correct me if I'm wrong, but the major advances in MPEG-4 over MPEG-2 come
> from
> different algorithms from the predicted B and P frames. The DCT-based
> compression
> of the I-Frames is the same. So, you'd have to decode the data to gain any
> compression.
>
> Brian
>
> -----Original Message-----
> From: Ezra Auerbach [mailto:[email protected]]
> Sent: Thursday, February 01, 2001 11:53
> To: [email protected]
> Subject: [Opendivx] Mpeg2 -> Mpeg4
>
>
> Hi,
> I'm a third year student in collage. Every student in my college must choose
> a project to do durring his third/fourth year. One of the projects on the
> list was to write a program that converts mpeg2 to mpeg4 (or Mpeg1 to Mpeg2
> - but that isn't as interesting) without uncompressing the mpeg2 to a full
> bitmap and then recompressing...rather to use the compression to further
> compress it to mpeg4. (The professor in charge of the project said he
> himself doesn't know if it is possible.)
>
> I wrote an email to the projectmayo team a while ago but haven't really
> gotten an answer yet, and I noticed a simular post here, so I was wondering
> if anyone can point me in the right direction. I kneed to know the
> following:
> 1) Is this at all posible
> 2) Is it worth spending time on (will compressing mpeg2->4 this way achive
> the same quality, speed)
> 3) Do you think it can be done in about a year (2 people that don't know
> much about compression working 15-20hours a week)
> 4) Where can I find a information on mpeg compression. (I've started going
> through the offical mpeg site...but I couldn't find information about how
> the compression works in all the mpeg documentation there.)
>
> Thanks for any help,
> Ezra Auerbach
>
--__--__--
Message: 3
From: "Thomas Hargrove" <[email protected]>
To: <[email protected]>
Subject: Re: [Opendivx] Mpeg2 -> Mpeg4
Date: Fri, 2 Feb 2001 00:22:52 -0800
I think a mpeg2 -> mpeg4 is a great idea. With the way the industry is
looking right now, it could be an extremely popular tool.
Possible uses:
DVD -> DivX
yeah, duh
Mpeg2 Caputre Cards (Hauppaug PVR) -> DivX
Usefull for creating a simpsons / south park archive
Tivo -> DivX
It isn't possible yet, but it WILL happen.
HDTV -> DivX
This might take a little longer.
Just food for thought.
--Tom
--__--__--
Message: 4
Reply-To: [email protected]
From: "ridaas syncprodz.com" <[email protected]>
Date: Fri, 02 Feb 2001 01:00:46 -0800
To: [email protected]
Subject: [Opendivx] divx, the scope
i checked projectmayo website but i have not really understood where open=
divx project want to move.
i see 2 possibility:
1)build something like an opensource core for mpeg4-compliants encoder/de=
coder, of course some parts of mpeg4 will not be implemented as they are =
of not real interest (example the synthetic stuff encoding etc..)
2)build something new from the scratch to do what mpeg2 was already doing=
but with better algos and ideas (can be aac or wavelets or whateva), mos=
t important, just something free that allow you to encoded DVD movies whe=
n ripped.
i think 1) will be the ideal for everybody and can help a lot for the fut=
ure opensource programs, actually i think it's not very clear if MPEG gro=
up will be ALLOWED to publish a code implementation free for everybody of=
their standard, if the mpeg4 will be free or licensed and who will pay t=
he license to who.
2) is of course easier to implement and can get rid off all the extra thi=
ngs of mpeg4 we don't need when copying a movie.
Does things like object-based encoding respect frame-based encoding reall=
y help in divx or is just cause divx is directly borned from a mpeg4 enco=
der?
federico
-------------------------------------
http://www.syncprodz.com=20
------(mp3 since 1997)-------
_________________________________________________________________________=
__
Visit http://www.visto.com/info, your free web-based communications cente=
r.
Visto.com. Life on the Dot.
--__--__--
Message: 5
From: Isaac Cruz Ballesteros <[email protected]>
Organization: SGI
To: [email protected]
Subject: Re: [Opendivx] NASM
Date: Fri, 2 Feb 2001 10:05:23 +0100
> Does anyone here have any experience linking assemb;y from NASM (which
> uses INTEL syntax) with gcc output? Seems it would be easier then
> maintaining both formats, and the object files from NASM could be
> distributed in the tar files as they should be the same across any elf
> format intel machine. That is, or course, if this is possible.. I'll look
> over it, but I'm still a rather marginal programmer ;-)
In allegro (a game programming library) we use .s files in AT&T format, so to compile
in windows you need some DJGPP tools (like GAS) to generate .o files, which are linked
with MSVC output.
--__--__--
Message: 6
From: "John Funnell" <[email protected]>
To: <[email protected]>
Date: Fri, 2 Feb 2001 14:53:54 -0000
Subject: [Opendivx] x86 assembler portability
> Von: Gunter Ohrner <[email protected]>
.....
> Today I found a tool called intel2gas which automatically converts
> Intel-style assembler code into the AT&T-syntax. It even does handle MSVC
> inline assembly sections in c-files. The translation looks usuable
although
> not directly compilable. intel2gas does not not seem to recognize
> C-variable names within the inline assembler code and precedes them with a
> "%" and it can't convert "byte ptr [some_register]" constructs.
> But maybe it's a start for automatic generation of the linux source files.
It sounds like this is almost working and that intel2gas would not need much
modification to work with our code. I mailed the main author of intel2gas
asking what would need to be done to make it work with our code. It would
even be worth changing our code slightly if that meant we only had to
maintain one codebase for all x86 optimisations.
For the C-variable names, intel2gas would have to replace the C names by %0,
%1, %2 ...etc. and then reference them as appropriate in the
clobbered/input/output part. I'm sure it shouldn't be too hard to handle
the "byte ptr [some_register]" constructs. If intel2gas could do this then
everyone would be very happy. There's going to be a LOT of new MME, SSE and
other processor-specific stuff here eventually. And, most likely it will be
available first as Intel-syntax inline C.
On a different note, I just discovered that the demo Intel compiler can be
run from Linux. Install it on a Windows partition ('98 in my case). Then
use wine in Linux to run Intel's compiler: "wine icl.exe /c file.c". This
will make "file.obj". You can convert this to "file.o" (elf format) by
using objcopy [you may have to recompile binutils first, enabling pe-i386
support]. "file.o" can then be linked into your Linux library or
application.
The above is a real bitch to set up, and compiles are slow, but you can
automate with 'make'. Both decore and encore build perfectly. (This was
using M$'s cl.exe by the same trick). Perhaps in our makefile/configure
setup for encore and decore we could have an option for people who have the
capability to do "wine (i)cl.exe".
The Intel compiler is on a 30-day demo, so unless you can spare the cash it
may be of limited use but it is very good. Comparable to pgcc ;-).
Apparently, there's a native-Linux C++ compiler from Intel available soon.
I doubt somehow that this will be free :-(
John
--__--__--
Message: 7
Date: Fri, 2 Feb 2001 16:21:00 -0600 (CST)
From: Arpi <[email protected]>
To: [email protected]
Subject: [Opendivx] decore/encore API change requests
Hi,
I just want to ask you, opendivx core developers to do some
little change on encore/decore interfaces.
The only think I want is YUV (YV12 planar and maybe YUY2 packed)
input and output.
I've seen that encore wants Y,U,V pixels in 16-bit (short int) format
instead of bytes. You should allow users to pass 16-bit/component
images, so the application can do the conversion.
(for example the decoder in the mpeg2->opendivx converter can be
changed to output 16-bit/component pixels)
In the encoder it's easy to add these changes: I'm using (in my
linux encoder) the 'flip' flag to do this.
CUrrently flip==0 means normal RGB image, and flip==1 means flipped RGB.
I've added flip==2 for YV12 planar 8bit/component image, and the
other formats (YV12 16bit and YUY2) can be added as flip==3 and ==4.
For the decoder just see the libdecore for linux, it has this feature.
YUV i/o is very important, because most of the current hardware &
software (I mean windows/DX, linux/Xv, mac, beos) can do YUV overlays,
and most file converters/recompressors use YUV internally
(because most input formats (huffyuv, mjpeg, mpegs etc) are already
YUV, so why convert it to rgb and then back to yuv?).
A'rpi / Astral & ESP-team
--
mailto:[email protected]
http://esp-team.scene.hu
--__--__--
Message: 8
From: "Calvin Redding" <[email protected]>
To: <[email protected]>
Date: Fri, 2 Feb 2001 10:38:27 -0600
Subject: [Opendivx] unsubscribing
Hey guys, I've looked around, and can't figure out how to unsubscribe.
Could someone please tell me how?
Thanks!
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--__--__--
_______________________________________________
Opendivx mailing list
[email protected]
http://lists.projectmayo.com/mailman/listinfo/opendivx
End of Opendivx Digest
Reply To Poster
Local References / HOW-TO / FAQs