search

AlexPresso / VideoStation-FFMPEG-Patcher

Patcher to enable DTS, EAC3 and TrueHD transcoding support to Synology VideoStation (from DSM 6.2 to DSM 7.0 and above ; ffmpeg4, 5, 6, 7 ready)
1.06k stars 102 forks source link

[BUG] HEVC still doesn't play #74

Closed ner00 closed 1 year ago

ner00 commented 1 year ago

Before going any further, I should clarify that I'm using DSM 7 in a PC, not an actual Synology NAS - this patches the system to boot as if it was a DS920+ Intel Gemini Lake but actually it's an Intel i5 4590. The only thing I'm not positive on is if by needing AME I also need an actual Synology account and a license or if maybe the issue is hardware-related.

I've followed the first steps:

System details

Describe the bug HEVC videos do not play (tried with AAC, OPUS and EAC3 audio)

ffmpeg.log (containing the ffmpeg-wrapper execution logs)

The playback never starts, so I assume this is the reason for no log file; I had log files there but deleted them to start with a fresh log, but no log file gets produced when attmpting to load HEVC files, although it does generate a log file when playing valid videos like H264 encoded ones.

ffmpeg-xxxx.stderr (containing chunks transcoding operations)

Same as above, no error log file gets produced since no playback occurs.

gstreamer.log (containing the ffmpeg-wrapper execution logs)

No gstreamer log exists inside /tmp

gstlaunch-xxxx.stderr (containing chunks transcoding operations)

Same as above, no error log file gets produced, probably because no playback occurs.

AlexPresso commented 1 year ago

Hi @ner00

Could you try the following commands please, I was doing some tests and forgot to remove the limitation to ARMv8 CPUs:

  1. curl https://raw.githubusercontent.com/AlexPresso/VideoStation-FFMPEG-Patcher/fix_gstreamer/patcher.sh | bash -s -- -a unpatch
  2. curl https://raw.githubusercontent.com/AlexPresso/VideoStation-FFMPEG-Patcher/fix_gstreamer/patcher.sh | bash -s -- -a patch
ner00 commented 1 year ago

Thanks for the reply @AlexPresso , but unfortunately that didn't seem to help.

Although, why would an ARMv8 CPU limitation influence the behavior of the wrapper with a x86_64 CPU?

AlexPresso commented 1 year ago

Could you please provide:

Although, why would an ARMv8 CPU limitation influence the behavior of the wrapper with a x86_64 CPU?

There is no direct influence but I was not sure if the GSTOmx library was always present on every architectures

AlexPresso commented 1 year ago

The cache clearing step was incorrect, please also try to unpatch/repatch using previous commands

ner00 commented 1 year ago

No luck... although gst-inspect-1.0.orig wasn't found :/

root@ner0-NAS:/# curl https://raw.githubusercontent.com/AlexPresso/VideoStation-FFMPEG-Patcher/fix_gstreamer/patcher.sh | bash -s -- -a unpatch
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  7710  100  7710    0     0  18502      0 --:--:-- --:--:-- --:--:-- 18533
[2023-07-23 22:58:06] [INFO] ffmpeg-patcher v2.0
[2023-07-23 22:58:07] [Message of the day]

The patcher now supports every scenarios including gstreamer (credits to @nap-liu).

As always, please let me know of any issue you could have.

[2023-07-23 22:58:07] [INFO] You're running DSM 7.2 64570-1
[2023-07-23 22:58:07] [INFO] ====== Unpatch procedure ======
[2023-07-23 22:58:07] [INFO] Restoring libsynovte.so
[2023-07-23 22:58:07] [INFO] Restoring VideoStation's /var/packages/VideoStation/target/bin/ffmpeg.orig
[2023-07-23 22:58:07] [INFO] Restarting VideoStation...
restart package [VideoStation] successfully

[2023-07-23 22:58:17] [INFO] unpatch complete
root@ner0-NAS:/# curl https://raw.githubusercontent.com/AlexPresso/VideoStation-FFMPEG-Patcher/fix_gstreamer/patcher.sh | bash -s -- -a patch
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  7710  100  7710    0     0  38353      0 --:--:-- --:--:-- --:--:-- 38550
[2023-07-23 23:00:06] [INFO] ffmpeg-patcher v2.0
[2023-07-23 23:00:07] [Message of the day]

The patcher now supports every scenarios including gstreamer (credits to @nap-liu).

As always, please let me know of any issue you could have.

[2023-07-23 23:00:07] [INFO] You're running DSM 7.2 64570-1
[2023-07-23 23:00:07] [INFO] ====== Patching procedure (branch: main) ======
[2023-07-23 23:00:07] [INFO] Saving current ffmpeg as ffmpeg.orig
[2023-07-23 23:00:07] [INFO] Downloading and installing ffmpeg's wrapper...
[2023-07-23 23:00:08] [INFO] Setting ffmpeg version to: ffmpeg
[2023-07-23 23:00:08] [INFO] Saving current libsynovte.so as libsynovte.so.orig
[2023-07-23 23:00:08] [INFO] Enabling eac3, dts and truehd
[2023-07-23 23:00:08] [INFO] Restarting VideoStation...
restart package [VideoStation] successfully

[2023-07-23 23:00:18] [INFO] Done patching, you can now enjoy your movies ;) (please add a star to the repo if it worked for you)
root@ner0-NAS:/# /var/packages/VideoStation/target/bin/gst-inspect-1.0.orig | grep -E 'dts|eac3|truehd|h265'
-ash: /var/packages/VideoStation/target/bin/gst-inspect-1.0.orig: No such file or directory
AlexPresso commented 1 year ago

Hmm, the issue is that the patcher is not downloading the gstreamer files at all Do you have the following file :

ner00 commented 1 year ago

Do you have the following file :

* `/var/packages/VideoStation/target/bin/gst-launch-1.0` ?

No, also says not found.

AME is installed, but not signed-in as I mentioned.

image

AlexPresso commented 1 year ago

okay 🤔 what about /var/packages/CodecPack/target/pack/bin/gst-launch-1.0 ?

ner00 commented 1 year ago

Negative!

root@ner0-NAS:/# ls /var/packages/CodecPack/target/bin
ffmpeg33-for-audio  ffmpeg33-for-surveillance  ffmpeg41  synocodectool
AlexPresso commented 1 year ago

Okay, so my assumptions were correct, gstreamer/GSTOmx seems to only be present on ARMv8 CPUs.

the content of CodecPack you posted is after patch or "unpatched" ? I'm asking because ffmpeg41 should be copied to ffmpeg41.orig after patch

AlexPresso commented 1 year ago

But anyway, AME is the one providing HEVC support, so you will need to inject a licence to bypass the synology account (I'm on phone right now, but there are tools to do it)

I could add it in the wrapper in a future release

ner00 commented 1 year ago

the content of CodecPack you posted is after patch or "unpatched" ? I'm asking because ffmpeg41 should be copied to ffmpeg41.orig after patch

This is after patch, there is no *.orig even in this folder, although the patcher says Saving current ffmpeg as ffmpeg.orig; it doesn't mention ffmpeg41 or ffmpeg41.orig

AlexPresso commented 1 year ago

That's very strange behavior, the patcher is looping over ffmpeg files in AME to create symlinks

ner00 commented 1 year ago

But anyway, AME is the one providing HEVC support, so you will need to inject a licence to bypass the synology account

Oh, in that case then it would never work lol I need to try to find how this is done.

AlexPresso commented 1 year ago

I'll send a link tomorrow

ner00 commented 1 year ago

Some progress on this front, I found a patch for AME, namely a python script named amepatch.py which happens to be compatible with the latest AME version. This patch seems to work in order to enable HEVC support in AME and now playback works, but then I have an issue with CPU usage...

ffmpeg immediately starts gobbling 80%-90% of CPU time to decode the video, reaching 99% in a few minutes. I guess there's no HW acceleration so it ends up using the only thing it can and that's basic SW decoding. Curiously, a new ffmpeg process is spawned every time that I seek, so after 3 seeks I'll have 4 processes running, each using 25% of the CPU.

I assume this is essentially how it's supposed to work when HEVC has no HW decoding support, unless there are any other steps I could take to minimize the impact on CPU usage?

AlexPresso commented 1 year ago

Curiously, a new ffmpeg process is spawned every time that I seek, so after 3 seeks I'll have 4 processes running, each using 25% of the CPU

Yes this one is an issue in VideoStation's code, it's not killing the previous process when spawning a new one, I can try to make a "hack" for it, like writing the previous process PID in a file and kill it when a new process is spawned for the same file, but to make it work I need to find if the client is the same as the other process. Because if I can't do it, there's a chance two people trying to play the same file will kill each others process and... that's not good 😅

But there is something I don't understand here: Why the patcher didn't create a symlink to VideoStation's ffmpeg (once patched it's the SynoCommunity's ffmpeg)

AlexPresso commented 1 year ago

Aaaaah I know why, you gave me the content of [...]/target/bin but the .orig file is in [...]/target/pack/bin (notice the "pack") 😉

AlexPresso commented 1 year ago

My bad, the orphan processes were due to the shell script, by default, exiting a shell script doesn't kill child processes, I fixed it It will not change anything for HW transcoding but at least you'll not eat all your NAS resources when changing video time

ner00 commented 1 year ago

Yes this one is an issue in VideoStation's code, it's not killing the previous process when spawning a new one

I was about to say that this is incorrect given that, since AME license was a prerequisite, after patching that I could now play videos without your wrapper or community FFMPEG at all. And in that case there is no duplicate processes ever when seeking.

I might try some more later today, busy at the moment. I also need to get to the bottom of the lack of HW acceleration, but that's outside the scope of this wrapper.

ner00 commented 1 year ago

My bad, the orphan processes were due to the shell script, by default, exiting a shell script doesn't kill child processes, I fixed it It will not change anything for HW transcoding but at least you'll not eat all your NAS resources when changing video time

Okay, so this is fixed. Seeking no longer spawns a new ffmpeg process each time. I still can't get HEVC to play smoothly since the CPU keeps getting hammered doing SW decoding or maybe transcoding, I have no clue - anyway, that's off-topic.

By the way, did you have a different AME license patch in mind or was it the same as I mentioned above? The python script looks flimsy in that a new version of AME is probably going to disable the license.

Anyway, thanks for the hard work!

AlexPresso commented 1 year ago

Thanks for the feedback Yes I had the same tool in mind, that's the one used by many xpenology users as far as I know