简体   繁体   English

使用 Stream/RAF Tester 调试 Roku 技巧模式

[英]Debug Roku trick mode with Stream/RAF Tester

I am trying to implement trick mode for our VoDs on Roku.我正在尝试在 Roku 上为我们的 VoD 实现技巧模式。 I have followed their guide for HLS here: https://developer.roku.com/en-gb/docs/developer-program/media-playback/trick-mode/hls-and-dash.md我在这里遵循了他们的 HLS 指南: https://developer.roku.com/en-gb/docs/developer-program/media-playback/trick-mode/hls-and-dash.md

I see my playlist get updated with the EXT-X-IMAGE-STREAM-IN:我看到我的播放列表使用 EXT-X-IMAGE-STREAM-IN 进行了更新:

#EXTM3U
#EXT-X-VERSION:7
#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="audio_0",NAME="main",DEFAULT=YES,AUTOSELECT=YES,URI="a/3000/chunklist_audio_1611173953675_1611174576175.m3u8"
#EXT-X-STREAM-INF:BANDWIDTH=3000000,CODECS="avc1.640020,mp4a.40.2",RESOLUTION=1280x720,AUDIO="audio_0"
a/3000/chunklist_1611173953675_1611174576175.m3u8
#EXT-X-IMAGE-STREAM-INF:BANDWIDTH=311040,RESOLUTION=480x270,CODECS="jpeg",URI="media_playlists/media_playlist_480x270_1611173953675_1611174576175.m3u8"

As you can see, the playlist points to media_playlists/media_playlist_480x270_1611173953675_1611174576175.m3u8 which exists with this content:如您所见,播放列表指向media_playlists/media_playlist_480x270_1611173953675_1611174576175.m3u8与此内容存在:

#EXTM3U
#EXT-X-TARGETDURATION:1000
#EXT-X-VERSION:7
#EXT-X-MEDIA-SEQUENCE:1
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-IMAGES-ONLY
#EXTINF:1000.000
#EXT-X-TILES:RESOLUTION=480x270,LAYOUT=10x10,DURATION=10.000
../images/tiles_480x270_1611173953675_1611174576175_0001.jpg
#EXT-X-ENDLIST

And I've confirmed the image exists at the location pointed to above.而且我已经确认图像存在于上面指出的位置。

I'm stumped because I do not have any visibility into the requests being made by the Stream/RAF tester tool, so I do not know what request might be failing.我很困惑,因为我对 Stream/RAF 测试工具发出的请求一无所知,所以我不知道哪个请求可能会失败。

When I play the video on the test channel, it plays fine, so I know the HLS is working as expected.当我在测试频道上播放视频时,它可以正常播放,所以我知道 HLS 正在按预期工作。 However, when I try to seek while the video is playing, the thumbnails do not show and the scrubber stays at the starting position.但是,当我在播放视频时尝试搜索时,缩略图不显示,并且洗涤器停留在起始 position。

Any advice would be greatly appreciated - especially if there is a way to see logging from the stream/raf testing tool!任何建议都将不胜感激 - 特别是如果有办法从流/raf 测试工具中查看日志记录!

Hi I am facing a similar issue with DASH which behaves similarly you are describing with the scrubber position suck at 0.嗨,我遇到了与 DASH 类似的问题,其行为与您描述的洗涤器 position 吸在 0 时类似。

I cannot tell why your scrubbing is not working.我不知道为什么你的擦洗不起作用。 As far as据,直到...为止

Any advice would be greatly appreciated - especially if there is a way to see logging from the stream/raf testing tool!任何建议都将不胜感激 - 特别是如果有办法从流/raf 测试工具中查看日志记录!

One way to go would be adding a proxy server between the test channel and your remote endpoint where the video stream is published. go 的一种方法是在测试通道和发布视频 stream 的远程端点之间添加代理服务器。 I wrote a simple proxy in GO.我在 GO 中写了一个简单的代理。 Here is the code https://play.golang.org/p/-EA8bVt75cG I deployed the server locally on localhost:8998 in my example code.这是代码https://play.golang.org/p/-EA8bVt75cG我在示例代码中将服务器本地部署在 localhost:8998 上。 Then in the stream tester request replace your host:port with localhost:8998.然后在 stream 测试仪请求中将您的主机:端口替换为 localhost:8998。 The proxy will forward requests from Roku player to the stream-publish-host and log all the details.代理会将来自 Roku 播放器的请求转发到流发布主机并记录所有详细信息。

Now I can see all trickplay requests/responses.现在我可以看到所有的特技播放请求/响应。

2021/02/15 19:44:46 RquestUri /live/dev/trickplay/trickplay/1613433254/thumbnails-1727.jpeg
2021/02/15 19:44:46 New RquestUri http://myhost.com:80/live/dev/trickplay/trickplay/1613433254/thumbnails-1727.jpeg
Header field "User-Agent", Value ["Roku/DVP-9.40 (509.40E04200A)"]
Header field "Accept", Value ["*/*"]
2021/02/15 19:44:46 10.0.0.15:50536   200 OK
2021/02/15 19:44:46 Remote Address 10.0.0.15:50521 
2021/02/15 19:44:46 RquestUri /live/dev/trickplay/trickplay/1613433254_video_288p-30fps-350k/video_1865.ts
2021/02/15 19:44:46 New RquestUri http://myhost.com:80/live/dev/trickplay/trickplay/1613433254_video_288p-30fps-350k/video_1865.ts
Header field "User-Agent", Value ["Roku/DVP-9.40 (509.40E04200A)"]
Header field "Accept", Value ["*/*"]
2021/02/15 19:44:46 10.0.0.15:50521   200 OK
2021/02/15 19:44:46 Remote Address 10.0.0.15:50523 
2021/02/15 19:44:46 RquestUri /live/dev/trickplay/trickplay/1613433254_video_288p-30fps-350k/video_1866.ts
2021/02/15 19:44:46 New RquestUri http://myhost.com:80/live/dev/trickplay/trickplay/1613433254_video_288p-30fps-350k/video_1866.ts
Header field "User-Agent", Value ["Roku/DVP-9.40 (509.40E04200A)"]
Header field "Accept", Value ["*/*"]
2021/02/15 19:44:46 Remote Address 10.0.0.15:50537 
2021/02/15 19:44:46 RquestUri /live/dev/trickplay/trickplay/1613433254/thumbnails-1728.jpeg
2021/02/15 19:44:46 New RquestUri http://myhost.com:80/live/dev/trickplay/trickplay/1613433254/thumbnails-1728.jpeg
Header field "User-Agent", Value ["Roku/DVP-9.40 (509.40E04200A)"]
Header field "Accept", Value ["*/*"]
2021/02/15 19:44:46 10.0.0.15:50523   200 OK
2021/02/15 19:44:46 10.0.0.15:50537   200 OK
2021/02/15 19:44:47 Remote Address 10.0.0.15:50535 
2021/02/15 19:44:47 RquestUri /live/dev/trickplay/trickplay/1613433254/thumbnails-1729.jpeg
2021/02/15 19:44:47 New RquestUri http://myhost.com:80/live/dev/trickplay/trickplay/1613433254/thumbnails-1729.jpeg
Header field "Accept", Value ["*/*"]
Header field "User-Agent", Value ["Roku/DVP-9.40 (509.40E04200A)"]
2021/02/15 19:44:47 10.0.0.15:50535   200 OK
2021/02/15 19:44:47 Remote Address 10.0.0.15:50538 
2021/02/15 19:44:47 RquestUri /live/dev/trickplay/trickplay/1613433254/thumbnails-1730.jpeg
2021/02/15 19:44:47 New RquestUri http://myhost.com:80/live/dev/trickplay/trickplay/1613433254/thumbnails-1730.jpeg
Header field "User-Agent", Value ["Roku/DVP-9.40 (509.40E04200A)"]
Header field "Accept", Value ["*/*"]
2021/02/15 19:44:47 10.0.0.15:50538   200 OK
2021/02/15 19:44:47 Remote Address 10.0.0.15:50536 
2021/02/15 19:44:47 RquestUri /live/dev/trickplay/trickplay/1613433254/thumbnails-1731.jpeg

I don't have an exact answer, but we have some clues and a resolution.我没有确切的答案,但我们有一些线索和解决方案。

I did exactly what @allap described but with python's SimpleHTTPServer and pointed the stream tester to my IP (not my localhost).我完全按照@allap 的描述进行了操作,但使用了 python 的 SimpleHTTPServer,并将 stream 测试仪指向我的 IP(不是我的本地主机)。 We found that the media/trickplay playlist wasn't event getting requested.我们发现媒体/trickplay 播放列表不是事件请求。 When we removed the reference to it from the playlist OR made the media playlist 404, scrubbing worked just fine.当我们从播放列表中删除对它的引用或将媒体播放列表设为 404 时,清理工作正常。 Obviously there were no thumbnails for trick mode.显然,特技模式没有缩略图。

I started with a tiled image with a layout of 10x10 and each tile a resolution of 480x270.我从一个布局为 10x10 的平铺图像开始,每个平铺的分辨率为 480x270。 We bumped this down to 5x5 and it worked.我们将它降低到 5x5 并且它起作用了。 ...On my tv with a new Roku device, It did not work on an older Roku device. ...在我的电视上使用新的 Roku 设备,它在旧的 Roku 设备上不起作用。 nor did it work on a TCL Smart Tv, We bumped the layout down to 5x2.它也不适用于 TCL 智能电视,我们将布局降低到 5x2。 and it worked on the TCL.它适用于 TCL。 We had to drop the resolution down to 320x180 for it to work on the older Roku device.我们必须将分辨率降低到 320x180 才能在较旧的 Roku 设备上工作。

TL;DR; TL;博士; if scrubbing breaks when introducing trickplay to your playlist, try reducing the layout of the tiled image archive file (if you are using tiles) and/or drop the resolution for the media playlist.如果在将特技播放引入播放列表时擦洗中断,请尝试减少平铺图像存档文件的布局(如果您使用平铺)和/或降低媒体播放列表的分辨率。 I assume increasing the interval may help as well (we started with 10 seconds, increasing this would mean fewer images, thus fewer requests).认为增加间隔也可能会有所帮助(我们从 10 秒开始,增加这意味着更少的图像,因此更少的请求)。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM