H.265/HEVC specification released, any decoders/encoders in sight?

[easyfab]

Has someone any news of when the final release of the HEVC file format will be out ?

[JEEB]

Has someone any news of when the final release of the HEVC file format will be out ?
This seems to be one of the "What on earth is going on!?" kind of things right now. Last year's draft (http://x264.fushizen.eu/random/29n13120t.pdf) finished in the pre-final ballot in April, and there were comments published regarding it and so forth. These were published on mp4-sys. According to the documents, MPEG seems to be handling the development of this document and new versions have seemingly since been put out, but the working drafts seem to only be located on some semi-secret MPEG document tracker. So yeah, we the mere mortals are currently completely left out from the whole process so that we do not even see what the status is. Quite a setback after having such a nice experience with HEVC itself, with little to nothing being behind walls of user names and passwords.

GPAC happens to have one of the editors on board, and thus is the only OSS project that can currently implement the worked upon draft. Copying GPAC's implementations has always been an affair that one should preferably not indulge oneself in (even more so without any specifications on hand!), so all you can say from their code is that things have changed since the last public draft.

Then, in May, it is decided that 14496-15 should be renamed (as it will no longer only host AVC, but HEVC as well). A two-month ballot is initiated on the change, and it is finished in mid-July. 14496-15 was thus renamed to "NAL File Format".

And then... nothing. The Vienna File-format Meeting Report published on 2nd of August notes the following things:

1.4.1 m30312 ISOMBFF extensions to allow storage of HEVC coded still images and image sequences along with other ISOMBFF compatible media
1.4.2 m30313 Carriage of image sequences using HEVC-FF
1.4.3 m30314 Signalling of cover pictures for HEVC-FF image sequence tracks
1.4.4 m30255 Sub tracks for HEVC file format
1.4.5 m30294 Describing HEVC Tiles in ISOBMFF
1.4.6 m30371 Proposal to support tile access in the HEVC File Format

None of these seem to be related to basic HEVC video in a container any more. Still image sequences, subtracks (see: MVC/SVC) and other ways of giving tiles a "place" to be signalled in the container instead of just being a part of the video data. At this point, I really don't know what is going any more to be honest. Might even poke mp4-sys about all this. Mraulet, who has access to the editors via GPAC, was already saying in early July that they were trying to finish it up. Yet we do not even have a final draft yet :)

P.S.
My grievances are mostly with the fact that there is currently close to zero clarity to the outside world regarding the development, bundled together with the fact that there is a single software project that just happens to have the access. This leaves libavformat, L-SMASH as well as matroska-devel (yes, most people on the mailing list seem to want to use the 14496-15 amd2 extradata for Matroska, not the DivX implementation), among others, all hanging on... absolutely nothing, while others seem to be given the way to go further.

[easyfab]

Thanks JEEB for this explanation . So no hope for a quick release.
It seems more harder to release the file format than HEVC itself.

[Kurtnoise]

Microsoft has published the DXVA 2.0 specifications (http://www.microsoft.com/en-ie/download/details.aspx?id=39947) for HEVC streams & published some tests contents (http://msdn.microsoft.com/en-us/library/windows/hardware/dn343543.aspx)...

[Sulik]

FYI for x265 developers: there is a bug in x265 with B-frames: B-frames are incorrectly not included in the max_dec_pic_buffering value (non-compliant, even though this is currently not yet validated by the HM decoder)

[filler56789]

FYI for x265 developers: there is a bug in x265 with B-frames: B-frames are incorrectly not included in the max_dec_pic_buffering value (non-compliant, even though this is currently not yet validated by the HM decoder)

Bug reports should be sent directly to the x265 mailing list. Reason: neither Steve Borho nor Tom visit the Doom9 forums on a daily-basis.

https://mailman.videolan.org/listinfo/x265-devel

[x265_Project]

Bug reports should be sent directly to the x265 mailing list. Reason: neither Steve Borho nor Tom visit the Doom9 forums on a daily-basis.

https://mailman.videolan.org/listinfo/x265-devel

Yes, please.

x265 has undergone some fairly substantial changes in the past few weeks, with the addition of lookahead functionality, ABR rate control and frame-level parallelism. Results are very encouraging. Encoding efficiency, code quality and raw performance continue to improve every day.

Tom

[Marchand]

Strongene Android HEVC/H.265 Decoder
Version: V2013.10.15 Release Date: 2013/10/15 Size: 6.24MB

Release Notes:
1. A demo version; 2. Adopting ffmpeg as audio-video framework, offering amended patches for ffmpeg; 3. Supporting .flv file with HEVC/H.265 stream; 4. Supporting .hevc, .hm10, .hm91, .bin and .bit format HEVC/H.265 streams; 5. The default thread setting is 1 and can be changed via application menu
Configuration:
Resolution: 480x320 pixels or above; Supporting ARMv7 CPU Architecture and NEON Multimedia Instruction Set; Supporting Android 2.3 or higher

http://xhevc.com/resouce/Strongene_Lentoid_HEVC_Decoder_Android_2013_10_15.rar

Strongene iOS HEVC/H.265 Decoder
Version: V2013.10.15 Release: 2013/10/15 Size: 1.53MB

Release Notes:
1. A demo version; 2. Adopting ffmpeg as audio-video framework, offering amended patches for ffmpeg; 3. Supporting .flv file with HEVC/H.265 stream; 4. Supporting .hevc, .hm10, .hm91, .bin and .bit format HEVC/H.265 streams; 5. The default thread setting is 1 and can be changed via application menu
Configuration:
Compatible with iphone and ipad; Supporting iOS 6.0 or higher

http://xhevc.com/resouce/Strongene_Lentoid_HEVC_Decoder_iOS_2013_10_15.rar

[Kurtnoise]

Since yesterday, the current FFmpeg branch (http://git.videolan.org/?p=ffmpeg.git;a=shortlog) now supports HEVC decoder/demuxer streams...:cool:

[VFR maniac]

What way is used to encapsulate HEVC into FLV?
As far as I know, the specification is not published by Adobe.
I'll add the support of HEVC-in-FLV into ffmpeg/libav if available.

[JEEB]

The HEVC-in-FLV hack (or actually, hacks) is/are completely unrelated to Adobe in any way or form, and as we now have at least somewhat official ways of putting HEVC into containers, I would most definitely recommend people to refrain from using or implementing this hacked up mapping for public consumption. FLV is simple to hack things into, yes. But using possible values that Adobe might use in the future sounds like a big pot of problems.

(I still do wish that ISO/IEC would finally do their ballot and make 14496-15, 3rd edition, official -- the draft specification hasn't had changes done to it for months by now)

[Kurtnoise]

A hack like this (http://pastie.org/8409833) ?

Yeah, sadly...

[VFR maniac]

So, The Flash Player can't play them at all but they are called FLV? Retarded!

A hack like this (http://pastie.org/8409833) ?

Yeah, sadly...

I don't think it works well unless the extradata encoded as concatenations of parameter sets with start codes and the stream is encapsulated as Annex B format.
As far as I read the change in MPC-HC BE, Strongene imitates the AVCDecoderConfigurationRecord not a draft of HEVCDecoderConfigurationRecord.
The ffmpeg/libav's HEVC decoder works only when extradata is encoded as HEVCDecoderConfigurationRecord (14496-15 format) or concatenations of parameter sets with start codes (Annex B format).

[benwaggoner]

So, The Flash Player can't play them at all but they are called FLV?
Wow, FLV is the last format I'd think anyone would adopt on purpose for a new technology unrelated to Flash!

[filler56789]

Can someone please say if the AVIs and VfW-based MKVs created through Graphstudio from the Strongene HEVC source filter
are or are not standard-compliant? :confused:

{ for the uninformed: sample file(s) @ http://optavisse.com/2013/07/11/hevc-in-avi-why-not/ }

[VFR maniac]

There is no official specification of HEVC-in-AVI and VfW-based HEVC as there is no official specification of AVC-in-AVC and VfW-based AVC.

VfW is problematic for B-frames without hacks because of 1-frame-in-1-frame-out.
AVI is problematic for seek when any B-frame is present because AVI has no concept of presentation and/or composition timestamp.

[filler56789]

There is no official specification of HEVC-in-AVI and VfW-based HEVC as there is no official specification of AVC-in-AVC and VfW-based AVC.

Thanks for the clarification.

VfW is problematic for B-frames without hacks because of 1-frame-in-1-frame-out.
AVI is problematic for seek when any B-frame is present because AVI has no concept of presentation and/or composition timestamp.

I thought that B-frames were a problem only for the VfW API, not for the AVI and ASF containers themselves :confused:
At least according to http://guru.multimedia.cx/avi-and-b-frames/,

So one could now argue AVI doesnt support b frames as it doesnt store PTS and would if the application needs to know PTS (simpler players dont need to know the PTS…) to calculate the PTS based upon frame type and DTS, but that argument against AVI+b frames has a critical flaw, MPEG-PS and MPEG-TS dont store PTS for every frame either but only require it to be stored every 0.5 seconds or so. Which means that the same complicated calculate the PTS from DTS + frame types code is needed for the official MPEG format too

[VFR maniac]

The point is that handling of AVI with frame/picture-reordering for presentation is CODEC specific.
It is out of ranges of container.
This is already problematic from a viewpoint of container.

Also, presentation/output order of AVC and HEVC depends on POC not frame/picture types unlike the MPEG-1/2 Video and VC-1.
For instance, IDR-picture is output after subsequent P-pictures in coded order when those P-pictures have negative POC.

[filler56789]

^ Again, thanks for answering.

I had to ask, because the most recent version of the DirectShow filter "MPCVideoDec.ax" doesn't understand HEVC-in-AVI:

http://forum.doom9.org/showthread.php?p=1648629#post1648629

[benwaggoner]

I thought that B-frames were a problem only for the VfW API, not for the AVI and ASF containers themselves :confused:
At least according to http://guru.multimedia.cx/avi-and-b-frames/,
Out of order frames were kind of a hack in ASF as well, with some weird tricks being done with timestamps in the headers that need to get ignored by the decoders.

It worked okay for VC-1, but I was one of the advocates against using ASF for Smooth streaming with H.264 because the worst-case mismatches given a 2-second GOP and up to 16 B-frames were crazy.

I think trying to stuff HEVC into old file formats would mainly be opting into pain. And what would the point even be again?

[filler56789]

Out of order frames were kind of a hack in ASF as well, with some weird tricks being done with timestamps in the headers that need to get ignored by the decoders.

It worked okay for VC-1, but I was one of the advocates against using ASF for Smooth streaming with H.264 because the worst-case mismatches given a 2-second GOP and up to 16 B-frames were crazy.

I wasn't aware of that :o ,

thanks for the information :goodpost:

I think trying to stuff HEVC into old file formats would mainly be opting into pain. And what would the point even be again?

Hmmm, the "trick that works for VC-1", is it the same thing as storing VC-1 in Matroska by using the "VfW-compatible" mode (which is what mkvmerge does)? :confused:

[benwaggoner]

Hmmm, the "trick that works for VC-1", is it the same thing as storing VC-1 in Matroska by using the "VfW-compatible" mode (which is what mkvmerge does)? :confused:
Could be. I've actually never made a MVK file in my life. But there are only so many ways to deal with out-of-order decode in file formats not designed for it.