Support CodecID 12 for HEVC

[daveisfera]

Several existing implementations used CodecID of 12 to support HEVC before this project began, and there are also hardware implementations based on those concepts, so could this be added to Enhanced RTMP as well?

[veovera]

Hey Dave,

• Gotcha, can you list some of the hardware and software implementations
• let's us consider this
• curious: switching to fourcc HEVC is straight forward and minimal work. Is that not possible?

thx

[daveisfera]

Here's some of the implementations that I'm aware of:

• H265: Support HEVC in RTMP/SRT/HLS/WebRTC/DASH/GB28181 ossrs/srs#465
• https://github.com/ksvc/FFmpeg/wiki
• HEVC RTMP ID 12 shogo4405/HaishinKit.swift#343
• https://blog.wmspanel.com/2019/05/support-hevc-rtmp-nimble-streamer-larix.html
• https://github.com/aileone/nginx-rtmp-module

I agree that switching appears to be doable, but getting all of the existing implementations to do this can be a difficult and the even bigger challenge is then upgrading all of the existing installs

And then when you consider all of the existing content that has been generated over the years with CodecID of 12, it would be really nice to have that brought into the standard as valid. From my perspective, it could be introduced as "deprecated" or "not recommended", so future implementations and uses would be using fourcc but all of the existing usage would still work as is

[zenomt]

i'm concerned that making "id 12 == HEVC" official is a negative incentive to transition to the fourCc way, no matter how much you say it's "deprecated" or "NOT RECOMMENDED", especially given the inertia of existing implementations.

[zenomt]

there is no Protocol Police, and nobody is stopping anyone from using any codec ID any way they want (i'm currently using audio codec id 15 ("Device Specific") for Opus in my Javascript+WebCodecs implementation). the only reason to document video codec id 12 as HEVC would be to encourage interoperation and adoption in new implementations, but new implementations should be preferring the fourCc way.

IMO use of any "unassigned" or "reserved" code points should be considered ad hoc, uncoordinated, and nonstandard, and especially now that there's Enhanced RTMP, doing so should be considered "NOT RECOMMENDED".

[veovera]

Hey David,

I understand the suggestion and appreciate you bringing it up. After thinking about this some more, it feels like the best course of action is to leave this alone. Some of the thinking behind this is:

• Introducing CodecID 12 for HEVC as part of the spec while at the same time deeming it as “deprecated” or “not recommended” feels at odds with each other and ultimately will not have any real effect.

• While unlikely, Introducing CodecID 12 for HEVC, could perhaps be incompatible with other unofficial implementations.

• Leaving this alone will not break anything, and future implementations for HEVC will be compelled to adopt the FourCC approach as outlined in the enhanced RTMP specification.

Hope this helps. I will close this issue out for now. If a compelling argument comes up, we will reopen.

Thanks!

[veovera]

closing per previous reason (#24 (comment))