Changes between Initial Version and Version 1 of Ticket #6389, comment 1


Ignore:
Timestamp:
May 14, 2017, 4:58:39 PM (3 years ago)
Author:
JEEB
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #6389, comment 1

    initial v1  
    22
    33Not to mention that there are alternatives out there are properly specified for newer formats such as VP9 or HEVC that can be utilized instead for both ingest to a media server as well as something the actual playback clients get. I mean, even plain MPEG-TS or fragmented ISOBMFF over HTTP would be achievable easily. And while things like HLS or MPEG-DASH are usually used with relatively high latency (often in order to improve compression ratios), they can also be used so that the latency would be within those parameters you mention, so that sort of latency limitation is not really a limitation per se (considering the ingest to a media server that handles the packaging is done in a relatively sane way and that the encoder in the very beginning of the chain is configured accordingly latency-wise).
     4
     5'''edit''':
     6Just to reiterate my point: The pure passing of MPEG-TS or fragmented ISOBMFF over HTTP and HLS/MPEG-DASH are two completely separate themes in my paragraph. The latter I only bring up because you noted that such low latency on the content distribution side of things would be impossible according to you. Of course for ingest to a media server you would not utilize such a format, as it clearly is not a single push or pull type of a format (and usually for publishing you want the encoder to push to a media server, not the other way due to that being less of a PITA NAT-wise etc).