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

[OpenDivX] OpenDivX Encoder -> OpenDivX Daily Forum Digests



OpenDivX Encoder -> OpenDivX Daily Forum Digests





Topic:		Does anybody want this?
Author:		gruel
Posted:		 2001-02-26 02:46
------------------------------------------------------------------------
--------
Quote:
On 2001-02-25 15:56, czw wrote:
The distributed workload code existed from an experiment at the
university, so the only thing we needed to do was to distribute a
different set of data.
[...]
First stop is support for Linux and Win32, support for other OS:es will
come as we find systems or get patches. 

Well, I meant details on the implementation: 
What is going to be parallel afterwards? What protocols do you use for
exchange of data? 

chl

P.S. spatz is right: Beer in the sauna is soooooo swedisch ;-)


Topic:		Awesome quality!! but porblems with overlay driver in
fullscreen.
Author:		BetaBoy
Posted:		 2001-02-26 03:15
------------------------------------------------------------------------
--------
Quote:
On 2001-02-24 16:02, ananonymoususer wrote:
sorry to go off topic, is there a web page where i can learn about
mpeg-4 specs

Here are a few links for you:
<!-- BBCode Start --><A HREF="http://www.cselt.it/mpeg/standards.htm";
TARGET="_blank">www.cselt.it/mpeg/standards.htm</A><!-- BBCode End -->
<!-- BBCode Start --><A HREF="http://www.m4if.org/index.html";
TARGET="_blank">www.m4if.org/index.html</A><!-- BBCode End -->
<!-- BBCode Start --><A
HREF="http://www.cselt.it/mpeg/documents/koenen/mp4ieee.htm";
TARGET="_blank">www.cselt.it/mpeg/documents/koenen/mp4ieee.htm</A><!--
BBCode End -->

-----------------
Dan Marlin
<!-- BBCode Start --><IMG
SRC="http://www.mydivx.com/images/news/divxvideo.gif";><!-- BBCode End
-->
<!-- BBCode Start --><A HREF="http://www.mydivx.com";
TARGET="_blank">www.mydivx.com</A><!-- BBCode End -->
'We are the Music Makers and the Dreamers of the Dreams.' WW[ This
message was edited by: BetaBoy on 2001-02-26 03:17 ]


Topic:		Does anybody want this?
Author:		SVB
Posted:		 2001-02-26 03:35
------------------------------------------------------------------------
--------
So you are gonna develop some distributed Win32 (and Linux) appllication
for video encoding, do I understand right? Something independent of
OpenDivX and not involving any changes in encoder.
Do you want it to be useable with other codecs too?

(I've never drunk beer in the sauna, sorry ;-)[ This message was edited
by: SVB on 2001-02-26 03:36 ]


Topic:		Does anybody want this?
Author:		czw
Posted:		 2001-02-26 07:29
------------------------------------------------------------------------
--------
Quote:
Well, I meant details on the implementation: 
What is going to be parallel afterwards? What protocols do you use for
exchange of data? 

The principle is easy: distribute snippets to one or more encoders (say
eight seconds per block). This block will now be encoded and sent back
to the client who requested a movie encoding. When all eight-seconds
parts have arrived in encoded form, they are glued together.

Protocol? It's a really simple telnet-style protocol where the commands
are cleartext and data is sent in binary with CRC32 checksum and
(optional) data compression. All of this communication code is old code
being reused for the third or fourth time.


Topic:		Does anybody want this?
Author:		gruel
Posted:		 2001-02-26 10:09
------------------------------------------------------------------------
--------
Quote:
On 2001-02-26 07:29, czw wrote:
The principle is easy: distribute snippets to one or more encoders (say
eight seconds per block). This block will now be encoded and sent back
to the client who requested a movie encoding. When all eight-seconds
parts have arrived in encoded form, they are glued together.

Hej igen,
are you sure that it's useful to send away such short sniplet of fixed
length? If you use some sort of MPEG-style input, it would surely be
best to only cut at I-frames. But except for OpenDivx and some patched
Divx-versions there still may be produced too many of those. The
advantage of I-frames only at scene-changes should in no way be lost. 

Also the motion detection should be able to do some "look ahead",
otherwise the method will be fast, but give poor quality. 

Anyhow, I would be very much interested in the technicalities. Do you
want to extend the encoding-routine itself for this, or write some kind
of "wrapper", that handels snipping and merging again, or is it going to
be a parallel application, calling the ordinary encoder?

Is it perhaps possible for me to look into some of your code? Email is
<a href="mailto:[email protected]"; target="_new">[email protected]</a>

chl

P.S. If we continue like this, there might soon be to be a "parallel
encoding" forum ;-)


Topic:		Alpha 48 Bitrate slow to adjust?
Author:		tomnot
Posted:		 2001-02-26 10:16
------------------------------------------------------------------------
--------
Guys,

Great job with the new release.

I get blockiness when changing to some scenes, (maximum bitrate @
448x192). Any chance someone can make the codec alter the bitrate
faster? The DivX low motion did not seem to have this problem.

Hope it gets even better!
Tom.


Topic:		Does anybody want this?
Author:		czw
Posted:		 2001-02-26 11:01
------------------------------------------------------------------------
--------
Quote:are you sure that it's useful to send away such short sniplet of
fixed length? If you use some sort of MPEG-style input, it would surely
be best to only cut at I-frames. But except for OpenDivx and some
patched Divx-versions there still may be produced too many of those. The
advantage of I-frames only at scene-changes should in no way be lost.

Also the motion detection should be able to do some "look ahead",
otherwise the method will be fast, but give poor quality.

You are correct - we will do some primitive data analysis to break up at
I-frames only. I don't have extensive knowledge in the encoding process
yet, so I can't give a comment about the motion detection. Is the image
quality reduced if there are more I-frames or less I-frames in a scene?
Is there a big processing time difference? And why the hell is the
source code divided in separate places for Win32, Linux, Mac and Core
instead of just one XP source repository?

Quote:Anyhow, I would be very much interested in the technicalities. Do
you want to extend the encoding-routine itself for this, or write some
kind of "wrapper", that handels snipping and merging again, or is it
going to be a parallel application, calling the ordinary encoder?

This will act as a separate application. The OpenDivX code will never
realize that this is a part of a larger distributed task. By doing this,
the encoder engine is free to do large changes without affecting our
code.

About sending code: we keep the source in a private CVS server until it
can be used in the most basic way.


Topic:		Does anybody want this?
Author:		gruel
Posted:		 2001-02-26 12:46
------------------------------------------------------------------------
--------
Quote:
On 2001-02-26 11:01, czw wrote:
Is the image quality reduced if there are more I-frames or less I-frames
in a scene?

I-frames encode the whole frame, P- and B-frames only the differences to
others. So more I-frames make the file _larger_ in first place. If you
stick to a fixed data rate, that will lead to worse quality, of course.

Quote:
About sending code: we keep the source in a private CVS server until it
can be used in the most basic way.

Yes, that's what I thought, and that's why I asked you for a copy. ;-) 
I'm just interested in any (even non-compiling) snapshot, to see if the
methods are similar to what I had plans for with MPI. 
But never mind...

chl[ This message was edited by: gruel on 2001-02-26 12:47 ]


_______________________________________________
OpenDivX mailing list
[email protected]
http://lists.projectmayo.com/mailman/listinfo/opendivx


Reply To Poster

Local References / HOW-TO / FAQs