Error: Media decode error or unsupported media features

[Velkas]

Image

I get a failure to playback video in the web and on mobile. This is regardless of the video codec I choose to record to. Currently, I've been recording to H.264 MP4.

I'm running the latest build in an Ubuntu 10.10 VM. Playback is unavailable in Firefox, Chrome, Edge, iOS Safari, and macOS Safari.

Is there something wrong with my install?

Edit: When I go into the VM and look at the videos in storage, it plays back locally in the VM and when I access it from my Windows machine. So the videos are not actually corrupt.

[hughb8on]

I have exactly the same problem. I am running Ubuntu 18.04 on an Intel NUC.

H.264 MP4 recordings are being made correctly and they are definitely not corrupt - they play back normally in other software on that machine and when downloaded to Windows, but they will not play back through the MotionEye web interface - I've tried Firefox, Edge and Safari on iOS.

The thumbnail displays ok but when I click on the Play icon a message is displayed at the top of the window: "Error: media decode error or unsupported media features".

I have tried various formats in addition to H.264 and nearly all produce valid recordings but none will play back through the web interface.

[hughb8on]

I now have this working in all the browsers I use. First I tried upgrading to the latest version of motion, from source. This didn't help. I then deleted my cameras and added them back. That did the trick. I haven't done a before-and-after comparison of the resulting thread confs, but as far as I am concerned everything accessible from the motioneye interface is unchanged.

[Marc--]

Hello there, same issue for me, did you find a solution?

[olskar]

Me to have this issue. Hope for a fix!

[olskar]

I use this fix from this report https://github.com/ccrisan/motioneye/issues/1067

[Marc--]

I found why it's not working in my case. It's not a MotionEye issue, it's a browser issue. I'm using passthroug recording, and my cameras are recording in H265 (HEVC).

HEVC isn't supported by a lot of browsers : https://caniuse.com/#feat=hevc

I change my cameras settings to H264, and it's now OK.

[MarcCOLSON]

Hi all, I met a similar but different issue with same symptoms : "Error: Media decode error or unsupported media features". By default, movie quality is set to 75% => no problem to read saved movies from my PC or smartphone inside web MotionEye user interface. When I raise the movie quality to 100%, impossible to read video files any more. If I downgrade movie quality to 75%, I can read move file again.

I use the version 0.42 of MotionEye & use H264.mp4 codecs.

[starbasessd]

@MarcCOLSON motionEye or motionEyeOS? If motion/motionEye on another Base OS, which baseOS? If motionEyeOS which version? 20190911, 20200203, 20200606 or dev20201026 Pi or other SBC?

[Marc--]

Hi, I'll try to reproduce the problem on my computer :

motionEye Version | 0.42.1 Motion Version | 4.2.2 OS Version | Debian 10

Since my last post, everything is working, but i'm my video quality is at 75%. I'll change it on one cam and post the results.

[starbasessd]

Running in Docker?

On Wed, Dec 30, 2020 at 4:17 PM Marc-- notifications@github.com wrote:

Hi, I'll try to reproduce the problem on my computer :

motionEye Version | 0.42.1 Motion Version | 4.2.2 OS Version | Debian 10

Since my last post, everything is working, but i'm my video quality is at 75%. I'll change it on one cam and post the results.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ccrisan/motioneye/issues/1206#issuecomment-752761285, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEZTUHOOXGQFWPUX6LWMERLSXOKHVANCNFSM4HC4TACQ .

-- Thanks

Kevin Shumaker

Personal Tech Support https://kevinshumaker.wixsite.com/thethirdlevel

N38° 19' 56.52" W85° 45' 8.56"

Semper Gumby “Don't tell people how to do things. Tell them what to do and let them surprise you with their results.” - G.S. Patton, Gen. USA Ethics are what we do when no one else is looking. Quis custodiet ipsos custodes? “There is no end to the good you can do if you don’t care who gets the credit.” - C Powell You know we're sitting on four million pounds of fuel, one nuclear weapon and a thing that has 270,000 moving parts built by the lowest bidder. Makes you feel good, doesn't it?

[MarcCOLSON]

@MarcCOLSON motionEye or motionEyeOS? If motion/motionEye on another Base OS, which baseOS? If motionEyeOS which version? 20190911, 20200203, 20200606 or dev20201026 Pi or other SBC?

motionEye running on raspbian 10 on a raspberry pi 4

[zagrim]

I think this is Motion related, see #1641 for more details. Basically the quality parameter, when set to 100%, causes Motion to produce h264/mp4 files with such an exotic parameters that still not all software (the browser, mostly) can play them. VLC player should be able to play those files, too. Just set the quality to e.g. 90% or lower until you get files which play fine.

[MarcCOLSON]

I confirm #1641 matches perfectly. But the root cause is really counterintuitive. May I suggest to change this behaviour and avoid video not to be read when 100% quality is set?

[zagrim]

I don't really know about that... You see, MotionEye can't know if the browser has the required codecs (or in this case more specifically whether it is able to support a certain "level" or "type" of content within a specific codec) before it tries to play something the browser does not support. I agree that it is not very intuitive to offer such setting when it really doesn't work, but I doubt that there is any way for MotionEye (or any other web application) to be able to ask the browser for what it supports. Besides, you might be using both a laptop and a phone/tablet to access MotionEye, and it's likely that the phone or tablet would have somewhat reduced support for more aggressive compression options. Or you might not even be using the built-in media player to view the recordings.

I'm not an expert on the matter so perhaps someone can shine more light on the possibilities. The only improvement I can see for MotionEye is to have more informative error message displayed for that case when h264 is being used (but it still is somewhat guessing as there might be other causes for the same error).