publishTime missing

[joywelt]

According to the standard and the conformance software, if MPD is of type "dynamic" publishTime shall be defined. It's currently missing in develop and feature-segment-timeline (maybe also other) branches.

[joywelt]

The plan is to use availabilityStartTime as publishTime for single period content. For multiple period content, the publishTime shall be defined as the start time of the last period.
Any other ideas?

[waqarz]

"availabilityStartTime as publishTime for single period content" I think you said the other way around: publishTime would be the availabilityStartTime for a single period.

We could say in general that publishTime is aligned to the start time of the lastest period ...?

[TobbeMobiTV]

publishTime was not mandatory when the dash-live-source-simulator was first written. The manifest validator even complained if it was added (as it was it was at some time).

The publishTime should reflect the date of the latest MPD change. For one-period content publishTime=AST should be fine. For multiperiod content it should reflect the time where the MPD changes which is not at the period boundary, but before that (enough time so that polling with minimumUpdatePeriod works).

Please make a proposal on how to add it, but make sure that the namespace is update in accordance (if it needs to be).

[waqarz]

"For multiperiod content it should reflect the time where the MPD changes which is not at the period boundary, but before that (enough time so that polling with minimumUpdatePeriod works)."

Right, so then could it be generalized to: PublishTime = (Live edge time) - (Live edge time)%minimumUpdatePeriod ..?

"but make sure that the namespace is update in accordance"

Not sure what do you mean, what needs to be done?

[waqarz]

Or probably easier approximation: PublishTime = (time now) - (time now)%minimumUpdatePeriod

[TobbeMobiTV]

@waqarz I don't think that is a good approach. In my view, publishTime should only change if the manifest does. Otherwise, there may be a complete parsing in the client just to find out that nothing has changed.

[waqarz]

@TobbeMobiTV OK, so we need to estimate this in the emulator, i.e. publish time would be the time instance the live emulator generates a different MPD from the previous instance of time. This is why I was relating it to period start, wouldn't it be the start time of the period in which time now falls in? I am not sure if its implemented differently.

[waqarz]

We're checking this on our end, will post update.

[waqarz]

@joywelt , as we just discussed: there exists a partial implementation already in the code, please propose an initial implementation update as an example.

[TobbeMobiTV]

Just wanted to mention that there is a mode of the simulator which has MPD updates and even periods when no content is available, but will be soon again. In such cases, the publishTime is before the AST which is in the future.

A test URL is

http://vm2.dashif.org/livesim/modulo_10/testpic_2s/Manifest.mpd

and the module_X mode is described as Dynamic MPD with static URLs on https://github.com/Dash-Industry-Forum/dash-live-source-simulator/wiki

The publishTime should be the time when the "state" of the MPD generator changes.

I'll spend my time on getting SegmentTimeLine a bit further today. I hope to get back to this issue tomorrow.

[TobbeEdgeware]

I added the most simplistic publishTime implementation in commit 4572ddd by adding the current DateTime, and haven't had time to come back to this.. However, when looking at singling Manifest update according to the SAND specification as well as the part 1 of the standard, it is obvious that it is important that the manifest has a "constant" publishTime that can be referred to. Thus, I think one should go through every principal mode of the live simulator and make sure to only update the publishTime when the MPD content changes. There should be two tests for each case to make sure that the change in publishTime is done at the right time instance.

[TobbeEdgeware]

I've created a new issue #40 for an improved implementation.