Weird playback behavior of 3D files with respect to aspect ratio (or vertical downsampling)

[STiFU 0]

I am having playback issues with HTAB and HSBS 3D files. Normally, these files should be played as they are, so that the 3DTV can handle the deshrinking and rearranging of the 3D views. With Emby, some files are played with a wrong aspect ratio or even vertically downsampled. The issues occur when there is a wrong aspect ratio detected, e.g., 32:9 while the source material is simply a regular Full HD 16:9 HSBS 3D format. I observe two distinct types of misbehavior in Emby that is dependent on the type of access (i.e. internal via LAN or public via internet) and on the current user settings for "conversion without reencoding" and for the two transcoding options.

 

Type 1:

• Web player (Chrome and Firefox, most recent versions): The wrong aspect ratio reflects in the web player. The 3D views are deshrinked prior to playback. If I were to enable 3D mode on my TV now, I would get a wrong aspect ratio.
  • Internal access: Can be fixed by allowing either conversion without reencoding or one of the two transcoding options in the user settings.
  • Public access: Either conversion or audio playback with transcoding has to be allowed, but video playback with transcoding breaks it again.
• DLNA play to: Playback works fine. The views appear in a shrinked manner so that I can activate 3D mode on the TV and have the display handle everything else.

Type 2: 

• Web player (Chrome and Firefox): Same as type 1
  • Internal access: Either conversion or audio playback with transcoding has to be allowed, but video playback with transcoding breaks it again. (same as public access of type 1)
  • Public access: Can be fixed in the same way as the internal access.
• DLNA play to: The content is vertically downscaled (in case of HSBS) via transcoding to, e.g., 1920x400, resulting in a wrong aspect ratio during playback.
  • This behaviour is independent on the transcoding and conversion settings.
  • 3D mode is activated automatically on my TV.
  • If a movie is started from the beginning, 3D mode works aside from the aspect ratio issue. If a movie is continued 3d mode is activated, but not correctly. The two views are somehow still visible.
  • I cannot jump back or forth in time using the tv remote or the web interface.

 

So, in conclusion, the web player behaviour can be fixed by allowing audio playback transcoding and conversion without reencoding, but disallowing video playback transcoding. I do not consider this a true fix for the issue, however. So, I leave video playback transcoding enabled too for the following server log.

 

The attached server and transcode logs were recorded after a fresh restart of the server. I provoke the different errors in the following order:

1) public access via web player of a type 1 file (transcodeLog1.txt)

2) internal access via web player of a type 2 file (transcodeLog2.txt)

3) internal access via dlna play to of a type 2 file (transcodeLog3.txt)

serverLog.txt

Edited January 31, 2017 by STiFU

[Luke 42079]

Hi there, we're very sorry to hear about your playback issue. In order for us to best help you, please provide the information requested in how to report a media playback issue. thanks !

[STiFU 0]

My appologies. I updated the first post with a lot more information and also did some further testing. I hope it's not too much information now.

[Luke 42079]

The web app can stream the original video without re-encoding but it is only requesting a 4mbps bitrate from the server. So either you adjusted quality or the auto measurement detected that as the ideal amount. Either way, you can try changing that setting.

[Luke 42079]

The dlna transcoding is happening due to dvdsub format subtitles being selected which the device does not support natively.

[STiFU 0]

Ok, thank you. I can confirm that removing the 4 mbit limit for streaming and setting maximum quality fixes the problem for type 1 files. I don't know yet what to do about the dvdsub format, but will look into that.

 

So, now we know what triggers the transcoding. But why does the transcoding output a wrong aspect ratio in the first place? I definitely need transcoding in some occasions, so I would prefer fixing the actual transcoding process. Please check out these example Screenshots.

How a type 1 file is rendered in the webbrowser when transcoding is active:

How it should look like:

 

How a type 2 file is displayed on my TV via DLNA play to. Notice the reduced vertical resolution!

 

As I mentioned earlier, all of these files show a wrong aspect ratio already in the media properties. Here is an example:

The aspect ratio obviously should be 240:101 instead of 480:101. I bet, if I could somehow fix these wrongly detected aspect ratios, transcoding would work fine. However, I cannot access the aspect ratio from the meta data manager. How can I edit it? I also checked the meta data of the source file using the program mkvinfo, which does not show any aspect ratio parameter, so there is probably something wrong with the aspect ratio detection in Emby.

Edited January 31, 2017 by STiFU

[Luke 42079]

I'm not sure at this point. if you can provide some samples files i'll take a look. thanks.

[STiFU 0]

Ok, I sent you some files via pm.

 

When creating those snippets, I noticed that the wrongful behavior was not given at first and the files were not identified as 3D. I compared the mkv-tags with the original file an noticed the missing stereo-mode tag. Adding this stereo-mode tag leads to type 1 misbehavior.

 

In order to create the type 2 snippet, I had to set the stereo-mode tag on the mkv and add the subtitles to the file, but for your testing purposes, the type 1 file snippet should probably suffice.

Edited January 31, 2017 by STiFU

[STiFU 0]

Any news?

 

As this appears to be an actual bug in Emby, is there some sort of bug tracker somewhere?

[Happy2Play 9780]

To me if it is a bug wouldn't it be in FFMPeg since that is were the media info is coming from?

[STiFU 0]

That's a good pointer for further investigation. Here is what ffprobe returns on a critical HSBS-format file:
 

Input #0, matroska,webm, from 'F:\test\type 1 file 3d hsbs snippet problematic.mkv':
  Metadata:
    creation_time   : 2017-01-31 08:52:30
    ENCODER         : Lavf56.25.101
  Duration: 00:00:50.13, start: 0.251000, bitrate: 2380 kb/s
    Stream #0:0: Video: h264 (High), yuv420p, 1920x816 [sAR 1:1 DAR 40:17], SAR 2:1 DAR 80:17, 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
    Metadata:
      stereo_mode     : left_right
      BPS             : 871882
      BPS-eng         : 871882
      DURATION        : 00:00:50.134000000
      DURATION-eng    : 00:00:50.134000000
      NUMBER_OF_FRAMES: 1202
      NUMBER_OF_FRAMES-eng: 1202
      NUMBER_OF_BYTES : 5463868
      NUMBER_OF_BYTES-eng: 5463868
      _STATISTICS_WRITING_APP: mkvmerge v7.6.0 ('Garden of Dreams') 64bit built on Feb  8 2015 13:04:34
      _STATISTICS_WRITING_APP-eng: mkvmerge v7.6.0 ('Garden of Dreams') 64bit built on Feb  8 2015 13:04:34
      _STATISTICS_WRITING_DATE_UTC: 2017-01-31 08:52:30
      _STATISTICS_WRITING_DATE_UTC-eng: 2017-01-31 08:52:30
      _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
      _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
    Side data:
      stereo3d: side by side
    Stream #0:1(ger): Audio: dts (DTS), 48000 Hz, 5.1(side), fltp, 1536 kb/s (default)
    Metadata:
      LANGUAGE        : ger
      BPS             : 1509000
      BPS-eng         : 1509000
      DURATION        : 00:00:50.016000000
      DURATION-eng    : 00:00:50.016000000
      NUMBER_OF_FRAMES: 4689
      NUMBER_OF_FRAMES-eng: 4689
      NUMBER_OF_BYTES : 9434268
      NUMBER_OF_BYTES-eng: 9434268
      _STATISTICS_WRITING_APP: mkvmerge v7.6.0 ('Garden of Dreams') 64bit built on Feb  8 2015 13:04:34
      _STATISTICS_WRITING_APP-eng: mkvmerge v7.6.0 ('Garden of Dreams') 64bit built on Feb  8 2015 13:04:34
      _STATISTICS_WRITING_DATE_UTC: 2017-01-31 08:52:30
      _STATISTICS_WRITING_DATE_UTC-eng: 2017-01-31 08:52:30
      _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
      _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES

I highlighted the problemtic area. After searching the web a little, I found that the issue has been reported for ffmpeg and the guys basically answered that the output of ffmpeg is correct but that it's simply interpreted wrong. In my example, the SAR and DAR marked in red say how the views should look like naturally. However, it is the task of the TV to handle that and not Emby's. The TV definitely does a correction and if Emby does one too, you end up with the wrong DAR. Hence, only the SAR and DAR in braces of the example should be considered by Emby.

Edited February 1, 2017 by STiFU

[STiFU 0]

So, it's been two weeks. At this point, I would just like to know if this has been acknowledged as a bug in Emby, because if it is, it is probably going to be fixed eventually. Otherwise, I would have to install Serviio again, as a backup solution, which would be a real shame.

 

I think my last post identified the problem pretty clearly: When the stereo 3D tag is set on the mkv, the wrong aspect ratio is retrieved from the meta data and used to stretch the video file in the Emby transcoding process.

Edited February 17, 2017 by STiFU

[Luke 42079]

Yes it is an issue that we'll look at for a future update. Thanks !