Re: [CDNi] Triggers playlist: draft-finkelman-cdni-sva-extensions-00.txt

[Ori Finkelman <[e-mail]>]

And, if we use the explicit option, is the type mandatory, or the
implementation may choose to omit it and rely on the dCDN to be able to
auto-detect it by file extension or format ?

On Tue, Feb 6, 2018 at 9:42 AM, Ori Finkelman <[e-mail]> wrote:

> Kevin, Ben,  Colleagues,
>
> I am working on the playlist specifications and would like to get your
> views on the question of playlist types.
>
> Should it be implicit from the playlist file extension (or even from the
> file format) for example *.m3u8 is HLS, *.ismc is MSS, *.mpd is DASH.
> or, the palylist object should explicitly state that type of playlist, for
> example:
>     {
>        "playlist": "https://www.example.com/a/b/c/1/index.m3u8",
>        "type": hls
>     }
>
> I think that the explicit option is preferable due to the following
> + it allows to register more types
> + it allows for private implementations to have their own private types.
> + it allows the dCDN to advertise which types it supports via the FCI (I
> am working on extending it to support trigger objects).
>
> Thanks,
> Ori
>
>
>
>
> On Thu, Nov 30, 2017 at 7:35 AM, Kevin Ma <[e-mail]>
> wrote:
>
>> (as an individual)
>>
>> > [OF] >> I think the dCDN should return an error for unsupported format
>> and the uCDN should not delegate that service to the dCDN
>>
>> Ideally, the uCDN would not attempt to send a playlist URL if the dCDN
>> has not advertised the playlist URL trigger capability.
>>
>> > Is the uCDN expected to fallback to producing a trigger request with
>> the URLs from the playlist enumerated as *.urls/*.patterns?
>>
>> I would expect so.  I think of the playlist URL more as an optional
>> optimization.  Without this optimization, the uCDN would be using
>> individual urls/patterns anyway -- though for prepositioning, patterns are
>> trickier and the playlist becomes arguably more useful.
>>
>>
>> On Wed, Nov 29, 2017 at 11:57 AM, Ori Finkelman <[e-mail]> wrote:
>>
>>> Hi Ben,
>>> Please see some comments and answers below
>>>
>>> On Tue, Nov 28, 2017 at 2:28 PM, Ben Niven-Jenkins <
>>> [e-mail]> wrote:
>>>
>>>> Ori, Colleagues,
>>>>
>>>> I just read draft-finkelman-cdni-sva-extensions-00 and have some
>>>> comments I will send in separate emails to keep each conversation to a
>>>> single topic.
>>>>
>>>>
>>>> > On 16 Nov 2017, at 12:27, Kevin Ma <[e-mail]> wrote:
>>>> >
>>>> >   For Triggers playlist, a long time ago we decided to not deal with
>>>> HTTP adaptive streaming to simplify the initial scope, but I think video
>>>> and HAS awareness is probably necessary and worthwhile for us to
>>>> re-address.  I think I like content.playlists better than playlist.urls,
>>>> but that's a detail.
>>>>
>>>> Support for multiple optional playlist formats places a burden on the
>>>> dCDN to support the multiple playlist formats. Multiple optional playlist
>>>> formats places a burden on the uCDN, e.g. it needs to be able to handle a
>>>> dCDN that does not support a particular playlist e.g. by transforming the
>>>> playlist to a dCDN supported format or by falling back to a list of URLs
>>>> carried in the triggers request.
>>>>
>>> [OF] >> Another option would be for the uCDN NOT to delegate traffic of
>>> un-supported playlist format. That would motivate the dCDN to support all
>>> of them.
>>>
>>>>
>>>> Support for multiple optional playlist formats therefore (IMO) works
>>>> against interoperability. What is the use case for requiring multiple
>>>> optional playlist formats?
>>>>
>>> [OF] >> I agree that multiple formats is not in favor of
>>> interoperability, but this is where the video industry currently stands, so
>>> we can decide not to standardize it but then we will need to find other
>>> solutions for the video use cases. ABR protocol awareness is something
>>> video CDNs have to do anyway. Features like trans-packaging at the edge are
>>> already being discussed and developed, and for trans-packaging the dCDN
>>> cache has to be manifest type aware.
>>> So, basically we could treat it as just a list of files, but I am not
>>> sure it is in favor of the whole solution.
>>>
>>>>
>>>> What is the envisioned model if a dCDN does not support playlists in
>>>> trigger requests? Is the uCDN expected to fallback to producing a trigger
>>>> request with the URLs from the playlist enumerated as *.urls/*.patterns?
>>>>
>>> [OF] >> I think the dCDN should return an error for unsupported format
>>> and the uCDN should not delegate that service to the dCDN.
>>>
>>>
>>>>
>>>> Thanks
>>>> Ben
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> *Ori Finkelman*Qwilt | Work: [phone] <+972%2072-222-1647> |
>>> Mobile: [phone] <+972%2052-383-2189> | [e-mail]
>>>
>>
>>
>
>
> --
>
> *Ori Finkelman*Qwilt | Work: [phone] <072-222-1647> | Mobile:
> [phone] <052-383-2189> | [e-mail]
>



-- 

*Ori Finkelman*Qwilt | Work: [phone] | Mobile: [phone] |
[e-mail]