-
Notifications
You must be signed in to change notification settings - Fork 103
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
[QA] How does it work & Capabilities (moved to Wiki section) #88
Comments
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 1You 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 interfaceIn this case, the web interface calls the VideoStation's API ( These HLS slices are generated (transcoding) in the (I agree, this webapp is very unstable) Case 2 : using DS Video app on Android/iOSThis 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 TVThis case is a bit different. 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 2The 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. |
Question 3Yes, 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. 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). Everything else is just summarized to:
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.
Yes, Samsung is not paying for licensed audio codecs. |
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
<#88 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKGRV47JXXJ6WYUS34JAKI3XWZCWDANCNFSM6AAAAAA33UHV4U>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
I think I understood my issue : I had installed ffmpeg6 (I don't know why, just because this is the latest release).
================ ISSUE REPORT TOOL ================ System Details..................................... Package Details.................................... Patch Details...................................... CodecPack target/bin content: CodecPack target/pack/bin content: CodecPack status: GSTInspect last stderr logs......................... GSTInspect last stderr.prev logs......................... GSTLaunch last stderr logs......................... GSTLaunch last stderr.prev logs.........................
================ ISSUE REPORT TOOL ================ System Details..................................... Package Details.................................... Patch Details...................................... CodecPack target/bin content: CodecPack target/pack/bin content: CodecPack status: GSTInspect last stderr logs......................... GSTInspect last stderr.prev logs......................... GSTLaunch last stderr logs......................... GSTLaunch last stderr.prev logs......................... |
Aah no, this one is just an issue from the issue-report.sh, I'll fix it, if the patcher let you patch with What issue are you facing ? |
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. |
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" |
Yes, you forgot the |
I'm moving this issue to the Wiki section: https://github.com/AlexPresso/VideoStation-FFMPEG-Patcher/wiki/FAQ |
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 :
From the DSM point of view, are these configurations working in the same way ?
Finaly I wonder what we are changing with the patch and how should we test it ?
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 ?
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 ?
thanks for your time :)
Henri
The text was updated successfully, but these errors were encountered: