Error decoding H265 over UMS

[Foul]

Here is the Trace log as requested :

ffmpegfs.log

test files : https://s3.amazonaws.com/x265.org/video/Tears_400_x265.mp4 https://s3.amazonaws.com/x265.org/video/Tractor_500kbps_x265.mp4

[nschlia]

2020-04-18 22:52:21 TRACE  : [/mnt/BACKUP/Video/Test/Tears_400_x265.mp4] getattr: File is marked as passthrough.
2020-04-18 22:52:21 TRACE  : [/mnt/BACKUP/Video/Test/Tractor_500kbps_x265.mp4] getattr: File is marked as passthrough.

These two lines mean that these files are not recoded. They simply show up as copies, still in H265.

You should add "--recodesame=YES" to the command line. In this case everything is recoded, even if already an MPEG-4 container.

[Foul]

a bit better... with my computer.. VLC is reading the files now.. it detect them as h264.. good... but still "video cannot be decoded" on my box... With do others test tomorrow... i suspect Universal Media Server doing a wrong job...

thx you :)

Le sam. 18 avr. 2020 à 23:15, Norbert Schlia notifications@github.com a écrit :

2020-04-18 22:52:21 TRACE : [/mnt/BACKUP/Video/Test/Tears_400_x265.mp4] getattr: File is marked as passthrough. 2020-04-18 22:52:21 TRACE : [/mnt/BACKUP/Video/Test/Tractor_500kbps_x265.mp4] getattr: File is marked as passthrough.

These two lines mean that these files are not recoded. They simply show up as copies, still in H265.

You should add "--recodesame=YES" to the command line. In this case everything is recoded, even if already an MPEG-4 container.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nschlia/ffmpegfs/issues/56#issuecomment-615950679, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGKTEWL7IIZQ5IDL7DR6Q3RNIJ55ANCNFSM4MLQBEYA .

[nschlia]

I guess I need to add a INFO level log entry that makes it clear that a playable file is passed through. The TRACE log would tell that e.g. readme.txt or coverart.png are treated as passthrough. but I think no one cares about that as this is the expected behaviour. It also shows that the MP4 files are passthrough, but that should be made more prominent. I'll change the level for these files from TRACE to INFO.

For the other problem, files not playable through Universal Media Server, this is probably due to the MP4 file flavour. Unfortunately there are several subtypes that do not work with every playback software.

The default profile creates a an MPEG-4 file level 3.1 high with faststart, empty MOOV and 1000 ms fragments (ffmpeg -profile:v high -level 3.1 -movflags +faststart+empty_moov -frag_duration 100000), maybe this is incompatible with Universal Media Server.

The profiles are defined in ffmpeg_profiles.cc, but you could simply try --profile=IE, this will create a profile high level 3.1 file without add-ons. Maybe Universal Server would like this.

If not I could install Universal Server here and try to figure the right settings out.

[nschlia]

I guess I need to add a INFO level log entry that makes it clear that a playable file is passed through

Changed the level to DEBUG as this message comes quite often, but also rephrased it:

2020-04-19 08:51:01 DEBUG  : [/home/norbert/test/in/Tractor_500kbps_x265.mp4] getattr: File not recoded because --recodesame=NO.
2020-04-19 08:51:01 DEBUG  : [/home/norbert/test/in/Tears_400_x265.mp4] getattr: File not recoded because --recodesame=NO.

This should be useful in case one wonders what happens :)

[Foul]

Hi!

Just re-tested but still "video not supported"

ffmpegfs -f --profile=IE --recodesame=YES --audiobitrate=256K --videobitrate=2M --videowidth=720 /mnt/BACKUP/Video/ /mnt/ffmpegfs -o allow_other,ro,d esttype=mp4 --log_maxlevel=TRACE --logfile=ffmpegfs.log

tested with ffmpeg and vlc decoder on Universal Media Server...

Le dim. 19 avr. 2020 à 08:54, Norbert Schlia notifications@github.com a écrit :

I guess I need to add a INFO level log entry that makes it clear that a playable file is passed through

Changed the level to DEBUG as this message comes quite often, but also rephrased it:

2020-04-19 08:51:01 DEBUG : [/home/norbert/test/in/Tractor_500kbps_x265.mp4] getattr: File not recoded because --recodesame=NO. 2020-04-19 08:51:01 DEBUG : [/home/norbert/test/in/Tears_400_x265.mp4] getattr: File not recoded because --recodesame=NO.

This should be useful in case one wonders what happens :)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nschlia/ffmpegfs/issues/56#issuecomment-616059071, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGKTEV5VMB6GDDKVYB7CUDRNKNYVANCNFSM4MLQBEYA .

[nschlia]

Just re-tested but still "video not supported" This comes from Universal Media Server?

There are two possible reasons:

1. UMS has problems with the way FFmpegfs creates files.
2. UMS needs a different MP4 flavour.

For 2: We already tried one out. Do you have an MP4 that you could successfully feed into UMS? Could you provide that to me? I could check which flavour it is and create a profile for that.

For 1: FFmpegfs files do not exist like disk files, they grow while the are transcoded. There is also another knick, it is not possible to open them with mmap (map the file into memory). This does not work because the end size of the file is not exactly known.

To find out if this is the problem:

Please copy the file e.g. to your home directory. Try out if UMS can open it from there.

If that works, unfortunately FFmpegs will not go together with UMS.

If that also does not work, please provide me an MP4 that works.

I'll install UMS here and check it out.

[Foul]

http://jell.yfish.us/media/jellyfish-3-mbps-hd-h264.mkv

the file is read with UMS on a single shared directory The file is NOT read with UMS on a ffmpegfs directory

Le ven. 24 avr. 2020 à 22:05, Norbert Schlia notifications@github.com a écrit :

Just re-tested but still "video not supported" This comes from Universal Media Server?

There are two possible reasons: UMS has problems with the way FFmpegfs creates files. UMS needs a different MP4 flavour.

For 2: We already tried one out. Do you have an MP4 that you could successfully feed into UMS? Could you provide that to me? I could check which flavour it is and create a profile for that.

For 1: FFmpegfs files do not exist like disk files, they grow while the are transcoded. There is also another knick, it is not possible to open them with mmap (map the file into memory). This does not work because the end size of the file is not exactly known.

To find out if this is the problem:

Please copy the file e.g. to your home directory. Try out if UMS can open it from there.

If that works, unfortunately FFmpegs will not go together with UMS.

If that also does not work, please provide me an MP4 that works.

I'll install UMS here and check it out.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nschlia/ffmpegfs/issues/56#issuecomment-619215671, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGKTEUWTQIHVKIO6HLJRO3ROHWKJANCNFSM4MLQBEYA .

[nschlia]

I've just installed UMS, I'll try to reproduce the issue here. Please stay tuned.

[Foul]

cool thank you for the work ;)

Le ven. 24 avr. 2020 à 23:01, Norbert Schlia notifications@github.com a écrit :

I've just installed UMS, I'll try to reproduce the issue here. Please stay tuned.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nschlia/ffmpegfs/issues/56#issuecomment-619237110, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGKTEUUCR5YD6FLZQJANS3ROH437ANCNFSM4MLQBEYA .

[nschlia]

I have created a H265 file, it plays well from FFmpegs over UMS in VLC. jellyfish-3-mbps-hd-h264.mkv does not play from FFmpegs over UMS in VLC.

Very strange... Another observation is that the file needs to be completely transcoded before it opens from UMS.

I guess I need to dig deeper into that. This will take awhile, please be patient.

[Foul]

i continue testing.. and surprise ! i found a H265 file it can decode ! without touching anything else ! attached to this mail... i think it can help you a bit ;)

Le ven. 24 avr. 2020 à 23:22, Norbert Schlia notifications@github.com a écrit :

I have created a H265 file, it plays well from FFmpegs over UMS in VLC. jellyfish-3-mbps-hd-h264.mkv does not play from FFmpegs over UMS in VLC.

Very strange... Another observation is that the file needs to be completely transcoded before it opens from UMS.

I guess I need to dig deeper into that. This will take awhile, please be patient.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nschlia/ffmpegfs/issues/56#issuecomment-619244526, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGKTERIWVQD56QYXRKLW2DROH7K7ANCNFSM4MLQBEYA .

[nschlia]

So far my testing revealed that UMS does not get by with files that are still in progress of transcoding.

To reproduce:

Create directories

mkdir ~/test/in
mkdir ~/test/out

Copy a video file to ~/test/in.

Start FFmpegfs:

ffmpegfs -f ~/test/in ~/test/out --log_stderr --log_maxlevel=DEBUG -o allow_other,desttype=mp4

Start UMS with ~/test/out as input path.

Now open that file via UMS, I used VLC for that. I can only see an thumbnail image of the video.

In FFmpeg's log I can see that the video is opened, transcoding starts, then it says "Client has gone away". I can repeat opening the video, same result: Just a thumbnail visible, "Client has gone away". FFmpegfs will stop transcoding after 15 seconds when I stop doing that. See log snipped below.

Then make FFmpegfs fully transcode the file by doing

cp ~/test/out/* /tmp/

Now the file can be opened in VLC via UMS.

The difference is, after the file has been transcoded once, it is provided from cache. This is not different as if the file was physically there.

This means that UMS is not compatible with the way FFmpegfs offers the files. I repeated the above with desttype WebM, same result.

2020-04-25 08:39:14 DEBUG  : [/home/norbert/test/out/Accept & Orchestra - Stalingrad (H265 AAC).ts] Opened video output codec H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 for stream #0.
2020-04-25 08:39:14 DEBUG  : [/home/norbert/test/out/Accept & Orchestra - Stalingrad (H265 AAC).ts] Deinterlacing initialised with filters 'yadif=mode=send_frame:parity=auto:deint=all'.
2020-04-25 08:39:14 DEBUG  : [/home/norbert/test/out/Accept & Orchestra - Stalingrad (H265 AAC).ts] Opened audio output codec AAC (Advanced Audio Coding) for stream #1.
2020-04-25 08:39:14 DEBUG  : [/home/norbert/test/out/Accept & Orchestra - Stalingrad (H265 AAC).ts] Audio out: aac@192.0 kbps 2 Channels 44.100 kHz [06:12.216]
2020-04-25 08:39:14 DEBUG  : [/home/norbert/test/out/Accept & Orchestra - Stalingrad (H265 AAC).ts] Video out: h264@1.04 Mbps [06:12.200]
2020-04-25 08:39:14 INFO   : [/home/norbert/test/cache/ffmpegfs//home/norbert/test/out//home/norbert/test/in/Accept & Orchestra - Stalingrad (H265 AAC).mp4.cache.ts] Opening cache file read/write.
2020-04-25 08:39:14 DEBUG  : [/home/norbert/test/out/Accept & Orchestra - Stalingrad (H265 AAC).ts] Pre-buffering up to 102400 bytes.
2020-04-25 08:39:14 WARNING: [mpegts @ 0x7fee7c05e780] Packets poorly interleaved, failed to avoid negative timestamp -5999 in stream 0.
Try -max_interleave_delta 0 as a possible workaround.
2020-04-25 08:39:14 WARNING: [mpegts @ 0x7fee7c05e780] Packets poorly interleaved, failed to avoid negative timestamp -2999 in stream 0.
Try -max_interleave_delta 0 as a possible workaround.
2020-04-25 08:39:14 DEBUG  : [/home/norbert/test/out/jellyfish-3-mbps-hd-h264.ts] Pre-buffer limit reached.
2020-04-25 08:39:14 DEBUG  : [/home/norbert/test/in/jellyfish-3-mbps-hd-h264.mkv] Decoder thread is running.
2020-04-25 08:39:14 DEBUG  : [/home/norbert/test/out/Accept & Orchestra - Stalingrad (H265 AAC).ts] Pre-buffer limit reached.
2020-04-25 08:39:14 DEBUG  : [/home/norbert/test/in/Accept & Orchestra - Stalingrad (H265 AAC).mp4] Decoder thread is running.
2020-04-25 08:39:23 INFO   : [/home/norbert/test/out/jellyfish-3-mbps-hd-h264.ts] Client has gone away.
2020-04-25 08:39:23 INFO   : [/home/norbert/test/out/Accept & Orchestra - Stalingrad (H265 AAC).ts] Client has gone away.
2020-04-25 08:39:37 INFO   : [/home/norbert/test/out/Accept & Orchestra - Stalingrad (H265 AAC).ts] Client has gone away.
2020-04-25 08:39:39 INFO   : [/home/norbert/test/out/Accept & Orchestra - Stalingrad (H265 AAC).ts] Client has gone away.
2020-04-25 08:39:39 INFO   : [/home/norbert/test/out/Accept & Orchestra - Stalingrad (H265 AAC).ts] Client has gone away.
2020-04-25 08:39:40 INFO   : [/home/norbert/test/out/jellyfish-3-mbps-hd-h264.ts] Client has gone away.
2020-04-25 08:39:40 INFO   : [/home/norbert/test/out/jellyfish-3-mbps-hd-h264.ts] Client has gone away.

[nschlia]

Another strange thing: The jellyfish video you provided also does not play from UMS when transcoded to WebM. Seems UMS does not like the transcoded file, no matter if it is in MP4 or WebM format...

One question: It seems that UMS can take H265 as input by itself, I sucessfully viewed H265 files thorugh it, what is the reason why you feed the files through FFmpegfs first? UMS can probably handle the files by itself, I suppose it also uses FFmpeg API internally.

[nschlia]

Download location: https://www.universalmediaserver.com/

[nschlia]

Retested with ums-9.8.3, all demo videos play without issue. Whatever the reason for the problem was, it's gone.

I suggest using the files directly, not through FFmpegfs. UMS can transcode a multitude of formats, probably as many as FFmpeg and double transcoding does not really make sense.

Can be closed.