Transcoding LiveTV

[sub]

Here they are, including the two ffmpeg logs created (with "-report") by the two instances of ffmpeg that NextPVR triggers on any streaming attempt.

FYI, if you get two instances of ffmpeg, it's because the client you're using has called the url twice.

[uspino]

After many attempts (with the "&client=1" argument), it looks like clients are able to send the right url call UNLESS it is inside an m3u playlist. It's a very weird thing: it works fine on direct url steaming from, say, VLC player, but if the client uses an m3u playlist the live stream gets called twice. The first call creates a 6-second transcode instance that never gets to the client, the second call -6 seconds later- delivers the stream. Tried in iPlayTV, IPTV and MrMC in Apple TV 4. The playlist is in the standard form:

#EXTM3U tvg-shift=1

#EXTINF:-1 tvg-id=“NBC”,NBC
http://IPADDRESS:PORT/transcode?channel=...k&client=1

I guess it's -as you said- a client bug, not a NextPVR bug, but it's surprising that it's spread to different apps. (When calling for a live, non-transcoded stream from those same clients, even inside a m3u playlist, the stream shows up almost instantly, with no double calls). Any advice would be appreciated.

[fred250]

In any case NextPVR web server is expecting only one http call to start streaming your client is making multiple probes to identify the stream characteristics.
Martin

I’d say Martin is on to something here.

I know from my client development that players often probe the stream before it starts playing.
In some cases such as with the LG TVS it’s possible to do a “single-shot-request” from code but I guess that’s nothing you can rule over in your clients.

Using a file extension of some “live format container” such as “.ts” at the end of the URL or having the streaming server returning a Mime type indicating a live stream may prevent this from happening.

http://IPADDRESS:PORT/transcode?chan...2...e=file.ts

/Fred

[uspino]

I’d say Martin is on to something here.

I know from my client development that players often probe the stream before it starts playing.
In some cases such as with the LG TVS it’s possible to do a “single-shot-request” from code but I guess that’s nothing you can rule over in your clients.

Using a file extension of some “live format container” such as “.ts” at the end of the URL or having the streaming server returning a Mime type indicating a live stream may prevent this from happening.

http://IPADDRESS:PORT/transcode?chan...2...e=file.ts

/Fred

I think you are absolutely right. It might have something to do with the m3u playlist format. I tried the &fake argument with no success. Calling the url from an m3u generates a double ffmpeg call, the first one always lasting 6-7 seconds (which looks like too much for a simple identifying task anyway). I've tried changing the #EXTINF:-1 (-1 is the live stream identifier) for a #EXTINF:123 (123 minutes), but the behavior is the same. Maybe there's some m3u expert out there who can share some knowledge.