ffmpeg remux on non-ps3 renderers

[mazey]

any chance we can get this pulled as muxing doesnt work for me using ffmpeg on bravia, ive had to untick the remux when compatible option under ffmpeg options for my videos to play with ffmpeg on my bravia, it does remux fine on the ps3 though if left ticked, would be nice to try it out as it should allow remux on the bravia according to the braviahx.conf and i just tested it with ums snap and it worked also but with pms it does not.

ffmpeg remuxing on non-ps3 renderers fix.

https://github.com/UniversalMediaServer ... 37e815a6e6

think it also needs this to work for me, bravia non-ps3 fixes

https://github.com/UniversalMediaServer ... b330951619
https://github.com/UniversalMediaServer ... 243bdb78fc

big ups if this gets looked into

[Raptor399]

Those patches are too specific for my taste, I'm not going to pull them.
I understand there may be a problem underneath that needs to be looked at, but it should be solved in more generic manner.

Still, thanks for the suggestion!

[mazey]

well basically if i leave the option remux if possible under ffmpeg ticked it wont play the file on my bravia and keeps skipping to the next file which does the same, it does work on ps3 though im sure since it comes up as avc instead of mpeg2. is there anything i can do to diagnose i do not see anything listed in traces.

[ExSport]

This pull is fixing my discovery of incorrect PN used for non PS3 devices.
Try to add "DLNAOrgPN=false" to the renderer. conf as a temporary fix. It works for PanTV.
When used, PMS will not send any PN string. Some renderers don't like it but some will refuse playing file totally when wrong PN is used.

[mazey]

This pull is fixing my discovery of incorrect PN used for non PS3 devices.
Try to add "DLNAOrgPN=false" to the renderer. conf as a temporary fix. It works for PanTV.
When used, PMS will not send any PN string. Some renderers don't like it but some will refuse playing file totally when wrong PN is used.

thanks its muxing now awesome.

-threads 2 -bufsize 1835000 -maxrate 499000000 -g 5 -q:v 1 -qmin 1 -c:a copy -c:v copy -bsf h264_mp4toannexb -fflags +genpts -f mpegts pipe:



EDIT: yeah its abit jerky when panning i guess my tv doesnt like mpegts streams or something plus the quality looks abit worse then transcoding weird. i think ill just stick to transcoding i dont have any issues with any 720p now im running ffmpeg its so good, i can even transcode 720p on my old server which is less powered at 1.5ghz dualcore on lossless settings. just would of been nice to rest my cpu abit i wonder why the quality is worse though.

[mazey]

are any of the devs able to test whats broken and if they can fix the ffmpeg remux on non-ps3 renderers , since right now its broken, sorry to bring this up again but can we atleast look into fixing it is there a chance atleast? it works fine when done properly and the renderer picks it up as avc. but the hotfix picks it up as mpeg and the quality is not good. or someone create a more generic pull request for pms this is the future mencoder is dead.

[Raptor399]

I have looked more into the problem, and it will take quite a rewrite to fix.

The problem basically stems from how the dlnaspec is determined. As I see it, there currently are a lot of renderer and player specific checks that need to go. This is the code of a resource and as such, it should not concern itself with renderer or player details at all. E.g. "mediaRenderer.isPS3()" or "getPlayer().id()" are unacceptable IMHO.

So I thought: well, let's refactor the responsibilities to the correct place then.
But that turns out to be easier said than done.

For example, one of the first things I encountered was this comment in DLNAMediaInfo.isMuxable().

When you take a step back and think about it, determining if something is muxable isn't all that simple. Can the encoder mux? Is this particular media muxable by that particular encoder? Does the renderer support the muxed result? Are we going to mux or transcode? Which class is responsible for the outcome of all these questions?

And before you know it, you are looking at getInputStream(), trying to figure out how it comes up with the arguments for launchTranscode()...

Summing up: the question seems simple, but a good solution will touch quite a lot of mission critical code. Coming up with a proper solution will take some time.

[mazey]

ok, glad you looked into it, hopefully some others can get involved too as this would be such a great feature and once working will make tsmuxer obsolete which isnt being developed anymore, and possibly the removal of mencoder also eventually as ffmpeg seeems to do everything nowadays transcoding and remux work great on ps3, and transcoding works great on non-ps3 renderers its just the remux thing. if you guys nail that, truly be amazing.

[ExSport]

Right now you can't mux DTS without tsMuxeR. Also FFmpeg doesn't have native support of embedded subtitles and supports only limited external subs formats.
So still it is not full replace of MEncoder and tsMuxeR.

[ziatonic]

Right now you can't mux DTS without tsMuxeR. Also FFmpeg doesn't have native support of embedded subtitles and supports only limited external subs formats.
So still it is not full replace of MEncoder and tsMuxeR.

Is this still valid? I was wondering because, with FFmpeg enabled, some of my movies with DTS remux, and some transcode. I would like all of them to mux of course. Are there some parameters that need to be met for FFmpeg to decide remux? I've been testing and it doesn't make sense.