SadKingBilly 0 Posted April 8 Posted April 8 (edited) Hi, The playback of 1080p 4:3 aspect ratio MKV HEVC video is squeezed to a narrower image within the Roku Emby app. It looks like the attached image found below. More details can be found on Github where I posted the problem: https://github.com/MediaBrowser/Emby.Roku/issues/155 I posted the additional requested information but have seen no reaction since. Does anyone here have any ideas how to correct this behavior? Edited April 8 by SadKingBilly
speechles 2001 Posted April 8 Posted April 8 (edited) Stream #0:0: Video: hevc (Main), yuv420p(tv, bt709), 1440x1080, SAR 1:1 DAR 4:3, Level 120, 29.97 fps, 29.97 tbr, 1k tbn, Start-Time 0.968s (default) 1440x1080 is not 4:3 aspect ratio. It is 1080 anamorphic. The Roku does not support direct playback of anamorphic video inside HEVC. The resulting playback will be incorrect. The video is being copied and the audio is being converted. This is changing the container and using ffmpeg. But because the video is copied directly this is a Roku issue and not an Emby issue. You can fix it during playback using the Roku app. You can press down during playback and open the OSD. Find the cog/gear and click it. On the playback menu find the "Attempt Playback Correction" button and click it once. That should cause full transcoding and may properly scale the video for playback. We will update the playback profile for the Roku to add the anamorphic = false restriction to the HEVC profile. Thank you for the issue report. Reference: Fix #1675: [Capabilities] Do NOT allow HEVC to playback anamorphic video Edited April 8 by speechles 1
SadKingBilly 0 Posted April 8 Author Posted April 8 Hi, Thanks for the quick reply! >1440x1080 is not 4:3 aspect ratio. It is 1080 anamorphic I'm still hazy on the cause. When I divide out 1440/1080 it is the ratio 4/3. Definitely the correct ratio. So what else in the stream says it's anamorphic. I'm missing some background here. Is there some metadata in the stream I can adjust to cause the expected behavior? Thanks!
speechles 2001 Posted April 8 Posted April 8 (edited) The bluray disc uses anamorphic pixels in H264/AVC. This is fine the Roku can play this back just fine. The problem comes in when you keep the original aspect ratio (which will retain those anamorphic pixels) when converting into HEVC and create anamorphic pixels in HEVC. This is what the Roku cannot play back. The Roku can only decode anamorphic pixels correctly for H264 and MPEG4. This is why I suggested you use the Attempt Playback Correction button on the Roku OSD. It will hopefully convert the HEVC into H264 with the correct anamorphic pixels. @LukeThe logs show his was remuxing the audio and copying the video stream. A single press of playback correction might solve it. Edited April 8 by speechles
pwhodges 1815 Posted April 9 Posted April 9 15 hours ago, speechles said: Stream #0:0: Video: hevc (Main), yuv420p(tv, bt709), 1440x1080, SAR 1:1 DAR 4:3, Level 120, 29.97 fps, 29.97 tbr, 1k tbn, Start-Time 0.968s (default) 1440x1080 is not 4:3 aspect ratio. It is 1080 anamorphic. How do you read that as anamorphic? 1440x1080 is 4:3, and it explicitly says SAR 1:1 (storage aspect ratio) which is clearly not anamorphic. Paul
SadKingBilly 0 Posted April 9 Author Posted April 9 Thanks for the link to the Reddit post. It was informative and filled in some gaps. Quote We will update the playback profile for the Roku to add the anamorphic = false restriction to the HEVC profile Is that something I can do from the client or server side? What will its effects be? I don't see any Roku specific settings in the server UI although I do see settings for HEVC and AVC. Quote You can press down during playback and open the OSD. Find the cog/gear and click it. On the playback menu find the "Attempt Playback Correction" button and click it once. That should cause full transcoding and may properly scale the video for playback. I tried this. On the first attempt the same squashed image was shown. Then I did it again and the image was correctly scaled but shoved over toward the left edge of the screen. An improvement but still kind of sketchy looking. I've attached the log file that were produce when I tried this. embyserver.txt ffmpeg-transcode-93e69c8f-291a-49f6-b6d4-8400fed05852_1.txt ffmpeg-transcode-cf728873-631c-4b22-98fc-647852bd719d_1.txt ffmpeg-directstream-1fd67a61-c11a-4ded-b735-6f291ef463ff_1.txt
visproduction 250 Posted April 9 Posted April 9 (edited) And Now for Something Completely Different (1971) original aspect ratio is 1.85. There can also be black bars within the video media. TV series may have different aspect ratios. Look up each title in member login to imdb.com at the bottom of the info page. Use an video editor or save a frame capture of some light colored frame in the middle of the content. See if there are any black or green bars, right and left or top and bottom. If so remove the black bars with an image editor and measure the image dimensions of the screenshot. This is what needs to be changed back to 1.85 ratio. This assumes that whereever the media came from was not previously edited by someone else. Easiest way to convert to correct aspect ration would be to remove any black bars with a video crop function, then resize the width out, until the ratio 1.85 is reached. Video editors and ffmpeg command line can both do this. Save the result at a reasonable quality in whatever codec and wrapper you prefer for the video. Leave the audio alone. Just check that it is in sync. If you encode directly to the older h.264 inside .mp4 wrapper and the audio to AAC, then you won't lose another generation when it is played back for most users with Emby. If your setup plays h.265 and / or other audio formats directly fine and you don't care about users getting a transcoded copy, then you chould choose h.265 instead. This will give you a media content that is back to it's original aspect ratio and will play correctly. The initial problem is that .mkv wrapper can accept forced aspect ratio changes during playback and some players, as well as blu-ray playback recognizes this aspect ratio change, while browser playback does not and TV App playback with aspect ratio metadata changes doesn't always work correctly without help, if at all. Blu-ray playback of this media would probably recognize the metadata aspect ratio change and play back correctly. Step 2 above needs either a custom ffmpeg command line but it depends on what you find out from step 1. An editor like AVIdemux can also do all the steps at once. There is a learning curve. Getting ever non-standard copy of media to playback correctly is not a simply click and change, because the player either has to recognize metadata aspect ratio preferences, which all browsers and TV Apps do not do this. Neither has anything to do with Emby. Emby cannot anticipate which media is not compatible with your choice of playback, so it cannot guess what to do. Each media can have different aspect ratio and black bar issues. Most solutions involve transcoding. Anytime there is a collection of media on a server or available, a lot of these issues have to be handled one by one, depending on where you get the media. Normally it's handed off to a video editor person to fix. Maybe there is a hardware transcoder that has a lot of features. Can the Nvidia hardware cards fix something like this? I don't know the answer. Maybe someone in the forum has a better solution. I just fix the media in advance and never run into a playback problem. Hope that helps? Edited April 9 by visproduction
speechles 2001 Posted April 9 Posted April 9 6 hours ago, pwhodges said: How do you read that as anamorphic? 1440x1080 is 4:3, and it explicitly says SAR 1:1 (storage aspect ratio) which is clearly not anamorphic. Paul 22 hours ago, SadKingBilly said: The playback of 1080p 4:3 aspect ratio MKV HEVC video is squeezed to a narrower image within the Roku Emby app. @pwhodgesThe fact it is squeezed is leading me to believe this is anamorphic. I also notice the "anamorphic" flag is not set inside the stream. Maybe if that anamorphic flag was set correctly it would unsqueeze the image on the Roku. The Roku player is not as adept at playing disc based media since it is a streaming device. There are certain things the Roku cannot do that BluRay players and other platforms video players can do. @SadKingBillyIs it possible you can upload one of those problem videos somewhere and share the link with me? GoogleDrive, TeraBox, OneDrive, etc. If you can share we can then reproduce and find the cause. Thanks
SadKingBilly 0 Posted April 9 Author Posted April 9 Quote Is it possible you can upload one of those problem videos somewhere and share the link with me? GoogleDrive, TeraBox, OneDrive, etc. If you can share we can then reproduce and find the cause. Thanks I did supply a sample video with the GitHub issue where I originally posted this problem: https://github.com/MediaBrowser/Emby.Roku/issues/155 It's described in the the last posted item-ish. For convenience here it is again... https://drive.google.com/file/d/1QE7v4Rqqfg7QEqnCJjLKWGLMLMJ3mjjC/view Basically it is a truncated version of the same video as this post's original video. I also have another 4/3 aspect show called Babylon 5 (B5) that I ripped from blu ray and play via Emby. When I view an episode of B5 using the Roku Emby app it is displayed properly. Plus, if I view either the Monty Python video we're discussing or the B5 video in the VLC player, they are both displayed in 4/3 formatted windows so that seems to imply they are actual square pixels. The ripped encodings for both shows used the same DVDFab profiles and settings. So I have two different 4/3 Tv shows both purchased in the Blu Ray format. Ripped with the same software and settings (but ripped weeks apart if DVDFab updates matter) that play identically using the VLC player but appear differently in Roku's Emby app. Here's the ffprobe dump for the B5 episode file: (I can create a truncated test file for B5 if needed) D:\_Rips_\shows\Babylon 5 (1995) [imdb-tt0105946]\Season 01 - Signs and Portents>ffprobe "Babylon 5 - S01E01 - Midnight on the Firing Line.mkv" ffprobe version 7.1-full_build-www.gyan.dev Copyright (c) 2007-2024 the FFmpeg developers built with gcc 14.2.0 (Rev1, Built by MSYS2 project) configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libaribb24 --enable-libaribcaption --enable-libdav1d --enable-libdavs2 --enable-libopenjpeg --enable-libquirc --enable-libuavs3d --enable-libxevd --enable-libzvbi --enable-libqrencode --enable-librav1e --enable-libsvtav1 --enable-libvvenc --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxeve --enable-libxvid --enable-libaom --enable-libjxl --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libharfbuzz --enable-liblensfun --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-dxva2 --enable-d3d11va --enable-d3d12va --enable-ffnvcodec --enable-libvpl --enable-nvdec --enable-nvenc --enable-vaapi --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libcodec2 --enable-libilbc --enable-libgsm --enable-liblc3 --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint libavutil 59. 39.100 / 59. 39.100 libavcodec 61. 19.100 / 61. 19.100 libavformat 61. 7.100 / 61. 7.100 libavdevice 61. 3.100 / 61. 3.100 libavfilter 10. 4.100 / 10. 4.100 libswscale 8. 3.100 / 8. 3.100 libswresample 5. 3.100 / 5. 3.100 libpostproc 58. 3.100 / 58. 3.100 [matroska,webm @ 0000026c940ed540] Could not find codec parameters for stream 2 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options Input #0, matroska,webm, from 'Babylon 5 - S01E01 - Midnight on the Firing Line.mkv': Metadata: title : Babylon 5 - s01e01 - Midnight on the Firing Line encoder : libebml v1.4.2 + libmatroska v1.6.3 creation_time : 2025-01-20T18:20:50.000000Z Duration: 00:44:10.14, start: 0.000000, bitrate: 4894 kb/s Chapters: Chapter #0:0: start 0.000000, end 271.896000 Metadata: title : (01)00:00:00:000 Chapter #0:1: start 271.896000, end 712.712000 Metadata: title : (02)00:04:31:896 Chapter #0:2: start 712.712000, end 1483.690000 Metadata: title : (03)00:11:52:712 Chapter #0:3: start 1483.690000, end 1883.256000 Metadata: title : (04)00:24:43:690 Chapter #0:4: start 1883.256000, end 2518.974000 Metadata: title : (05)00:31:23:256 Chapter #0:5: start 2518.974000, end 2609.315000 Metadata: title : (06)00:41:58:974 Chapter #0:6: start 2609.315000, end 2649.146000 Metadata: title : (07)00:43:29:315 Chapter #0:7: start 2649.146000, end 2650.144000 Metadata: title : (08)00:44:09:146 Stream #0:0: Video: hevc (Main), yuv420p(tv, bt709), 1440x1080 [SAR 1:1 DAR 4:3], 23.98 fps, 23.98 tbr, 1k tbn (default) Metadata: BPS : 4411663 BPS-eng : 4411663 DURATION : 00:44:09.147000000 DURATION-eng : 00:44:09.147000000 NUMBER_OF_FRAMES: 63516 NUMBER_OF_FRAMES-eng: 63516 NUMBER_OF_BYTES : 1460893095 NUMBER_OF_BYTES-eng: 1460893095 _STATISTICS_WRITING_APP: DVDFab 13 13.0.3.4 _STATISTICS_WRITING_APP-eng: DVDFab 13 13.0.3.4 _STATISTICS_WRITING_DATE_UTC: 2025-01-20 18:20:50 _STATISTICS_WRITING_DATE_UTC-eng: 2025-01-20 18:20:50 _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES Stream #0:1(eng): Audio: ac3, 48000 Hz, 5.1(side), fltp, 448 kb/s (default) Metadata: BPS : 448000 BPS-eng : 448000 DURATION : 00:44:10.144000000 DURATION-eng : 00:44:10.144000000 NUMBER_OF_FRAMES: 82817 NUMBER_OF_FRAMES-eng: 82817 NUMBER_OF_BYTES : 148408064 NUMBER_OF_BYTES-eng: 148408064 _STATISTICS_WRITING_APP: DVDFab 13 13.0.3.4 _STATISTICS_WRITING_APP-eng: DVDFab 13 13.0.3.4 _STATISTICS_WRITING_DATE_UTC: 2025-01-20 18:20:50 _STATISTICS_WRITING_DATE_UTC-eng: 2025-01-20 18:20:50 _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES Stream #0:2(eng): Subtitle: hdmv_pgs_subtitle (pgssub) Metadata: BPS : 34773 BPS-eng : 34773 DURATION : 00:43:13.549000000 DURATION-eng : 00:43:13.549000000 NUMBER_OF_FRAMES: 1096 NUMBER_OF_FRAMES-eng: 1096 NUMBER_OF_BYTES : 11273499 NUMBER_OF_BYTES-eng: 11273499 _STATISTICS_WRITING_APP: DVDFab 13 13.0.3.4 _STATISTICS_WRITING_APP-eng: DVDFab 13 13.0.3.4 _STATISTICS_WRITING_DATE_UTC: 2025-01-20 18:20:50 _STATISTICS_WRITING_DATE_UTC-eng: 2025-01-20 18:20:50 _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
rotational467 35 Posted April 14 Posted April 14 Try re-encoding an episode from source with any cropping disabled - and make sure the target resolution and framerate are same as source. I'm not familiar with DVDFab but just tell it basically not to do anything except the actual AVC-to-HEVC transcode. To @speechlespoint, I've found the Rokus (and other players) could have difficulty with HEVC encodes where I had cropped non-16:9 content, including problems properly displaying the embedded PGS subs. On Star Trek TOS for example, I found that cropping the source caused the PGS subs to be anamorphically squeezed on multiple players, but not the video itself. So yeah even though the show itself is 4:3, the source and my re-encodes are stored uncropped at 16:9 with the black bars: General Unique ID : 17679825478727803700810198252286011061 (0xD4D02B219CCB0BF949635F73D7666B5) Complete name : /run/user/1000/gvfs/smb-share:server=centaurus.local,share=share/Video/TV/Star Trek (1966)/Season 01/Star Trek - S01E10 - The Corbomite Maneuver.mkv Format : Matroska Format version : Version 4 File size : 3.43 GiB Duration : 50 min 31 s Overall bit rate mode : Variable Overall bit rate : 9 708 kb/s Frame rate : 23.976 FPS Movie name : Star Trek Season 1: Disc 3 Encoded date : 2024-07-13 06:49:34 UTC Writing application : HandBrake 1.8.1 2024062700 Writing library : Lavf61.1.100 ErrorDetectionType : Per level 1 Video ID : 1 Format : HEVC Format/Info : High Efficiency Video Coding Format profile : Main@L4@Main Codec ID : V_MPEGH/ISO/HEVC Duration : 50 min 31 s Width : 1 920 pixels Height : 1 080 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 23.976 (24000/1001) FPS Color space : YUV Chroma subsampling : 4:2:0 (Type 0) Bit depth : 8 bits Writing library : x265 3.6+1-aa7f602f7:[Linux][GCC 11.4.0][64 bit] 8bit+10bit+12bit I'd have to dig out my B5 blu-rays but I'd assume they're authored as 1920x1080 as well. I can't say it's 100% consistent - I had some material I had cropped that seemed to play OK. It probably has to do with the original source authoring. Regardless, I had enough stuff with issues that I've gone back and re-ripped and re-encoded anything that I had cropped the first time. I've found that just leaving the resolution and framerate same-as-source is the path of least resistance and most compatibility. if you've noticed anything that has a constant stutter during playback on the roku but not other players, go into the Roku advanced menu and enable display framerate changing to match the media, turning this on will fix it. Stuff has changed from DVD authoring, particularly with TV and non-16:9 content. There are lots of TV show DVDs that have to be messed with to get good encodes (e.g. original Futurama DVDs), with blu-ray I've always (eventually) found it more trouble than it's worth to do anything other than transcode the original video stream as-is (and audio if desired).
Luke 39648 Posted Sunday at 03:27 AM Posted Sunday at 03:27 AM Hi, we are looking into this. Thanks. 1
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now