Archived from groups: rec.video.desktop,rec.video (
More info?)
"Thomas G. Marshall" <tgm2tothe10thpower@replacetextwithnumber.hotmail.com>
wrote in message news:jZKRd.57379$8a6.39977@trndny09...
> Gene E. Bloch coughed up:
>> On 2/17/2005, Thomas G. Marshall managed to type:
>>> PTRAVEL coughed up:
>>>> "Thomas G. Marshall"
>>>> <tgm2tothe10thpower@replacetextwithnumber.hotmail.com> wrote in
>>>> message news:ABeQd.30612$t46.27305@trndny04...
>>>>> Thomas G. Marshall coughed up:
>>>>>> Panasonic GS15 w/ Nero:
>>>>>>
>>>>>> I'm not sure, but it /seems/ as if uploading from my gs-15 in DV
>>>>>> file format is as "native" a way possible to not lose any frames
>>>>>> or pixels.
>>>>>>
>>>>>> Is this true? I'm interested in bulk uploading my tapes, one file
>>>>>> per tape, for later splitting and perhaps converting to mpg or
>>>>>> burning on dvd.
>>>>>>
>>>>>> If it should be DV, then should I use type-1 or type-2?
>>>>>>
>>>>>> I'm afraid to chose the wrong format which might result in a
>>>>>> loss-compression being used, losing pixels I wouldn't able to get
>>>>>> back.
>>>>>>
>>>>>> What is the safest format to use? If I burn any to dvd, I'm
>>>>>> assuming that it would be best to burn in native DV format?
>>>>>
>>>>> By this I mean, placing the DV format file itself onto a /data/
>>>>> dvd.
>>>>
>>>> Transfers from your camcorder will be a miniDV codec AVI -- these
>>>> will be lossless. However, unless you're interested only in
>>>> archiving chunks no larger than 20 minutes
>>>
>>> Why 20 minutes? Because of huge files? Does this miniDV codec not
>>> do a lossless compression?
>>>
>>
>> Exactly (well, sort of). The contents of the tape is compressed 5:1 by
>> the camera electronics, and the transfer to the PC over FireWire is
>> just a bit for bit copy to the computer.
>> This is also true if you
>> transfer directly from the camera section without tape (e.g., analog
>> pass-through or WebCam style). The full video only exists temporarily
>> in the internal electronics.
>
> Since the internal hoohah is not under my control, I don't really care.
>
> But there *are* lossless compressions available for this version of AVI,
> no?
Yes. Huffy is a lossless codec.
> > AH, *wait*. I think I understand what you are getting at. The 5:1
> compression that is done by the camera is already a fully digital
> compression and cannot be easily compressed further without loss.
Almost. The 5:1 compression done by the camera results in loss. Howelver,
as you've surmised, it is done at the camera end, is part of the DV-25 spec,
and can't be by-passed.
> But that
> all depends upon the algorithm used by that compression. For example,
> using
> the LZ built into winzip can manage to squeeze an extra lossless 10% out
> of
> compressions done by LZ of smaller bit width by other applications.
LZ is particularly unsuited for video, which is one of the reasons why it
isn't used. It's highly unlikely you'll realize gains of as much as 10%
using it -- 1 or 2% is more likely.
>
> It's just that some people in this ng seem to imply that any compression
> at
> all *necessitates* loss, and that is just not true in the digital world.
> It
> may be an analog holdover.
You're right -- compression does not necessarily imply loss. However, in
the video world, for all practical purposes, it does.
>
> Thanks.
>
> But my next question is that Nero offers a multitude of AVI compressions,
> should I decide to encode from the tape in AVI. Some of these
> compressions
> are lossless, and might squeeze the (already 5:1) output a little better,
> no?
If it's a true lossless compression and don't you care about the ability to
view the archived video directly, then in theory you're right. However, in
practice, lossless compressions will not gain very much.
>
>
>
>> Anyway, the resulting data takes up about 3.6 MBytes/sec or 13 GB per
>> hour, and the DVD holds only 4.37 GB (or 4.7 GB if you prefer 10^9
>> instead of 2^30 for a GB).
>>
>> It would be a lot worse if the 5:1 compression wasn't there...
>>
>> BTW, if you're using FAT32 instead of NTFS or a Unix file system,
>> individual files can't be over 4GB anyway - and not only that, some
>> software cuts this limit in half.
>
> Nah, NTFS. But the 4 gig to 2 gig thing is a very common problem: it
> centers on software not regarding a 32 bit integer as unsigned. The
> presense of that sign bit knocks the range of the integer in half. In
> this
> day and age, nearly /everything/ should be using 64 bit integers anyway.
>
>
> ...[rip]...
>
>
> --
>
http://www.allexperts.com is a nifty way to get an answer to just about
> /anything/.
>
>