Universal Media Server | Forum

OK I am stumped. Since all those work when streaming and from the USB then UMS is sending them correctly.
I tested your video on my TV and it does stream and play normally. Even though it is an old Samsung is should work the same way as yours.

I'll have a think about other options to try and do a bit of research as I don't see why those videos are not working.

I did make an issue about adding the level as a parameter in supported formats but I would not expect any work to be done on this for a while.

One thing that looks odd is I am still seeing Engine "FFmpeg Video" is incompatible before the decision is made whether to transcode or stream.
This should have no effect if the video is streaming as it will not need to use FFmpeg, but maybe this is causing UMS to send the wrong info to the TV.
However the jellyfish videos work just fine when streaming so is probably not it.

Could you try what I suggested in the second post again to set the profile to just Since part of the problem was the FFmpeg path.

Re: Could you try what I suggested in the second post again to set the profile to just
Ans: Ran again with the updated renderer file. Log file is attached.
I also just noticed something "different" about this video file. According to the MediaInfo utility, the "covr" metadata shows "Unknown kind of value!".
Not sure if this could impact things...

That did answer one question about Engine "FFmpeg Video" is incompatible as it does not show when there is only the one transcoding profile.

What I think this is doing is saying favour FFmpeg HLS Video over FFmpeg Video, just that is is not even looking at FFmpeg Video for checking compatibility so says it is not.
I guess this could have been worded differently.
However it had no effect on streaming so the problem is with those videos themselves.

There were some things in the media info that I was unfamiliar with and the covr field was one.
I looked up what all the fields mean and this one does not exist, but there is a cover field so maybe this was a typo when the video was encoded.
That would explain the "Unknown kind of value!" message.

The other thing was the codec ID being mp42 (mp42/isom/avc1)
This appears to mean "MPEG-4 Part 2" which would be part of the standard MP4 playback support but need to look more into this.
It might be your TV does not have support for part 2 as I see mention it is basically H.263 in a MP4 container, however one of the supported formats in the specs is H.263 Sorenson.

There is also a menu stream which I did not know was possible in MP4s. Maybe it is this that is causing it. I'll look into this a bit more and see if there is a way of changing the covr field or strip the menu stream for testing.

Re: There is also a menu stream which I did not know was possible in MP4s. Maybe it is this that is causing it.
Ans: I just ran a test on another video that is the same video format, etc. But it does not have the menu stream...and it works ok.
UMS doesn't like the menu stream.
Is there a way to get it to accept the menu stream? Or a simple way to remove the Menu stream from the video???

P.S. It appears that ffmpeg can programmatically remove the Menu stream from an .mp4 video file. I will update when I have more information.

Through much testing, I have discovered the following.
UMS/FFMpeg does not like/play videos with the Menu. I have used a utility called XXRECODE that can remove the menu and keep the underlying video/audio streams the same. After removing the Menu, the new file plays fine. I even have the ability to Fast-Forward and Rewind, which is not available when using the option to play (FFMPeg/HLS) via the #TRANSCODE# folder.
I have also used a utility called MKVTOOLNIX to remove the Menu, but also changes the format to .MKV. The new .MKV file also plays fine, also with the ability to Fast-Forward and Rewind.

The XXRECODE utility I used is here:
https://www.xmedia-recode.de/en/download-portable.php

The MKVTOOLNIX utility is here:
https://mkvtoolnix.download/downloads.html#windows

I don't know why UMS/FFMpeg doesn't like it, but I noticed FFPROBE.EXE of the file that has the menu and does not work shows...notice the last line.
VLC has no issues playing the video, but perhaps it is more forgiving of small errors.?.?
If we cannot figure out how to get UMS/FFMpeg to play these videos with Menus, I can always use either of these utilities to convert them so they can be played.
Let me know if you would like me to post the log file for any of these videos.
-------------
[mov,mp4,m4a,3gp,3g2,mj2 @ 000001c47a546240] UDTA parsing failed retrying raw
[mov,mp4,m4a,3gp,3g2,mj2 @ 000001c47a546240] stream 0, timescale not set
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'A Charlie Brown Christmas (1965).mp4':
Metadata:
major_brand : mp42
minor_version : 0
compatible_brands: mp42isomavc1
creation_time : 2016-06-08T21:03:26.000000Z
title : 2
artist :
album : PEANUTS_1960_COLLECTION_DISC_1
comment :
encoder : DVDFab 9.2.4.4
Duration: 00:25:28.30, start: 0.000000, bitrate: 1754 kb/s
Chapters:
Chapter #0:0: start 0.000000, end 133.466625
Metadata:
title : Chapter 1
Chapter #0:1: start 133.466625, end 506.505958
Metadata:
title : Chapter 2
Chapter #0:2: start 506.505958, end 1035.284208
Metadata:
title : Chapter 3
Chapter #0:3: start 1035.284208, end 1376.833708
Metadata:
title : Chapter 4
Chapter #0:4: start 1376.833708, end 1525.815875
Metadata:
title : Chapter 5
Chapter #0:5: start 1525.815875, end 1527.817875
Metadata:
title : Chapter 6
Stream #0:0[0x1](und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(smpte170m/smpte170m/bt709, progressive), 640x480 [SAR 1:1 DAR 4:3], 1618 kb/s, 23.98 fps, 23.98 tbr, 24k tbn (default)
Metadata:
creation_time : 2016-06-08T21:03:26.000000Z
encoder : JVT/AVC Coding
Stream #0:1[0x2](eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, mono, fltp, 128 kb/s (default)
Metadata:
creation_time : 2016-06-08T21:03:26.000000Z
name : English (aac mono)
Stream #0:2[0x3](und): Data: bin_data (text / 0x74786574)
Metadata:
creation_time : 2016-06-08T21:03:26.000000Z
Stream #0:3[0x0]: Video: bmp, bgra, 640x480, 90k tbr, 90k tbn (attached pic)
Unsupported codec with id 98314 for input stream 2

The TV itself can play them from USB and I can stream these to my TV so maybe your TV just cannot play them over the network?

I have been trying a way to remove these menu streams without altering the audio and video to try and narrow down the problem to them.
I think in those videos the menu stream is actually the chapters.
I also wanted to fix that misspelled covr tag and I think I have found a way without altering anything else.

I have uploaded some videos for you to test, I'll PM you the link
I opened the video in a MP3 tag editing program (Mp3tag) which also does MP4 tags. All I did was click save for the tags to be rewritten, I did not touch anything else.
The video had an embedded bmp picture file which is the thumbnail but was appearing as a separate resource.
Saving the tags puts it in the right place and replaces covr with cover and the value yes
I used FFmpeg to strip the thumbnail data and metadata but not sure it worked. It is still showing the menu stream but now there are 2. Maybe this has fixed some corruption?
The BMP picture is still there as it is not seen as a thumbnail I think.
This strips the chapter data which removes the menu streams so this suggests that is what it is.
It does leave another stream #3 which could be the BMP or something else I did not see this in other tests
It does say GoPro which is obviously incorrect so could be junk data. I don't know how to get rid of it though
This may be the same junk as appeared in your tests that said Unsupported codec as "98314" is not a codec. Using FFmpeg only took a second for me as it is just copying the steams and rebuilding the MP4 container.

Give these a try both from USB and streaming from UMS and hopefully one will work.


Using MKVtoolnix was something else I was looking at but will convert them into MKVs and I wanted to find exactly what in those MP4s that is not compatible first.

As it can copy the streams and not re-encode them it would take seconds to work and the container should be organised properly and preserve all the metadata.
It is certainly an option if non of the test videos work.

Re: Give these a try both from USB and streaming from UMS and hopefully one will work.
Ans: All three videos work fine from the USB thumb drive.
When streaming from UMS, I got the following results:
CharlieTest-noChapters.mp4 works (FF and Rewind functions as well)
CharlieTest-noMetaData_NoThumbnail.mp4 works (FF and Rewind functions as well)
CharlieTest-fix_covr_tag.mp4 does NOT work at all. Video does not play.
Log file attached.

OK I think that confirms it is not the covr tag but menu stream that is the problem, and rebuilding the MP4 container does fix it.

I don't see any way UMS could detect these videos to automatically transcode so you would have to do a manual repair.

I found a way to do them in a batch by dragging and dropping them onto a bat file.

The forum won't allow me to attach a bat file but you can make it in a text editor and paste this. Then save it as a .bat file. I think it needs to be in the same folder as the videos otherwise the fixed videos will appear in the location of the bat file.
You can drag and drop many videos onto this file and it will convert them all at once.
It will append "_fixed.mp4" to the filename so won't overwrite your existing videos.
If you want to change this make sure you keep the %%~ni part as that will be replaced with the original filename minus the extension.

Excellent. I will make the change. Luckily, I do not have many videos like this.
Thank you for all your efforts. It is much appreciated.

P.S. It appears I have to drag/drop the file, as you mentioned. If I just try and run it from the current directory, it does not work.
Thanks again.