-
-
Notifications
You must be signed in to change notification settings - Fork 142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HEVC Failing to decode on HDHomeRun Flex 4k #529
Comments
In the tuner setting or globally? The Tuner setting does nothing to the server transcoding pipeline, it is only used to hint the tuner to use its own decoder or not. I think turning off hardware decoder globally could workaround this issue as the software decoder is more robust to streams from livetv where not everything is reliable. |
I turned off global hardware transcoding to test. It actually doesn't get as far with HW transcoding turned off, it just hangs:
|
Do you have something with faster cpu to tests with? Trying hevc decoding with CPU on N6005 is not fun and it might hang even for normal videos. If it still fails on a fast CPU the I don’t really know what to do if even ffmpeg cannot understand the stream from the tuner. |
This comment has been minimized.
This comment has been minimized.
If you are not using HDHomeRun Flex 4k you are not having “similar” issue. Also blindly choosing methods won’t help. It looks like you are very unfamiliar with hardware acceleration setup so I suggest you to ask in our forum or the matrix channel for help. |
Ok, I used a more powerful machine running windows. I tried both qsv using an intel arc 770 and using software decoding on an i9, both resulted in this ffmpeg result:
And here's the jellyfin log:
|
Can you go to your transcode cache folder, first clean that folder and do the attempt to open this channel and wait for a few seconds, like 10 seconds or so. There should be a ts file inside. If there are multiple, there should be one significantly larger. That one is the base stream directly copied from your tuner. Can you share that sample so that I can validate it on my end? I have a bad feeling about those ATSC 3.0 which might share a common problem that the encoder they are using might not be spec compliant which means the standard decoder could be unable to decode those streams. Similar issue was reported to ffmpeg before regarding ATSC 3.0 steams: https://trac.ffmpeg.org/ticket/9034, but that was closed as won’t fix because that stream even crashes the reference decoder. |
Here's the file. And here's the ffmpeg log:
|
The interesting part is that the file you are sharing is decodable by using almost the same cli but changes the file path:
But I do notice that with the default 1G probesize the stream might take very, very long time to begin and that could be the issue (the client timeouts before the playback can actually start). For this specific stream a probe size of 1M is enough. Can you try setting env var |
That did the trick! Thanks! For future reference, I added "JELLYFIN_FFMPEG__PROBESIZE=1M" to /etc/default/jellyfin on ubuntu as a jellyfin environment variable. I also didn't disable HW decoding. Here's the ffmpeg log:
|
Can you do me one more favor? So for a lot of streams 1M would be too low and ffmpeg may not output audio if that size is only 1M. 10M is a safer default value, can you verify if that works for your stream as well? If so I may use that value as the new livetv default |
When trying to decode HEVC (I think without the correct bitstream from this reddit post), ffmpeg fails to start encoding. This is any HEVC ATSC 3.0 Channels using the HDHomeRun Flex 4k by silicon dust (network tuner).
Steps To Reproduce
Expected Behavior
HEVC live streams can be decoded and encoded using ffmpeg.
System (please complete the following information):
Ubuntu 24.04.1 LTS (GNU/Linux 6.8.0-48-generic x86_64)
Server version 10.10.4
Web version 10.10.4
Build version 10.10.4
Hardware Acceleration: QSV
CPU & GPU Model: Intel N6005
MediaInfo
FFmpeg Logs
Additional Context
I tried turning off HW acceleration and there was no difference in logs or behavior.
The text was updated successfully, but these errors were encountered: