Whenever we try to play a video with the following properties: Primary color: ITU-R BT.601. UE crash. This is independent of the resolution, but by standard, videos with width resolutions lower than 1280 use this parameter.
Unfortunately, we can’t re-encode the videos to use anothe color primaries auch as BT.709 because they weren’t generated by our application.
What options do we have to avoid the crash and play these kind of videos without problems?
regards.
Steps to Reproduce
Try to reproduce a video on Editor/Runtime with the Color primaries: ITU-R BT.601. (Normally defined by videos with resolution less that FHD)
[Image Removed]
Hello,
I’m not sure I follow why you cannot re-encode the videos you have. Any mp4 file, no matter who created it or with what tool can be re-encoded.
If that is not feasible you can simply remove the checks that are triggering in
Engine\Plugins\Media\ElectraUtil\Source\ElectraSamples\Public\ElectraTextureSampleUtils.h
lines 28, 48 and 70
by changing them to a “break;” statement.
This is also what we have done in UE 5.6.
Regards,
Jens
Hi Jens,
We download the Videos from a third party plattform at runtime and play them, therefore we don’t have control about the videos to re-encode them. Also, we can not provide to our clients the ffmpeg (or another software) to re-encode the videos at runtime before open.
I forgot to mention, that we use only the vanilla version from the Engine, therefore it is not a solution to modify the ElectraTextureSampleUtils.h file. Additionally, it is currently not possible to upgrade to UE5.6.
What other options do we have to avoid the crash?
Is there a way to read the Color Primaries property, to avoid opening these files?
Regards,
Luis
I see. Since it says here you’re getting UE via Perforce I was assuming you are building it from source.
Since the issue is caused by a check() macro triggering and check()'s are not present in Shipping builds, this should not be a problem with your released application I think.
Unfortunately I cannot think of a way to check for such encoded files, at least not without modifying source code which, if you could, would not be necessary since you could then also just comment out the check()'s.
Hi Jens,
We think about a workaround, to ignore the small resolution videos. Are there a way in UE to get the resolution of the videos to be play?
We found anything in UMediaPlayer or UMediaSource.
Regards
There is, but it requires the video to have been opened, which is exactly what you cannot do as that will trigger your issue.
Normally we advise to use Electra instead of the platform specific players, but in your case would it be possible, assuming you are only targeting Windows, to use the WmfMedia player instead?
Is your project Blueprint only or C++? If C++, you could derive your own stream media source class from the original one and implement the GetMediaOption() for boolean values and have it return ‘false’ when Electra queries for the option value “ElectraNoPreloading”.
Then Electra will only open the video and retrieve the metadata, but not start buffering and decoding, assuming your “play on open” flag on the media player is also set to ‘false’.
When the metadata has been fetched your media event listener receives the ‘EMediaEvent::MediaOpened’ event, after which you can use ''GetVideoTrackFormat()" API from the IMediaTracks interface you get from the media player GetTracks() method.
The format structure will contain the resolution.
Haven’t tried that in a while but it should work in theory.
This is of course assuming you are playing a single mp4 or mkv file only. If you are using DASH or HLS this will return the largest available resolution.
Hello Jens,
After testing different possibilities, we activate the WmfMedia. Because all solutions to avoid the videos with the codec BT.601 do not work.
We have a C++ project and we tried the solution you propose, it works but as soon as we try to open a file with the BT-601 Codec the application crashes.
Now we have another problem. With the WmfMedia player. The playlist are frozen after a couple of minutes. That was the reason because we change to the Electra media player.
Do you have any idea, why are the playlist frozen? and what can we do?
Regards
While I admit that it is inconvenient for testing/debugging, if you package your project as a “Shipping” build, it will work with Electra.
What you see as a “crash” is merely a check() condition that triggers. Since these checks are all disabled in shipping configurations your project should then work with your 601 videos and Electra.
When you say the WmfMedia “freezes”, how exactly does that manifest itself? Is the entire application blocked or is playback not progressing?
If there is audio in the videos, does the audio continue to play and it’s just the video that does not advance?
If you set the LogWmfMedia log category to VeryVerbose (and maybe the LogMediaUtils as well), do any of the log messages at the time of the freeze indicate what might be happening?
Hi Jens,
Unfortunately, we can’t use “Shipping” builds.
Regarding the WmfMedia Player, We haven’t been able to debug the freezing issue because we couldn’t replicate it on our machines. We only have user information, which isn’t enough. But due to the problems it has caused us in the past, we have decided to try Electra Media Player again.
To avoid the BT.601 check, we tried using WmfMedia Player to open the video and check the resolution and remove the problematic files, then switching to Elctra Media Player. This worked without a problem. But we need to validate the ColorPrimaries property and not just the video resolution, unfortunately there are some videos that have FHD resolution but the BT.601 codec.
How can we read this property?
Regards
I do not believe there is a way to do that since you are not compiling the engine from source code. If you did you could also just remove the problematic check().
Without the use of a shipping build or compiling the engine from source, or re-encoding the videos, I am afraid there is no solution for your problem without having to write code of your own to read out this information from the mp4 file yourself, which is a rather involved process. To do that you need to understand the file structure of an mp4 file to get to the part containing this information, which is the AVCDecoderConfigurationRecord (see ISO/IEC 14496-15:2022 - 5.3.2 Decoder configuration information) containing the video sequence parameter sets that in turn may contain the color information (this is optional information in the SPS).