G
Guest
Guest
Archived from groups: rec.video.desktop (More info?)
(I happen to use Premiere, but I don't think that's relevant. If any of
you think otherwise, let me know and I'll post this in an Adobe forum.)
Here's the deal:
I bought the packaged Sony VAIO PCX-RX490TV (I know the "490TV" is
right, not sure about the rest) three years ago. 1.7 GHz processor, 80
Gb hard disk formatted C: 16 Gb, D: 64 Gb, 128 Mb memory (upgraded to
384 Mb), front and rear panel iLink (IEEE1394) connectors and a host of
other stuff. Software: Windows ME, Premiere 5.1LE (since upgraded to
6.5) and Sony's DVGate Motion/Still utilities.
My digital camcorder is a Sony TRV-730, which has an iLink connector.
I started out uploading tape from the 730 using DVGate motion. I'd edit
in Premiere, then (because 5.1 didn't have the right export settings, or
I couldn't find them), render the timeline to .avi (in < 4.7 GB chunks),
and export the collection to tape, again with DVGate Motion.
I noticed that after about 1-1/2 hours, digital artifacts (video
breakup, "jigsaw piece" sections of a frame) starting creeping in. If
allowed to continue, they got closer and closer until each frame was
affected. The sound also deteriorated.
I could find no cause, but adjusted my work so that no segment exceeded
1-1/2 hours. I found that closing and restarting DVGate motion would
reset this symptom, so I could continue.
Fast forward to Premiere 6.5 and 384 Mb memory upgrade. Now I can
export directly from the timeline, but the 1-1/2 hour limit is still
there.
Fast forward again to the addition of a 200 Gb external iLink drive
which I've been using for my latest projects. It uses the rear panel
connector. The camcorder uses the front one. During export, Premiere
accesses files on the 200 Gb drive and writes them to the camcorder.
But now my pre-artifact limit has dropped to one hour. I can't work
around that; I have more than an hour of stuff that needs to be
frame-accurate.
So I need to confront the problem, which is why I've put you through all
this prologue.
My thoughts, totally unsupported by any hard evidence:
o It's not a Premiere problem, since it occurred earlier with DVGate
Motion.
o It *is* a data rate problem, in which the camcorder consumes data
marginally faster than the computer can provide it (or IEEE1394 can
pass it) until any original buffers set up at the start of the
operation are exhausted. At that point data starts being lost, with
more and more data going by the boards as the situation continues.
o The reduction to 1 hour with the addition of the second iLink
component seems to suggest an overall iLink bandwidth limit
within the computer.
Oddly enough, I don't have a similar limit problem when uploading from
the camcorder to the computer, even though the same data paths are used.
I have no theory whatever for that.
Now the questions:
o Does any part of that analysis make sense to any of you?
o If so, can you suggest which element in the data path is the
bottleneck?
o The data path within the computer to the iLink port?
o The iLink itself?
o The data path within the camcorder itself?
Sudden stream-of-consciousness thought: I've observed the
phenomenon on the camcorder's built-in viewscreen and heard it on an
external speaker connected to the camcorder's audio output
connector. But during all this time I have *not* checked whether
the recorded tape is affected. So one more possible variable is
the camcorder's D-A converter. That would not seem to jibe with
the reduction in time-before-incident when I added the external
drive. Your thoughts?
o If the problem is buffer exhaustion in the computer, can any of
you suggest *which* buffer? Is it one supplied by the OS to
Premiere or DVGate Motion? Does either app request that buffer?
With a specific size, or all (or a percentage) of available
memory? Can that request size be configured?
o Is there any other explanation that I've missed?
If you've stayed with me this far, I'd be very grateful for any help you
could provide -- things to try, other forums to ask, etc. If I failed
to provide any relevant configuration info, let me know and I'll search
that out.
Many thanks in advance.
-Larry Byler-
annlarryATpcbellDOTnet
(I happen to use Premiere, but I don't think that's relevant. If any of
you think otherwise, let me know and I'll post this in an Adobe forum.)
Here's the deal:
I bought the packaged Sony VAIO PCX-RX490TV (I know the "490TV" is
right, not sure about the rest) three years ago. 1.7 GHz processor, 80
Gb hard disk formatted C: 16 Gb, D: 64 Gb, 128 Mb memory (upgraded to
384 Mb), front and rear panel iLink (IEEE1394) connectors and a host of
other stuff. Software: Windows ME, Premiere 5.1LE (since upgraded to
6.5) and Sony's DVGate Motion/Still utilities.
My digital camcorder is a Sony TRV-730, which has an iLink connector.
I started out uploading tape from the 730 using DVGate motion. I'd edit
in Premiere, then (because 5.1 didn't have the right export settings, or
I couldn't find them), render the timeline to .avi (in < 4.7 GB chunks),
and export the collection to tape, again with DVGate Motion.
I noticed that after about 1-1/2 hours, digital artifacts (video
breakup, "jigsaw piece" sections of a frame) starting creeping in. If
allowed to continue, they got closer and closer until each frame was
affected. The sound also deteriorated.
I could find no cause, but adjusted my work so that no segment exceeded
1-1/2 hours. I found that closing and restarting DVGate motion would
reset this symptom, so I could continue.
Fast forward to Premiere 6.5 and 384 Mb memory upgrade. Now I can
export directly from the timeline, but the 1-1/2 hour limit is still
there.
Fast forward again to the addition of a 200 Gb external iLink drive
which I've been using for my latest projects. It uses the rear panel
connector. The camcorder uses the front one. During export, Premiere
accesses files on the 200 Gb drive and writes them to the camcorder.
But now my pre-artifact limit has dropped to one hour. I can't work
around that; I have more than an hour of stuff that needs to be
frame-accurate.
So I need to confront the problem, which is why I've put you through all
this prologue.
My thoughts, totally unsupported by any hard evidence:
o It's not a Premiere problem, since it occurred earlier with DVGate
Motion.
o It *is* a data rate problem, in which the camcorder consumes data
marginally faster than the computer can provide it (or IEEE1394 can
pass it) until any original buffers set up at the start of the
operation are exhausted. At that point data starts being lost, with
more and more data going by the boards as the situation continues.
o The reduction to 1 hour with the addition of the second iLink
component seems to suggest an overall iLink bandwidth limit
within the computer.
Oddly enough, I don't have a similar limit problem when uploading from
the camcorder to the computer, even though the same data paths are used.
I have no theory whatever for that.
Now the questions:
o Does any part of that analysis make sense to any of you?
o If so, can you suggest which element in the data path is the
bottleneck?
o The data path within the computer to the iLink port?
o The iLink itself?
o The data path within the camcorder itself?
Sudden stream-of-consciousness thought: I've observed the
phenomenon on the camcorder's built-in viewscreen and heard it on an
external speaker connected to the camcorder's audio output
connector. But during all this time I have *not* checked whether
the recorded tape is affected. So one more possible variable is
the camcorder's D-A converter. That would not seem to jibe with
the reduction in time-before-incident when I added the external
drive. Your thoughts?
o If the problem is buffer exhaustion in the computer, can any of
you suggest *which* buffer? Is it one supplied by the OS to
Premiere or DVGate Motion? Does either app request that buffer?
With a specific size, or all (or a percentage) of available
memory? Can that request size be configured?
o Is there any other explanation that I've missed?
If you've stayed with me this far, I'd be very grateful for any help you
could provide -- things to try, other forums to ask, etc. If I failed
to provide any relevant configuration info, let me know and I'll search
that out.
Many thanks in advance.
-Larry Byler-
annlarryATpcbellDOTnet