[FFmpeg Web Video] videostream unnecesary transcoding?

[Wolfgan]

I prepared an internal livestream via VLC that I want to distribute/be discovered via UMS. The VLC command includes:

Code: Select all

:sout=#http{mux=ts,dst=:8082/} :sout-all :ttl=3 :sout-keep

And UMS.conf includes the line:

Code: Select all

videostream.Web,IPTVh8082=LiveHttp 8082,http://192.168.1.84:8082/

My Kalemsoft renderer supports that stream in the conf file, and that's reflected in the logs:

Code: Select all

Matched support line f:mpegps|mpegts|mpg   m:video/mpeg

Problem is, that when ffmpeg is launched to treat that stream, it launches a full transcoding as per:

Code: Select all

Starting D:\Program Files\Universal Media Server\win32\ffmpeg64.exe -y -loglevel info -i http://192.168.1.84:8082/ -c:a ac3 -c:v mpeg2video -f vob -g 5 -q:v 1 -qmin 2 -qmax 3 -q:a 3 \\.\pipe\ffmpegwebvideo_68_1452711823793

Is there any way to control ffmpeg behavior in Web Video mode and avoid transcoding, or if remuxing is needed, at most force video / audio streams to be copied as is and let the renderer handle them natively?

Ichecked https://github.com/UniversalMediaServer ... webfilters and https://github.com/UniversalMediaServer ... Video.java but couldn't find any tip in how/if additional configuration is needed.

Thx for any help, Wolf.

[Nadahar]

I don't know anything about web streaming in UMS, but it doesn't seem like it even tries to match the "supported" lines. This line could be a hint:

Code: Select all

TRACE 2016-01-13 15:43:10.025 [main] Could not match any format to ".84:8082/"

I don't think UMS manages to find any information about the media, and thus it's not possible to check if it's supported or not. I'd give the "old mediaparser" a try and see if it does a better job with web streams. To enable that, set

Code: Select all

MediaInfo = false

in the renderer profile. I'm sure you know this, but that means the "supported" lines won't be read, and the old "TranscodeExtensions" and "StreamExtensions" come into play instead. But, there's no extension for a stream, so I don't know what it will do. It will probably transcode as well.

[Wolfgan]

Thanks Nadahar for the catch, I didn't noticed the line:

Code: Select all

TRACE 2016-01-13 15:43:10.025 [main] Could not match any format to ".84:8082/"

That's weird as ".84:8082/" is the trail part of the URL declared in Web.conf
Will do a quick test with MediaInfo = false and see what happens then...
Thanks!

[infidel]

if remuxing is needed, at most force video / audio streams to be copied as is and let the renderer handle them natively?
...Ichecked ...ffmpeg.webfilters ... but couldn't find any tip in how/if additional configuration is needed.

For ffmpeg.webfilters, you could try to copy streams by adding a rule in the OPTIONS section like so:

Code: Select all

192.168.1.84:8082 | -c copy

which should add the '-c' option to the end of the ffmpeg command (no guarantees on whether this would make sense to ffmpeg or not ). Also note that technically as a regex the dots in the address should be escaped, i.e. '192\.168\.1\.84:8082', but since '.' is itself a regex wildcard, it should work in unescaped form too.

[Wolfgan]

That worked (at least in light testing), thanks Infidel & Nadahar! The logs reflect ffmpeg mapping the streams in copy mode, no transcode involved.

What puzzles me now is that the live stream stops around 5 seconds after the start in all the renderers I tested. The metadata received reflects a (fake) file size of 8589934592.00 GB but just 04.08 seconds in time length.
Is there any other config option to touch and assign a longer fake 24hs length or so?
Thx, Wolf

[infidel]

What puzzles me now is that the live stream stops around 5 seconds after the start in all the renderers I tested.

I tried it myself and I don't know whether this is the critical difference in your case, but on linux it wouldn't work until I streamed from vlc using a fake extension, per (possibly outdated?) caveat #1 in vlc wiki streaming how-to in order to avoid flv output:

:sout=#transcode{vcodec=h264,acodec=mpga,ab=128,channels=2,samplerate=44100}:http{dst=:8080/go.mpg} :sout-keep

and

Code: Select all

videostream.Web,VLC=test,http://127.0.0.1:8080/go.mpg

Anyhow it streams ok for me using vlc 2.2.1 and Kodi as renderer.

[Wolfgan]

What puzzles me now is that the live stream stops around 5 seconds after the start in all the renderers I tested.

I tried it myself and I don't know whether this is the critical difference in your case, but on linux it wouldn't work until I streamed from vlc using a fake extension, per (possibly outdated?) caveat #1 in vlc wiki streaming how-to in order to avoid flv output:

:sout=#transcode{vcodec=h264,acodec=mpga,ab=128,channels=2,samplerate=44100}:http{dst=:8080/go.mpg} :sout-keep

and

Code: Select all

videostream.Web,VLC=test,http://127.0.0.1:8080/go.mpg

Anyhow it streams ok for me using vlc 2.2.1 and Kodi as renderer.

Thanks Infidel. It seems is a matter of how the renderer interprets the received stream and the assigned size (9223372034707292159 sent by ffmpeg) / length (09:59:59 sent by ffmpeg), as I guess some renderers do their own stream analysis to assign the total length and cut after what they decide is the calculated end (and that's why I was able to watch just 5"). I need more testing on different renderers to see how they react.

Do you know by any chance where those values come from? Are they fakely sent by any UMS module? (I suspect some old renderers like WDTV may get confused receiving numbers so big, or simply overflow the values)
Thx, Wolf

[infidel]

Do you know by any chance where those values come from? Are they fakely sent by any UMS module?

Yes, ums does it when there's no media info (afaik this dates back to early PMS days and spoofing the PS3 to accept transcoding). But I somehow doubt that this is why you're getting an abrupt termination.

If fake extension had no effect for you, maybe try

Code: Select all

ChunkedTransfer=true

in the renderer conf, which will cause 'honest' Content-Length and Content-Range headers to be sent with the streamed data.