Frage von Klaus Neyer:
Hello,
I wanted my two plates umpartitionieren, with Linux, I want movies
cut.
How much space do raw data, therefore, I would be my
home directory interpret.
Let's say 4 hours on the plate material, which is then available on DVD
wants to burn.
Greeting
Klaus
Antwort von Thomas Beyer:
Klaus Neyer wrote ...
> How much space do raw data, therefore, I would be my
> Home directory interpret.
>
> Let's say 4 hours on the plate material, which is then available on DVD
> Want to burn.
At 720x576 with PAL YUV colorspace go of 37MB per second. Power
then:
2220MB/min
133.2GB / h
is therefore ~ 533GB. But I believe rather, you do not want with raw data * *
work.
Regards,
Thomas
Antwort von Josef Moellers:
Klaus Neyer wrote:
> Hello,
>
> I wanted my two plates umpartitionieren, with Linux I will fi =
LME
> Cut.
>
> How much space do raw data, therefore, I would be my
> Home directory interpret.
>
> Let's say 4 hours on the plate material, which is then =
on DVD
> Want to burn.
If it is not mentioned of Thomas 533 GB should be: For me
The DVB-S transport streams at about 4.5 GB for 90 minutes of film, =
roughly 3GB / h makes 12 GB for 4h. Since MPEG compressed: YMMV. Then
I need at least once again the same order of TS on
demux-ge-te Video / Audio to MPG DVD subdirectory and then to convert =
n.
Tip: Home-LVM to create a directory, then isses never too small.
Josef
--
Josef Möllers (penguin keeper at FSC)
If failure had no penalty success would not be a prize
- T. Pratchett
Antwort von Klaus Neyer:
Thomas Beyer wrote:
Have just MainActor Trial tested the draw for 3 minutes
Film about 650 MB, so 12 * 650 = about 12 GB per hour?
> So is ~ 533GB. But I believe rather, you do not want with raw data * *
> Work.
"Will" is not, but perhaps "must"? MainActor and "Movies" on Linux
but only copy the material (capture) the digicam on hard drive, the
I said with raw data ...
Antwort von Klaus Neyer:
Josef Moellers wrote:
> If it is not mentioned of Thomas 533 GB should be: For me
> Are the DVB-S transport streams at about 4.5 GB for 90 minutes of film,
Have no DVB, would, for example, by capture of a digicam record.
> Tip: Home-LVM to create a directory, then isses never too small.
OK, I look at times.
Antwort von Thomas Beyer:
Klaus Neyer wrote ...
> I just MainActor Trial tested the draw for 3 minutes
> Film about 650 MB, so 12 * 650 = about 12 GB per hour?
These are not (uncompressed) data more. What MainActor because
stores, so you have to know better, because you do that in the settings
set can :-).
The quantity to judge after you call, sounds like Motion JPEG
(MJPG).
>> So is ~ 533GB. But I believe rather, you do not want with raw data * *
>> Work.
>
> "Will" is not, but perhaps "must"? MainActor and "Movies" on Linux
> But only copy the material (capture) the digicam on hard drive, the
> I thought with raw data ...
Aha, so DV-AVI. Good. These are approximately 25GB per hour with my
DV Canopus HQ codec. There is still synonymous differences (depending on
what level of compression, the camera operates), but this value of
I would expect according to your requirement and at least 100GB space
free scoop.
Regards,
Thomas
Antwort von Markus Knapp:
Thomas Beyer wrote:
> Klaus Neyer wrote ...
>> Have just MainActor Trial tested the draw for 3 minutes
>> Movie about 650 MB, so 12 * 650 = about 12 GB per hour?
> These are not (uncompressed) data more. What MainActor because
> Stores, so you have to know better, because you do that in the settings
> Define it :-).
> The quantity by which to judge you call sounds like Motion JPEG
> (MJPG).
Even that sounds easy for me to DV ...
>>> So is ~ 533GB. But I believe rather, you do not want with raw data * *
>>> work.
>> "Will" is not, but perhaps "must"? MainActor and "Movies" on Linux
>> but only copy the material (capture) the digicam on hard drive, the
>> I thought with raw data ...
> Aha, so DV-AVI. Good. These are approximately 25GB per hour with my
> DV Canopus HQ codec.
So normal DV has about 13GB per hour. What your Canopus since
fabricates, seems not quite in accordance with the standard and is to be synonymous
more than a DV camcorder delivers.
> There is still synonymous differences (depending on
> What level of compression, the camera operates), but this value of
> I would expect according to your requirement and at least 100GB space
> Free scoop.
I thought once synonymous times that my 100GB for DV editing rich,
Now I have 300GB and in order to provide sufficient air.
Gruß,
Markus
--
Markus Knapp * * * http://www.markus-knapp.de video film *
"EineLiebeserklärungistwie eineEröffnungbeimSchach: The
Consequences are obvious. "[Hans Söhnke]
Antwort von Klaus Neyer:
Markus Knapp wrote:
> Also normal DV has about 13GB per hour. What your Canopus since
> Fabricates, seems not quite in accordance with the standard and is to be synonymous
> More than a DV camcorder delivers.
Then comes a yes for me, when I the 600 MB for 3 minutes times 20 to
one hours high computational ...
> I used to think synonymous times that I 100GB for DV editing rich,
> Now I have 300GB and in order to provide sufficient air.
Ich hab ne 160er and a 40er. Or rather on the small complete Linux
and Windows, then all the data on the 160er? Quasi / home completely to
the 160er lay, nothing else?
Antwort von Thomas Beyer:
Mark Knapp said ...
>> The quantity by which to judge you call sounds like Motion JPEG
>> (MJPG).
> Even that sounds easy for me to DV ...
DV-AVI with MJPEG compression is similar, but is not
synonymous with MJPEG.
>> Aha, ie DV-AVI. Good. These are approximately 25GB per hour with my
>> DV Canopus HQ codec.
>
> Also normal DV has about 13GB per hour. What your Canopus since
> Fabricates, seems not quite in accordance with the standard and is to be synonymous
> More than a DV camcorder delivers.
I have written that the accrued amount of data depending on the
Compression ratio of cameras may vary. Therefore
I presented as a guide to me s.niedrigsten compressed (and
therefore s.hochqualitiativsten working) DV codec based. This
is, if a planning of the workflow begins, sensibly, does not it?
> I used to think synonymous times that I 100GB for DV editing rich,
> Now I have 300GB and in order to provide sufficient air.
100GB is my Tempspace a week purely to what I might
in this period again might need ;-).
Regards,
Thomas
Antwort von Alan Tiedemann:
Thomas Beyer wrote:
> Markus Knapp wrote ...
>> So normal DV has about 13GB per hour. What your Canopus since
>> Fabricates, seems not quite in accordance with the standard and is to be synonymous
>> More than a DV camcorder delivers.
>
> I have written that the accrued amount of data depending on the
> Compression ratio of cameras may vary. Therefore
> I presented as a guide to me s.niedrigsten compressed (and
> So s.hochqualitiativsten working) DV codec based. This
> Is, if a planning of the workflow depends ¤ Anfa, verna ¼ of future, right?
What handelsà ¼ Blicher Camera produces ask for more than ~ 13.5 GB per
Hour?
Please synonymous in "affordable" think. The SonyHD-DV is Available,
certainly synonymous produces slightly more data, but is certainly not
"¼ handelsà panoramic view" (and I think that is here).
>> I thought frà ¼ her synonymous times that I 100GB fà ¼ r rich DV editing,
>> Now I have 300GB and so Gena ¼ mainly air.
>
> 100GB is my Tempspace a week purely to what I might
> In that period again might need kà ¶ ;-).
With my VDR has 120 GB, and the plate is permanently full.
My long-term "buffer" (before it moves on DVD) has
protected ¤ tzt 1 TB, my "workstation" just under 700 GB ;-)
GruÃx,
Alan
--
Please only reply to newsgroup! Re: mails, I call only rarely from.
http://www.schwinde.de/webdesign/ ~ http://www.schwinde.de/cdr-info/
Mail: at__0815
hotmail com ~ news-2003-10 wane de
Antwort von Kristian Schmees:
Alan Tiedemann wrote:
[Thomas:]
>> 100GB is my Tempspace a week purely to what I might
>> In that period might once again need ;-).
>
> With my VDR has 120 GB, and the plate is permanently full.
This corresponds to the VDR (-> DVB), but approximately 50 hours recording, gell? Someone,
the MJPEG AVI stores, this would have at 12 GB / h so 600 GB of disk space
have.
> My long-term "buffer" (before it moves on DVD) has
> 1 TB appreciated my "workstation" just under 700 GB ;-)
"Engine room! Unauthorized entry is forbidden!" :-)
SCNR
Kristian
Antwort von Alan Tiedemann:
Kristian Schmees wrote:
> Alan Tiedemann wrote:
>> With my VDR has 120 GB, and the plate is permanently full.
>
> This corresponds to the VDR (-> DVB), but approximately 50 hours recording, gell?
Yes, kà ¶ could get rough. I do not geza ¤ hlt ;-)
> Someone
> The MJPEG AVI stores, sste Dafa ¼ mà ¼ r at 12 GB / h so 600 GB of disk space
> Have.
Who does denn sowas? * SCNR *
>> My long-term "buffer" (before it moves on DVD) has
>> Protected ¤ tzt 1 TB, my "workstation" just under 700 GB ;-)
>
> "The engine room! Admission fà ¼ r trespassers forbidden!" :-)
Hehe, so Approximately hr ;-)
GruÃx,
Alan
--
Please only reply to newsgroup! Re: mails, I call only rarely from.
http://www.schwinde.de/webdesign/ ~ http://www.schwinde.de/cdr-info/
Mail: at__0815 hotmail com ~ news-2003-10 wane de
Antwort von JörgTewes:
Hi!
Monday, 21.02.05 Thomas Beyer schrub ...
> Klaus Neyer wrote ...
>> How much space do raw data, therefore, I would be my
>> Home directory interpret.
>>
>> Let's say 4 hours on the plate material that can
>> Then want to burn to DVD.
> When PAL 720x576 with YUV colorspace go of 37MB per second.
Hmm, how many bits are necessary for the YUV color space? I was always of
something around 20 Mbyte / s is assumed.
And Bye Jörg
--
"I never start a conversation unless I know where it's going. But I
Always leave a little room for someone to disappoint me. Thanks for
not doing it. "
(Garibaldi (to G'Kar), "Comes the Inquisitor")
Antwort von Thomas Beyer:
Jörg Tewes wrote ...
> Monday, 21.02.05 Thomas Beyer schrub ...
>
>> Klaus Neyer wrote ...
>
>>> How much space do raw data, therefore, I would be my
>>> Home directory interpret.
>>>
>>> Let's say 4 hours on the plate material that can
>>> Then want to burn to DVD.
>
>> For PAL 720x576 with YUV colorspace go of 37MB per second.
>
> Hmm, how many bits are necessary for the YUV color space? I was always of
> Something by 20 Mbyte / s is assumed.
Ok, in contrast, the YUV to RGB (24 bits per pixel) "only"
16 bits per pixel are required.
In this country of the common analog TV with standard PAL
and 625 lines per picture with 25B / s would be the * approximate * a
768x576 digital Resolutionvon correspond.
These are then 768x576 = 442368 pixels
442368 x 16 = 7077888 bits
7077888 / 8 = 884736 bytes per frame
884736 * 25 = 22118400 bytes per second
=> 22.118 MB / sec video data
I am a little too lax s.die matter and approach of a Stream
assumed here that still contained 5.1 PCM and also contained more
RGB24 was encoded.
So I correct myself, after I take stupide Schema F nachzubeten
( "with all drum and dran kommst Du loose to ~ 37MB / s) again
after had expected.
Taking to the ~ 22MB / s video data used in stereo audio
48kHz/16Bit stereo to come again poplige 192KB / s to us
remain significantly below the value of me mentioned - assuming that
the signal processing can be consistently in the YUV mode takes place.
Thanks for the correction.
Regards,
Thomas
Antwort von Heiko Nocon:
Jörg Tewes wrote:
> Hmm, how many bits are necessary for the YUV color space? I was always of
> something by 20 Mbyte / s is assumed.
And that is synonymous correctly. Usually YUY2 and I420-coding
(in principle the same, just the sequence of the U-and V-data
is variable) is used and need the 16 bit / pixel, then what good
20MByte / s results.
Other common YUV formats (eg YUV12 or YUV9) still need
fewer bits per pixel. How much, indicates the name of each.
This whole different YUV format to correspond with what is
often under the term "Subsampling" in some programs will take place.
The case affected simply that the human eye
Color dissolves less accurate than the brightness information.
Therefore, the color with lower resolution
saved. Is reduced but not really about the number of bits per
Channel and Pixel, but it will be for the U-and V-channels simply
larger pixels. For example einequadratische group of four
Brightness of pixels is only one Farbpixel saved.
But there are in the professional sector synonymous YUV format to the U-and
V-channel with full resolution and work on top of more bits / channel
use. In the home area but due to lack of appropriate equipment technology
rather uninteresting. Delivery is normally YUY2 and it does
simply does not make sense, based on 24 or even 32bit aufzublasen.
Antwort von JörgTewes:
Hi!
Thursday, 24.02.05 Thomas Beyer schrub ...
> Taking on the ~ 22MB / s video data is still used
> Stereo audio in stereo 48kHz/16Bit to come again poplige
> 192KB / s about this, we remain significantly lower than the me of
> Value above - provided that the signal processing can
> Throughout the YUV mode takes place.
> Thanks for the correction.
Please, please, although I really wanted garnicht correct. I
actually wanted on my reasoning to be elucidated. :-))
And Bye Jörg
--
"There's only one truth about was: the people. Killing is part of a
soldier's job. We can not deny it. We can only live with it and hope
The reasons for doing it are justified. "
(Sheridan, "GROPOS")
Antwort von Andre Beck:
Thomas Beyer writes:
> Klaus Neyer wrote ...
>
>> "Will" is not, but perhaps "must"? MainActor and "Movies" on Linux
>> But only copy the material (capture) the digicam on hard drive, the
>> I thought with raw data ...
>
> Aha, so DV-AVI.
Nope, who needs as AVI. Under Linux you prefer working with a bare
DV, without in any container fit and perhaps even
Extra sausages for the sound to roast. DV is already a container, no one
really wants yet another drumrum ¹.
¹) Admittedly, I speak here * not * for MainActor. No idea what
the Windows port so all of the foreign-entry platform.
--
The _S_anta _C_laus _O_peration
or "how to turn a complete illusion into a neverending money source"
-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <--
Antwort von Thomas Beyer:
Andre Beck wrote ...
>> Aha, ie DV-AVI.
>
> Nope, who needs as AVI. Under Linux you prefer working with a bare
> DV without it in any container fit and perhaps even
> Extra sausages for the sound to roast. DV is already a container, no one
> Really wants yet another drumrum ¹.
Why extra sausage. AVI / WAV based on the RIFF format, and are by
Modularly structured chunks. It is established since 1983 and was
synonymous others on the Amiga / Atari used. Some graphic formats
use this synonymous. Now I know not, what extra sausages because under
Linux fried, but I look like to me ;-).
> ¹) Admittedly, I speak here * not * for MainActor. No idea what
> the port as Windows so all of the foreign-entry platform.
MainActor Windows has long before his birth on the Commodore
Amiga had. The guys at Mark Mönig to insinuate they would
windowslastig that would be absolutely ludicrous.
Regards,
Thomas
Antwort von Frank Derlin:
"Thomas Beyer wrote ...
[Andre Beck]
>> ¹) Admittedly, I speak here * not * for MainActor. No idea what
>> the Windows port so all of the foreign-entry platform.
>
> MainActor Windows has long before his birth on the Commodore
> Amiga had. The guys at Mark Mönig to insinuate they would
> Windowslastig that would be absolutely ludicrous.
Ehm, sorry, but the MainaActor v5 drags on as Linuz
Win something synonymous with one. The win is definitely synonymous with everything
Other than 'Windowskonform'. IMHO is the supposed "third platform"
in any case * not * Windows.
Gruß, Frank
Antwort von Thomas Beyer:
Derlin Frank wrote ...
> [Andre Beck]
>>> ¹) Admittedly, I speak here * not * for MainActor. No idea what
>>> The Windows port so all of the foreign-entry platform.
>>
>> MainActor Windows has long before his birth on the Commodore
>> Amiga had. The guys at Mark Mönig to insinuate they would
>> Windowslastig that would be absolutely ludicrous.
>
> Ehm, sorry, but the MainaActor v5 drags on as Linuz
> Win something synonymous with one. The win is definitely synonymous with everything
> Other than 'Windowskonform'.
Do I have something else claims?
> IMHO is the supposed "third platform"
> In any case * not * Windows.
Also the I have never objected. But it is now time, if you
cross-platform for Mac, Windows and Linux programming needs and
Includes neutral as its holds. This goes to the detriment of the GUI
Affinities of individual platforms, as well as in such a way as to
widespread file formats and to keep any of the Specials
individual systems as possible to ignore - or ideally, to
complement, but the cause expensive. The Core should be but in any
Neutral case.
Regards,
Thomas
Antwort von Frank Derlin:
"Thomas Beyer wrote ...
> Do I have something else claims?
No..
>> IMHO is the supposed "third platform"
>> Any case, * not * Windows.
>
> Also the I have never objected. But it is now time, if you
[snip]
Yes, only I had the urge.
Gruß, Frank
Antwort von Thomas Beyer:
Derlin Frank wrote ...
> "Thomas Beyer wrote ...
>> Do I have something else claims?
>
> No..
>
>>> IMHO is the supposed "third platform"
>>> Any case, * not * Windows.
>>
>> Also the I have never objected. But it is now time, if you
> [Snip]
>
> Yes, only I had the urge.
Oh yes, sorry, I know that of me synonymous. yes I will not always synonymous
keep quite and always have the last word. So I do now
first break ;-)
Regards,
Thomas
Antwort von Andre Beck:
Thomas Beyer writes:
> Andre Beck wrote ...
>
>>> Aha, so DV-AVI.
>>
>> Nope, who needs as AVI. Under Linux you prefer working with a bare
>> DV without it in any container fit and perhaps even
>> Extra sausages for the sound to roast. DV is already a container, no one
>> Really wants yet another drumrum ¹.
>
> Why extra sausage.
As I said, audio-extra sausage. See below.
> AVI / WAV based on the RIFF format, and are by
> Modularly structured chunks. It is established since 1983 and was
> Synonymous others on the Amiga / Atari used.
I know;)
> Some of the graphics formats
> Use this synonymous. Now I know not, what extra sausages because under
> Linux fried, but I look like to me ;-).
It's about the extra sausage and that it is completely independent life -
enabled unnecessarily DV format into another format container packs * and *,
because the now wrapped times already from Mux A and V, while the
A synonymous nor raustrennt and decoded a clone of it in the A-track
the "outer" container chartered. Or can be ebenjenes.
What us the nice divergence between DV-AVI Type 1 "and" Type 2 "
brings.
I just wanted to suggest that the processing of data on
a computer in any way as DV-AVI file format implies
on the contrary - that is inflexible.
>> ¹) Admittedly, I speak here * not * for MainActor. No idea what
>> the Windows port so all of the foreign-entry platform.
>
> MainActor Windows has long before his birth on the Commodore
> Amiga had.
I still know;)
> The guys at Mark Mönig to insinuate they would
> Windowslastig that would be absolutely ludicrous.
I must admit, the program for about a decade ago no longer
up close to have seen. I had assumed it would be the way
of most Amiga software gone, are not now under the
Earth is visiting, but the leap to Windows has managed - in the
plenty of ten years following the development with new platforms
shape to be deformed. That was premature and it should be synonymous
not "windowslastig" sound, only hint at the fact, where the Project
at the time when it came Linux port, his leg had.
There are certain preferences or alternative world views expected.
I think some software is already equipped with AVI, only
because the coder before except with Windows with other nix contact had
and easy for the only relevant form of the world. The
redmondschen memes are just agile. How can otherwise the whole
Win GUI Nachäfferei by KDE and GNOME itself explain ...
--
The _S_anta _C_laus _O_peration
or "how to turn a complete illusion into a neverending money source"
-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <--
