Tvheadend

[Feature Request]

Most channels don't use constant bitrates, so what should it show in that case?

Anyways, I don't think this should be implemented as it would require extracting the bitrate (which would require media parsing if I'm not mistaken) and storing it along the other channel infos while for almost all channels around the world it will never work properly anyways. Add in transcoding and you have the next problem. Also it's not clear what's part of a channel, are subtitles included? How about secondary audio streams? How about teletext? Those are all questions you should think about if you want this feature to be implemented.

I know another PVR keeps track of bitrates. This then allows it to report in the UI that "you have enough space to record X hours at your maximum bitrate of x and record Y hours at your average bitrate of y."

It would be slightly more difficult with Tvheadend since there are transcoding profiles. So, just because a channel has Xmb/s, the transcode would cause it to be Ymb/s.

The key problem that I see is that many people have a mixed system (terrestrial and satellite) that have the same channel but at different bitrates, and merged HD and SD channels. So, if one were to record HD from satellite, its bitrate is far higher than SD from terrestrial. The actual channel on which the recording happens isn't known until the time the recording starts (since it depends on free tuners), and could even change during recordings.

The Tvheadend already keeps some statistics. I could imagine tracking how many mb/s were written during recordings per channel, perhaps per hourly timeslot, to account for channels that have their capacity reduced at certain times of day. You could then just take the median bitrate of all recordings on the merged channel to use as the estimated value for bitrate.

Some channels do change the bitrate based on what they are broadcasting, for example Sky is ramping up their bitrate during live sports for that channel, so an hourly timeslot would not even be able to account for that. There are so many things that this depends on, this will be a nightmare to implement and I am sure there will be many bug reports saying "estimated file size is wayyyy to high/low" even with the best implementation possible.

As others said earlier the bitrate are variable.
Sports for example have more information and movement in the picture and that's why that gives a higher bitrate.
The only way this would work is having the current program running for a while like 5 minutes and then estimate from that.

Andreas Fornberg wrote:

As others said earlier the bitrate are variable.
Sports for example have more information and movement in the picture and that's why that gives a higher bitrate.
The only way this would work is having the current program running for a while like 5 minutes and then estimate from that.

Other things is that a transponder/mux have a few or a lot of channels and they share same total bandwidth on transponder/mux so other channels can also need more bandwidth and of that reason it lower the bandwidth on other channels.

Andreas Fornberg wrote:

Andreas Fornberg wrote:

As others said earlier the bitrate are variable.
Sports for example have more information and movement in the picture and that's why that gives a higher bitrate.
The only way this would work is having the current program running for a while like 5 minutes and then estimate from that.

Other things is that a transponder/mux have a few or a lot of channels and they share same total bandwidth on transponder/mux so other channels can also need more bandwidth and of that reason it lower the bandwidth on other channels.

lower the bitrate i mean.