Universal Media Server | Forum

zoomcns wrote: ↑Sun Dec 23, 2018 4:17 am

Paradox wrote: ↑Sat Dec 22, 2018 2:45 pm FFMPEG will now be broken for some bravia devices it seems FFMPEG newer versions also now have an issue where fractional percents for input width and height will not work properly. So my work on getting that line working in the renderer conf file is now reundant :sigh:

Can you EMPTY your Media libabry and try an AVI file which is not 4:3 or 16:9 (Ie something that should have black bars top and bottom like a 2.35:1 or 2.40:1 aspect ration movie) using FFMPEG as the video engine and see what happens. I suspect now it shifts the video to the top of the screen and doubles the black bar size at the bottom. Thats what it does on mine now.

Yeah that's been a problem for a longer while already, but I either just *shrug*, or select mencoder, which doesn't have this bug.

Yeah the trouble is i do not have much time to look into things like this nowadays. I suspect that issue came along around build 6.8 or the earlier 7.x.x builds. People do upgrade for upgrades sake. Using Mencoder as you say works perfect (Its what i set to the top of my video engines). If you want FFMPEG to also (well as close as it can for now) work again on your bravia then alter the following line in the Sony-BraviaEX.conf file.

Alter from this... to either this... or this... Both should fix the issue where it doubles black bars at the bottom and re-centre the video content. NOTE: Both will very very slightly crop at the edge to the tune of 1 pixel (thats what the 1.01 i came up with actually previously fixed, it would shift non-multiples of 2 resoultions by 1 pixel) to be honest the devs and the point whenever it was which FFMPEG removed the ability to do factional heights/widths should had spotted this would be an issue and altered it, i know its hard to go through each time and check each conf file and commands will be compatible but they need to, especially when every few versions they add new renderers. Bravias it appears get no love anymore .

Also as i think i told you elsewhere (may of been another user appologie if it was not you), sometimes with UMS if you come across a version that works just stick to that version, especially if you have an older model of TV. There are sooooo many components that make up UMS from all the profiles, the playback/transcode apps, the java code etc etc that one issue fixed often means something else gets broken somewhere. The latest releases do not fix the issues mentioned here (MAY fix the AVI displaying problem, personally i doubt it but not the not displaying all MP4 and it also has the previous 1.01 FFMPEG code above).

FFMPEG is useful to have and will often playback the very odd MP4 and MKV file where sound goes out of sync when using MENCODER or playing it with MENCODER results in almost slow motion like playback (you have probably came across one of them now and again ). I am not 100% sure what causes that although i think its something to do with profile level being higher than 3.x or 4.x on the MP4 or MKV file and MENCODER in combo with Sony TVs not liking that either lol.

I wish i had more time than i do i rebuild UMS from ground up ripping out everything and just making a 100% solid build for Sony and their highly annoying DLNA implementations.

@Paradox thanks I have now tried those. Your first suggestion doesn't make a difference at all, the picture is still fully aligned to the top. The second line does something, but the video is still not centered, the bottom black bar is about 4 times as high as the top bar.

zoomcns wrote: ↑Sat Dec 29, 2018 1:53 am @Paradox thanks I have now tried those. Your first suggestion doesn't make a difference at all, the picture is still fully aligned to the top. The second line does something, but the video is still not centered, the bottom black bar is about 4 times as high as the top bar.

Yep you are right for files with incorrect multiples of resolution it still may/will not work properly (as stated i think thats down to the revision of FFMPEG they now seem to be using and it not supporting fractionals of resolutions properly).

The first revision IE (OverrideFFmpegVideoFilter = pad=max(iw*1.00\\,ih*1.00*(16/9)):ow/(16/9):(ow-iw)/16:(oh-ih)/16, setdar=4/3) will still place things right at the top as it is trying to use the fraction (the 1.00 parts of the code) of the resolution still.

The other code IE (OverrideFFmpegVideoFilter = pad=max(iw\\,ih*16/9):max(ih\\,iw/16*9):(ow-iw)/4:(oh-ih)/4, setdar=4/3) for some files as you have noticed it makes things better (adds a black bar to the top but the black bar at the top of the screen is only around half the size of the black bar at the bottom of the screen.......... At least i guess that is basically what you also see )

The reason for that is to do with the setdar and /4 parts of the code.



Im not sure how much you or others including devs reading may or may not understand resolutions, aspect ratios and the like but ill try to explain whats going on further....

Example for a 2.40:1 (aspect ratio) 720P movie the correct resolution for encoding that movie/file (when cropping black bars) would be 1280x536... If it is that resolution then the second line i originally gave should work (i use should because god only knows what other quirks latest UMS builds and latest FFMPEG builds have) IE... Because both 1280 and 536 can be divided or / by a factor of 4 equally (thats what the (ow-iw)/4:(oh-ih)/4 bit of the code does... 1280 divide by 4 is 320 and 536 divided by 4 136, FFMPEG can if it wants process a 320:156 and is happy). Thats also how things should be done when encoding as your typical codec (IE xvid, H264 etc etc like resolutions that are muliples of 4, 8 or 16).

NOW this is where the problem now occurs..............
If your movie though is something like 1280x534 or 1280x535 which ordinarily when watching on your computer or a less fussy device will still by eye look right it will not work because the 534 or 535 (height) part of the resolution will not divide by 4. (534 divided by 4 equals an odd 133.5 and 535 is a bigger mess as that divided by 4 is 133.75) and when it comes to the 16*9 and setdar bits in the code it can not place the content dead centre.... or evenly. (IE ends up not knowing what to do with the odd 0.5 or 0.75........ IE a fraction of the resolution).

Previously if you had a resolution for a file/movie which was not quite right like say the above 1280x534 or 1280x535 example, FFMPEG would to all extents basically realise when taking the input resolution and when calculating the output for transcoding use the nearest multiple of 4 to make things correct..... Does not look like UMS or FFMPEG (maybe both) will do that now.

For now i do not think there is a fool proof way around things... Using this may help SOME MORE files depends on what files you have but will STILL WILL NOT solve it 100%..........
Using that for MP4, MKV (stuff encoded with H264 or H265) MAY solve the issue if both your height and width resolutions of the files are multiples of 2 (or can be divided or / by 2) IE it may work for the rogue example above of 1280x534 but it will likely still give issues for say a file with 1280x535 resolution.

It MAY also have issues or introduce other issues if the file is an AVI file, particularly divx and or xvid because depending on the revision of xvid or divx the file was encoded with some of them will only work with multiples of 4, 8 or 16 (IE they stick to common encoding principles, where as H264 H265 etc can use stupid singular multiples/fractions of 1 (IE the 535 example).


Short version............ 6.9x, 7.xx (and probably since around 6.80) versions of UMS for Sony Bravia EX models made around 2011 are completely borked if you want to use FFMPEG. Its change for change sake (updating code and components/programs used within UMS from what i can see), rather than any improvement which could had been made without screwing up other devices.

Its then left to people like me that understand a bit about whats going on with Sony and such like devices to then come up with a new bodge command line to wrangle into conf files rather than the issues being fixed at the core of the program itself

For now try the code of...
let me know if that makes things better of worse, you can also try experimenting by altering the /2 parts of the code.... IE replace the "? " in this with numbers....
OverrideFFmpegVideoFilter = pad=max(iw\\,ih*16/9):max(ih\\,iw/16*9):(ow-iw)/?:(oh-ih)/?, setdar=4/3

I do not think using a "1" will make any difference (i suspect FFMPEG will just then pass the resolution 1:1 and if its an odd figure like 535 still position the movie wrongly on the TV screen, ive not had time to try over the holiday period) Using a "2" is about the best i think you are likely to get, again i and you will need to/can test

After doing several tests, I think "OverrideFFmpegVideoFilter = pad=max(iw\\,ih*16/9):max(ih\\,iw/16*9):(ow-iw)/2:(oh-ih)/2, setdar=4/3" is the best choice, in any case better than the default one.

Paradox wrote: ↑Mon Dec 31, 2018 3:32 am For now try the code of...

Code: Select all

OverrideFFmpegVideoFilter = pad=max(iw\\,ih*16/9):max(ih\\,iw/16*9):(ow-iw)/2:(oh-ih)/2, setdar=4/3

I can confirm, this works perfectly so far, thank you!

Sorry for the delay in replying, but you are both welcome

The only thing that may cause issues is videos with an odd number resolution (IE any resolution that ends in a 1,3,5,7,9) thankfully unless its a complete bodge of an encode those are few and far between and when encoding your own movies decent encode software should never set resolutions to an odd number

Glad it works, cross your fingers nothing else gets broken in future UMS releases.

This fix is in master now so it will be in the next UMS release. By the way if anyone wants to contribute directly to us we are open source and on GitHub https://github.com/UniversalMediaServer ... ediaServer that way you can avoid being frustrated at us not doing things fast enough