You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficcontrol.apache.org by Shmulik Asafi <sh...@qwilt.com> on 2017/07/13 20:17:15 UTC
Issue with MPEG-DASH Live Player Switching to Fetch from Origin
Hi,
We have an installation of TC, where we've configured a Delivery Service
for a live Dash video stream.
The watch page's link to the manifest file points to the Delivery Service
(i.e. to Traffic Router), and indeed the player is routed to download the
manifest (and next few video segments) from the cache at first.
However, the manifest file contains a Location tag which instructs the
player to refresh the manifest from the origin itself (instead of sticking
to the same manifest location the player downloaded from at the first
place); and on the second time the player downloads the manifest from the
origin as instructed. All following video segments are served by the origin.
I was wondering if someone came accross this kind of issue, and if so -
what's the right way to solve it assuming we don't want to modify the
origin manifest?
e.g. Is there support for re-writing the manifest file on the Traffic
Server (for modifying the Location tag)?
Thanks a lot,
--
*Shmulik Asafi*
Qwilt | Work: +972-72-2221692| Mobile: +972-54-6581595| shmulika@qwilt.com
<yo...@qwilt.com>
Re: Issue with MPEG-DASH Live Player Switching to Fetch from Origin
Posted by Jason Tucker <ja...@gmail.com>.
Oh, gotcha. Yeah, when I read "Location tag" in the original email, I
immediately thought HTTP redirect headers. :-/
I still think the 'reverse_map' might not be a bad thing to have enabled,
FWIW... even though it doesn't address this particular problem.
__Jason
On Fri, Jul 14, 2017 at 11:19 AM, Eric Friedrich (efriedri) <
efriedri@cisco.com> wrote:
> The DASH Location is an XML tag in a DASH manifest
>
> https://www.wowza.com/docs/how-to-do-mpeg-dash-streaming#mpd_location
>
> —Eric
>
>
> On Jul 14, 2017, at 9:48 AM, Jason Tucker <ja...@gmail.com> wrote:
>
> Traffic Server does have the notion of a 'reverse_map' entry in
> remap.config, which specifically seems to be for rewriting outbound
> Location headers (assuming they match the mapping. For those that may be
> familiar with httpd mod_proxy, this is sort of analogous to adding a
> 'ProxyPassReverse' config. For example:
>
> map http://edgexx.cdn.example.com/ http://packager.origin.example.com/
> [remainder of remap options...]
> reverse_map http://packager.origin.example.com/
> http://edgexx.cdn.example.com/
>
> This would take a Location header matching the origin url and rewrite them
> to be the edge. It does *not* rewrite links within the body of the
> response, however. And unfortunately, Traffic Ops does not currently add
> the 'reverse_map' entry today (although, I think I'm of the opinion that
> perhaps it should be...)
>
> __Jason
>
> On Fri, Jul 14, 2017 at 9:05 AM, Eric Friedrich (efriedri) <
> efriedri@cisco.com> wrote:
>
>> Of course the easiest path is to have the packager change the value in
>> the Location tag. In DASH you can specify multiple Location’s, so maybe
>> adding a 2nd one is sufficient.
>>
>> Otherwise, traffic server does have a stream_editor plugin:
>> https://github.com/apache/trafficserver/blob/6.2.x/
>> plugins/experimental/stream_editor/stream_editor.cc
>>
>> I’ve never used it.
>>
>>
>> —Eric
>>
>> On Jul 13, 2017, at 4:17 PM, Shmulik Asafi <sh...@qwilt.com> wrote:
>>
>> Hi,
>>
>> We have an installation of TC, where we've configured a Delivery Service
>> for a live Dash video stream.
>>
>> The watch page's link to the manifest file points to the Delivery Service
>> (i.e. to Traffic Router), and indeed the player is routed to download the
>> manifest (and next few video segments) from the cache at first.
>>
>> However, the manifest file contains a Location tag which instructs the
>> player to refresh the manifest from the origin itself (instead of sticking
>> to the same manifest location the player downloaded from at the first
>> place); and on the second time the player downloads the manifest from the
>> origin as instructed. All following video segments are served by the origin.
>>
>> I was wondering if someone came accross this kind of issue, and if so -
>> what's the right way to solve it assuming we don't want to modify the
>> origin manifest?
>> e.g. Is there support for re-writing the manifest file on the Traffic
>> Server (for modifying the Location tag)?
>>
>> Thanks a lot,
>>
>> --
>> *Shmulik Asafi*
>> Qwilt | Work: +972-72-2221692 <+972%2072-222-1692>| Mobile:
>> +972-54-6581595 <+972%2054-658-1595>| shmulika@qwilt.com <yo...@qwilt.com>
>>
>>
>>
>
>
Re: Issue with MPEG-DASH Live Player Switching to Fetch from Origin
Posted by "Eric Friedrich (efriedri)" <ef...@cisco.com>.
The DASH Location is an XML tag in a DASH manifest
https://www.wowza.com/docs/how-to-do-mpeg-dash-streaming#mpd_location
—Eric
On Jul 14, 2017, at 9:48 AM, Jason Tucker <ja...@gmail.com>> wrote:
Traffic Server does have the notion of a 'reverse_map' entry in remap.config, which specifically seems to be for rewriting outbound Location headers (assuming they match the mapping. For those that may be familiar with httpd mod_proxy, this is sort of analogous to adding a 'ProxyPassReverse' config. For example:
map http://edgexx.cdn.example.com/ http://packager.origin.example.com/ [remainder of remap options...]
reverse_map http://packager.origin.example.com/ http://edgexx.cdn.example.com/
This would take a Location header matching the origin url and rewrite them to be the edge. It does *not* rewrite links within the body of the response, however. And unfortunately, Traffic Ops does not currently add the 'reverse_map' entry today (although, I think I'm of the opinion that perhaps it should be...)
__Jason
On Fri, Jul 14, 2017 at 9:05 AM, Eric Friedrich (efriedri) <ef...@cisco.com>> wrote:
Of course the easiest path is to have the packager change the value in the Location tag. In DASH you can specify multiple Location’s, so maybe adding a 2nd one is sufficient.
Otherwise, traffic server does have a stream_editor plugin: https://github.com/apache/trafficserver/blob/6.2.x/plugins/experimental/stream_editor/stream_editor.cc
I’ve never used it.
—Eric
On Jul 13, 2017, at 4:17 PM, Shmulik Asafi <sh...@qwilt.com>> wrote:
Hi,
We have an installation of TC, where we've configured a Delivery Service for a live Dash video stream.
The watch page's link to the manifest file points to the Delivery Service (i.e. to Traffic Router), and indeed the player is routed to download the manifest (and next few video segments) from the cache at first.
However, the manifest file contains a Location tag which instructs the player to refresh the manifest from the origin itself (instead of sticking to the same manifest location the player downloaded from at the first place); and on the second time the player downloads the manifest from the origin as instructed. All following video segments are served by the origin.
I was wondering if someone came accross this kind of issue, and if so - what's the right way to solve it assuming we don't want to modify the origin manifest?
e.g. Is there support for re-writing the manifest file on the Traffic Server (for modifying the Location tag)?
Thanks a lot,
--
Shmulik Asafi
Qwilt | Work: +972-72-2221692<tel:+972%2072-222-1692>| Mobile: +972-54-6581595<tel:+972%2054-658-1595>| shmulika@qwilt.com<ma...@qwilt.com>
Re: Issue with MPEG-DASH Live Player Switching to Fetch from Origin
Posted by Jason Tucker <ja...@gmail.com>.
Traffic Server does have the notion of a 'reverse_map' entry in
remap.config, which specifically seems to be for rewriting outbound
Location headers (assuming they match the mapping. For those that may be
familiar with httpd mod_proxy, this is sort of analogous to adding a
'ProxyPassReverse' config. For example:
map http://edgexx.cdn.example.com/ http://packager.origin.example.com/
[remainder of remap options...]
reverse_map http://packager.origin.example.com/
http://edgexx.cdn.example.com/
This would take a Location header matching the origin url and rewrite them
to be the edge. It does *not* rewrite links within the body of the
response, however. And unfortunately, Traffic Ops does not currently add
the 'reverse_map' entry today (although, I think I'm of the opinion that
perhaps it should be...)
__Jason
On Fri, Jul 14, 2017 at 9:05 AM, Eric Friedrich (efriedri) <
efriedri@cisco.com> wrote:
> Of course the easiest path is to have the packager change the value in the
> Location tag. In DASH you can specify multiple Location’s, so maybe adding
> a 2nd one is sufficient.
>
> Otherwise, traffic server does have a stream_editor plugin:
> https://github.com/apache/trafficserver/blob/6.2.
> x/plugins/experimental/stream_editor/stream_editor.cc
>
> I’ve never used it.
>
>
> —Eric
>
> On Jul 13, 2017, at 4:17 PM, Shmulik Asafi <sh...@qwilt.com> wrote:
>
> Hi,
>
> We have an installation of TC, where we've configured a Delivery Service
> for a live Dash video stream.
>
> The watch page's link to the manifest file points to the Delivery Service
> (i.e. to Traffic Router), and indeed the player is routed to download the
> manifest (and next few video segments) from the cache at first.
>
> However, the manifest file contains a Location tag which instructs the
> player to refresh the manifest from the origin itself (instead of sticking
> to the same manifest location the player downloaded from at the first
> place); and on the second time the player downloads the manifest from the
> origin as instructed. All following video segments are served by the origin.
>
> I was wondering if someone came accross this kind of issue, and if so -
> what's the right way to solve it assuming we don't want to modify the
> origin manifest?
> e.g. Is there support for re-writing the manifest file on the Traffic
> Server (for modifying the Location tag)?
>
> Thanks a lot,
>
> --
> *Shmulik Asafi*
> Qwilt | Work: +972-72-2221692 <+972%2072-222-1692>| Mobile:
> +972-54-6581595 <+972%2054-658-1595>| shmulika@qwilt.com <yo...@qwilt.com>
>
>
>
Re: Issue with MPEG-DASH Live Player Switching to Fetch from Origin
Posted by "Eric Friedrich (efriedri)" <ef...@cisco.com>.
Of course the easiest path is to have the packager change the value in the Location tag. In DASH you can specify multiple Location’s, so maybe adding a 2nd one is sufficient.
Otherwise, traffic server does have a stream_editor plugin: https://github.com/apache/trafficserver/blob/6.2.x/plugins/experimental/stream_editor/stream_editor.cc
I’ve never used it.
—Eric
On Jul 13, 2017, at 4:17 PM, Shmulik Asafi <sh...@qwilt.com>> wrote:
Hi,
We have an installation of TC, where we've configured a Delivery Service for a live Dash video stream.
The watch page's link to the manifest file points to the Delivery Service (i.e. to Traffic Router), and indeed the player is routed to download the manifest (and next few video segments) from the cache at first.
However, the manifest file contains a Location tag which instructs the player to refresh the manifest from the origin itself (instead of sticking to the same manifest location the player downloaded from at the first place); and on the second time the player downloads the manifest from the origin as instructed. All following video segments are served by the origin.
I was wondering if someone came accross this kind of issue, and if so - what's the right way to solve it assuming we don't want to modify the origin manifest?
e.g. Is there support for re-writing the manifest file on the Traffic Server (for modifying the Location tag)?
Thanks a lot,
--
Shmulik Asafi
Qwilt | Work: +972-72-2221692| Mobile: +972-54-6581595| shmulika@qwilt.com<ma...@qwilt.com>