General strategy for DVB-recordings

[linuxuser]

Description of problem or question:

DVB-recordings can be very different

DVB-S2 with AVC / X264
720p / 1080p

DVB-T2
with AVC 720p / X264
with HEVC 1080p / X265

Probably the transmission is upscaled most times, so there seems to be no advantage to record 1080p instead of 720p.

DVB-S2 with X264 has a very high bitrate normally, most times over 10000

DVB-T2 has lower bitrates, about 3000-4000, while 1080p with HEVC has a little bit lower bitrates than 720p with X264.

Does ist make sense to use X264 for HEVC-recordings?

So my question is what could be a general thumb rule to encode DVB-recordings with handbrake. I know it depends on the recording / movie, but it is impossible to check every DVB-recording in detail. The aim is to reduce the filesize without loosing quality.

What is normally a "good" bitrate for a DVB-recording?

I think DVB-S2 is preferred before DVB-T2.

But what is preferred with DVB-T2 if transmissions are available in 720p X264 and 1080p X265, where upscaling can be assumed with 1080p



Steps to reproduce the problem (If Applicable):

no problem


HandBrake version (e.g., 1.0.0):

handbrake-gtk 1:1.3.3.1-zhb-1ppa1~focal1


Operating system and version (e.g., Ubuntu 16.04 LTS, macOS 10.13 High Sierra, Windows 10 Creators Update):

Ubuntu 20.04

[musicvid]

HEVC has lower native bitrates than AVC, so the differences in transmission protocol may not be as great as you think.
Yes, 1080p HEVC-to-AVC makes sense, as local playback does not have streaming bandwidth constraints.
What you should be concerned with is getting a clean, error free transport stream to work with.

[linuxuser]

> Yes, 1080p HEVC-to-AVC makes sense, as local playback does not have streaming bandwidth constraints.

Not sure, if I understand you correctly.

My playbacks are PC, mobile phone and TV. Never noticed a problem with HEVC-files created by handbrake. So do you mean, the reason to use X.264 are compatibility reasons?

> What you should be concerned with is getting a clean, error free transport stream to work with.

LOL, what can I do? The stream is broadcasted as it is and yes I know, the stream is very often broken. Handbrake does a very good job, but sometimes it is necessary to convert with mkvmerge and then the problems go. The problems with AVC-recordings are a lot less then with HEVC-recordings.

[musicvid]

You asked, "Does ist make sense to use X264 for HEVC-recordings?"
I answered,

> Yes, 1080p HEVC-to-AVC makes sense, as local playback does not have streaming bandwidth constraints.

You replied:

Not sure, if I understand you correctly.

My playbacks are PC, mobile phone and TV. Never noticed a problem with HEVC-files created by handbrake. So do you mean, the reason to use X.264 are compatibility reasons?

As I first stated, in my opinion none of those are significant concerns, so I won't comment further.

> What you should be concerned with is getting a clean, error free transport stream to work with.

LOL, what can I do? The stream is broadcasted as it is and yes I know, the stream is very often broken. Handbrake does a very good job, but sometimes it is necessary to convert with mkvmerge and then the problems go. The problems with AVC-recordings are a lot less then with HEVC-recordings.

I use VideoRedo in Windows to clean up transport stream errors and broken GOPs in broadcast streams, and it's a sure fix in all but the worst cases. I can't advise you concerning Mac, but anecdotal reports suggest Subler may be helpful. Good luck!

[linuxuser]

I am using Linux / Ubuntu 20.04, not a Mac. The only tool for repair I know with Linux is using mkvmerge.

[rollin_eng]

H265 will save you space over h264 at equal quality, its whether its worth the extra encode time and compatibility issues.

Personally I wouldn’t encode h265 to h264 unless you have a specific need to.

There is no “good” bitrate for most videos as it depends on too many variables.