播放录制内容Playback of recordings

预读Pre-read

背景Background

可以使用 IoT Edge 上的实时视频分析进行连续视频录制 (CVR),持续数周或数月将视频录制到云中。You can use Live Video Analytics on IoT Edge for continuous video recording (CVR), whereby you can record video into the cloud for weeks or months. 还可以通过基于事件的视频录制 (EVR) 将录制限制为你感兴趣的剪辑。You can also limit your recording to clips that are of interest, via event-based video recording (EVR).

媒体服务帐户已链接到 Azure 存储帐户,将视频录制到云中时,内容会写入媒体服务资产Your Media Service account is linked to an Azure Storage account, and when you record video to the cloud, the content is written to a Media Service asset. 通过媒体服务,你可以在录制完成后或在录制进行时流式传输此内容Media Services allows you to stream that content, either after the recording is complete, or while the recording is ongoing. 媒体服务提供将流通过 HLS 或 MPEG-DASH 协议交付到播放设备(客户端)所需的功能。Media Services provides you with the necessary capabilities to deliver streams via HLS or MPEG-DASH protocols to playback devices (clients). 有关详细信息,请参阅视频播放一文。See the video playback article for more details. 使用媒体服务 API 来生成必备的流式处理 URL – 由客户端用来播放视频和音频。You would use Media Service APIs to generate the requisite streaming URLs – used by clients to play back the video & audio. 若要为资产构造流式处理 URL,请参阅创建流式处理定位符并生成 URLTo construct the streaming URL for an asset, see create a streaming locator and build URLs. 在为资产创建了流式处理 URL 后,你可以并且应该将此 URL 与视频源(即相机)的关联存储在内容管理系统中。Once the streaming URL has been created for an asset, you can and should store the association of the URL with the video source (that is, camera) in your content management system.

例如,当通过 HLS 进行流式处理时,流式处理 URL 类似于 https://{hostname-here}/{locatorGUID}/content.ism/manifest(format=m3u8-aapl).m3u8For example, when streaming via HLS, the streaming URL would look like https://{hostname-here}/{locatorGUID}/content.ism/manifest(format=m3u8-aapl).m3u8. 对于 MPEG-DASH,它则类似于 https://{hostname-here}/{locatorGUID}/content.ism/manifest(format=mpd-time-cmaf).mpdFor MPEG-DASH, it would look like https://{hostname-here}/{locatorGUID}/content.ism/manifest(format=mpd-time-cmaf).mpd.

这会返回一个清单文件,其中描述了正在传送的流的总持续时间,以及它是表示预先录制的内容还是正在进行的“实时”源。This returns a manifest file, which, amongst other things, describes the overall duration of the stream that is being delivered, and whether it represents pre-recorded content, or the on-going 'live' feed.

实时与VoDLive vs. VoD

流协议(例如 HLS 和 MPEG-DASH)是为处理实时视频的流式处理等方案以及为流式处理点播/预先录制的内容(例如电视节目和电影)而创建的。Streaming protocols like HLS and MPEG-DASH were authored to handle scenarios like streaming of live videos, as well as streaming of on-demand/pre-recorded content like TV shows and movies. 对于实时视频,HLS 和 MPEG-DASH 客户端被设计为从“最近”时间开始播放。For live videos, HLS and MPEG-DASH clients are designed to start playing from the 'most recent' time onwards. 但是对于电影而言,观看者希望能够从开头看起,并且可以选择跳过某些内容。With movies, however, viewers expect to be able to start from the beginning and jump around if they choose to. HLS 和 MPEG-DASH 清单拥有标记,这些标记会向客户端指示视频表示的是实时流还是预先录制的内容。The HLS and MPEG-DASH manifests have flags that indicate to the clients whether the video represents a live stream, or it is pre-recorded content. 此概念也适用于来自资产的 HLS 和 MPEG-DASH 流,这些资产包含使用 IoT Edge 上的实时视频分析录制的视频。This concept also applies to HLS and MPEG-DASH streams from Assets that contain video recorded using Live Video Analytics on IoT Edge.

浏览和选择性地播放录制内容Browsing and selective playback of recordings

请考虑下面的情况:在整个学年期间,你使用了 IoT Edge 上的实时视频分析来仅在学校开放日上午 8 点到 10 点的时间段录制视频。Consider the scenario where you have used Live Video Analytics on IoT Edge to record video only from 8AM to 10AM on days when a school was open, for the entire academic year. 或者你只在全国法定假日上午 7 点到晚上 7 点的时间段录制视频。Or perhaps you are recording video only from 7AM to 7PM on national holidays. 在这两种情况下,如果要尝试浏览并观看你的视频录制,你需要:In either of these two scenarios, when attempting to browse and view your video recording, you would need:

  • 一种能确定录制视频的日期/时间的方法。A way to determine what dates/hours of video you have in a recording.
  • 一种能选择要播放的录制部分(例如新年当天上午 9 点到 11 点)的方法。A way to select a portion (for example, 9AM to 11AM on New Years Day) of that recording to playback.

媒体服务提供了查询 API (availableMedia),用于解决第一个问题,并提供了时间范围筛选器(startTime,endTime),用于解决第二个问题。Media Services provides you with a query API (availableMedia) to address the first issue, and time-range filters (startTime, endTime) to address the second.

查询 APIQuery API

使用 CVR 时,播放设备(客户端)无法请求包含播放整个录制内容的清单。When using CVR, playback devices (clients) cannot request a manifest covering playback of the entire recording. 多年的录制会生成一个清单文件,此文件会因太大而无法播放,并且难以在客户端上被分析为可用的部分。A multi-year recording would produce a manifest file that was too large for playback and it would be unwieldy to parse into usable portions on the client side. 客户端需要知道哪些日期/时间范围有录制的数据,这样一来,无需太多猜测工作即可进行有效的请求。The client needs to know what datetime ranges have data in the recording so that it can make valid requests without much guess work. 因此,我们引入了新的查询 API – 客户端现在可以使用此服务器端 API 来发现内容。This is where the new Query API comes in – clients can now use this server-side API to discover content.

其中,精度值可以是以下值之一:year、month、day 或 full(如下所示)。Where the precision value can be one of: year, month, day, or full (as shown below).

PrecisionPrecision yearyear 月份month dayday fullfull
查询Query /availableMedia?precision=year&startTime=2018&endTime=2019 /availableMedia?precision=month& startTime=2018-01& endTime=2019-02 /availableMedia?precision=day& startTime=2018-01-15& endTime=2019-02-02 /availableMedia?precision=full& startTime=2018-01-15T10:08:11.123& endTime=2019-01-015T12:00:01.123
响应Response { "timeRanges":[{ "start":"2018", "end":"2019" }]} { "timeRanges":[{ "start":"2018-03", "end":"2019-01" }]} { "timeRanges":[ { "start":"2018-03-01", "end":"2018-03-07" }, { "start":"2018-03-09", "end":"2018-03-31" } ]} 全保真响应。Full fidelity response. 如果根本没有间隔,那么 start 为 startTime,end 为 endTime。If there were no gaps at all, the start would be startTime, and end would be endTime.
约束Constrains • startTime <= endTime•startTime <= endTime
• 两者都应采用 YYYY 格式,否则会返回错误。•Both should be in YYYY format, otherwise return error.
• 值可以间隔任意年数。•Values can be any number of years apart.
• 值为包含式。•Values are inclusive.
• startTime <= endTime•startTime <= endTime
• 两者都应采用 YYYY-MM 格式,否则会返回错误。•Both should be in YYYY-MM format, otherwise return error.
• 值最多可间隔 12 个月。•Values can be at most 12 months apart.
• 值为包含式。•Values are inclusive.
• startTime <= endTime•startTime <= endTime
• 两者都应采用 YYYY-MM-DD 格式,否则会返回错误。•Both should be in YYYY-MM-DD format, otherwise return error.
• 值最多可间隔 31 天。•Values can be at most 31 days apart.
值为包含式。Values are inclusive.
•startTime < endTime•startTime < endTime
• 值最多可间隔 25 小时。•Values can be at most 25 hours apart.
• 值为包含式。•Values are inclusive.

其他请求格式注意事项Additional request format considerations

  • 所有时间均是 UTC 时间All times are in UTC

  • 需要精度查询字符串参数。The precision query string parameter is required.

  • 对于 month、day 和 full 精度值,startTime 和 endTime 查询字符串参数是必需的。The startTime and endTime query string parameters are required for the month, day, and full precision values.

  • startTime 和 endTime 查询字符串参数对于 year 精度值是可选的(不支持、支持其中一个、或者两者都支持)。The startTime and endTime query string parameters are optional for the year precision value (none, either, or both is supported).

    • 如果省略 startTime,则假定它为录制的第一个年份。If the startTime is omitted, it is assumed to be the first year in the recording.

    • 如果省略 endTime,则假定它为录制的最后一个年份。If the endTime is omitted, it is assumed to be the last year in the recording.

    • 例如,如果录制从 2011 年开始并一直持续到 2020 年,则:For example, if your recording started in 2011, and has continued until 2020, then:

      • /availableMedia?precision=year is the same as /availableMedia?precision=year&startTime=2011&endTime=2020/availableMedia?precision=year is the same as /availableMedia?precision=year&startTime=2011&endTime=2020
      • /availableMedia?precision=year&startTime=2015 is the same as /availableMedia?precision=year&startTime=2015&endTime=2020/availableMedia?precision=year&startTime=2015 is the same as /availableMedia?precision=year&startTime=2015&endTime=2020
      • /availableMedia?precision=year&endTime=2018 is the same as /availableMedia?precision=year&startTime=2011&endTime=2018/availableMedia?precision=year&endTime=2018 is the same as /availableMedia?precision=year&startTime=2011&endTime=2018

如果针对时间范围没有可用的媒体数据,则返回一个空列表。If no media data is available for the time ranges, then an empty list is returned.

如果资产不包含来自媒体图的录制,则将返回 HTTP 400 响应,并附带一条错误消息,说明此功能仅适用于通过媒体图录制的内容。If the asset does not contain a recording from a media graph, then an HTTP 400 response will be returned with an error message explaining that this feature is only available for content recorded via a media graph.

在给定某一查询类型的情况下,如果参数指定的持续时间大于最大时间范围所允许的持续时间,则将返回 HTTP 400,并附带一条错误消息,说明请求的查询类型所允许的最大时间范围。If the duration of time specified by the parameters is larger than allowed by the Maximum Time Range for a given query type, then an HTTP 400 will be returned with an error message explaining the maximum allowed time range for the requested query type.

假设时间范围对于给定的参数是有效的,那么对于数据录制时段之外的查询,不会返回错误。Assuming the time range is valid for the parameters given, no errors will be returned for queries that are outside of the time window of data in the recording. 这意味着,如果录制是在 7 小时前启动的,但客户要求提供从 {UtcNow – 24 小时} 到 UtcNow 的可用媒体,那么我们只会返回 {UtcNow – 7} 小时的数据。Meaning if the recording started 7 hours ago but the customer asks for available media from {UtcNow – 24 hours} to UtcNow, then we’d just return the {UtcNow – 7} hours of data.

响应格式Response format

availableMedia 调用返回一组时间值。The availableMedia call returns a set of time values.

响应将为 JSON 正文,其中,对于 year(格式为 YYYY)、month(格式为 YYYY-MM)或 day(格式为 YYYY-MM-DD),timeRanges 值是由 ISO 8601 UTC 日期组成的数组,具体取决于请求的精度。The response will be a JSON body, with timeRanges values being an array of ISO 8601 UTC dates for the year (in YYYY format), month (in YYYY-MM format), or day (YYYY-MM-DD) depending on the precision requested. 完整的 timeRanges 将包含格式为 ISO 8601 UTC 日期时间的开始值和结束值(格式为 YYYY-MM-DDThh:mm:ss.sssZ)。The full timeRanges will contain both a start and end value formatted as an ISO 8601 UTC date time (in YYYY-MM-DDThh:mm:ss.sssZ format).

对于 availableMedia 查询,API 将切断视频时间线。For the availableMedia query, the API will key off of the video timeline. 时间线中的任何中断将显示为响应中的间隔。Any discontinuities in the timeline will show up as gaps in the response.

availableMedia 的响应示例Response example for availableMedia

示例 1:无间隔的实时录制Example 1: Live recording with no gaps

下面是显示 2019 年 12 月 21 日所有可用媒体的响应,其中,录制已 100% 完成。Here is a response showing all of the available media for December 21, 2019, where the recording was 100% complete. 响应仅有一个开始/结束对。Response has only one start/end pair.

GET https://hostname/locatorId/content.ism/availableMedia?precision=full&startTime=2019-12-21T00:00:00Z&endTime=2019-12-22T00:00:00Z
{
   "timeRanges":[
   {
         "start":"2019-12-21T00:00:00.000Z", 
         "end":"2019-12-22T00:00:00.000Z"
    }
   ]
}
示例 2:间隔为 2 秒的实时录制Example 2: Live recording with a 2-second gap

假设出于某种原因,相机无法在一天内以 2 秒的间隔发送有效视频。Suppose for some reason, the camera failed to send valid video for a 2-second interval on a day. 下面是显示 2019 年 12 月 21 日所有可用媒体的响应:Here is a response showing all of the available media for December 21, 2019:

GET https://hostname/locatorId/content.ism/availableMedia?precision=full&startTime=2019-12-21T00:00:00Z&endTime=2019-12-22T00:00:00Z
{
   "timeRanges":[
    {
         "start":"2019-12-21T00:00:00Z", 
         "end":"2019-12-21T04:01:08Z"
    },
    {
         "start":"2019-12-21T04:01:10Z", 
         "end":"2019-12-22T00:00:00Z"
    }
   ]
}
示例 3:间隔为 8 小时的实时录制Example 3: Live recording with an 8 hour gap

假设相机和/或本地设施在一天中从 UTC 凌晨 4 点到 UTC 中午一直处于断电状态,持续了 8 小时,并且没有备份电源。Suppose the camera and/or on-premise facility lost power for an 8-hour period during the day, from 4 AM UTC to noon UTC, and there was no backup power source. 下面是显示这一天内所有可用媒体的响应Here is a response showing all of the available media for such a day

GET https://hostname/locatorId/content.ism/availableMedia?precision=full&startTime=2019-12-21T00:00:00Z&endTime=2019-12-22T00:00:00Z
{
   "timeRanges":[
    {
         "start":"2019-12-21T00:00:00Z", 
         "end":"2019-12-21T04:00:00Z"
    },
    {
         "start":"2019-12-21T12:00:00Z", 
         "end":"2019-12-22T00:00:00Z"
    }
   ]
}

示例 4:在暑假期间不录制视频的实时录制Example 4: Live recording where no video is recorded over summer holidays

假设你仅在学校上课时才录制视频,并且在 6 月 17 日至 9 月 6 日之间停止了录制。Suppose you recorded video only when the school was in session, and recording was stopped from June 17 through September 6. 针对可用月份的一个查询如下所示:A query for available months would look like:

GET https://hostname/locatorId/content.ism/availableMedia?precision=month&startTime=2019-01&endTime=2019-12
{
   "timeRanges":[
    {
         "start":"2019-01", 
         "end":"2019-06"
    },
    {
         "start":"2019-09", 
         "end":"2019-12"
    }
   ]
}

如果随后要求你提供 6 月可用天数的录制内容,你会看到:If you then asked for the available days in June, you would see:

GET https://hostname/locatorId/content.ism/availableMedia?precision=day&startTime=2019-06-01&endTime=2019-06-30
{
   "timeRanges":[
    {
         "start":"2019-06-01", 
         "end":"2019-06-17"
    }
   ]
}
示例 5:在周末或节假日不录制视频的实时录制Example 5: Live recording where no video is recorded over weekends or holidays

假设你仅在工作时间内录制了视频。Suppose you recorded video only during business hours. 针对可用天数的一个查询如下所示A query for available days would look like

GET https://hostname/locatorId/content.ism/availableMedia?precision=day&startTime=2020-02-01&endTime=2020-02-29
{
   "timeRanges":[
    {
         "start":"2020-02-03", 
         "end":"2020-02-07"
    },
    {
         "start":"2020-02-10", 
         "end":"2020-02-14"
    },
    {
         "start":"2020-02-18", // Monday Feb 17th was a holiday
         "end":"2020-02-21"
    },
    {
         "start":"2020-02-24", 
         "end":"2020-02-28"
    }
   ]
}

时间范围筛选器Time range filters

如上所述,这些筛选器可帮助你选择录制的某些部分(例如新年当天上午 9 点到 11 点)进行播放。As mentioned above, these filters help you select portions of your recording (for example, from 9AM to 11AM on New Years Day) for playback. 当通过 HLS 进行流式处理时,流式处理 URL 类似于 https://{hostname-here}/{locatorGUID}/content.ism/manifest(format=m3u8-aapl).m3u8When streaming via HLS, the streaming URL would look like https://{hostname-here}/{locatorGUID}/content.ism/manifest(format=m3u8-aapl).m3u8. 若要选择录制的部分,需要添加 startTime 和 endTime 参数,例如:https://{hostname-here}/{locatorGUID}/content.ism/manifest(format=m3u8-aapl,startTime=2019-12-21T08:00:00Z,endTime=2019-12-21T10:00:00Z).m3u8In order to select a portion of your recording, you would add a startTime and an endTime parameter, such as: https://{hostname-here}/{locatorGUID}/content.ism/manifest(format=m3u8-aapl,startTime=2019-12-21T08:00:00Z,endTime=2019-12-21T10:00:00Z).m3u8. 因此,时间范围筛选器是 URL 修饰符,用于描述包含在流式处理清单中的录制时间线的部分:Thus, the time range filters are URL modifiers used to describe the portion of the recording’s timeline that is included in the streaming manifest:

  • starttime 是 ISO 8601 日期/时间戳,描述返回的清单中视频时间线的预期开始时间。starttime is an ISO 8601 DateTime stamp that describes the desired start time of the video timeline in the returned manifest.
  • endtime 是 ISO 8601 日期/时间戳,描述清单中返回的视频时间线的预期结束时间。endtime is an ISO 8601 DateTime stamp that describes the desired end time of the video timeline returned in the manifest.

此类清单的最大长度(以时间为单位)不能超过 24 小时。The maximum length (in time) of such a manifest cannot exceed 24 hours.

下面是对筛选器的约束。Here are the constraints on the filters.

startTimestartTime endTimeendTime 结果Result
不存在Absent 不存在Absent 返回资产中视频的最近部分,最大长度为 4 小时。Returns the most recent portion of the video in the Asset, up to a maximum length of 4 hours.

如果资产最近尚未被写入(没有任何新的视频数据传入),则返回点播 (VoD) 清单。If the Asset has not been written to (no new video data coming in) recently, an on-demand (VoD) manifest is returned. 否则,将返回实时清单。Else, a live manifest is returned.
现值Present 不存在Absent 如果此类清单小于 24 小时,则返回一个清单,此清单包含任何比 startTime 更新的可用视频。Return a manifest with whatever video is available that is newer than startTime, if such a manifest would be shorter than 24 hours.
如果清单的长度超过 24 小时,则返回错误。If the length of the manifest would exceed 24 hours, then return an error.
如果资产最近尚未被写入(没有任何新的视频数据传入),则返回点播 (VoD) 清单。If the Asset has not been written to (no new video data coming in) recently, an on-demand (VoD) manifest is returned. 否则,将返回实时清单。Else, a live manifest is returned.
不存在Absent 现值Present 错误 – 如果 startTime 存在,endTime 则是必需的。Error – if startTime is present, then endTime is mandatory.
现值Present 现值Present 返回一个 VoD 清单,此清单包含 startTime 和 endTime 之间可用的任何视频。Return a VoD manifest with whatever video is available between startTime and endTime.
跨度(startTime,endTime)不能超过 24 小时。The span (startTime, endTime) cannot exceed 24 hours.

响应示例Response examples

示例 1:无间隔的实时录制Example 1: Live recording with no gaps

下面是显示 2019 年 12 月 21 日所有可用媒体的响应,其中,录制已 100% 完成。Here is a response showing all of the available media for December 21, 2019, where the recording was 100% complete. 响应仅有一个开始/结束对。Response has only one start/end pair.

GET https://hostname/locatorId/content.ism/availableMedia?precision=full&startTime=2019-12-21T00:00:00Z&endTime=2019-12-22T00:00:00Z
{
   "timeRanges":[
   {
         "start":"2019-12-21T00:00:00Z", 
         "end":"2019-12-22T00:00:00Z"
    }
   ]
}

在连续录制的情况下,你可以在该 Start/End 对中的任何时段内请求 HLS 或 DASH 清单 – 只要跨度为 24 小时或更小即可。When the recording is continuous, then you can request HLS or DASH manifests for any portion of time within that Start/End pair – as long as the span is 24 hours or less. 下面是上述 4 小时的 HLS 清单请求的示例:An example for a 4-hour HLS manifest request for the above would be:

GET https://{hostname-here}/{locatorGUID}/content.ism/manifest(format=m3u8-aapl,startTime=2019-12-21T14:00:00.000Z,endTime=2019-12-21T18:00:00.000Z).m3u8

示例 2:间隔为 2 秒的实时录制Example 2: Live recording with a 2-second gap

假设出于某种原因,相机无法在一天内以 2 秒的间隔发送有效视频。Suppose for some reason, the camera failed to send valid video for a 2-second interval on a day. 下面是显示 2019 年 12 月 21 日可用媒体的响应:Here is a response showing the available media for December 21, 2019:

GET https://hostname/locatorId/content.ism/availableMedia?precision=full&startTime=2019-12-21T00:00:00Z&endTime=2019-12-22T00:00:00Z
{
   "timeRanges":[
    {
         "start":"2019-12-21T00:00:00Z", 
         "end":"2019-12-21T04:01:08Z"
    },
    {
         "start":"2019-12-21T04:01:10Z", 
         "end":"2019-12-22T00:00:00Z"
    }
   ]
}

对于如上所示的录制,再次强调,只要跨度小于 24 小时,你就可以使用任何 startTime/endTime 对来请求 HLS 和 DASH 清单。With a recording such as the above, again, you could request HLS and DASH manifests with any startTime/endTime pairs, as long as the span was below 24 hours. 如果这些值在 04:01:08AM UTC 时跨越了间隔,那么根据这些协议的相关规范,返回的清单将指示出媒体时间线中的中断。If these values straddled the gap at 04:01:08AM UTC, then the returned manifest would signal the discontinuity in the media timeline, per the relevant specs for those protocols.

示例 3:间隔为 8 小时的实时录制Example 3: Live recording with an 8-hour gap

假设相机和/或本地设施在一天中从 UTC 凌晨 4 点到 UTC 中午一直处于断电状态,持续了 8 小时,并且没有备份电源。Suppose the camera and/or on-premise facility lost power for an 8-hour period during the day, from 4 AM UTC to noon UTC, and there was no backup power source. 下面是显示这一天内所有可用媒体的响应。Here is a response showing all of the available media for such a day.

GET https://hostname/locatorId/content.ism/availableMedia?precision=full&startTime=2019-12-21T00:00:00Z&endTime=2019-12-22T00:00:00Z
{
   "timeRanges":[
    {
         "start":"2019-12-21T00:00:00Z", 
         "end":"2019-12-21T04:00:00Z"
    },
    {
         "start":"2019-12-21T12:00:00Z", 
         "end":"2019-12-22T00:00:00Z"
    }
   ]
}

对于此类录制:With such a recording:

  • 如果你请求一个清单,其中 startTime/endTime 范围筛选器都在时间线的“可用”部分内,即从午夜到凌晨 4 点或从中午到午夜,此服务则将返回一个清单,其中包含从 startTime 到 endTime 的时间,例如:If you request a manifest where both startTime/endTime range filters were inside the ‘available’ parts of the timeline, namely from midnight to 4AM, or noon to midnight, then the service would return a manifest that covers the time from startTime to endTime, such as:

    GET https://{hostname-here}/{locatorGUID}/content.ism/manifest(format=m3u8-aapl,startTime=2019-12-21T14:01:00.000Z,endTime=2019-12-21T03:00:00.000Z).m3u8

  • 如果你请求一个清单,其中 startTime 和 endTime 都位于中间的“缺口”内(例如从 UTC 上午 8 点到 10 点),此服务的行为则与资产筛选器会导致空结果时的行为相同。If you request a manifest where the startTime and endTime were inside the ‘hole’ in the middle – say from 8AM to 10AM UTC, then the service would behave the same way as if an Asset Filter were to result in an empty result.

    [这是一个获取空响应的请求] GET https://{hostname-here}/{locatorGUID}/content.ism/manifest(format=m3u8-aapl,startTime=2019-12-21T08:00:00.000Z,endTime=2019-12-21T10:00:00.000Z).m3u8[This is a request that gets an empty response] GET https://{hostname-here}/{locatorGUID}/content.ism/manifest(format=m3u8-aapl,startTime=2019-12-21T08:00:00.000Z,endTime=2019-12-21T10:00:00.000Z).m3u8

  • 如果你请求一个清单,其中只有一个 startTime 或 endTime 位于“缺口”内,则返回的清单将仅包含该时间跨度的一部分。If you request a manifest where only one of the startTime or endTime is inside the ‘hole’, then the returned manifest would only include a portion of that timespan. 它会将 startTime 或 endTime 值与最接近的有效边界对齐。It would snap the startTime or endTime value to the nearest valid boundary. 例如,如果要求上午 10 点到下午 1 点这 3 小时的流,响应则将包含中午 12 点到下午 1 点这 1 小时的媒体For example, if you asked for a 3-hr stream from 10AM to 1PM, the response would contain 1-hr worth of media for 12 noon to 1PM

    GET https://{hostname-here}/{locatorGUID}/content.ism/manifest(format=m3u8-aapl,startTime=2019-12-21T10:00:00.000Z,endTime=2019-12-21T13:00:00.000Z).m3u8

    返回的清单将从 2019-12-21T12:00:00.000Z 开始,即使此请求要求从上午 10 点开始。Returned manifest would start at 2019-12-21T12:00:00.000Z, even though the request asked for a start of 10AM. 使用播放器插件构建视频管理系统时,要注意向观看者发出此信号。When building a video management system with a player plugin, care should be taken to signal this to the viewer. 不知道的观看者会感到困惑,为什么播放时间线从中午开始,而不是按请求从上午 10 点开始An unaware viewer would be confused as to why the playback timeline was beginning at noon, and not 10AM as requested

录制和播放延迟Recording and playback latencies

使用 IoT Edge 上的实时视频分析来记录到资产时,你将指定 segmentLength 属性,该属性指示模块在将视频录制到云之前聚合视频的最小持续时间(以秒为单位)。When using Live Video Analytics on IoT Edge to record to an Asset, you will specify a segmentLength property which tells the module to aggregate a minimum duration of video (in seconds) before it is recorded to the cloud. 例如,如果将 segmentLength 设置为 300,则在上传一段 5 分钟的“区块”之前,该模块将首先累积 5 分钟的视频,然后在下一个 5 分钟进入累积模式,然后再次上传。For example, if segmentLength is set to 300, then the module will accumulate 5 minutes worth of video before uploading one 5 minutes “chunk”, then go into accumulation mode for the next 5 minutes, and upload again. 增加 segmentLength 有助于降低 Azure 存储事务成本,因为读取次数和写入次数将不会超过每 segmentLength 秒一次。Increasing the segmentLength has the benefit of lowering your Azure Storage transaction costs, as the number of reads and writes will be no more frequent than once every segmentLength seconds.

因此,从媒体服务流式处理视频将至少延迟这么长时间。Consequently, streaming of the video from Media Services will be delayed by at least that much time.

确定播放延迟(延迟处于相机前事件发生的时间与可以在播放设备上观看的时间之间)的另一个因素是画面组 GOP 持续时间。Another factor that determines playback latency (the delay between the time an event occurs in front of the camera, to the time it can be viewed on a playback device) is the group-of-pictures GOP duration. 正如通过使用 3 个简单的技术来降低实时流的延迟所解释的一样,GOP 持续时间越长,延迟越长。As reducing the delay of live streams by using 3 simple techniques explains, longer the GOP duration, longer the latency. 通常会在监视和安全性方案中使用 IP 相机,将使用 GOP 的时间配置为超过 30 秒。It’s common to have IP cameras used in surveillance and security scenarios configured to use GOPs longer than 30 seconds. 这会对总体延迟会产生很大的影响。This has a large impact on the overall latency.

后续步骤Next steps

连续视频录制教程Continuous video recording tutorial