Possible bug: Emby web player displays video in wrong AR when SAR != DAR

[Bloodred 12]

Hello, I believe I may have stumbled upon a bug relating to how files where the storage aspect ratio is not equal to the display aspect ratio are displayed in the web player. It seems that the web player ignores the DAR, so the video ends up playing in the wrong aspect ratio (i.e. the player was supposed to stretch it but does not).

 

In practice: I have a 720x480 (3:2) video which is supposed to play back in 16:9, but actually plays back in 3:2. It's a rip from a DVD. I have taken a screenshot of Emby 3.1.2.0 playing in Chromium on Windows and one of MPC-HC playing the same file. Both were taken in full-screen mode and resized.

Comparison here: http://screenshotcomparison.com/comparison/198384

 

The web client correctly shows the resolution as 720x480 and also correctly shows the aspect ratio as 16:9 in the Media Info section.

 

Video info:

 

 

ffprobe

Stream #0:0: Video: h264 (High), yuv420p(progressive), 720x480 [SAR 1:1 DAR 3:2], SAR 186:157 DAR 279:157, 29.97 fps, 29.97 tbr, 1k tbn, 59.94 tbc (default)

MediaInfo

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 6 frames
Codec ID : V_MPEG4/ISO/AVC
Bit rate : 1 221 Kbps
Nominal bit rate : 1 556 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 16:9
Original display aspect ratio : 3:2
Frame rate mode : Variable
Original frame rate : 29.970 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.150
Writing library : x264 core 116 r2074 2641b9e
Encoding settings : cabac=1 / ref=6 / deblock=1:1:1 / analyse=0x3:0x133 / me=tesa / subme=8 / psy=1 / psy_rd=0.40:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=2 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=5 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=1556 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:0.60
Default : Yes
Forced : No

 

 

 

I've tried playing the file in Chromium, Edge and IE, the AR is incorrect in all of them so it doesn't seem to be browser-specific. I'm not sure if there's anything wrong with the video itself, but as I've said MPC-HC does manage to pick up on the correct AR and plays in 16:9.

 

I haven't been able to find anything about this already posted, sorry if it's been discussed and I missed it.

[Luke 42086]

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

[Bloodred 12]

I forgot to add the logs, my apologies. Problem description, screenshots and Emby server version (3.1.2.0) are in the first post. I'm using Chromium 55, but I also tried Edge 38.14393.0.0 and IE 11.576.14393.0. Please let me know if there's any more info I could provide.

ffmpeg-remux-a855d78e-a14c-4db0-a2f6-9533b7c69d61.txt

server log.txt

Edited January 25, 2017 by Bloodred

[Luke 42086]

It's stream copying the original video as-is which means that in the browser the issue is out of our control. The only thing we could do is force a full transcode but most people will find that to be undesirable.

[Bloodred 12]

Yeah, I noticed myself that it was not transcoding. Then I take it that control over the aspect ratio belongs to the browser, so basically there's no support for videos with rectangular pixels in Chrome/Edge/IE.

 

I agree that forcing a transcode would generally be undesirable. If I select a lower bitrate in order to force the server to transcode it does indeed serve a video with correct aspect ratio in the browser, but obviously lower quality as well. A default-off option to force a transcode without lowering the bitrate target might be nice to have though, basically just something that would transcode at high bitrate when selected by the user.

 

In any case, thanks for the quick response!