Re: Recording bitrate is there a definitive answer?
 

That's not true of most modern NLEs. He'll only be re-encoding the imagery when he renders out his final edit.

Re: Recording bitrate is there a definitive answer?
 

Going from 50p to 25p means you have to remove frames there is no alternative.

If the encoding is not all-intra you have to re-encode because with long GOP encodings frames are encoded with respect to other frames.

Re: Recording bitrate is there a definitive answer?
 

The way you are describing it comes across that you're saying if you record the AVCHD/MP4 format on the HF G30 in 50p, put it on a 25p timeline, edit it, add your titles/color/etc, then render it out via the YouTube preset, that your resulting .MP4 render of your timeline will be two generations removed from the source. That is simply not true. All footage, Intra or LongGOP, is decoded into full frames whenever you play it back on the timeline in memory. With Intra, it's easier to decode because it's less computationally expensive. With LongGOP, it's more compressed, so more computationally expensive. However, it is all first generation.

When you start editing, it's all based on that in memory decode of full frames from the source. When you render out to a YouTube preset MP4 or ProRes or DNxHD, or nearly anything else, the first generation source will be re-rendered, whether it's Intra or LongGOP, into the new format. This file that you render out from your timeline is now a second generation of the video. The only way you get away from this is if your source footage is already ProRes or DNxHD, which is not the case here, depends on your NLE, and whether you're just making cuts. If you add any kind of filter, title, color correction, etc. then the frames will be re-encoded, period.

Re: Recording bitrate is there a definitive answer?
 

I did not say that at all.

That is all correct.

Not quite, you can decimate frames with all all-intra codecs without re-encoding, so that includes H.264.

Obviously.

Re: Recording bitrate is there a definitive answer?
 

I didn't say you said it. I said, explicitly, "The way you are describing it comes across"

You cannot "decimate" frames. If you want to claim that frames in LongGOP can be "decimated", that is something I have never heard of or experienced in all of the LongGOP material I have worked with, and I'll have to ask for an example of this.

Re: Recording bitrate is there a definitive answer?
 

You keep putting words in my mouth. I wrote all-intra not long GOP.

Here is what I wrote:

"Not quite, you can decimate frames with all all-intra codecs without re-encoding, so that includes H.264."

H.264 supports all-intra.

Sorry Gary, but I am getting the feeling you want to argue for arguments sake even if there is nothing to argue about.

Re: Recording bitrate is there a definitive answer?
 

I made a mistake and read it backwards. Even with your point of it being Intra and not LongGOP, it still doesn't make sense.

Yes there is, because what you're trying to claim isn't true. What do you mean by "decimate" frames specifically? You've already agreed it has to be re-encoded if you add filters or titles, so what else can you possibly mean by "decimate"?

Re: Recording bitrate is there a definitive answer?
 

Ah, I re-read this and now it makes more sense, because you were saying that what I say below is "not quite".

So what you're saying is that frames aren't re-encoded if the source is Intra if you're rendering out to a YouTube preset, or ProRes, or DNxHD. Yet you said, "That is all correct." to this other thing I said:

Which is a direct contradiction to your claim that frames aren't "re-encoded" if they are Intra. That's simply not true at all.

Re: Recording bitrate is there a definitive answer?
 

It is a pretty common term in video processing, decimate means removing, most often described by a pattern.

It is relatively easy to for instance remove any other frame from an all-intra encoding without the need for re-encoding.

Decimation is used to change the frame rate, it could be used to go from 50p to 25p but it can also be used if there are duplicate frames for instance as part of an inverse 3:2 telecine process.

But I suspect you will argue against this as well, so I check out of this "discussion" with you and let you be right about everything.

Re: Recording bitrate is there a definitive answer?
 

It's not a common term in dealing with digital video within a NLE environment, so it's best to stick to that and not analog processing terms you heard back in the 80s and 90s or because you've dabbled with Windows command-line tools for video.

You've already agreed that the NLE is decoding full frames into memory whether or not the source is Intra or LongGOP. This is a direct contradiction to that agreement. So do you agree or disagree with this statement?

Your whole statement about "If you convert 50p to 25p you lose every other frame, but in order to do that you must re-encode the file unless you use an all-intra encoding." adds nothing to the discussion at all, because, even if it were true (and it's not), it is of no consequence to the issue at hand.

Re: Recording bitrate is there a definitive answer?
 

The fireworks are pretty and all, but it's time to cease fire.

Thanks in advance.

Re: Recording bitrate is there a definitive answer?
 

Exactly right (although the term "decimate" is unfortunate, but by common usage it is what it is).

Re: Recording bitrate is there a definitive answer?
 

Not exactly because, in LongGOP, groups of similar frames in the 50 images per second frame rate gives an opportunity for better use of the bitrate than other images. So it's not quite as simple as halving the bitrate if you toss away the frames.

Think of it like this: a third of your image is a sky for 30 seconds. That's 1500 frames. Each frame is about 1.43Mb of information. However, the bitrate is not being wasted on the sky, because the sky is being expertly compressed by the LongGOP compression scheme. Therefore, the saved bitrate is going to other things in the frame. You might be getting the equivalent 2Mb of detail per frame because the sky is being being spread out over each frame instead of taking up the full amount of compression per frame (like Intra). That's why LongGOP can sometimes have more quality than Intra if the bitrate is not directly correlated (such as LongGOP vs ProRes LT, which is lower bitrate, generation 1 MJPEG-based Intra).

It's why you can't just use basic division to figure out anything about the image. It's all subjective based on what's in the frame, what the motion is, what compresses best, etc.

Frankly, it's a moot point because Dave doesn't like the look of 50p, he's going to get that given what Noa suggested, and I would say he will not notice any quality difference either.

Re: Recording bitrate is there a definitive answer?
 

Sorry Chris. Gary, what you say is true in terms of IQ, but that's a different issue. And also true in reference to Dave.

Re: Recording bitrate is there a definitive answer?
 

I do not see it as such, because it's all about what's represented visually, that's what the whole idea of bitrate is about. So yes, you can make the mathematical argument that the bitrate will be halved by tossing away 1/2 of all the captured frames, but it doesn't represent what is seen visually, as given my example above. So it's a non-issue. The problem is, specifically, that 50p on a 25p timeline will look stuttery (when you're not conforming the 50p to 25p for the purposes of half speed), which is going to be far more apparent than anything regarding the bitrate.