Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Updated live2vod #431

Merged
merged 2 commits into from
Oct 8, 2024
Merged

Updated live2vod #431

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
b81dccd
Updated live2vod
haudiobe Sep 27, 2024
032dbe0
Fixed indentation and missing quite
thasso Sep 27, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion specs/authoring/authoring.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -77,7 +77,7 @@ commands. For example for `authoring`:

# Remote Editing Setup # {#remote-editing}

To quickly edit text in a GitHub repository, you can use the [github.dev](https://docs.github.com/en/codespacesthe-githubdev-web-based-editor)
To quickly edit text in a GitHub repository, you can use the [github.dev](https://docs.github.com/en/codespaces/the-githubdev-web-based-editor)
browser-based editor. Simply press `.` while viewing the repository to open the
editor in your browser. This will launch a lightweight version of VSCode where
you can edit files, create branches, commit changes, and open pull requests
Expand Down
113 changes: 62 additions & 51 deletions specs/live2vod/01-live2vod.inc.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,17 +10,18 @@ clause 4.6. It obsoletes clause 4.6 of DASH-IF IOP Guidelines v4.3 [[!IOP43]].
### Common aspects ### {#live2vod:scenario-common-aspects}

A common scenario for DASH distribution is that a live distributed content is
also made available On-Demand. Common to the different use cases presented in
the following is the
also made available On-Demand. Different use cases exist and are discussed in
the following. Common to the different use cases presented are the following
aspects when converting a live service to VoD:

* desire to re-use the Segments as generated for the live service are also
used for the On-Demand case. This avoids reformatting and also permits to
reuse the Segments that are already cached.

* the re-use of the live MPD, obviously with some modifications

* Problems from live delivery may be addressed, e.g. variable segment durations are signaled,
or unavailable Segments are marked properly or replaced.
* Problems from live delivery may be addressed, e.g. variable segment durations can be signaled,
or unavailable Segments can be marked properly or replaced.

* The content may be augmented with ads.

Expand All @@ -38,7 +39,9 @@ the MPD and a media time within the Period. Specifically,
<em>P<sub>1</sub></em> of the live service, and the media presentation time
<em>T<sub>1</sub></em> within this Period <em>P<sub>1</sub></em>.

<figure>
<a href="#fig:live2vod">The figure below</a> provides an overview of the scenarios.

<figure id="fig:live2vod">
<img src="Images/Live2VoD.png">
<figcaption>Different Live to VoD Scenarios</figcaption>
</figure>
Expand All @@ -47,26 +50,26 @@ the MPD and a media time within the Period. Specifically,

A first scenario for Live Content being converted to VOD is the case that a
scheduled live event starting at a known date and time is also made available
for On-Demand offering after the live program is completed. This case is
well known from sports events, for example football matches (for which the duration
for On-Demand offering after the live program is completed. This case is
well-known from sports events, for example football matches (for which the duration
can be relatively easily predicted) or tennis matches (for which the duration may
be quite arbitrary).

### Extracting a time period from continuous live ### {#live2vod:scenario-extraction}

In the second scenario, the content is extracted from a longer, e.g. 24/7 stream,
at the beginning, the end, or in between. This allows that the content is
offered in a recorded fashion to users. The On-demand content again is defined as
a start and end time in the live content.
offered in a recorded fashion to users. The On-demand content again is defined by a
start and an end time in the live content.

### Transition between Live and On-Demand ### {#live2vod:scenario-transition}

Extending the first scenario, the live service may be converted to a VOD service
In an extension of the first scenario, the live service may be converted to a VOD service
in a seamless manner. To allows this, the service is provided in live and on-demand
concurrently in a transition phase. Assume towards the end of a
live service, the content and service remains on the portal, but the clients are
no longer experience the joining of the live service at the live edge, but the
On-Demand service from the start.
On-Demand service from the start while using the same MPD URL.

## Content Offering Requirements and Recommendations ## {#live2vod:content-offering}

Expand All @@ -76,10 +79,10 @@ A live service is offered with an MPD, where for the MPD the `MPD@type` is set
to `dynamic`. In addition, the MPD may be updated by having the
`MPD@minimumUpdatePeriod` present. The live service may use different types of
profiles, including multi-Period content, number-based or time-based templating,
as well using `@duration` or Segment Timeline based signaling. The live service
may include events in the MPD and/or Inband Event Streams. Segments get
available over time, whereby the latest segment availability start time can be
determined by information in the MPD as the sum of the `MPD@availabilityStartTime`,
as well using `@duration` or Segment Timeline based segment duration signaling.
The live service may include events in the MPD and/or Inband Event Streams. Segments get
available over time, whereby the latest segment availability start time can be
determined by information in the MPD as the sum of the `MPD@availabilityStartTime`,
the start of the Period provided in *PeriodStart* as defined in [[!DASH]], clause
5.3.2.

Expand Down Expand Up @@ -112,7 +115,7 @@ In order to provide live content as On-Demand, the following is recommended:
* Content may be offered in the same Period structure as for live or in a
different one. However,

* if Periods were only added to provide ad insertions opportunities and
* if Periods were only added to provide ad insertion opportunities and
are signaled to be period-continuous [[!IOP5-PART5]], it is preferable
to remove the Period structure.

Expand All @@ -123,35 +126,37 @@ In order to provide live content as On-Demand, the following is recommended:
* The presentation duration is determined through either the
`@mediaPresentationDuration` attribute or, if not present, through the sum
of the *PeriodStart* and the `Period@duration` attribute of the last
Period in the MPD. Details on this setting are defined specifically for
each scenario.
Period in the MPD. More details on this setting are defined specifically for
each scenario further below.

* Independent whether the `@duration` attribute or the `SegmentTimeline`
element was used for the live distribution, the static distribution
version preferably uses the `SegmentTimeline` with accurate timing to
support seeking and to possibly also signal any gaps in the Segment
timeline. However, to obtain the accurate timeline, the segments may have
timeline. However, to obtain the accurate timeline, the Segments may have
to be parsed (at least up to the `tfdt`) to extract the accurate start
time and duration of each Segment.

* The same templating mode as used in the live service should also be used
* The same templating mode as used in the live service shall also be used
for static distribution in order to reuse the URLs of the cached Segments.

* MPD validity expiration events should not be present in the MPD. However,
it is not recommended that `emsg` boxes are removed from Segments as this
would result in change of Segments and invalidate caches.
would result in change of Segments and invalidate caches. It is expected that
by removal of the corresponding `InbandEventStream` element in the MPD, the
DASH client will ignore the `emsg` boxes.

Specifically on the timing of the Periods,
Specifically on the timing signaling of the Periods in the VoD offering,

* for first period <em>P<sub>0</sub></em> in the live period,
* for first Period <em>P<sub>0</sub></em> in the live period,

* `Period@start` shall be either be removed or set to zero.

* the `@presentationTimeOffset` for each Adaptation Set is set to the media
presentation time included in the Segment at <em>T<sub>0</sub></em>,
* the `@presentationTimeOffset` for each Adaptation Set shall be set to the media
presentation time included in the first Segment at <em>T<sub>0</sub></em>,
normalized by the value of the `@timescale` of the Adaptation Set.

* The value of the `Period@duration` attribute shall be set as follows. If
* The value of the `Period@duration` attribute shall be set as follows: If
the first Period and the last Period are identical, i.e.
<em>P<sub>0</sub></em> is <em>P<sub>1</sub></em>, then *PeriodDuration* is
set to <em>T<sub>1</sub></em> – <em>T<sub>0</sub></em>. If the first
Expand All @@ -173,7 +178,7 @@ Specifically on the timing of the Periods,

* For all cases the *PeriodDuration* is preferably signaled by removing the
`Period@start` attribute for each Period and setting the `Period@duration`
attribute to *PeriodDuration*. However, setting the `Period@start`attribute
attribute to *PeriodDuration*. However, setting the `Period@start` attribute
may also be used. Also, to signal the *PeriodDuration* of the last Period,
the `MPD@mediaPresentationDuration` attribute may be used. According to
ISO/IEC 23009-1 [[!DASH]], Annex A.3.2, the `MPD@mediaPresentationDuration`
Expand Down Expand Up @@ -207,36 +212,35 @@ aspects in clause [[#live2vod:content-offering-common-aspects]] apply.
### Transition between Live and On-Demand ### {#live2vod:content-offering-transition}

In the case of transitioning the services, the content offering should take into
account the following guidelines.
account the following guidelines.

Generally, in particular in 24/7 live service,
or if the VOD service starts before the live service ends, it is discouraged
that the the same MPD URL is used for live and On-Demand content. It is
preferred to create a new MPD URL for the On-demand content to not confuse
clients when transitioning from live to VoD MPD. Note that the same Segments may
and should be shared across live and VOD MPD.
clients when transitioning from live to VoD MPD. Note that the same Segments
with the same Segment URLs may and should be shared across live and VOD MPD.

However, there are cases for which a transition from live to On-demand content
can be considered at the end of a live service and re-using the existing MPD
URL, in particular when the live service follows the specific restrictions in
section [[#live2vod:content-offering-scheduled-and-bounded]].
However, there are relevant use cases for which a transition from live to On-demand content
at the end of a live service and re-using the existing MPD URL, in particular when the live
service follows the specific restrictions in section [[#live2vod:content-offering-scheduled-and-bounded]].

In this transitioning phase, as a first action, once the URL and publish time of
the last Segment is known for the live service, and the duration of the service
is known as well, the live MPD should be changed as follows as defined in clause
4.4.3.1 of [[!IOP43]],, i.e.,
In this transitioning phase when the live service comes to an end, as a first action,
once the URL and publish time of the last Segment is known for the live service,
and the duration of the service is known as well, the live MPD should be changed
as defined in clause 4.4.3.1 of [[!IOP43]],, i.e.,

* adds the attribute `MPD@mediaPresentationDuration`
* adding the attribute `MPD@mediaPresentationDuration` to match the duration of the service

* removes the attribute `MPD@minimumUpdatePeriod`
* removing the attribute `MPD@minimumUpdatePeriod`

This action is the normal action when terminating a live service.

In this case and at this time, all Segments are available and clients playing the live
service can complete the playback of the service until the end. Clients may also
use the timeshift buffer to go back to earlier media times. The beneficial
aspect of this action is, that the DASH clients are expected stop updating the
MPD for operational reasons.
service can complete the playback of the service until the end. However, some clients may also
use the timeshift buffer to go back to earlier media times, or play the live service with some
delay. The beneficial aspect of the action above is that the DASH clients are expected stop
updating the MPD for operational reasons.

However, clients joining the service for the first time seeing the above MPD
will see the type `dynamic` and will attempt to access the live edge, but the
Expand All @@ -256,13 +260,14 @@ playback of live, and have not implemented MPD updates in pause state.

Hence, it is recommended that in the general case, service providers are
permitted to change the MPD and replace the `@type` to be `static` and apply all
of the modifications as documented in clause 4.6.2.
of the modifications as documented in section [[#live2vod:content-offering-common-aspects]].

In the specific service offering above for which the `MPD@availabilityStartTime` is
set to a value that is aligned with the start of the live presentation, and for
which the `Period@start` of the first Period is set to 0, none of the Period
modifications described in 4.6.2 need to be done and the MPD can be used as is.
In this case, the change from `static` to `dynamic` may happen even earlier.
modifications described in section [[#live2vod:content-offering-common-aspects]]
need to be done and the MPD can be used as is. In this case, the change
from type `dynamic` to `static` may happen even earlier.

## Client Behavior ## {#live2vod:client}

Expand All @@ -280,11 +285,17 @@ that a DASH client should be aware of:
(e.g., MPD validity expirations) for which no Inband Event Stream is present
in the MPD.

* clients that access an MPD with `MPD@type='static'` for first time will
* clients that access an MPD with `MPD@type='static'` for first time should
start playback from the beginning (unless a specific start time is chosen
using an MPD anchor). Clients that access an `MPD@type='dynamic'` for the
first time will start from the live edge (unless a specific start time is
chosen using an MPD anchor).
using an MPD anchor).

* clients that access an `MPD@type='dynamic'` for the
first time should start from the live edge (unless a specific start time is
chosen using an MPD anchor). If the live edge is close to the end or past the end
of the media presentation, the DASH client should play the last few seconds
of the live service in order for the user to provide the impression of
joining the service. The DASH client should also update the MPD and should expect
that the type changes from `dynamic` to `static`.

DASH clients should support the transition from `MPD@type` being `dynamic` to
`static` in the case when the `@minimumUpdatePeriod` is no longer present in the
Expand Down