Jump to content

Video issues when trying to view an episode


Cokefrevr
 Share

Recommended Posts

I am having an issue with the output of the video. In the image attached the video is a small band and the episode is stretched off the screen. 

I currently have a Roku TCL running the most recent Emby update. 

I have not touched the settings much since originally installing Emby on my PC and setting it up. 

 

Thanks!

ffmpeg-transcode-1424ce36-bc09-4787-92b9-37d4f094d5c5.txt

post-128355-0-23246300-1532133626_thumb.jpg

Link to comment
Share on other sites

This happens with other episodes, i find its rather random. I have not found a reason for the episodes that show up like this. 

Link to comment
Share on other sites

All files are h265 but only some are doing this. I have other series are h265 as well and as far as i can tell do not do this. 

Link to comment
Share on other sites

If you're interested in installing the beta server from the website and letting me know if that makes any difference, that would be helpful. thanks !

Link to comment
Share on other sites

How would you like me to provide a sample as the current attach doesn't allow me to attach a video sample, states cannot upload this kind of file. 

 

Never mind I have made the attachment.

 

Test File.zip

Edited by Cokefrevr
Link to comment
Share on other sites

yes, this is one of the files this occurs with on emby. On a regular video player it has no issues. 

Link to comment
Share on other sites

@@Waldonnis, would you mind trying this sample? It plays fine on Android TV but squeezed on Roku.  Both apps are direct playing it.

 

It is a 4:3 video so my guess is that there is something wonky in the metadata of the file itself that is causing the Roku player to misinterpret it. Thanks !

Link to comment
Share on other sites

yniQe91.png

 

It seems the level of 1.0 might be the issue. Seems the roku, while it may play it, might not do it correctly. Notice it likes 3 and above for level.

The profile in capabilities might need adjusting to account for this.

 

Edit: any user of the blue neon app can find the information shown above. Choose "show overview/info" and it will either show the overview, with a media info button below, or go right to the media information if there is no overview. At the bottom of the media information screen is the OS7 compatibility test. This is just to show what the roku believes it can and cannot play. This is not indicative of what really can or cannot play, since that requires verification. It is what roku recommends when playing media is to use this CanDecodeVideo function to give you clues as what might need adjustment. I only use it for this media information screen. This function is not used anywhere else in the app. It's just there to see what the roku thinks about the media. Most times it means nothing, this time it might be saying something we should be listening to.

 

Roku docs about this function:

https://sdkdocs.roku.com/display/sdkdoc/ifDeviceInfo#ifDeviceInfo-CanDecodeVideo(video_formatasObject)asObject

Edited by speechles
Link to comment
Share on other sites

Could this be a reporting/scanning issue?  The test file attached above is showing a level of 4.0, so I'm not sure where 1.0 is coming from.  The file direct plays here, so something's wrong beyond that as it still stretches even when not transcoding.

 

I'm a bit suspicious of the ARs in the file, though...they are awfully large.  I'm wondering if the AR dimensions are causing an overflow during the scaling calculation.  If that's the case, this may not be an easy fix, but I'll see if I can find one.

 

To give you an idea, here's the SAR info from the bitstream SPS:

[AVBSFContext @ 000001f58568d600] 256         sar_width                                    1001010010100100 = 38052
[AVBSFContext @ 000001f58568d600] 272         sar_height                                   0000110110110001 = 3505
Edited by Waldonnis
Link to comment
Share on other sites

Yep, it was the sample aspect ratio in the bitstream (NOT in the container, which appeared okay but clearly wasn't based on the bitstream info).  Altering it produced a playable video.
 
Easiest way to fix it is to figure out what the SAR is supposed to be for a file, then altering the bitstream info to match using a command like this (substituting the proper AR value for the video):

ffmpeg -i input.mkv -map 0 -c copy -bsf:v "hevc_metadata=sample_aspect_ratio=1/1" output.mkv

In this case, I just used 1/1 to square the pixels as a starting point, but other values may be more appropriate if the presentation is supposed to be widescreen.  Note that the above only fixes the bitstream, since that's what the Roku TV seems to be getting choked up on.  You may need to fix the container's private headers too via a careful remux if you have other devices that display the modified file strangely.

Link to comment
Share on other sites

So if I am understanding this correctly, I would need to reformat the video files using ffmpeg, that way it would properly direct play or transcode. 

Link to comment
Share on other sites

Yep, it was the sample aspect ratio in the bitstream (NOT in the container, which appeared okay but clearly wasn't based on the bitstream info).  Altering it produced a playable video.

 

Easiest way to fix it is to figure out what the SAR is supposed to be for a file, then altering the bitstream info to match using a command like this (substituting the proper AR value for the video):

ffmpeg -i input.mkv -map 0 -c copy -bsf:v "hevc_metadata=sample_aspect_ratio=1/1" output.mkv

In this case, I just used 1/1 to square the pixels as a starting point, but other values may be more appropriate if the presentation is supposed to be widescreen.  Note that the above only fixes the bitstream, since that's what the Roku TV seems to be getting choked up on.  You may need to fix the container's private headers too via a careful remux if you have other devices that display the modified file strangely.

 

Do you think he's just going to have to re-encode the videos, or can this situation be detected by ffprobe data and corrected with server transcoding?

Link to comment
Share on other sites

Do you think he's just going to have to re-encode the videos, or can this situation be detected by ffprobe data and corrected with server transcoding?

If you transcode the hevc to h264 it solves the problem entirely. How to detect within the hevc file when to do this? Hmmm.. I just use "force transcode w/o stream copy" in blue neon and it sets the bitrate below the video stream by 1.

 

What is unique in the hevc file to detect this?

 

@@Waldonnis the 1.0 is because emby actually sees level 120. The app was left and right 1 of level. This is wrong. Right can be one, left should be length of level minus one. It should be left(level,level.len()-1)+"."+right(level,1). The reason? Emby calls things level 40 and 50. The Roku canDecodeVideo() likes 4.0 and 5.0 used instead. So I wrote a cheap way at first to do it that works for levels below 100. For that hevc video emby reports 120 for level. Now that I know this I fixed it and the app gives this as level 12.0 rather than 1.0 to the Roku and correctly transcodes to h264.

Edited by speechles
Link to comment
Share on other sites




function fixdecimel(level)
        return left(level,level.len()-1)+"."+right(level,1)
end function
 
... snipped irrelevant parts ...
 
... down where you do the actual transcoding codec part add this bit ...

device = CreateObject("roDeviceInfo")
if FindMemberFunction(device, "CanDecodeVideo") <> invalid and codec = "hevc" then
        if device.CanDecodeVideo({codec: "hevc", profile: profile, level: fixdecimel(level)}).result = true
                transVideo = "h264,hevc"
else
                transVideo = "h264"
        end if
else
transVideo = "h264"
end if
 
... snipped irrelevant parts ...
 
profiles.push({
Type: "Video"
Container: "ts"
AudioCodec: transAudio
VideoCodec: transVideo
Context: "Streaming"
Protocol: "Hls"
})


 

Basically, you can get the same by letting the app decide.

 

NOTE: The initial if statement (findmemberfunction) protects against firmware reporting the candecodevideo() function is no longer present which will kill the app. The fixdecimel function wrapped around level in the candecodevideo() is because of what I mentioned in the post above. I've Included all the relevant little bits of code. With this the app can decide should it direct stream hevc or not since it has better knowledge of capabilities in that regard.

Edited by speechles
Link to comment
Share on other sites

Right but that's in terms of the level. He's also saying there's an incorrect aspect ratio in the video file metadata. So i guess there's two things we're looking at here.

Link to comment
Share on other sites

Do you think he's just going to have to re-encode the videos, or can this situation be detected by ffprobe data and corrected with server transcoding?

 

None of the above, actually.  Detecting this with ffprobe isn't easy, since container-level SAR is different and is what ffprobe shows:

"sample_aspect_ratio": "10:11"

Ironically, ffmpeg itself showed that there was a disparity (below), but I couldn't find the same in the ffprobe show_streams results:

[SAR 38052:3505 DAR 279048:17525], SAR 10:11 DAR 4:3

^^ shows the bitstream values in brackets, while the container-level info was after that.  I've never tried to extract the info in a SPS with ffprobe, so I'm not sure if it's even possible.  I suppose I could try the same methodology that I used in my local scripts for getting HDR metadata (involves decoding a frame or two), but I'm not sure if it'll let me get the info in that type of packet.  The way I got the above output was from a trace_headers bitstream filter, which is obviously too much of a pain for a library scan.  I'll see what I can do, but no promises.  There's no real need to transcode to fix it, though, since there's a bitstream filter to alter the SAR info in the bitstream (thankfully), so a remux with the appropriate bitstream filter should do the trick (as noted in my previous post).  It's not a "long run" fix, clearly, but should help the OP in the meantime.

 

Speaking of which:

 

So if I am understanding this correctly, I would need to reformat the video files using ffmpeg, that way it would properly direct play or transcode. 

 

Kinda...but basically yes.  It's what we call a remux, where the contents of the original file are copied to a new file, but this particular command has an added twist: the option that begins with -bsf:v and the quoted part after that tells it to modify specific data inside the video stream while it's doing the copy.  The problem seems to be that, because it was an anamorphic video, the aspect ratio value stored in the video's bitstream was so large that when the Roku OS did the calculation to figure out what aspect ratio it was supposed to be displayed at, the result was likely so large that it exceeded the maximum value their OS could handle (bad Roku...should have an error handler for this).

 

Of course, you could transcode to h.264 or even to HEVC again, but there's no real need.  The remux command I gave above took less than two seconds on my system (which is pretty old, lol)....much faster than any transcode would be.

 

Edit: One other thought.  I used 1/1 for an SAR value in my example line, but it should probably be "10/11" in this case.  I suspect the container-level info is correct in this case, so it is probably best to just use that when fixing the file instead of 1/1.

Edited by Waldonnis
Link to comment
Share on other sites

If you transcode the hevc to h264 it solves the problem entirely. How to detect within the hevc file when to do this? Hmmm.. I just use "force transcode w/o stream copy" in blue neon and it sets the bitrate below the video stream by 1.

 

What is unique in the hevc file to detect this?

 

@@Waldonnis the 1.0 is because emby actually sees level 120. The app was left and right 1 of level. This is wrong. Right can be one, left should be length of level minus one. It should be left(level,level.len()-1)+"."+right(level,1). The reason? Emby calls things level 40 and 50. The Roku canDecodeVideo() likes 4.0 and 5.0 used instead. So I wrote a cheap way at first to do it that works for levels below 100. For that hevc video emby reports 120 for level. Now that I know this I fixed it and the app gives this as level 12.0 rather than 1.0 to the Roku and correctly transcodes to h264.

 

Yeah, I guess I just "autoconvert" ffprobe-reported levels in my head without noticing, so I didn't even think about whether or not h.264-esque parsing was being applied to HEVC level values.  Glad you pointed it out or I wouldn't have made that connection.

 

...as for what's going on in the file itself, detecting the bitstream SAR may be problematic, as noted above, but the real question is how to know if the SAR itself is too big for Roku to handle safely (without overflow).  I suspect I may know what their max would be, but since they don't document it (at least not that I've found), the best I can do is guess and figure out a "safe max" SAR.

Link to comment
Share on other sites

Oh, almost forgot to mention what the conversion is that I do in my head.  I wouldn't use shifts, but rather the actual formulae:

 

For HEVC:

level/30

...and h.264:

level/10

That should yield accurate levels from the level string returned by ffprobe.  I'd have to look into other codecs (if applicable) since I don't use them enough to have any needed conversion memorised.

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
 Share

×
×
  • Create New...