On Wed, 17 Sep 2014, Thomas Volkert wrote:
Hallo,
Am 17.09.2014 14:27, schrieb Vittorio Giovara:
RTPDynamicProtocolHandler ff_hevc_dynamic_handler = {
- .enc_name = "HEVC",
- .codec_type = AVMEDIA_TYPE_VIDEO,
- .codec_id = AV_CODEC_ID_HEVC,
- .init = hevc_init,
- .parse_sdp_a_line = hevc_parse_sdp_line,
- .alloc = hevc_new_context,
- .free = hevc_free_context,
- .parse_packet = hevc_handle_packet
-};
-
-RTPDynamicProtocolHandler ff_h265_dynamic_handler = {
.enc_name = "H265",
.codec_type = AVMEDIA_TYPE_VIDEO,
.codec_id = AV_CODEC_ID_HEVC,
Okay, it seems that this entry is a duplicated one. But the idea was to
remain compatible to a possible "HEVC" description.
So, if some other software signals "HEVC" inside SDP as indicator for
H.265, the "duplicated entry" is needed.
I would suggest to leave this duplicated entry in the code.
I'm not completely convinced. Yes, somebody might accidentally start
creating such streams - but if we accept them there's less chance people
actually notice and fix it, before it becomes a de-facto standard.
I'd suggest keeping only the official one from the RFC draft, at least
until there's a concrete need of something more. And even then, this is a
new standard and there's very little content we "need" to stay compatible
with, so we can actually hope people would fix the other implementations
towards complying with the standard, instead of piling up more hacks where
hacks aren't necessary.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
