POV-Ray : Newsgroups : povray.general : Video Compression Server Time
6 Aug 2024 08:12:02 EDT (-0400)
  Video Compression (Message 11 to 14 of 14)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Jan Walzer
Subject: Re: Video Compression
Date: 24 May 2002 10:26:59
Message: <3cee4db3@news.povray.org>
"Warp" 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...).

I ever wondered myself, why they have to specify the filesize in the header,
as (IIRC) the data is already written in chunks so the could simply stop
loading/playing thhe file when there's EOF (or a bad chunk) ...
When it happens, that my File has some errors at the end, I still like to watch
the first part I got... this is only possible if the filesize in the header gets
adjusted ... thats so senseless/painful ...

>   As for Linux, yes, it supports files larger than 2 or 4 gigabytes, but only
                                                              ^^-bi ;)
> 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.

Have you tried SuSE-Linux ? [1]

>   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).
->[1]

>   Also AFAIK the most used file system, ext2, does not have support for files
> over 2 GB.

define "most" `?

if you really mean "Most of all filesystems that ever existed until now and
that are supported by the linux-kernel" then you're probably right.
But if you only consider the Filesystems that are recent and supported by the
distributors or the ones, that are currently "usable" (You know what I mean
by this), you'll see, that the ext2 that you mean (actually there's a
64Bit-patch for ext2[2]) is one of only a few FS that don't support this. The
internal VFS-Layer of the kernel already supports 64Bit since 2.4.0.

So there are really only the tools left, that don't support 64Bit. But:
most of these tools are AFAIK linked against glibc and if these tools
only do simple read/write ops, (They don't need a fileseekpointer) they
wouldn't need recompiling, but only a recent libc (please correct me here,
as I avoid programming C/C++ where I can). So only FS-critical apps need
to be recompiled when upgrading the FS, but wouldn't you normally do so ?

[1] Some call it the Nurembergian Windows because SuSE is located in Nuremberg
    and the installation and usability is luserfriendly like Windows. After boot
    you need three mousclicks until your harddisk gets partitioned and installed
    in the recent 8.0 version ...
    In this standard install it will choose ReiserFS for anything except /boot
    and all the tools are 64Bit-ready ...

    So it depends on your distribution, if you need to recompile your tools
    yourself to use the big filesystems or not...

[2] They used some flags in the FS that were ought to hold ACL-data, but this
    feature never got implemented ...


Post a reply to this message

From: Warp
Subject: Re: Video Compression
Date: 24 May 2002 13:33:34
Message: <3cee796e@news.povray.org>
Jan Walzer <jan### [at] lzernet> wrote:
> I ever wondered myself, why they have to specify the filesize in the header,
> as (IIRC) the data is already written in chunks so the could simply stop
> loading/playing thhe file when there's EOF (or a bad chunk) ...
> When it happens, that my File has some errors at the end, I still like to watch
> the first part I got... this is only possible if the filesize in the header gets
> adjusted ... thats so senseless/painful ...

  That's not the whole story.
  AVI is bad because it's not streamable. If you chop an AVI from the end,
probably all players will refuse to play it. For some reason you need the
*whole* AVI file in order to play it. (There might be some players out there
which ignore these things and are able to play the AVI even if it has been
chopped off, but at least MediaPlayer does not do this.)
  In streamable formats (such as MPEG) you can take any part of the file
(it doesn't even have to be from the beginning of the file) and you probably
will be able to play that part. This is how net radios work: The mp3 format
is perfectly streamable, and a player can start playing from anywhere in
the middle of the stream, which means that you can "join" the net radio
station at any time. You can also add garbage at the beginning and end of an
mp3 file and it will probably not affect its playing in any way (players
usually are able to search the file for chunks they recognize and they ignore
garbage).

-- 
#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

From: Jan Walzer
Subject: Re: Video Compression
Date: 24 May 2002 15:50:49
Message: <3cee9999$1@news.povray.org>
"Warp" <war### [at] tagpovrayorg> wrote:
> > I ever wondered myself, why they have to specify the filesize in the header,
> > as (IIRC) the data is already written in chunks so the could simply stop
> > loading/playing thhe file when there's EOF (or a bad chunk) ...
> > When it happens, that my File has some errors at the end, I still like to watch
> > the first part I got... this is only possible if the filesize in the header gets
> > adjusted ... thats so senseless/painful ...
>
>   That's not the whole story.
>   AVI is bad because it's not streamable. If you chop an AVI from the end,
> probably all players will refuse to play it. For some reason you need the
> *whole* AVI file in order to play it. (There might be some players out there
> which ignore these things and are able to play the AVI even if it has been
> chopped off, but at least MediaPlayer does not do this.)

but, doesn't that also depend on the used codecs?
AVI is only the container for the whole stuff ...

If I choose to convert a stream (under Windows) to an AVI, using the divX codec
it will create an *.avi file with (in theory) an streamable movie. What makes
it so worse under windows is, that the filesuffix doesn't mean anything to the
kind of file stored, as long as its linked with the mediaplayer. This prog decides
itself from the header, which codec it wants to use, so it's hard to tell, if the
AVI-file, you downloaded isn't an mpg in reality, vice versa. So it then can
happen, that you have the luck, to view it on your own computer, but giving it
someone else, who hasn't installed some senseless codec and he can't see anything
from the *.mpg...

... BTW: WMP isn't even capable of playing a RAW-PCM-Wavefile, that is truncated,
only because the length doesn't fit. The specification of the data is already in
the header (ie 44.1kHz,16Bit,Stereo) so it only needs something like "cat > /dev/dsp"
... silly wmp ...


Post a reply to this message

From: Hugo
Subject: Re: Video Compression
Date: 25 May 2002 17:32:45
Message: <3cf002fd$1@news.povray.org>
> : 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=

Hmm, allright but I DO use the Huffyuv codec all the time, and it doesn't
have bugs! I am a quality freak. Huffyuv is lossless compression. Mjpeg
isn't.. File-size is not a problem for me, I bought extra harddisk space
just for this.. After capturing, I run the video and audio through several
filters and enhancers, and finally re-encode as Divx.. The quality I get
from this work, is much better than everything I ever downloaded from the
net.. If you're trying to make great video, don't forget that Huffyuv allows
you to *edit* the files and save them again and again.. They won't loose
quality until you switch to another codec.

- Hugo


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.