I don't have dropped frames in any video I've ever output with Final Cut. With real-time display, sure, but that doesn't have anything to do with encoding tasks.matticus008 said:That's not true. What do you think causes dropped frames?
I don't have dropped frames in any video I've ever output with Final Cut. With real-time display, sure, but that doesn't have anything to do with encoding tasks.matticus008 said:That's not true. What do you think causes dropped frames?
Then you're fortunate. But it does happen, and it's caused by low available RAM or a tie-up in the I/O system. Loss of sound bits (or whatever the proper audio term is) happens the same way, as does the occasional playback stutter in iTunes or QuickTime. The system is far from bulletproof, and while rare, encoding can fail, especially when the computer is tossing large files around and the installed RAM is being used by other applications.Heb1228 said:I don't have dropped frames in any video I've ever output with Final Cut. With real-time display, sure, but that doesn't have anything to do with encoding tasks.
Why? If both computers are capable of running the software, then the PowerBook would simply be faster. But if your PB ran out of RAM, you'd drop frames and have failed encodings, same as if your iMac ran out of RAM. It's not spec-dependent, it's available resource dependent. An iBook and a quad PowerMac are both capable of dropping frames and not successfully encoding from time to time.Heb1228 said:If that were true... my Powerbook should do a better job encoding music/video than my iMac.
I'm making up dropped frames, beach balls, and playback stutters?You really need to provide some documentation for this theory... cause I think you're making it up.
Like I've said several times above... dropped frames during playback has nothing whatever to do with encoding.matticus008 said:An iBook and a quad PowerMac are both capable of dropping frames and not successfully encoding from time to time.
Hopefully a clean install will fix the problem then! Good luck. And sorry for hijacking your thread.jesusphreak said:Well it certainly isn't having any problems with the OSX discs...
It shouldn't be a disagreement at all. It's an objective, technical reality.neocell said:Agree to Disagree, and move on![]()
1. Yeah it does. Say you have a DV source and you try to convert it to H.264 on a weak system. It'll drop frames. That encoded video will have dropped frames whether it's played back on that system or copied over to a fully loaded PowerMac, because it lost data in the conversion process.Heb1228 said:Like I've said several times above... dropped frames during playback has nothing whatever to do with encoding.
I defy you to show me a video that dropped frames during the encoding process.
Capturing video is also a completely different question. The reason frames can be dropped in capture is because the tape plays at a fixed rate.matticus008 said:If it's absolutely necessary (though it shouldn't be), here's a link to causes of dropped frames in capturing video.
Nope. the only dropped frames are in playback. On a faster machine, it'll play back perfectly.matticus008 said:1. Yeah it does. Say you have a DV source and you try to convert it to H.264 on a weak system. It'll drop frames. That encoded video will have dropped frames whether it's played back on that system or copied over to a fully loaded PowerMac, because it lost data in the conversion process.
Because I could look at the frame rate in the Quicktime info window to make sure it wasn't dropping frames on playback. Easy enough?matticus008 said:2. If I gave you a video with dropped frames, how would you be able to tell whether it was caused by playback or encoding without having the raw footage on the camera to compare it?
Prove it. If that's the case, why can't low end computers encode H.264? Why do some codecs produce horrible video and others work fine on the same system?Heb1228 said:Nope. the only dropped frames are in playback. On a faster machine, it'll play back perfectly.
They can encode it. They just can't play it back. If you want I'll encode a video on my 450 iMac and let you see that it plays back perfectly on a faster computer.matticus008 said:Prove it. If that's the case, why can't low end computers encode H.264?
huh? because some codecs are better than others.matticus008 said:Why do some codecs produce horrible video and others work fine on the same system?
I'd like to see documentation on frame dropping "never" occurring during encoding. There's a reason you never see encoding (edit)an HDV source to high-definition H.264 without data loss on a system with <256MB RAM and/or <400MHz CPU. You've yet to demonstrate that running out of RAM or an I/O stutter (i.e. reasons for buffer underruns) can't result in a failed or corrupted encoding. I'm not going to go back and forth on this, because that's just how computers work.Heb1228 said:They can encode it. They just can't play it back. If you want I'll encode a video on my 450 iMac and let you see that it plays back perfectly on a faster computer.
Yes, and the better codecs won't run adequately without the muscle to lift them. Encoding to 320x240 MPEG is going to be a lot easier on the system than pumping out 1080p from HDV tape. You think that a 300MHz iBook with 128MB of RAM could do it?huh? because some codecs are better than others.
Look man, you just don't know what you're talking about. Here's how I'll prove it.matticus008 said:I'd like to see documentation on frame dropping "never" occurring during encoding. There's a reason you never see encoding a DV source to high-definition H.264 without data loss on a system with <256MB RAM and/or <400MHz CPU. You've yet to demonstrate that running out of RAM or an I/O stutter (i.e. reasons for buffer underruns) won't result in a failed or corrupted encoding.
And if I have to explain it to you, then its no wonder we're having this conversation.you never see encoding a DV source to high-definition H.264
I agree thats very odd. Sounds like its gotta be faulty hardware.jesusphreak said:Had to force quit to get iTunes to close. Guess I'll be calling Apple Support tommorrow, no clue what the problem may be.
Well, you seem to be talking about transcoding, not encoding, so I'd watch the accusations. Also, you can't convert a DV clip to a higher quality--any change in quality is a downward one.Heb1228 said:Look man, you just don't know what you're talking about. Here's how I'll prove it.
My iMac is currently working on converting a 1 minute DV clip to the higher quality H.264 setting in Quicktime sharing preferences.
The way memory is managed in OS X, free RAM is relatively low in Activity Monitor at all times. I have just 100MB reported free right now, and the only apps I'm currently running are iTunes and Firefox. Reported free RAM isn't reflective of the system's capabilities.I've also got 14 apps open on the machine and less than 10MB of free RAM showing in Activity Monitor.
On this, we agree completely. But we already knew that a dozen posts ago.Heb1228 said:I agree thats very odd. Sounds like its gotta be faulty hardware.
matticus008 said:Also, you can't convert a DV clip to a higher quality--any change in quality is a downward one.
When I said higher, I meant higher than the "Small" or "Medium" H.264 settings in the output window. You were the one talking about encoding an HD clip from a DV original source a few posts ago so don't try it make it look like I don't know what I'm talking about.
iTunes encoding does not fail because of a slow data transfer rate from the optical drive. Or because RAM is full.matticus008 said:but I am saying that video and audio encoding does occasionally fail.
Considering that its impossible to prove a negative, I guess you'll never see any such document. You're the one that needs to produce something saying that a slower machine results in lower quality video/audio encoding from the same source file. Because that's an absurd assertion.matticus008 said:but I'll still be waiting on a document that says that you can never, ever lose frames while encoding video, ever.
HDV. Like you didn't know it was a typo.Heb1228 said:You were the one talking about encoding an HD clip from a DV original source a few posts ago so don't try it make it look like I don't know what I'm talking about.
If the optical drive stalls or the RAM fills completely, the encoding DOES fail. I don't want to kick a dead horse here, but those are exactly causes of failed encodings.iTunes encoding does not fail because of a slow data transfer rate from the optical drive. Or because RAM is full.
That's not my assertion at all. I said that a resource failure can result in a corrupted recording. A resource failure can occur on a G3 iBook or a quad PowerMac. Proving a negative is not impossible, and in this case is required for your argument to make sense. I've given you a link listing the various system components that play a role in capture, encoding, and transcoding. A problem with any of them can produce bad files with varying degress of seriousness. Here are a couple more:Considering that its impossible to prove a negative, I guess you'll never see any such document. You're the one that needs to produce something saying that a slower machine results in lower quality video/audio encoding from the same source file. Because that's an absurd assertion.
jesusphreak said:Hmm, well I just pulled out a like-new CD from its case and the MacBook ripped the whole thing successfully. It just appears that the drive is sensitive to the most minute scratches? Is that really an issue or do I need to get some kind of CD polisher?
codo said:Possibly, but it could be the drive. I mean, if it was that sensitive, surly by now other MB owners would have said something too? If I were you, I'd want it checked out.