Closed mreid-tt closed 4 years ago
@th0ma7 - I think even if you put in a new ffmpeg build you have to do the mod advised by neves-0 which removes the blacklisted codecs in LivSynoVTE "# remove "eac3" from blacklisted codecs in LibSynoVTE::ArgumentHelper::AbleToDecodeAudioByCodec() cp /var/packages/VideoStation/target/lib/libsynovte.so /var/packages/VideoStation/target/lib/libsynovte.so.old sed -i 's/eac3/ZXXZ/' /var/packages/VideoStation/target/lib/libsynovte.so”
Then the vid with VideoStation prohibited codec should go to the ffmpeg. If you don’t remove the libsynovte.so entry then no matter which ffmpeg version you put in there the library will prohibit it.
@th0ma7 - can I put the generic ffmpeg you posted on my Intel Atom C2538 DS1817+ ?
@EngMarc can you please email me
I am current playing H264 with DTS soundtrack
SecuritySense how do you do? Are you using old videostation?
@Yod4z DS918+ DSM 6.2.2-24922 Update 4 VideoStation 2.4.6-1594 th0ma7 ffmpeg_x64-6.1_4.2.1-14.spk
Have you commented out eac3 in libsynovte.so as per @EngMarc's comment above?
Do that first to check EAC3 is working. It should do as your DS916+ has a 64bit Intel Pentium N3710.
Currently playing HEVC 265 with 6 Channel DTS
From VideoStation
Have you done the samething for dts? In libsynovte
Yes.
DSM: 6.2.2-24922
VideoStation: 2.4.6-1594
FFMPEG: 4.2.1-15.spk
So move back to latest version of VideoStation and did the suggested hack. Note that it's important to keep the same amount of characters for each modifications as otherwise I wasn't able to login into videostation unless I would put the backup file back into place:
$ sudo sed -i'-BACKUP' -e 's/eac3/ZAAP/' -e 's/dts/ZAP/' -e 's/truehd/ZAPZAP/' /var/packages/VideoStation/target/lib/libsynovte.so
Gave it a shot but it looks like it's still using videostation's ffmpeg:
4569 root 20 0 123.9m 16.5m 98.0 0.1 0:05.12 R /var/packages/VideoStation/target/bin/ffmpeg -ss 0.000 -i /volume1/media/video/film/...
Am I missing something to in order to get SynoCommunuity ffmpeg to be used instead of videostation default?
Note: @EngMarc yes, default x64
package should be compatible with your NAS.
Tried sed -i 's/eac3/ZXXZ/' /var/packages/VideoStation/target/lib/libsynovte.so Eac3 no more error but looping. Maybe ffmpeg problem.
I commented out eacs and dts with sed: sed -i 's/eac3/ZXXZ/' /var/packages/VideoStation/target/lib/libsynovte.so sed -i 's/dts/ZXZ/' /var/packages/VideoStation/target/lib/libsynovte.so
ffmpeg in /var/packages/VideoStation/target/ffmpeg is the shell script created by:
mv /var/packages/VideoStation/target/bin/ffmpeg /var/packages/VideoStation/target/bin/ffmpeg.old
echo H4sIAMiai1wAA32SMU/DMBCF9/sVhxuhBhRMWatUXRgYEAOiS1VVbnJOrCaxFZsyAP+d2KlQUgU8WXf33vN98uyKH1TDD8KWADPKSo0sWjNcrZC72nApa0PFXaULANEWNp3H8FGqinC7xWiGSeHwHnc7yDVkwlKnXjBUDWB3krKye0t03DtVUxxqtlTShduomXpdKC+XvVZdztf6pAZz/jW36ZwlioXQeKi+iUczwzZZkUHvmuuGfrd+ftk8PWKKUciZJqAk8pNouRHZURRk+UblpF+dcEo33HVx5AJPKU2rD57G2e1hdb3ALyxaMsjeGvtujG4d5ZjpnDK2RFdSgNap03FG/4Cxu68AVZZgSGJE1FMZF+Jp/793CIvrKgepACw5TJLO9NPnbde7b3ZGF3XTU7j+/059d4py8PMy+AEpctu1ngIAAA==|base64 -d|gunzip > /var/packages/VideoStation/target/bin/ffmpeg
I also copied /var/packages/ffmpeg/target/bin/ffmpeg over the top of /bin/ffmpeg (after renaming it) just in case that had any effect.
EAC3 and DTS play fine with H264 and H265
@th0ma7 quick question, does your ffmpeg compile have the Synology Videostation extra command line argument ‘hls_seek_time’? If not, then will use neves-0 script technique to strip the command line argument. I think the ‘hls_seek_time’ adds the functionality of going back to the last time the video was played but not sure.
I tried that before with the 4.1 ffmpeg from the community forum but the video pic was black with good sound for a h.265 eac3 video. I reverted back after that check since I can work around by playing these vids on my iPad -> VLC.
@EngMarc can you please email me
not sure how to email you on here - I looked at your profile but it only had the hyperlink.
Never mind the cat is out of the bag now ;-)
I've found that VideoStation may do some checking of files when the service is restarted so be aware when editing libsynovte.so.
You may have to revert to the original then make the sed changes again.
@EngMarc yes my packages has all the synology patches ported to ffmpeg 4.2.1 with hls_seek_time
although after playing with the script it doesn't work so further investigation is needed on the patches side probably (and already having a clue as of why, new package may be upcoming shortly for that).
@SecuritySense the script was the missing part for me (150+ comments are hard to go through). thnx.
@kc6108 it did ported the latest version of synology patches but it didn't got enabled at compilation time. Will be looking into it but help from C coders in the thread appreciated.
Good news, I think I've nailed it!
Would require others to test things up before I can confirm submition of my patches to spksrc upstream. But my initial testing showed that this new ffmpeg build now handles -hls_seek_time
option (fixed a #define
) and should also enable other Synology optimizations as well.
Building of -16
in completed for a few archs. Following packages available for testing:
That is awesome news, thnx for the feedback @kc6108 ! Additional testers on other arch would be appreciated to confirm all is looking good.
It's insteresting to see that you where able to simple symlink the ffmpeg
file. I'm guessing you could also do the same with the ffprobe
as well to be consistent?
BTW, the following one liner does the backup & change for all 3x "eac3", "dts", and "truehd" :
$ sudo sed -i'-BACKUP' -e 's/eac3/ZAAP/' -e 's/dts/ZAP/' -e 's/truehd/ZAPZAP/' /var/packages/VideoStation/target/lib/libsynovte.so
tested on my 916+ with last version (-16) and with kc6108 ln method for ffmpeg and ffprobe working eac3, dts. Thanks guys good job
Just tested on my DS418 (aarch). When streaming inside the DS Video App on my Fire TV, DTS decoding works. When I try to play the same video in my browser, it just shows the loading spinner, but nothing happens. EDIT: Also works inside the DS Video iPhone app, but still no luck inside the browser (Safari 13). EDIT 2: TrueHD doesn't work. But Dolby Digital Plus (EAC3) does work.
good to know. @th0ma7 let me know when you get the Atom version compiled and I’ll test it on my DS1817+. I have a good mix of both eac3 and aac videos. I’ll have to see if I have any dts videos. Not sure but likely in my huge library. Let me know if you need anything and also if you’re compiling ffprobe or if community pkg is available to put in place with the -16 ffmpeg build you are working on currently. Marc
I test on my DS918+, it works well! I can play eac3, dst with the method of @kc6108 I link ffmpeg and ffprobe from ffmpeg pkg to VideoStation and change libsynovte.so. Tonight, I will test truehd. thanks
UPDATE: I tested and found that only part of the dst, eac3 and truehd can be played. Some videos will show http 405 error when playing. By the way, because I cannot find ffmpeg and video station log, I cannot determine the cause of the error. Can anyone tell me where the log save.
DS 918+ DSM: 6.2.2-24922 Update4 VideoStation: 2.4.6-1594 FFMPEG: 4.2.1-16 (ffmpeg_apollolake-6.1_4.2.1-16.spk)
@EngMarc if you using an Intel Atom then the x64 package should be good to go.
@873314461 if you want logging you will need to replace the VideoStation ffmpeg
with a script such as being advised earlier that you will have to modify accordingly to meet your need. Uncommenting the few logging lines should do the trick. Good luck!
Bare in mind that you are modifying a software behaviour (e.g. VideoStation). As such this solution might not work exactly as intended and help & support will be limited. In the best world it either requires changes from Synology to add greater flexibility to VideoStation or you to switch to an alternative solution (I'd personally recommend CIFS/NFS export volume with Kodi client but it may not meet everyone's need).
It is my understanding that the original issue is now solved, closing the bug. Again, thnx all for testing!
@kc6108 @th0ma7, I just tested with h265 videos and the -16 version of ffmpeg. It doesn't work with either of the two methods (symbolic link or wrapper script) This is a pity because with the symbolic link method there are no more problems with the multiplication of ffmpeg processes and the impossibility to progress in the video. However, with this version of ffmpeg, everything works fine with VideoStation version 2.3.4.
@th0ma7 - does the x64 pkg posted have the hls_seek_time #define enabled (you noted -16 as I recall)?
I was able to reproduce using a 1080p, AAC 5.1, h265 where it doesn't work with hevc file. I noticed it tried using vaapi so I'll dig in that direction.
As the issue specific to this bug entry is solved please report a different issue against this problem specifically so it can be tracked down individually. Thnx
BTW, noticed that in order to be using vaapi setuid must be set on the ffmpeg
binary as otherwise it cannot access the dri device file /dev/dri/renderD128
using the following:
$ sudo chmod u+s /var/packages/ffmpeg/target/bin/ffmpeg
i have no probleme with x265 video i have tried tu add sudo chmod u+s /var/packages/ffmpeg/target/bin/ffmpeg but see no change on cpu use. I noticed that videosation don't play the movie as original but higher quality
It's a 1080p x265, all x264 play at original but not the x265. I have to try another x265 movie
Has anyone managed to get any video with TrueHD or Atmos 7.1 playing (in either H264 or H265)?
Also had to revert back to -14 and the shell script as I was getting pixelation and artifacts in some of my videos.
With the -16 version the h265 10bit does not work. As soon as I have some time I will prepare samples to be able to test more easily. Concerning the evolution of the shell script, I would like to try it.
Ok, I tested on -14 -15 builds: the h265 10bit does not work. I tested the sed on main 10: No better
I did some more tests: the VideoStation ffmpeg works with h265 10bit so it can't come from libsynovte.so
.
I just think that the SynoCommunity's ffmpeg doesn't support this format or maybe not all the parameters passed by VideoStation for this format such as hls_seek_time
Here is the list of parameters used by VideoStation for my test:
-ss 0.000 -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -noautorotate -i /volumeUSB2/usbshare/Films/VID_H265_10bit_AC3.mkv -vcodec h264_vaapi -vf format=nv12|vaapi,hwupload,setsar=sar=1,scale_vaapi=w=1856:h=1072 -vsync 2 -bf 0 -vb 1360275 -acodec libmp3lame -ab 128K -ac 2 -f ssegment -pix_fmt yuv420p -segment_format mpegts -segment_list_type m3u8 -segment_time 5 -segment_time_delta 0.000 -segment_start_number 00000 -avoid_negative_ts 0 -break_non_keyframes 1 -max_muxing_queue_size 1024 -map 0:0 -map 0:1 /tmp/VideoStation/HLS/7fab9891cc911233ccea174478a72d6a_OAcbBaCF/slice-%05d.ts
Edit SynoCommunity's ffmpeg supports h265 10bit very well but maybe not via hardware acceleration. I'll try to remove the parameters that cause problems via the shell script.
Hi @BenjaminPoncet
Which shell script are you referring to when you say you are going to "remove the parameters that cause problems"?
New test -17
packages available at https://github.com/th0ma7/synology/tree/master/packages
I've ported @kref patches from https://github.com/kref/spksrc/commit/0b9f5d14e39ecc529409b33c953307f707971a36
Let me know if this helps and/or solve some of the problems found.
Still can't play any 10bit audio with 265 using -17 (I'm using the symlink method for ffmpeg and ffprobe).
I remuxed a 265 Atmos 7.1 to 264 Atmos 7.1 (using Handbrake and passthru for audio) and that plays OK.
New test
-17
packages available at https://github.com/th0ma7/synology/tree/master/packages I've ported @kref patches from kref@0b9f5d1 Let me know if this helps and/or solve some of the problems found.
I have tested package -17, it indeed fixed the DTS-HD MA issue.
The only thing left now is the H.265 issue, VideoStation will transcode it and if this could be fixed in SynoCommunity ffmpeg, it will be a perfect version.
Hi @chengleon would you happen to have a link to an example DTS-HD MA video that wouldn't play before and now plays as I still can't get my videos playing.
Still can't play any 10bit audio with 265 using -17
I wonder if a similar fix applied directly over x265 would do the trick... I'll investigate that for a bit.
Thanks @th0ma7
Thank you @th0ma7 for a great job, we are very close to perfection. @SecuritySense , I'm talking about the shell script method, it allows you to rewrite the ffmpeg transcoding parameters. So I tested the transcoding of my h265 10bit video with the default ffmpeg settings and it seems to work. I'm not done yet but there's a track to explore in addition to @th0ma7' work in order to have a more robust solution with a fail over.
Remuxed a 265 DTS-HD MA 7.1 CH to 264 DTS-HD MA 7.1 CH and it plays fine.
Hi @BenjaminPoncet
Are you able to share your shell script?
hint: maybie related to https://github.com/intel/media-driver/issues/204
Looking into updating VAAPI layer which would include that fix into -18
test packages to see if there may be a resolution in sight.
@SecuritySense , I haven't created a script yet, for the moment I'm testing with command lines. However, as soon as I have something that works, I'll share it here. But honestly, I think @th0ma7 is going to be faster than me...
I am currently not investing any time into the script thing, insuficient cycles to do that.
Still, I've created new packages -18
only for intel type architectures (apollolake
& x64
).
The new package set has the updated layer & tools related to VAAPI.
@SecuritySense please give it a shot and see if the h265 issue is finally solve.
@th0ma7 - when I get back in town Monday afternoon, I will do the link to my installed -18 pkg and test it. I have a lot of different videos so will be pretty diverse testing. Thank you very much for your diligence. We all are indebted to you and the group!
I have tested the generic x64 and apollolake x64 -18 and still have some videos that don't play.
An example being one with the filename containing UHD 2160p HDR DTS-HDMA.5.1 HEVC which shows in VideoStation as hevc dts.
I also had some strange playback issues. Some videos that play when using the Shell Script method do not play when using the symlink method.
The videos had the following in the name 2160p UHD HDR BluRay H265 10bit DD5.1 and were shown in VideoStation as hevc ac3.
@th0ma7 , same! No better with the h265 10bit. @SecuritySense , be careful with the shell script: it uses the SynoCommunity ffmpeg only when the VideoStation ffmpeg does not support the codec. So with the shell script a h265 10bit AC3 video works while with the symbolic link it doesn't work.
If it helps, here is the ffmpeg error return:
Input #0, matroska,webm, from '/volumeUSB2/usbshare/Films/VID_H265_10bit_AC3.mkv': Metadata: CREATION_TIME : 2019-12-19T20:28:19Z ENCODER : Lavf57.7.2 Duration: 00:02:00.04, start: 0.000000, bitrate: 453 kb/s Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt709), 1612x932 [SAR 1:1 DAR 403:233], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default) Stream #0:1(eng): Audio: ac3, 48000 Hz, stereo, fltp, 160 kb/s (default) Metadata: title : Stereo Stream mapping: Stream #0:0 -> #0:0 (hevc (native) -> h264 (h264_vaapi)) Stream #0:1 -> #0:1 (ac3 (native) -> mp3 (libmp3lame)) Press [q] to stop, [?] for help Incompatible pixel format 'yuv420p' for codec 'h264_vaapi', auto-selecting format 'vaapi_vld' [h264_vaapi @ 0x11554c0] No usable encoding profile found. Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [libmp3lame @ 0x1158780] 2 frames left in the queue on closing Conversion failed!
@th0ma7 , same! No better with the h265 10bit. @SecuritySense , be careful with the shell script: it uses the SynoCommunity ffmpeg only when the VideoStation ffmpeg does not support the codec. So with the shell script a h265 10bit AC3 video works while with the symbolic link it doesn't work.
If it helps, here is the ffmpeg error return:
Input #0, matroska,webm, from '/volumeUSB2/usbshare/Films/VID_H265_10bit_AC3.mkv': Metadata: CREATION_TIME : 2019-12-19T20:28:19Z ENCODER : Lavf57.7.2 Duration: 00:02:00.04, start: 0.000000, bitrate: 453 kb/s Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt709), 1612x932 [SAR 1:1 DAR 403:233], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default) Stream #0:1(eng): Audio: ac3, 48000 Hz, stereo, fltp, 160 kb/s (default) Metadata: title : Stereo Stream mapping: Stream #0:0 -> #0:0 (hevc (native) -> h264 (h264_vaapi)) Stream #0:1 -> #0:1 (ac3 (native) -> mp3 (libmp3lame)) Press [q] to stop, [?] for help Incompatible pixel format 'yuv420p' for codec 'h264_vaapi', auto-selecting format 'vaapi_vld' [h264_vaapi @ 0x11554c0] No usable encoding profile found. Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [libmp3lame @ 0x1158780] 2 frames left in the queue on closing Conversion failed!
See https://github.com/SynoCommunity/spksrc/issues/3688#issuecomment-484685507
TL;DR you'll have to pass -vf scale_vaapi=format=nv12
for that to work with VAAPI, but the video quality will be affected. Best workaround is to stick with ffmpeg 4.0.x builds for now. Thanks though for confirming that this issue is still not fixed in the 4.2.x branch.
For new Package Requests, see the guidelines
Setup
Package Name: FFmpeg _Package Version:_3.3.3-7
_NAS Model:_DS916+ _NAS Architecture:_Intel _DSM version:_6.1.3-15152 Update 6
Expected behavior
Playback of video with Dolby tracks in DS Video work without issue
Actual behavior
Playback error "failed to play the video because the file format of the currently selected audio track is not supported" (for EAC3).
Steps to reproduce
_1._Launch DS Video _2._Select video with EAC3 audio _3._Play
Package log
Check Package Center or
/usr/local/{package}/var/
Other logs (attempted a re-install)
E.g.
/var/log/messages
or/var/log/synopkg.log