My Canon HF G30, set to MP4 mode, will record 25p at (up to) 24mbps and 50p at 35mbps, the 35mbps bitrate is not separately user selectable. I have no regular use for 50p, so normally shoot 25p. The question is, if I shoot 50p for the higher bitrate, do I lose some of the original bitrate by converting the footage to 25p in post? I have seen several opinions, but I am hoping someone will know.

Failing that, is there any way I can find out for myself? Somehow the logical 35/2 = 17.5 seems too simple.

Convert a file, then check its video bit rate. MediaInfo is a free program for that sort of thing.

https://mediaarea.net/en/MediaInfo

Thanks, but if it was that easy I would have done it. Every transcoder/converter I have used requires the output bitrate to be set, somehow defeating the object. Mediainfo does not convert, only gives the info. I use it often.

Don't convert, just put your 50p files in a 25p project, I do that all the time.

Dave, I suspect that's about the quality of the advice you're going to get. If you're delivering 25p from 50p at a CBR it's that simple. If you're delivering 25i (or as the marketers now call it, 50i) you get better quality capturing 50p at 35Mbps. Summary, for best quality per progressive frame and more latitude in post, shoot 25p 24Mbps and 50p 35Mbps for BluRay. If you're not worried about post and aiming at Youtube, that only recommends 8Mbps uploads at 1080p so 17Mbps is more than adequate.

What's wrong with my advice Rainer? Dave wanted to know if he shot 50p for the higher bitrate would he lose some of the original bitrate by converting the footage to 25p in post?

That's why I said not to convert and just place the 50p file in a 25 project because in that way you don't loose the original bitrate.

I'd be inclined to go with what Noa says as it will not only reduce handling steps but also the opportunities for generational loss due to re-encoding. Keep it simple.

Andrew

I also agree with Noa, I often use a variety of bitrates from different cameras, and just import the different clips into the project .

Roger

Dave, I suspect that's about the quality of the advice you're going to get.I've looked around the web and generally it is as you say, I was just hoping for an answer rather than opinions. Then along comes Noa, the first person who I have seen say anything tangible on this subject. I have seen it said that you do lose bitrate and also that you don't, but Noa has qualified his advice by saying in what instance you don't lose bitrate.

Noa, it goes against the grain a bit because I have always used an intermediate codec for editing, but I have seen your work and the quality is outstanding, so maybe I should follow your example. I'll certainly give it a go! Thanks.

You will loose bitrate if you render it out to a low bit rate file but if you place the native file on your timeline nothing changes that file, the change occurs once you render it out, you will loose half of the frames if you render a 50p file out in a 25p project but the bitrate is something you can set yourself when you render the file.

Thanks Noa, I would render it as ProRes Normal, target bitrate 147mbps, so no loss there. I do have some 50p footage, so I am about to test your method, I shall try it with some 25p as well.

As I said in my original post, I normally don't shoot 50p, but it's good to know that if I do I can keep the higher bitrate.

Thanks, but if it was that easy I would have done it. Every transcoder/converter I have used requires the output bitrate to be set, somehow defeating the object. Mediainfo does not convert, only gives the info. I use it often.

Isn't image quality what you really care about? If that's the case, you should do the timeline conversion and render at a given bit rate and compare the image quality visually to a straight up 25P recording, rendered with the same settings. Maybe so some color correction or other effects to stress it a bit.

As I said in my original post, I normally don't shoot 50p, but it's good to know that if I do I can keep the higher bitrate.

Why do you not normally shoot 50p? Is it because of the look of the footage at 50p? Shooting 50p and then dropping in a 25p timeline will keep the overall look, just not as smooth with the motion.

Isn't image quality what you really care about? Yes of course and now my question is answered closely enough to know I won't lose bitrate if I shoot at 50p, as long as I put it on the timeline without transcoding first.

Is it because of the look of the footage at 50p?Yes, I suppose it is. I am used to 25p and it feels right, so I prefer it.

My Canon HF G30, set to MP4 mode, will record 25p at (up to) 24mbps and 50p at 35mbps, the 35mbps bitrate is not separately user selectable. I have no regular use for 50p, so normally shoot 25p. The question is, if I shoot 50p for the higher bitrate, do I lose some of the original bitrate by converting the footage to 25p in post? I have seen several opinions, but I am hoping someone will know.

Failing that, is there any way I can find out for myself? Somehow the logical 35/2 = 17.5 seems too simple.
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.

You can calculate the bits per frame which, if you decimate every other frame in the video, becomes a total of half the amount.

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.

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

That's not true of most modern NLEs. He'll only be re-encoding the imagery when he renders out his final edit.
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.

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.

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.

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.

I did not say that at all.

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.

That is all correct.

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.

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

If you add any kind of filter, title, color correction, etc. then the frames will be re-encoded, period.
Obviously.

I did not say that at all.

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

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

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.

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.
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.

I wrote all-intra not long GOP.

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.

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

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"?

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

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

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.

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:

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.

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.

What do you mean by "decimate" frames specifically?
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.

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

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.

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

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?

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.

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.

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

Thanks in advance.

You can calculate the bits per frame which, if you decimate every other frame in the video, becomes a total of half the amount.
Exactly right (although the term "decimate" is unfortunate, but by common usage it is what it is).

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.

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.

Gary, what you say is true in terms of IQ, but that's a different issue.

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.

Interesting stuff indeed! It's amazing what can be picked up reading this kind of discussion, including answers to questions I didn't know needed asking.:-)

I've been testing a few things, including some footage from the only project I ever completed in 50p. I put some raw camera clips on the timeline as Noa suggested, colour corrected and rendered 25p as ProRes. Apart from the jerkiness of motion, I saw an increase in IQ.

Then I tried some 25p footage from my current project, which has been transcoded as always. Again I put some raw camera files on the timeline, same MO as before and again saw an increase in IQ when comparing ProRes renders of each. That's the opposite of what I expected! Methinks I shall save the time and effort of transcoding in future and, you guessed it, start the project again using raw clips. Of course, not transcoding removes the need for my original question, since the camera bitrate will go straight on the timeline.

Thanks everyone.