Compression of black bars in AVC, does it take a lot of space?

[Shevach]

Originally Posted by Dark Shikari

Perhaps you should look again at who the person you're responding to is

I responded to akupenguin.

Originally Posted by Dark Shikari

Both of which, from my testing, are totally useless.

I conjecture that in your tests slices contains large number of MBs. Therefore the choice of cabac_init_idc is useless since the number of bits you can save by optimal choice of cabac_init_idc/sliceQP is negligible against total slice size.

But in situations where each slice contains say 50-100 MBs the optimal initiation of context models might give a significant bit-saving.

[Dark Shikari]

Originally Posted by Shevach

I responded to akupenguin.

My point stands

Originally Posted by Shevach

I conjecture that in your tests slices contains large number of MBs. Therefore the choice of cabac_init_idc is useless since the number of bits you can save by optimal choice of cabac_init_idc/sliceQP is negligible against total slice size.

But in situations where each slice contains say 50-100 MBs the optimal initiation of context models might give a significant bit-saving.

Adaptive cabac_init_idc was tried years ago and was useless: 0 is practically always the best in all situations.

And I did most of my tests regarding slice QP using CIF videos.

Edit: I take that back. Re-tested it now and got some slightly better results:

517.74 -> 517.45 kbps on soccer CIF
33.68 -> 33.61 kbps on akiyo QCIF

(by optimizing frame QP so that the average of the frame's delta quants is 0, or at least rounds to zero)

Measurable, but hardly worth spending that much time on.

Edit again: maybe not. Foreman CIF:

438.63 -> 439.58 kbps

[Shevach]

Originally Posted by Dark Shikari

Adaptive cabac_init_idc was tried years ago and was useless

Dark Shikari,

It is hard to believe that Gary Sullivan and Detlev Marpe (one of H.264 authors) could adopt the syntax element of cabac_init_idc without rigorious check that this feature is beneficial.
I also provided some experiments with cabac_init_idc and revealed bit-savings.

Unfortunately I can't find in IEEE papers any research related to this issue (i.e. optimal choice of cabac_init_idc).
I'll ask Gary Sullivan, maybe in JVT archieves there are relevant documents.

[Dark Shikari]

Originally Posted by Shevach

Dark Shikari,

It is hard to believe that Gary Sullivan and Detlev Marpe (one of H.264 authors) could adopt the syntax element of cabac_init_idc without rigorious check that this feature is beneficial.

Why's that? H.264 is absolutely dripping with completely useless features.

[Shevach]

Originally Posted by Dark Shikari

H.264 is absolutely dripping with completely useless features.

So, you are welcome to list useless features of H.264

[Dark Shikari]

Originally Posted by Shevach

So, you are welcome to list useless features of H.264

Everything in extended profile (which almost nobody has ever used and was only included in the spec for political reasons--this category alone could fill a page)
Everything in Baseline that isn't in Main (same as above)
Constrained intra prediction
The ridiculously unnecessary amount of flexibility with regard to poc type and frame nums (in particular, poc type 1, the golomb-coded poc method, which is totally useless). But the number of LSBs that the spec allows you to code is also stupid since the maximum reorder_frames is 16.
direct-8x8-inference=0 is incredibly pointless and its mere existence complicates decoders. I have never managed to get more than 0.001db gain using it, which is why I removed it from x264.
constraint_set2_flag is completely pointless.
Half the SEI messages are completely useless, or at a minimum ridiculously overcomplicated for their intended task (especially all the repeat_count syntax elements that specify how often something will be changed...)
cabac_init_idc (of course)

This is not even listing badly designed features or features which could be made vastly simpler: this is simply a list of things which could be completely excised from the spec and absolutely nothing of value would be lost. If you want me to start listing redundancies in the bitstream and so forth the list could get a lot longer...

[Shevach]

Dark Shikari,

Why you don't ask H.264 designers (e.g. Gary Sullivan) under what circumstances for example direct-8x8-inference=0 gives a gain (if ever).
I propose to open a new thread - "useless features in H.264".
Perhaps someone can points onto particular circumstances when for example constrained_intra_pred mode =1 is beneficial.

[G_M_C]

Sorry for all this. I started this discussion about slices a couple of post ago, not because of the technical side of it but wondering on the practical use of it. The technical side of it, and especially the level of discussion now, is way over my head (and I mean WAY over my head, something like Mount Everest is over my head here in the Netherlands, which is in fact below sea-level :P).

The reason i asked is because I remembered the tsMuxeR thread, where Roman tried using slices to achieve "uncropping" of cropped encodes. The idea beeing that you can "uncrop" the encoded video re-writing the raw video-stream, and by adding (modifying) slices above and underneath the encoded video get to blu-ray specified resolutions. I thought the idea of using slices this way was "nifty".

But Roman's efforts did not succeed, and reading above technical info gives me the idea that it would never have worked, even now x264 supports BD compliant slicing.

Just to let you guru's know why I came to this question/discussion, a simple useful (read: hopeful) idea.

[Dark Shikari]

Originally Posted by G_M_C

The reason i asked is because I remembered the tsMuxeR thread, where Roman tried using slices to achieve "uncropping" of cropped encodes. The idea beeing that you can "uncrop" the encoded video re-writing the raw video-stream, and by adding (modifying) slices above and underneath the encoded video get to blu-ray specified resolutions. I thought the idea of using slices this way was "nifty".

But Roman's efforts did not succeed, and reading above technical info gives me the idea that it would never have worked, even now x264 supports BD compliant slicing.

No, it absolutely would have worked. Of course, the other Blu-ray restrictions are likely to be more of an issue.

[akupenguin]

Originally Posted by Dark Shikari

No, it absolutely would have worked.

What do you do with mvs that used to point off the frame?

[Dark Shikari]

Originally Posted by akupenguin

What do you do with mvs that used to point off the frame?

... oops. I keep forgetting that AVC doesn't have a way to disable that, and even the relevant SEIs only say that MVs won't point off the frame, not that edge emulation is changed.

[G_M_C]

Originally Posted by akupenguin

What do you do with mvs that used to point off the frame?

Yup that's exactly what happened in the trial-and-error tool Roman wrote.

[Shevach]

Originally Posted by Shevach

Dark Shikari,
I'll ask Gary Sullivan, maybe in JVT archieves there are relevant documents.

The answer of Gary Sullivan on the usefullness of cabac_init_idc is:

The usefulness of the feature is closely related to slice size. When slices are large, the benefit of custom initialization will be negligible, because the coder will adapt reasonably quickly on its own. When slices are small, there will be a benefit, although typically a relatively small one. The basic idea is just to help minimize the penalty of using small slice sizes. I believe the original proposal was JVT-D020. It was proposed again in JVT-E154 with a small refinement in JVT-F039.



As that time, we may have thought that small slices would be used more commonly than they seem to be today. In MPEG-2 video, there's at least one slice per row of macroblocks. My impression is that more recent common practice has become to use relatively few slices (sometimes just one slice per picture).



Note that the method of selecting the initialization value is outside the scope of the standard. The method used by the proposer was very simple (which was to use the value that corresponds best with the result of the table adaptation for the preceding slice). I believe the benefit reported by using that method with standard-definition video with two macroblock rows per slice was about an average of 2%. That may not seem like so much, but we wanted CABAC to retain a substantial compression benefit over CAVLC even when small slices were used, and with smaller slices such as one slice per macroblock row (or a more exhaustive encoder selection of the initialization value) the benefit would presumably be greater.

[G_M_C]

Originally Posted by G_M_C

Sorry for all this. I started this discussion about slices a couple of post ago, not because of the technical side of it but wondering on the practical use of it. The technical side of it, and especially the level of discussion now, is way over my head (and I mean WAY over my head, something like Mount Everest is over my head here in the Netherlands, which is in fact below sea-level :P).

The reason i asked is because I remembered the tsMuxeR thread, where Roman tried using slices to achieve "uncropping" of cropped encodes. The idea beeing that you can "uncrop" the encoded video re-writing the raw video-stream, and by adding (modifying) slices above and underneath the encoded video get to blu-ray specified resolutions. I thought the idea of using slices this way was "nifty".

But Roman's efforts did not succeed, and reading above technical info gives me the idea that it would never have worked, even now x264 supports BD compliant slicing.

Just to let you guru's know why I came to this question/discussion, a simple useful (read: hopeful) idea.

Originally Posted by Dark Shikari

No, it absolutely would have worked. Of course, the other Blu-ray restrictions are likely to be more of an issue.

Originally Posted by akupenguin

What do you do with mvs that used to point off the frame?

Originally Posted by Dark Shikari

... oops. I keep forgetting that AVC doesn't have a way to disable that, and even the relevant SEIs only say that MVs won't point off the frame, not that edge emulation is changed.

Originally Posted by G_M_C

Yup that's exactly what happened in the trial-and-error tool Roman wrote.

I just want to add that I would really have liked a feature like that. I even think that i would have been very useful and that i also have the feeling that it would have been used very much.

I can even imagine that some manufacturers might have used in their suits. You could give the camera more non-standard resolution-options, and you offer a "fast setting" in your software-suits (no transcoding required only rewriting of the stream & adding slices).