I would like to have a custom transcoding profile which would avoid transcoding and upscaling 2Mbps channels to 8Mbps.
In my case I would like to have anything encoded with h264/h265 at the original speed w/o transcoding.
mpeg2, but only above the target speed, would be transcoded to h264 at 1/4 - 1/2 bandwidth.
Also no deinterlancing on already progressive videos. Maybe deinterlacing, in general, should be left to the client device.
This isn't something we have intention to do — we have opted to make the right decisions to provide the most efficient streaming experience in a very complicated series of situations which would be beyond the realm of what we could easily solve with a rules-based system.
Is this for a Recording or Live TV? Is this for an h.264 source? This shouldn't (and usually doesn't) happen. There must be something specific happening if it is not.
I'm not completely sure what you're saying, but if I understand it correctly, this already happens.
When viewing from the Channels app if you have Quality set to Original, transcoding does not happen.
When viewing from a web browser if you have an h.264 encoding (that is HLS-compliant) with a bitrate equal or lower than the requested bitrate, transcoding does not happen.
When viewing from the Channels app if you have any h.264 encoding with a bitrate equal or lower than the requested bitrate (when not set to Original), transcoding does not happen.
We do not support transcoding to mpeg2 because it is not supported by the HLS RFC and does not have hardware encoding on the majority (and maybe all) the platforms we support.
We have future plans to support transcoding to h.265 but don't have a timeline for when that will happen. It will require infrastructure on both the server and client to make this happen seamlessly across the range of versions and platforms we support.
Because we don't support transcoding to mpeg2 or h.265, we must transcode those formats to be able to provide Adaptive Bitrate streaming — our player cannot seamlessly handle the codec changing on the fly when switching from one bitrate to another.
We have decided that Adaptive Bitrate streaming is much more important for the seamless experience of our customer base vs not transcoding original content. If a user specifically does not want transcoding, they can set the Quality to Original to opt out of transcoding and the Adaptive Bitrate streaming.
I am not saying we should transcode to mpeg2, however the DVR doesn't take into account h264 is a better codec and tries to convert 2Mbps 480i mpeg video to 4Mbps h264.
Say you have a limit of 6Mbps and the mpeg2 stream from ATSC 1.0 station is 8Mbps. The dvr will try to transcode this to 6Mbps h264 which just wastes bandwidth.
Another problem:
On my DVR, if I set the bw limit to a number all streams get transcoded. The DVR starts the muxer first, but it never gets used. Two seconds later the transcoder gets started and used.
This results in extra 2 secs delay plus wasted bw/cpu.
It doesn't take it into account because the range in quality of the h.264 encoders on customer systems varies enough that we can't guess what the right quality curve is to not have a loss in QP. We could do a lot of tests and come up with that for each customer encoder, but so far we haven't identified enough cases where it would make a difference.
The transcoding should not be upscaling video — if the source is 480, the maximum size of the transcoded video should match. If that isn't happening, that's a bug and we'll look into it.
The default bitrate for Mobile (or any network that is marked as Low Data) is 4mbps, the default for WiFi is 8mbps. You can adjust either of them if you would like to use less data.
It sounds like you're referring to Live TV streams. It is untrue that all streams are transcoded — only non-h.264 streams are transcoded.
You are mistaken in thinking that the remux process is not used. It's a core part of how we are providing streaming for remuxed and transcoded streams.
A part of the 2+ second delay in streams starting is fundamental to the way the video is being sent from the HDHomeRun, part of it is related to the encoders we use. We will continue to optimize the entire HLS startup pipeline, but there will always be a fundamental limit that we will run into with HLS compared to direct streaming.
Here is how ffmpeg is executed on my system when I set the quality of Home Streming to 8Mbps
I am logging every execution of ffmpeg, so please do not dispel my remarks as hearsay. I am pressing play on a 1080i KQED stream. The number in the second field is PID.
2021/12/12 17:09:10.141340 250148 /home/channels/channels-dvr/2021.12.10.2110/ffmpeg -hide_banner -nostats -loglevel warning -progress http://127.0.0.1:8089/hls/progress?key=ch9.1-d10A22E9C-ip10.168.0.175-remux -fflags discardcorrupt+genpts -f mpegts -probesize 8000000 -i - -enc_time_base -1 -max_muxing_queue_size 4096 -muxdelay 0 -map 0:v:0? -map 0:a? -ignore_unknown -sn -c:v copy -c:a copy -f hls -hls_time 1.000000 -hls_list_size 3600 -hls_delete_threshold 1 -hls_flags temp_file+delete_segments -start_number 1 /mnt/sda1/Channels/recordings/Streaming/ch9.1-d10A22E9C-ip10.168.0.175-622206406/remux/stream.m3u8
2021/12/12 17:09:13.394679 250160 /home/channels/channels-dvr/2021.12.10.2110/ffmpeg -hide_banner -nostats -loglevel warning -noautoscale -progress http://127.0.0.1:8089/hls/progress?key=ch9.1-d10A22E9C-ip10.168.0.175-1-h264-aac-copy--8000-256-1080-0-40--blend-false-false-0.01 -fflags discardcorrupt+genpts -f mpegts -copyts -probesize 8000000 -i - -enc_time_base -1 -max_muxing_queue_size 4096 -muxdelay 0 -map 0:v:0? -map 0:a? -ignore_unknown -map 0:s? -c:v h264_v4l2m2m -g:v 60 -force_key_frames:v source -profile:v high -filter:v fastdeint=blend,scale_v4l2m2m=-2:min(ih,1080) -b:v 8000k -minrate 7200k -maxrate 8800k -bufsize 16000k -c:a aac -ac 2 -b:a 256k -filter:a aresample=async=1 -c:s copy -f hls -hls_time 0.010000 -hls_list_size 360000 -hls_delete_threshold 1 -hls_flags temp_file+delete_segments -start_number 1 -hls_passthrough_subtitles 1 /mnt/sda1/Channels/recordings/Streaming/ch9.1-d10A22E9C-ip10.168.0.175-622206406/encoder-1-439180960/stream.m3u8
In show options on Fire TV I have HLS and codec h264 so not sure what happens to the first stream.
Let's do 480i stream same 8Mbps limit locally:
2021/12/12 17:16:10.298515 250639 /home/channels/channels-dvr/2021.12.10.2110/ffmpeg -hide_banner -nostats -loglevel warning -progress http://127.0.0.1:8089/hls/progress?key=ch11.2-d10A22E9C-ip10.168.0.175-remux -fflags discardcorrupt+genpts -f mpegts -probesize 8000000 -i - -enc_time_base -1 -max_muxing_queue_size 4096 -muxdelay 0 -map 0:v:0? -map 0:a? -ignore_unknown -sn -c:v copy -c:a copy -f hls -hls_time 1.000000 -hls_list_size 3600 -hls_delete_threshold 1 -hls_flags temp_file+delete_segments -start_number 1 /mnt/sda1/Channels/recordings/Streaming/ch11.2-d10A22E9C-ip10.168.0.175-2202405319/remux/stream.m3u8
2021/12/12 17:16:14.412572 250653 /home/channels/channels-dvr/2021.12.10.2110/ffmpeg -hide_banner -nostats -loglevel warning -noautoscale -progress http://127.0.0.1:8089/hls/progress?key=ch11.2-d10A22E9C-ip10.168.0.175-1-h264-aac-copy--8000-256-480-0-40--blend-false-false-0.01 -fflags discardcorrupt+genpts -f mpegts -copyts -probesize 8000000 -i - -enc_time_base -1 -max_muxing_queue_size 4096 -muxdelay 0 -map 0:v:0? -map 0:a? -ignore_unknown -map 0:s? -c:v h264_v4l2m2m -g:v 60 -force_key_frames:v source -profile:v high -filter:v fastdeint=blend,scale_v4l2m2m=-2:min(ih,480) -b:v 8000k -minrate 7200k -maxrate 8800k -bufsize 16000k -c:a aac -ac 2 -b:a 256k -filter:a aresample=async=1 -c:s copy -f hls -hls_time 0.010000 -hls_list_size 360000 -hls_delete_threshold 1 -hls_flags temp_file+delete_segments -start_number 1 -hls_passthrough_subtitles 1 /mnt/sda1/Channels/recordings/Streaming/ch11.2-d10A22E9C-ip10.168.0.175-2202405319/encoder-1-3063021289/stream.m3u8
show options have h264 at 2Mbps so the encoder can not produce the bw requested via
-b:v 8000k -minrate 7200k -maxrate 8800k
The first HLS stream could have been used given the original stream is less than 1Mbps but instead 4 seconds later the transcoder was started and finally Fire TV started playing.
I also think the DVR server is working a bit too hard when this takes place.
Apologies for daring to look under the hood and finding these things 
Instead of addressing your misunderstandings on a point by point basis, I'm just going to jump to the end.
You lack the context to make such a claim.
Honestly, the only thing to apologize for is that you presume to know more than you do, repeatedly make incorrect statements and many of your posts are just wasting everyones time.
I've spent a lot of time to help you with your understanding of the system, and I'm just exhausted from it at this point.
This is incorrect.