AVC: Should I use main or high profile? What are reference frames?

[sofakng]

I've purchased a new AVCHD camcorder (Canon HF20) and so I'm slowly learning more about video encoding/editing but I have two questions...

The camcorder records using high profile at level 4.1 with max bitrate of 24 Mbps.

1) When editing the video, should I encode using main profile or high profile? Why? Which is more compatible?

2) How many reference frames should I use during encoding? AVC level 4.1 supports a maximum of 4 but what does that even mean? What is the benefit/disadvantage to using more or less of them?

Thanks for any help!

[LoRd_MuldeR]

1) Use "High" profile whenever possible. It compresses more efficient than "Main" profile. That means you can get higher quality at the same bitrate -or- same quality at a lower bitrate.

2) More reference frames will increase compression efficiency. However there is a point where the benefit of additional ref frames is near zero.

[Sagekilla]

That's incorrect that Level 4.1 supports a max of 4 ref frames. At 1080p, you can have 4 refs. 9 for 720p, and 16 for 480p or lower.

The actual max depends on Decoded Picture Buffer size, which is about ~12 MB for L4.1 -- About 12533760 bytes I think.

[LoRd_MuldeR]

The actual max depends on Decoded Picture Buffer size, which is about ~12 MB for L4.

Which means that the maximum number of reference frames depends on the Level and on the resolution of the video...

[Esurnir]

Which means that the maximum number of reference frames depends on the Level and on the resolution of the video...

and the presence of B-frames (-1 ref compared to no b-frame) and the presence of B-pyramids (-2 compared to no b-frame)

[Manao]

and the presence of B-frames (-1 ref compared to no b-frame) and the presence of B-pyramids (-2 compared to no b-frame) No. Having bframes or bpyramid doesn't prevent you from using 16 refs on P frames.

[Comatose]

Levels do not actually restrict the amount of ref frames. That restriction is imposed by the playback device.
In a nutshell, the levels only restrict the bitrate/framerate and resolution.

This is according to the table on Wikipedia, which only specifies max macroblocks in a frame, max macroblocks per second, and max bitrate.

[kemuri-_9]

Levels do not actually restrict the amount of ref frames. That restriction is imposed by the playback device.
In a nutshell, the levels only restrict the bitrate/framerate and resolution.

This is according to the table on Wikipedia, which only specifies max macroblocks in a frame, max macroblocks per second, and max bitrate.

the table on wikipedia is also missing the Max decoded picture buffer (DPB) size associated with each level.
this buffer is used by the reference frame process and effectively caps how many ref frames you can have for that resolution of video for that level.

this should still be Table A-1 in the h.264 spec sheet.

[Comatose]

Oh. Well, so much for referencing Wikipedia :\

[LoRd_MuldeR]

Oh. Well, so much for referencing Wikipedia :\

Wikipedia is a good source to find information quickly. But you really can't rely on Wikipedia to be correct and complete ;)

To be sure you will need to refer to the official H.264 specs:
http://neuron2.net/library/avc/T-REC-H[1].264-200711-I!!PDF-E.pdf

[kemuri-_9]

To be sure you will need to refer to the official H.264 specs:
http://neuron2.net/library/avc/T-REC-H[1].264-200711-I!!PDF-E.pdf

has anyone been able to get their hands on the 200903 revision of the spec yet?

[popper]

Wikipedia is a good source to find information quickly. But you really can't rely on Wikipedia to be correct and complete ;)

To be sure you will need to refer to the official H.264 specs:
http://neuron2.net/library/avc/T-REC-H[1].264-200711-I!!PDF-E.pdf

so, in this case you have access to the spec,know the missing data etc, so why doesnt someone here just do the simple thing and update the page and include all the current data and feedback ....

[LoRd_MuldeR]

so, in this case you have access to the spec,know the missing data etc, so why doesnt someone here just do the simple thing and update the page and include all the current data and feedback ....

Because Doom9 members are not responsible for the correctness/completeness of Wikipedia articles.

And because on Wikipedia there is a great chance that some ignoramus will come along and undo your edit very soon :rolleyes:

Anyway, why not do the edit yourself instead of asking other people to do it for you?

[Esurnir]

No. Having bframes or bpyramid doesn't prevent you from using 16 refs on P frames.

Uhhhh? But the Bframe require an "extra" picture (the future P-frame used by the b-frame as a reference) to be stored in the Decoded Picture Buffer, unless I'm wrong the --ref only say the number of "past" p-frame will be accounted for by the encoder, not futures. Same with b-pyramids where you need to have the reference B-frame stored in the DPB. Or did I just said something stupid ?

[Esurnir]

And because on Wikipedia there is a great chance that some ignoramus will come along and undo your edit very soon :rolleyes:

On technicalities such as this one, chance of a rollback sounds unlikely. I'll do it at school during the 10 am if no one did it before.

[Dark Shikari]

Uhhhh? But the Bframe require an "extra" picture (the future P-frame used by the b-frame as a reference) to be stored in the Decoded Picture Buffer, unless I'm wrong the --ref only say the number of "past" p-frame will be accounted for by the encoder, not futures. Same with b-pyramids where you need to have the reference B-frame stored in the DPB. Or did I just said something stupid ?B-frames have 15 past refs, 1 future ref, while P-frames have 16 past refs.

[Esurnir]

B-frames have 15 past refs, 1 future ref, while P-frames have 16 past refs.

My bad then, wasn't there a problem with b-pyramids ?

[Dark Shikari]

My bad then, wasn't there a problem with b-pyramids ?Technically yes, but for far more subtle reasons outside the purview of this thread.

[Manao]

Bframes can have a full L0 and L1 lists (ie 16 frames in both), and none of those frames needs to be in the future. Do note that somebody in that thread has yet to utter "x264", so don't assume we're talking about it, and we're having its limitations.

[Sagekilla]

Dark, is x264 capable of using the full 16 for L1 lists? I notice that if I try bframes 16 (which I no longer do) it will show the full L0 list, but L1 will have only two entries.

Thanks for the insight Manao ;)

[Gabriel_Bouvigne]

Dark, is x264 capable of using the full 16 for L1 lists? I notice that if I try bframes 16 (which I no longer do) it will show the full L0 list, but L1 will have only two entries.

Current x264 is only able to use future frames as L1 refs.

(but yes, the specs don't prevent you from using past and future frames within L1, or even doing some unusual things like using 16x the same frame as reference but with different explicit weights, which would then only use 1 single DPB slot)

[drpaulng]

I've purchased a new AVCHD camcorder (Canon HF20) and so I'm slowly learning more about video encoding/editing but I have two questions...

The camcorder records using high profile at level 4.1 with max bitrate of 24 Mbps.

1) When editing the video, should I encode using main profile or high profile? Why? Which is more compatible?

2) How many reference frames should I use during encoding? AVC level 4.1 supports a maximum of 4 but what does that even mean? What is the benefit/disadvantage to using more or less of them?

Or better say, can you submit some MTS shot with xvColor scheme so that we can know more about the nature of these MTS. I think some analysor such as Elecard Streameye may tell us something.
Thanks for any help!

Can I ask you a question about the xvColor feature? Do you shoot everything with xvColor? The original MTS has to be encoded with present 8bit scheme (profile 4.1). That means you will eventually loss the original xvColor after editing and transfer for bluray production. In order to preserve the original xvColor in your MTS what should you do?