DivX 10 HEVC/H265 implementation

[foxyshadis]

The odd frames are indeed non-reference frames and are not required for decoding the base layer.

Thanks, that makes it a snap for decoders to quietly catch up when they need to then.

In the future, will they be capable of being reference frames, but restricted to only their layer? Or is that pretty pointless?

[benwaggoner]

Thanks, that makes it a snap for decoders to quietly catch up when they need to then.
Well, hierarchical frame dropping has been around for a long time. This feature ensures an easy 2x reduction, but almost any normally encoded video will have lots of non-reference B-frames, or even reference B-frames, that can be skipped in decoding if they're not on the reference list for whatever frame's presentation time is coming up next for decode.

In the future, will they be capable of being reference frames, but restricted to only their layer? Or is that pretty pointless?
It could sure be handy if there was a 30 Hz strobe or something :). However allowing a reference B frames in the "droppable" layer would mean one less to use in the main layer, which might not be worth it quality-wise.

This feature is roughly equivalent to x265's --temporal-layers (http://x265.readthedocs.org/en/default/cli.html?highlight=temporal#cmdoption--temporal-layers). The trick with fixed GOP 3 B is cool, as you automatically get 2x and 4x options. Probably a meaningful loss in efficiency, though. Perhaps if 120 fps catches on :).

[birdie]

15 fps is an odd frame rate for content distribution so it's not supported. Is there a particular reason you prefer that framerate?

Tons of old point and shoot cameras record video at 15 frames per second. I really really doubt that the hardware which is capable of playing FullHD@30fps HEVC streams cannot properly decode 1024x768 videos encoded at a half frame rate.

Then again, your CLI encoder doesn't produce HEVC videos (so "certification" and such are not the things to really care about), it only produces raw HEVC video streams.

So leave the choice to the user please.

One last question: your CLI encoder doesn't have any notion of 2 passes encoding and CRF encoding which is kinda counterintuitive 'cause I really don't know what to expect from the encoding based on average bitrate.

[mademoisellesocal]

Tons of old point and shoot cameras record video at 15 frames per second. I really really doubt that the hardware which is capable of playing FullHD@30fps HEVC streams cannot properly decode 1024x768 videos encoded at a half frame rate.

Then again, your CLI encoder doesn't produce HEVC videos (so "certification" and such are not the things to really care about), it only produces raw HEVC video streams.

So leave the choice to the user please.

One last question: your CLI encoder doesn't have any notion of 2 passes encoding and CRF encoding which is kinda counterintuitive 'cause I really don't know what to expect from the encoding based on average bitrate.


Yes, definitely there is content from some devices at 15fps and devices should be able to play that frame rate, but it wouldn't be within the DivX HEVC profile specs. My point about content was more about content distribution, especially in the case of something like 4K where high quality on large screens is a key consideration.

FWIW, we have a backlog item to allow custom frame rates for HEVC output from DivX Converter later in the year (definitely for the GUI; I need to check on if this will be available in DivXEngine.exe also). I brought this up to our PMs and they're reviewing the possibility of adding non-profile-compliant encoding like lower frame rates to the DivX265 encoder as well.

[stax76]

StaxRip includes the encoder and a CLI profile.

http://forum.doom9.org/showthread.php?p=1719130#post1719130

[Gravitator]

Silence on a 2-pass ?