NextPVR Forums

Hi,

I have a channel set up with the IPTV device which will play when the type is set to 'Internet Source IPTV', but not when the type is set to H264. It is a .ts stream.
I can see that when using 'Internet Source IPTV', the stream is being transcoded on the fly, but this is using close to 100% CPU.

If I capture a stream from the same source using VLC and tell it to capture the original audio and video tracks, it shows video codec of H264 MPEG-4 AVC and audio codec of MPEG AAC (mp4a).
If I look at the codec information for a recording or live-tv buffer file produced by NPVR for the same source, the codec information is exactly the same, as is the framerate and resolution.

So my questions are:

What is ffmpeg actually doing here which enables NPVR to be able to handle the stream, given that the original source is a .ts containing the same codecs?

Is it potentially possible to adjust the transcoding such that the original audio and video tracks are passed through and the process is less CPU intensive?

When you set a channel to 'Input Sourced IPTV', you're effectively telling NextPVR this channel could be one of dozens of different IPTV standards. It doesn't know if the source material is already using the correct audio/video codec, and it is usually in a different container format that needs remux. To receive this channel, it generically asks ffmpeg to convert the URL from "whatever IPTV type it is" to a transport stream containing H.264+AAC. This allows NextPVR to accept anything ffmpeg can receive, but admittedly isn't always doing it the smartest way.

Thank you for taking the time to reply. I realise that what I'm trying to do is not necessarily the main purpose of NPVR.

I was surprised that this source didn't work when set up as H264 as it is already the correct codecs in a .ts container, so I'm wondering what is actually being changed in the transcoding in this case. Perhaps the process is providing some additional buffering?

Are the transcoding options in use here configurable? The only settings I see are in the 'Webserver' section of config.xml - do those apply to this process?

Can you upload a sample recording of the raw file that won't play?

Martin

To be honest, there is very little that is tweakable with this IPTV stuff. I can look into

NextPVR just generally asks ffmpeg to get the stream from the specified URL, and convert it to H.264/AAC. Unfortunately ffmpeg isn't very smart about this and always decodes the stream to raw audio/video (regardless of what it originally was), then reencodes it to H.264/AAC. In theory NextPVR could tell it to not reencode the video if it knew it was already in the correct format, and just keep the original video stream, but unfortunately NextPVR doesn't know this, so takes the safer route of just asking for ffmpeg to converting it.

If you knew a stream was a transport stream, with either MPEG2 or H.264, then you can use the other IPTV channel type options (MPEG2 TS, H264 TS), and it'll download it directly without needing to use ffmpeg. This wont work with othe types of containers though, like HLS, or rtsp, or mp4 etc - only raw transport stream.

mvallevand Wrote:Can you upload a sample recording of the raw file that won't play?

Martin

https://drive.google.com/file/d/0BwXTbs8...sp=sharing

Thanks for taking a look, even if it can't be made to play without transcoding I'll be curious to know what's different about this stream compared to .ts streams that NPVR will play.

Are you sure that was the raw feed? It plays in NextPVR and it reports it was created with ffmpeg.

Martin

Absolutely, I captured it with the download function in internet explorer.

No I wanted you to record it raw via NextPVR as a h264 file not Internet sourced.

Martin

If I set the IPTV source type to H264 it doesn't play, and any recording that I attempt just results in a 0 byte file.

Obviously if I set the IPTV source type to 'Internet sourced...' it gets transcoded. That's not what I've done for this sample.

I thought you just wanted a sample of the raw video, so I just downloaded it directly from the stream address.