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.05k stars 100 forks source link

[QA] How does it work & Capabilities (moved to Wiki section) #88

Closed henriguillemot closed 1 year ago

henriguillemot commented 1 year ago

This page moved to the FAQ Section : https://github.com/AlexPresso/VideoStation-FFMPEG-Patcher/wiki/FAQ

Hello A good idea this patch. I don't know very well how VideoStation works, so I have several questions : 1) VideoStation works on different configurations :

thanks for your time :)

Henri

AlexPresso commented 1 year ago

Hello :)

I'll do my best to answer your questions, maybe you will already know some stuff I will talk about here, but I'll say it anyway in case someone else also wants to understand the process:

Question 1

You are correct, VideoStation behaves (a little bit) different based on the platform you are playing your movie on and also your NAS model.

Case 1 : using web interface

In this case, the web interface calls the VideoStation's API (entry.cgi) asking it to generate HLS slices of your movie, using ffmpeg (and/or gstreamer depending on your NAS architecture). If the video has HEVC codec or AAC codec, VideoStation will use the CodecPack (also known as Advanced Media Extensions) ffmpeg/gstreamer. In other cases, it will use its embedded ffmpeg/gstreamer (packaged with VideoStation).

These HLS slices are generated (transcoding) in the /tmp/VideoStation/HLS/<playback id> and listed into a "playlist" (m3u8 file) which the client uses to "download" the video slices and play it on the client side.

(I agree, this webapp is very unstable)

Case 2 : using DS Video app on Android/iOS

This case is pretty similar to the Webapp case (API and HLS playlist/slices), because it's working through HTTP/s but if possible, it's always using the CodecPack ffmpeg/gstreamer version.

Case 3: using DS Video app on Smart TV

This case is a bit different. If you're trying to connect to a remote NAS (not on local network), it will behaves the same as "case 2", and transport everything using HTTP/s (HLS playlist/slices).

But if you're playing a video having the NAS on your local network, the DS Video app uses the client hardware (your Samsung TV) to transcode the movie. I'm not sure about how the video bytes are sent to the TV yet, but after watching the NAS active processes, I suspect it's downloaded either using HTTP range requests or directly streamed over WebSocket connection.

Question 2

The ffmpeg process is spawned by VideoStation just after probing (ffprobe) the video metadata and deciding "which ffmpeg to use" (the VideoStation's embedded one, or the CodecPack's one). It's working by transcoding the original video and saving the transcoded video bytes into HLS slices, ffmpeg continues to process slices until it processed the whole video or until it gets killed by VideoStation (i.e. if you stop watching the movie).

This transcoding process is (in many cases) seamless, but it's possible to face "buffer time" (the loading circle) if ffmpeg is too slow to generate the next HLS slice, that your client wants to play.

AlexPresso commented 1 year ago

Question 3

Yes, in many cases altering dynamic libraries can lead to unexpected behavior but fortunately, in this case the patch is only altering a dynamic library that VideoStation is the only one to use and we're only changing a tiny part of it:

To give a little bit of context, DTS, TrueHD and EAC3 are licensed audio codecs. Synology doesn't want to pay for this license and also that's hard for them to track who is transcoding licensed audio codecs. So basically, they hard-coded a if condition, checking for these specific codecs and giving an error if the condition is verified.

This is pure VideoStation's software limitation, ffmpeg on its side is 100% capable of transcoding it.

The goal was to remove this condition to continue the process. BUT the problem is we can't add or remove code (there are ways to do it, like program hooking, trampoline but it's not needed in this case) because if we do this, we will change the pointers offsets and the app won't work anymore (once a binary is compiled, pointers offsets are hardcoded inside the binary). So the best way to break this condition was to replace the strings dts, eac3 and truehd by their invert (std, 3cae, dheurt). This way VideoStation cannot validate the if condition anymore and also the binary still has the exact same size and exact same pointer offsets (the strings are the same length so nothing changes).

Everything else is just summarized to:

VideoStation is supposed to act as passthrough when encountering DTS sound track (to be decoded by a home cinema for example) or is it processing the sound track to produce a 5.1 sound track for example ?

On the SmartTV app, VideoStation is not performing any transcoding if you're on local network, so, as far as I know, it's passthrough. But when playing from web browser (or chromecast), android app or SmartTV app remotely, VideoStation is doing transcoding and have a chance to lose 5.1 or 7.1 (I'm trying to find a way to fix it by tweaking the ffmpeg args sent by VideoStation).

Most of Samsung TV don't allow DTS format soundtrack, because they don't pay royalties I guess, is the TV VideoStation plugin substituing the TV sound processing ?

Yes, Samsung is not paying for licensed audio codecs. Unfortunately not, but you may have a chance using a patched DLNA (Media Server), but I have to check something before giving you a solution for this one, I'll get back to you.

henriguillemot commented 1 year ago

thank you so much for all these explanations i have a better understanding now

On Wed, Aug 23, 2023 at 8:20 PM AlexPresso @.***> wrote:

Question 3

Yes, in many cases altering dynamic libraries can lead to unexpected behavior but fortunately, in this case the patch is only altering a dynamic library that VideoStation is the only one to use and we're only changing a tiny part of it:

To give a little bit of context, DTS, TrueHD and EAC3 are licensed audio codecs. Synology doesn't want to pay for this license and also that's hard for them to track who is transcoding licensed audio codecs. So basically, they hard-coded a if condition, checking for these specific codecs and giving and error if the condition is validated.

This is pure VideoStation's software limitation, ffmpeg on its side is 100% capable of transcoding it.

The goal was to remove this condition to continue the process. BUT the problem is we can't add or remove code because if we do this, we will change the pointers offsets (once a binary is compiled, pointers offsets are hardcoded inside the binary). So the best way to break this condition was to replace the strings dts, eac3 and truehd by their invert (std, 3cae, dheurt). This way VideoStation cannot validate the if condition anymore and also the binary still has the exact same size and exact same pointer offsets (the strings are the same length so nothing changes).

Everything else is just summarized to:

  • Replace VideoStation ffmpeg by a shell script calling SynoCommunity ffmpeg (which has better support of every codecs and optimisations)
  • Make CodecPack ffmpegs point to shell script (SynoCommunity ffmpeg) inside VideoStation
  • (only if you have gstreamer) download missing libraries and plugins to transcode audio codecs
  • (only if you have gstreamer) make CodecPack gstreamer point to VideoStation gstreamer (now having plugins and libraries to transcode audio codecs).

VideoStation is supposed to act as passthrough when encountering DTS sound track (to be decoded by a home cinema for example) or is it processing the sound track to produce a 5.1 sound track for example ?

On the SmartTV app, VideoStation is not performing any transcoding if you're on local network, so, as far as I know, it's passthrough. But when playing from web browser (or chromecast), android app or SmartTV app remotely, VideoStation is doing transcoding and have a chance to lose 5.1 or 7.1 (I'm trying to find a way to fix it by tweaking the ffmpeg args sent by VideoStation).

Most of Samsung TV don't allow DTS format soundtrack, because they don't pay royalties I guess, is the TV VideoStation plugin substituing the TV sound processing ?

Yes, Samsung is not paying for licensed audio codecs. Unfortunately not, but you may have a chance using a patched DLNA (Media Server), but I have to check something before giving you a solution for this one, I'll get back to you.

— Reply to this email directly, view it on GitHub https://github.com/AlexPresso/VideoStation-FFMPEG-Patcher/issues/88#issuecomment-1690426235, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKGRV47JXXJ6WYUS34JAKI3XWZCWDANCNFSM6AAAAAA33UHV4U . You are receiving this because you authored the thread.Message ID: @.***>

henriguillemot commented 1 year ago

I think I understood my issue :

I had installed ffmpeg6 (I don't know why, just because this is the latest release). Unfortunately, this version seems to be not correctly reconized, I can see it by using issue-report.sh: 1) with ffmpeg V6 installed

================ ISSUE REPORT TOOL ================

System Details..................................... DSM Version: 6.2.4 25556-7 Arch details: Linux NasBrest 3.2.40 #25556 Tue Mar 21 22:24:07 CST 2023 armv7l GNU/Linux synology_armada370_414slim

Package Details.................................... VideoStation version: 2.5.1-1668 FFMPEG version: Not installed CodecPack version: 1.0.2-0039

Patch Details...................................... Is patched ? yes Has gstreamer ? no

CodecPack target/bin content: total 32 lrwxrwxrwx 1 root root 44 Aug 11 10:45 ffmpeg27 -> /var/packages/VideoStation/target/bin/ffmpeg lrwxrwxrwx 1 root root 44 Aug 11 10:45 ffmpeg33 -> /var/packages/VideoStation/target/bin/ffmpeg lrwxrwxrwx 1 CodecPack CodecPack 30 Apr 27 03:51 ffmpeg33-for-audio -> ../pack/bin/ffmpeg33-for-audio lrwxrwxrwx 1 CodecPack CodecPack 37 Apr 27 03:51 ffmpeg33-for-surveillance -> ../pack/bin/ffmpeg33-for-surveillance -rwxr-xr-x 1 CodecPack CodecPack 29229 Apr 27 03:51 synocodectool

CodecPack target/pack/bin content: total 864 lrwxrwxrwx 1 root root 44 Aug 18 11:09 ffmpeg27 -> /var/packages/VideoStation/target/bin/ffmpeg -rwxr-xr-x 1 root root 203808 Jan 13 2023 ffmpeg27.orig lrwxrwxrwx 1 root root 44 Aug 18 11:09 ffmpeg33 -> /var/packages/VideoStation/target/bin/ffmpeg -rwxr-xr-x 1 root root 224432 Jan 13 2023 ffmpeg33-for-audio -rwxr-xr-x 1 root root 224424 Jan 13 2023 ffmpeg33-for-surveillance -rwxr-xr-x 1 root root 228544 Jan 13 2023 ffmpeg33.orig

CodecPack status: file not exists

GSTInspect last stderr logs.........................

GSTInspect last stderr.prev logs.........................

GSTLaunch last stderr logs.........................

GSTLaunch last stderr.prev logs.........................

2) with ffmpeg V4 installed:

================ ISSUE REPORT TOOL ================

System Details..................................... DSM Version: 6.2.4 25556-7 Arch details: Linux NasBrest 3.2.40 #25556 Tue Mar 21 22:24:07 CST 2023 armv7l GNU/Linux synology_armada370_414slim

Package Details.................................... VideoStation version: 2.5.1-1668 FFMPEG version: 4.4.4-49 CodecPack version: 1.0.2-0039

Patch Details...................................... Is patched ? yes Has gstreamer ? no

CodecPack target/bin content: total 32 lrwxrwxrwx 1 root root 44 Aug 11 10:45 ffmpeg27 -> /var/packages/VideoStation/target/bin/ffmpeg lrwxrwxrwx 1 root root 44 Aug 11 10:45 ffmpeg33 -> /var/packages/VideoStation/target/bin/ffmpeg lrwxrwxrwx 1 CodecPack CodecPack 30 Apr 27 03:51 ffmpeg33-for-audio -> ../pack/bin/ffmpeg33-for-audio lrwxrwxrwx 1 CodecPack CodecPack 37 Apr 27 03:51 ffmpeg33-for-surveillance -> ../pack/bin/ffmpeg33-for-surveillance -rwxr-xr-x 1 CodecPack CodecPack 29229 Apr 27 03:51 synocodectool

CodecPack target/pack/bin content: total 864 lrwxrwxrwx 1 root root 44 Aug 24 10:51 ffmpeg27 -> /var/packages/VideoStation/target/bin/ffmpeg -rwxr-xr-x 1 root root 203808 Jan 13 2023 ffmpeg27.orig lrwxrwxrwx 1 root root 44 Aug 24 10:51 ffmpeg33 -> /var/packages/VideoStation/target/bin/ffmpeg -rwxr-xr-x 1 root root 224432 Jan 13 2023 ffmpeg33-for-audio -rwxr-xr-x 1 root root 224424 Jan 13 2023 ffmpeg33-for-surveillance -rwxr-xr-x 1 root root 228544 Jan 13 2023 ffmpeg33.orig

CodecPack status: file not exists

GSTInspect last stderr logs.........................

GSTInspect last stderr.prev logs.........................

GSTLaunch last stderr logs.........................

GSTLaunch last stderr.prev logs.........................

AlexPresso commented 1 year ago

Aah no, this one is just an issue from the issue-report.sh, I'll fix it, if the patcher let you patch with -v 6 (to choose ffmpeg6), everything is patched correctly.

What issue are you facing ?

dbalcar commented 1 year ago

Question 3

[...]

Yeah I am seeing the same thing even on newer Samsung TV's that any video with DTS it will not play the audio even with the patch. I was hoping to find a solution to this.

AlexPresso commented 1 year ago

It's because the samsung TV is not supporting DTS and there's no transcoding on the NAS

dbalcar commented 1 year ago

It's because the samsung TV is not supporting DTS and there's no transcoding on the NAS

Thanks,

Oh I am running this cmd but the unpatch is not running, syntax issue? "curl https://raw.githubusercontent.com/AlexPresso/VideoStation-FFMPEG-Patcher/main/patcher.sh | bash -s -a unpatch"

AlexPresso commented 1 year ago

Yes, you forgot the --, it's verry important: curl https://raw.githubusercontent.com/AlexPresso/VideoStation-FFMPEG-Patcher/main/patcher.sh | bash -s -- -a unpatch

AlexPresso commented 1 year ago

I'm moving this issue to the Wiki section: https://github.com/AlexPresso/VideoStation-FFMPEG-Patcher/wiki/FAQ Please open another issue for any other questions