Jump to content

Issue with watching in-progress recording on Roku TCL TV


DamnedUndies

Recommended Posts

@@ebr

 

at some point, roku updated their SDK to give insight into what is going on.

 

zYBShcy.png

 

https://sdkdocs.roku.com/display/sdkdoc/Video#Video-TrickplayFields

click above and scroll down to videoFormat.

 

(note: vp8, the one codec we haven't dealt with. This is never returned as part of the CanDecodeVideo() so not sure how to actually detect this. Once I figure that out, which combination of codec/container makes it show I will add more insight. Maybe it needs the "webm" container before it will give it as an option? It's like digging for truffles. Not sure yet. But this is the only codec shown that I don't know how to detect support for... yet.)

 

Love it when a plan comes together. No mention of mpeg4 part14. So make sure MP4V is not allowed in h263/mpeg4. You can tell it by the CodecTag the server gives. It is already in my code above. This is just confirmation that yes, roku knows, but not everybody at roku knows. RokuDale, the maker of RMP certainly isn't in on this. Tried to get his attention but now some chinese guy is spamming that forum on roku. So my thread is buried until they clean up their camp. Unlike this forum which actually cleans up messes, doesn't allow them to carry on 5 hours posting thousands of posts from one user.. but I digress.. Suffice to say, p--x has some catching up to do now. Late to the party.

 

https://forums.roku.com/viewforum.php?f=28

 

More Info:

(from wikipedia) The only official filename extension for MPEG-4 Part 14 files is .mp4.

 

Oh really. So, no wonder mp4v codec doesn't work in MKV. So the restriction for MP4V needs to check the container the media is in @@ebr and if it is MKV only apply the restriction to transcode. If it is an MP4 container the mpeg4 part14 actually does play. So making note of this, not sure if you want to add into the code, since adding so much makes troubleshoot things later harder. This is just left on the table for the next meal. Will come back to this again and finish. Putting the little fly net covers over the food. We will be back to eat. :)

Edited by speechles
  • Like 1
Link to comment
Share on other sites

ddurdle

I'll be watching this thread and helping to test the changes, when ready.  I have access to 8 different roku devices (3 of which are tv-based) and a slew of different media and live tv services to test.

Link to comment
Share on other sites

  • 4 weeks later...
roberto188

Even with some select Roku's ability to decode mpeg2, none deinterlace. So unless you've got progressive mpeg2 (limited number of TV stations), this feature isn't that helpful for direct streaming TV.

Link to comment
Share on other sites

jfgilliam

The transport stream (TS) isn't really supported by roku. The reason it plays it direct is because when using HLS the m3u8 playlist will play TS slices. The issue will become that TS played this way it may restart at the beginning rather than at the position playback was requested to start. To avoid these problems my advice was no longer direct stream TS when the need for seeking is required. This is why for some things the app has begun to transcode. It is done to allow seeking. There is a reason for everything. :)

 

I have some information to add to this. I'm on beta .50 on Windows and 3.0.110 on Roku. I recorded a 3.5 hr football game. It saved it as .ts in the following format. I was not playing it back while recording. Instead, I allowed it to finish, I watched to make sure the Roku thumbnails process completed. Then I started watching it. At the first commercial, I went to skip forward (10sec skips for me) and the thumbnails where not in sync with the video. They were way ahead (I could tell by the scoreboard). Then when I clicked on one of them, it went back in time to start playing. I converted the stream to the built in "TV" format (i.e. MP4) and played that version on the Roku and it works perfectly. I also tried both versions on the Web App and the .ts stream would not skip forward correctly either (even though there were not any thumbnails.)

 

Title1080I MPEG2VIDEO

CodecMPEG2VIDEO

ProfileMain

Level4

Resolution1920x1080

Aspect ratio16:9

AnamorphicNo

InterlacedYes

Framerate29.97003

Bitrate14186 kbps

Color primariesbt709

Color spacebt709

Color transferbt709

Pixel formatyuv420p

Ref frames1

AudioTitleEng Dolby Digital 5.1

Languageeng

CodecAC3

Codec tagAC-3

Layout5.1

Channels6 ch

Bitrate448 kbps

Sample rate48000 Hz

DefaultNo

AudioTitleSpa Dolby Digital stereo

Languagespa

CodecAC3

Codec tagAC-3

Layoutstereo

Channels2 ch

Bitrate192 kbps

Sample rate48000 Hz

DefaultNo

Containermpegts
Link to comment
Share on other sites

 

I have some information to add to this. I'm on beta .50 on Windows and 3.0.110 on Roku. I recorded a 3.5 hr football game. It saved it as .ts in the following format. I was not playing it back while recording. Instead, I allowed it to finish, I watched to make sure the Roku thumbnails process completed. Then I started watching it. At the first commercial, I went to skip forward (10sec skips for me) and the thumbnails where not in sync with the video. They were way ahead (I could tell by the scoreboard). Then when I clicked on one of them, it went back in time to start playing. I converted the stream to the built in "TV" format (i.e. MP4) and played that version on the Roku and it works perfectly. I also tried both versions on the Web App and the .ts stream would not skip forward correctly either (even though there were not any thumbnails.)

 

Title1080I MPEG2VIDEO

CodecMPEG2VIDEO

ProfileMain

Level4

Resolution1920x1080

Aspect ratio16:9

AnamorphicNo

InterlacedYes

Framerate29.97003

Bitrate14186 kbps

Color primariesbt709

Color spacebt709

Color transferbt709

Pixel formatyuv420p

Ref frames1

Audio TitleEng Dolby Digital 5.1

Languageeng

CodecAC3

Codec tagAC-3

Layout5.1

Channels6 ch

Bitrate448 kbps

Sample rate48000 Hz

DefaultNo

Audio TitleSpa Dolby Digital stereo

Languagespa

CodecAC3

Codec tagAC-3

Layoutstereo

Channels2 ch

Bitrate192 kbps

Sample rate48000 Hz

DefaultNo

Containermpegts

 

 

If you turn on the option in the Roku app to show additional information on playback, and play this, how does it say it is playing?

Link to comment
Share on other sites

If the original .TS is remuxed with MKVToolNix GUI into .MKV copying all the streams does this exhibit the same problem?

 

Sent from my Nexus 7 using Tapatalk

Link to comment
Share on other sites

jfgilliam

If you turn on the option in the Roku app to show additional information on playback, and play this, how does it say it is playing?

 

With that on, is this where you get it? On the server it says it's transcoding it as well.

 

post-272710-0-29443900-1538413429_thumb.jpg

Link to comment
Share on other sites

With that on, is this where you get it? On the server it says it's transcoding it as well.

 

 

Thanks.  I don't know why Roku cannot seek it properly.

Link to comment
Share on other sites

jfgilliam

Thanks.  I don't know why Roku cannot seek it properly.

 

Just a hunch, maybe it's because it's so large and the seek indexes are not calculating properly?

Link to comment
Share on other sites

We are not transcoding the video stream if it appears the stream is supported by the Roku. Even during fallback we are still copying the video stream. Now this copying of the stream reduces CPU overhead on everything else, but for TS there is a slight hiccup. When you repackage in HLS this creates the m3u8 and TS slices. Since the original video is already TS and now we are taking that same stream and putting into TS this confuses the Roku I think. Usually when you direct play a TS container you cannot fast-forward or rewind unless the entire TS fits into the buffer. These small TS slices can fit into the buffer. But as you fast-forward or rewind outside of them, you can't. So it might show it possible you can get to any BIF and play point, but really you are stuck within the segment you are in.

 

To work around this problem, until I figure it out. You can use MKVToolNix GUI and let it remux these copying all streams into MKV. This will let you seek, no quality loss, and everything good without any of the bad.

 

I am downloading several m2ts and ts (both direct play) to find a solution. More sampes, more tests, more learned. I believe the rokuTV might allow TS container to seek.

 

@@ebr we might need another branch of the app on the Roku store as a private app. Call it "Emby Roku Alpha" or similar. This we can use to not disrupt anyone else on either branch beta/stable, and still be able to involve testers for edge cases. Then I can enable TS container as direct playable if mpeg2/h262 is supported on the device. These do direct play on my Roku Ultra. Just with the aforementioned seek issue, maybe on a RokuTV these seek issues aren't issues. Just trying to think outside the box and include users with these issues as testers. Good idea? Bad? The Alpha is really only used for strict edge cases period. It should not be a daily driver. It is just used when issues occur and we can push something to users quickly without impacting the other builds.

Edited by speechles
Link to comment
Share on other sites

jfgilliam

BTW, I remuxed it with the built in "Convert" functionality using the "TV" profile. This created an MP4 that is playable and seekable on the Roku just fine. I'm not using a Roku TV, I have an Ultra. As I also stated above, the Web client was not seeking very well with the .ts stream either.

Link to comment
Share on other sites

As a matter of rule, .ts is not a seekable container.

 

However, when you package it as HLS, it should be.  All of our transcodes are delivered as ts in HLS.

Link to comment
Share on other sites

I see the issue. We need to transcode the mpeg2 video stream, when... the recording isn't complete and the user attempts to playback this in progress recording. It cannot copy the video stream. This is what we aren't doing. I have files where the .TS isn't complete, composed of mpeg2/ac3. Because it isn't complete you cannot seek. So needs to be a way to transcode without copying the streams. Presently this isn't at all possible because the app detects support for the codec, that last thing it wants to do is transcode without copying the video stream. But for streams in progress recording, I think we have to tell it to do this. So we need a setting, maybe just like android has.

 

Allow Seeking In-Progress Recordings    [ YES ]

 

Now using this toggle in settings. We can read that in the app to tell the video player to transcode without stream copy when it is an in-progress recording. I see no other way to accomplish this and keep seeking in transport containers that aren't completed yet.

Edited by speechles
Link to comment
Share on other sites

Okay, I wish I had some LiveTV to test this on. It's finished.

 

I have the "Seek In-Progress Recordings" option done. It is ON by default.

 

Have the mechanism to force transcoding when liveTV recording is played and setting is enabled, do not copy stream.

 

When this is turned on, if the item.type =  "Recording" this will check if the seek in-progress recording setting is true, and if it is, this will always transcode to h264. This should allow seeking now.

 

I have to run out for awhile. @@ebr I can compare notes with you and discuss this more soon as I get back. :)

Edited by speechles
Link to comment
Share on other sites

You don't want to force this on all recordings because, if they are complete, it shouldn't be necessary.

 

You need only do it with a recording with a "Status" of "InProgress".

Link to comment
Share on other sites

You don't want to force this on all recordings because, if they are complete, it shouldn't be necessary.

 

You need only do it with a recording with a "Status" of "InProgress".

 

Oh,, even better. Let me add that. Then it should be pretty straight forward. The changes are pretty minor.

 

The icon.. the icon... it should be a little TV antenna thingy. I unfortunately am the master of "not that good at icon art". So I just copied the one used for trailers. This one needs to be made for the "Seek In-Progress Recordings" setting.

 

The rest of the work is done for this, but the icon.. the icon.. I don't even want to attempt one though I could..lol.. just know that isn't going to be in any commits...lol

 

Thanks. :)

 

I <3 emby.

Edited by speechles
Link to comment
Share on other sites

@@ebr The fix for this is up. :)

 

The icon needs changing though, I reused one because I'm a horrible artist..and not horrible, say...rather not as elegant as your icons look.

Edited by speechles
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...