Le 2014-09-17 15:54, Thomas Volkert a écrit :
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.
What is the reference that defines what an RTP receiver should do with
video/HEVC? The ways that HEVC could be packetized over RTP are
virtually infinite. For instance, someone could want to reuse the same
payload format as video/AVC payload format but with HEVC NALs inside.
IETF certainly did not standardize that. And proprietary payload RTP
formats are supposed to use explicit prefixes such as prs or vnd. If
there are no existing meaningful (mis)implementations or alternate
competing specification to aim for, then this code means really nothing.
I agree with Martin that it had better be removed, and as quickly as
possible.
--
Rémi Denis-Courmont
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
