Skip to content
Alex edited this page Oct 2, 2023 · 2 revisions

Is VideoStation's workflow different, based on the platform playing the video file ?

Yes, 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.

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.


When you launch a video, when ffmpeg is called, is it working in real time?

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.


I saw you patch directly dynamics libraries with sed, is it dangerous ? how is it working ?

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, using trampoline method, [...]) 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:

  • 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).

Video is playing in browser but not on my Samsung/LG/[...] TV, what should I do ?

Unfortunately, there's not much things we can do, the video is sent "RAW" to the TV and the TV is using its own ffmpeg version to transcode it. The wrapper is never called by your TV (because the transcoding is not occuring on the NAS) and then can't make it work.