 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Anyone tried this?
http://math.berkeley.edu/~benrg/huffyuv.html
=Bob=
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3ced21bd$1@news.povray.org> , "=Bob=" <bob### [at] threestrands com>
wrote:
> Anyone tried this?
>
> http://math.berkeley.edu/~benrg/huffyuv.html
On his website the author claims that using Motion JPEG would be inadequate to
produce MPEG because it would introduce artifacts. However, the opposite is
true. Conversion from Motion JPEG to MPEG is absolutely without quality loss
(if done properly - of course one can mess up anything if one does it
incorrectly) and it also much faster *.
Given that little knowledge of the author about the topic I seriously doubt he
is credible. Image compression is not physics ;-) His codec is only faster
because it does far less work which then the MPEG encoder will have to do
later anyway. Even worse, who knows what unexpected bugs or side-effects his
code has!
Deciding between some proven method like Motion JPEG and some method someone
cooked up obviously without even understanding much about the topic, well...
Thorsten
* The reason is that Motion JPEG as well as MPEG (1/2) share exactly the same
data structure and encoding/decoding algorithm for the DCT coefficients.
Consequently you don't need to perform the time consuming DCT/IDCT twice but
can simply transcode the image data. All good programs already support
transcoding of Motion JPEG to MPEG. The improper way is to first run a JPEG
decoder and then an MPEG encoder of its output. There are plenty of good
explanations about the exact process on the web to read for the boring
details.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Image compression is not physics ;-)
Really? What else?
http://rii.ricoh.com/~gormish/pdf/spie92_phys_data_compress.pdf
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> His codec is only faster
> because it does far less work which then the MPEG encoder will have to do
> later anyway.
Also with a compression of less than 3:1 you are not going to sample a lot
minutes.
Sampling to raw avi at 320x240 25fps the 2 gigabyte limit (of a single
file) is reached in about 5 minutes (supposing that your HD is fast enough
to write such amount of data in such short time).
This means that with a compression of 3:1 you can only sample about
15 minutes before the 2 gigabyte limit hits in (and what's worse: If the
sampling program does not check the 2 gigabyte limit, the file will grow
over 2GB, making it impossible to open, at least in win9x).
With current >1GHz computers it's perfectly possible to sample for
example 640x480 25 fps to MPEG-4 (eg. DivX) in real-time (I personally do
this all the time).
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3ced29bf@news.povray.org...
<excerpt>
: On his website the author claims that using Motion JPEG would be inadequate to
: produce MPEG because it would introduce artifacts. However, the opposite is
: true. Conversion from Motion JPEG to MPEG is absolutely without quality loss
: (if done properly - of course one can mess up anything if one does it
: incorrectly) and it also much faster *. --Thorsten
</excerpt>
I never knew that. Thanks for checking it out. A quick search for
the term "transcode" delivered a great deal of info.
=Bob=
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote:
> Sampling to raw avi at 320x240 25fps the 2 gigabyte limit (of a single
> file) is reached in about 5 minutes (supposing that your HD is fast enough
> to write such amount of data in such short time).
<mode flamewar=start>
What ? ... Probably your OS is a bit obsolete
2 gibibyte[1] filelimit is (with an apropriate filesystem, of course) neither a
limit under any commercial UNIX, nor under Linux, nor under w2000/XP.
Yes, I was surprised myself, whe I found out, that W2k+NTFS5 had no problems
when creating files greater than 4 gibibyte. Neither they had any problems
accessing a file on the network on a linux system (2.4.18+ReiserFS) over SMB.
So probably this senseless limit of a 32Bit FS is concerned to the obsolete
OS and vFAT ...
At least, if you have a machine, to grab (nearly) PAL in realtime, you should
be able to run any NT-Based Win on this hardware (if you want to with windows)
</mode>
[1] http://physics.nist.gov/cuu/Units/binary.html
http://mathworld.wolfram.com/Byte.html
http://slashdot.org/articles/99/08/10/0259245.shtml
http://nvl.nist.gov/pub/nistpubs/jres/104/2/j42nbr.pdf
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jan Walzer" <jan### [at] lzernet> schrieb im Newsbeitrag
news:3cee040d$1@news.povray.org...
> "Warp" <war### [at] tagpovrayorg> wrote:
> > Sampling to raw avi at 320x240 25fps the 2 gigabyte limit (of a single
> > file) is reached in about 5 minutes (supposing that your HD is fast
enough
> > to write such amount of data in such short time).
> <mode flamewar=start>
> What ? ... Probably your OS is a bit obsolete
He is not talking about the OS, he is talking about the AVI files format.
What does the OS help if the file format doesn't support larger files? :-(
Of course he could use a more modern file format such as the moov (.mov on
WinDOS) format defined by QuickTime which does not suffer from such
arbitrary limits. As a benefit he would also get rid of all AVI audio sync
problems he might be having ;-)
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" wrote:
> > > Sampling to raw avi at 320x240 25fps the 2 gigabyte limit (of a single
> > > file) is reached in about 5 minutes (supposing that your HD is fast
> enough
> > > to write such amount of data in such short time).
> > <mode flamewar=start>
> > What ? ... Probably your OS is a bit obsolete
>
> He is not talking about the OS, he is talking about the AVI files format.
> What does the OS help if the file format doesn't support larger files? :-(
So what? At least my cards are able to grab to a mp2-stream, and these files are
getting a lot bigger then these 4GB I told before ...
of course, mp2 is not AVI but I'm sure he doesn't need to grab as *.avi
... btw: his comment sounded like his filesystem has problems
with files >2GB (which is IIRC the case with vFAT) so it doesn't
help him to use another fileformat !AVI (while I'm still not 100%
sure that even AVI has such a limit)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> ... btw: his comment sounded like his filesystem has problems
> with files >2GB (which is IIRC the case with vFAT) so it doesn't
> help him to use another fileformat !AVI (while I'm still not 100%
> sure that even AVI has such a limit)
See
<http://www.google.com/search?q=%22avi+file+size+limit%22>
You will find that the AVI format has a 2 GB limit inherited by bad design.
Of course, the format is also limited by everything else, like the 512 MB, 8
GB 128 GB and so on limits of IDE harddrives, OS and filesystem file size
limits and so on and so on.
Of course, M$ in 2001 noticed that 2 GB for video isn't a whole lot and they
defined "AVI 2.0". Whether it is in wide-spread use or supported in many
products is of course a completely different story...
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jan Walzer <jan### [at] lzernet> wrote:
> What ? ... Probably your OS is a bit obsolete
> 2 gibibyte[1] filelimit is (with an apropriate filesystem, of course) neither a
> limit under any commercial UNIX, nor under Linux, nor under w2000/XP.
As Thorsten said, the AVI file format limits its size because it has
internally hardcoded 4 bytes for expressing the size of the file (of course
this is braindead because it doesn't only limit the size of the file but it
also makes the life of the encoder harder because it can't know the size of
the file when it writes its header, but only after it has created the whole
file, which means that it must seek again to the beginning to write those
mandatory bytes, but MS is MS...).
As for Linux, yes, it supports files larger than 2 or 4 gigabytes, but only
if you configure it properly. By default the system tools are not compiled so
that they support files over 4 gigabytes (and there might even be a limit of
2 gigabytes due to signedness) but you have to configure their compiling in
order to add this support.
Any third-party program which you may want to use will probably not have
support for files over 2GB (unless they are specifically designed for this)
because they will probably use the C-standard file handles (which in Linux
are 32 bits long).
Also AFAIK the most used file system, ext2, does not have support for files
over 2 GB.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
