Page 1 of 1

Mediabrowser ignores SAR

PostPosted: Sun Sep 09, 2012 2:18 am
by jhb50
As reported during the beta, viewtopic.php?f=8&t=6643&p=48045&hilit=mediabrowser+aspect#p48045 , mediabrowser ignores the SAR ratio and so plays videos in squashed form.

This stream as reported by ffmpeg:
Stream #0:1[0x4b]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 128
0x720 [SAR 2:3 DAR 32:27], 91.18 fps, 25 tbr, 90k tbn, 50 tbc

plays squeezed in the mediabrowser as 32:27 but it should play as 16:9 ie DAR/SAR.
The current ffmpeg command is scale=1280:1080,setsar=1, but when I change it to scale=1280:1080*sar,setsar=1 (by intercepting the ffmpeg command) it plays correctly as 16:9.

Re: Mediabrowser ignores SAR

PostPosted: Sun Sep 09, 2012 1:38 pm
by jhb50

Re: Mediabrowser ignores SAR

PostPosted: Sun Sep 09, 2012 10:02 pm
by zip
Do you have a URL where I can reproduce it?

Re: Mediabrowser ignores SAR

PostPosted: Sun Sep 09, 2012 10:36 pm
by jhb50
zip wrote:Do you have a URL where I can reproduce it?

Install SOPCAST, Add SOPCAST plugin.. open sop://broker.sopcast.com:3912/134896 which is usually SAR2:3 DAR32:27.. refresh plug-in, open SOPCAST folder and play SOPCAST#1 in mediabrowser.

Compare the SOPCAST window to the Mediabrowser window. Without the *sar it will be more 4:3 looking than 16:9

Re: Mediabrowser ignores SAR

PostPosted: Mon Sep 10, 2012 3:22 pm
by jhb50
Here is another (better) one. It is Eurosport on 24/7 sop://broker.sopcast.com:3912/124646
Video: h264 (Constrained Baseline) 646x396 [SAR 128:117 DAR 20672:11583]
With this one the SAR only stretches it by 9% to reach 16:9

Re: Mediabrowser ignores SAR

PostPosted: Wed Sep 12, 2012 12:48 am
by jhb50
This maybe a bug in ffmpeg or Serviio.
From the command line ffplay with -vf scale=iw:ih,setsar=1 plays the video correctly, but from Serviio the mediabrowser requires -vf scale=iw:ih*sar,setsar=1 to do the same.

Re: Mediabrowser ignores SAR

PostPosted: Mon Sep 17, 2012 9:47 pm
by zip
jhb50 wrote:As reported during the beta, viewtopic.php?f=8&t=6643&p=48045&hilit=mediabrowser+aspect#p48045 , mediabrowser ignores the SAR ratio and so plays videos in squashed form.

This stream as reported by ffmpeg:
Stream #0:1[0x4b]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 128
0x720 [SAR 2:3 DAR 32:27], 91.18 fps, 25 tbr, 90k tbn, 50 tbc

plays squeezed in the mediabrowser as 32:27 but it should play as 16:9 ie DAR/SAR.
The current ffmpeg command is scale=1280:1080,setsar=1, but when I change it to scale=1280:1080*sar,setsar=1 (by intercepting the ffmpeg command) it plays correctly as 16:9.

I didn't manage to get SOPCast working, but looking at this example it should be correct -

FLV can only display 1:1 pixels, so I have to change the resolution to mimick that.

The video has 2:3 SAR, which tells the displaying device to stretch them in height. To get square pixels-like display we have to change the resolution (either shrink width or, like in this case, extend height) by SAR.

  Code:
720 * (3 / 2) = 1080


Either my thinking is not right of FFmpeg shows wrong SAR values (maybe you can confirm via MediaInfo)

Re: Mediabrowser ignores SAR

PostPosted: Sat Sep 22, 2012 1:36 am
by jhb50
I've done a lot of investigating and testing, and your thinking is close.

First this video does have a SAR of 2:3 and should play with DAR 32:27 as it specifies, not with 16:9 as I first suggested.

Note however that ffmpeg shrinks the width, rather than increasing the height as you are doing. Serviio should apply the same scale=iw*sar:ih,setsar=1 as does ffmpeg and output 853x720 as per the following from the recorded stream. You do not need to compute the absolute values for each ffmpeg command because ffmpeg will do the math and set the square pixels per the formula.
I hope you will change Serviio to use the formula.

Input #0, mpegts, from 'D:\Azureus Active Downloads\avc-1500-mp2-2-3.mpg':
Duration: 00:01:25.07, start: 1.389089, bitrate: 1581 kb/s
Program 1
Metadata:
service_name : Service01
service_provider: FFmpeg
Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 12
80x720 [SAR 2:3 DAR 32:27], 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0:1[0x101]: Audio: mp2 ([3][0][0][0] / 0x0003), 44100 Hz, stereo, s1
6, 128 kb/s
[src @ 044f5d00] w:1280 h:720 pixfmt:yuv420p tb:1/90000 sar:2/3 sws_param:
[Parsed_setsar_1 @ 051f3b80] a:1/1
1.37 A-V:-1348[Parsed_scale_0 @ 051f31c0] 27w:1280 h:720 fmt:yuv420p sar:2/3
-> w:853 h:720 fmt:yuv420p sar:2560/2559 flags:0x4


Secondly while this stream is encoded to play 32:27, it is actually a 16:9 stream. I don't know why a few SOPCAST streams have a SAR of 2:3 but Sopcast does play them correctly as 16:9 because it uses the equivalent of scale=iw*max(1,sar) rather than dar to size its playback window. In order to get Serviio to also play these streams as 16:9, I added mediabrowser online transcoding rules to get mpegts-h264(high) streams with non-square pixels (which singles out these streams) and transcode them to flv with DAR=16:9. Unfortunately this did not work and I have reported the details in this post: Erroneous parameters generated when using DAR=16:9 viewtopic.php?f=7&t=7495
Note that uses a livestream from russia to illustrate the problem rather than a SOPCAST Stream.

Re: Mediabrowser ignores SAR

PostPosted: Sat Sep 22, 2012 10:42 am
by zip
[quote="jhb50"
Note however that ffmpeg shrinks the width, rather than increasing the height as you are doing. Serviio should apply the same scale=iw*sar:ih,setsar=1 as does ffmpeg and output 853x720 as per the following from the recorded stream.[/quote]
I can probably change that, but in the end it'll produce file with the same DAR, so should be displayed properly.

I'm not using the FFmpeg built-in formula, because in some cases it's not so straightforward - therefore doing the computation myself and just providing W and H values.

Re: Mediabrowser ignores SAR

PostPosted: Sat Sep 22, 2012 1:15 pm
by jhb50
I'm not using the FFmpeg built-in formula, because in some cases it's not so straightforward - therefore doing the computation myself and just providing W and H values.


That's not a problem for me, because it does not impact ffmpeg's ability to get the original w and h values if required. And I can usually deduce the original w and h values in my bat from your W and H values in the ffmpeg command based on you usually using the iw*sar:ih formula to compute them. If however you use a different formula in some cases to get the values, then thats hidden from me unless you use the actual different formula in the command rather than the values. Can you tell the conditions under which you use a different formula?