"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

"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

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

"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

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