search

motioneye-project / motioneye

A web frontend for the motion daemon.
GNU General Public License v3.0
3.95k stars 650 forks source link

Media format unsupported or otherwise unavilable/unsuitable for playing. #1824

Open Saku241 opened 4 years ago

Saku241 commented 4 years ago

Hello Im running motioneye 0.42.1 with motion 4.3.1 on Raspbian 10 buster on Raspberry Pi 3 model b. I record video on motion triggered in H264/OMX and since a few days I got the error « Media format unsupported or otherwise unavilable/unsuitable for playing. » ( Btw there is a misspelling on the word « unavailable ») when I read it through the web (192.168.1.x:8765)

I also upload my files on a Google Drive and videos on my drive are working correctly, same as read locally and when I download them

So where did the error come from ?

Thanks !

Saku241 commented 4 years ago

Update : it works on Chrome and Edge but not on Firefox

davebdb commented 4 years ago

@Saku241 I think there may be an issue similar to this https://github.com/ccrisan/motioneye/issues/1003#issuecomment-653840985 which is what I'm having issues with the format. Can you run ffprobe on the file to see what type of formatting its in? ffprobe -i FILENAME -show_format -hide_banner -show_streams I have put a convert script on mine for now just to make it work, but it does put a high load on the system if there is a lot of cameras recording, I have 4. But if it works after converting it with ffmpeg, I think it may have to do with the H264 profile setting.

Saku241 commented 4 years ago

Here is the ffprobe :

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '13-26-21.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf58.20.100
  Duration: 00:00:08.25, start: 0.000000, bitrate: 36397 kb/s
    Stream #0:0(und): Video: h264 (High 4:4:4 Predictive) (avc1 / 0x31637661), yuv420p, 1280x720, 36396 kb/s, 8.13 fps, 32 tbr, 14336 tbn, 28 tbc (default)
    Metadata:
      handler_name    : VideoHandler
[STREAM]
index=0
codec_name=h264
codec_long_name=H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
profile=High 4:4:4 Predictive
codec_type=video
codec_time_base=118213/1921024
codec_tag_string=avc1
codec_tag=0x31637661
width=1280
height=720
coded_width=1280
coded_height=720
has_b_frames=0
sample_aspect_ratio=N/A
display_aspect_ratio=N/A
pix_fmt=yuv420p
level=31
color_range=unknown
color_space=unknown
color_transfer=unknown
color_primaries=unknown
chroma_location=left
field_order=unknown
timecode=N/A
refs=1
is_avc=true
nal_length_size=4
id=N/A
r_frame_rate=32/1
avg_frame_rate=960512/118213
time_base=1/14336
start_pts=0
start_time=0.000000
duration_ts=118213
duration=8.245884
bit_rate=36396575
max_bit_rate=N/A
bits_per_raw_sample=8
nb_frames=67
nb_read_frames=N/A
nb_read_packets=N/A
DISPOSITION:default=1
DISPOSITION:dub=0
DISPOSITION:original=0
DISPOSITION:comment=0
DISPOSITION:lyrics=0
DISPOSITION:karaoke=0
DISPOSITION:forced=0
DISPOSITION:hearing_impaired=0
DISPOSITION:visual_impaired=0
DISPOSITION:clean_effects=0
DISPOSITION:attached_pic=0
DISPOSITION:timed_thumbnails=0
TAG:language=und
TAG:handler_name=VideoHandler
[/STREAM]
[FORMAT]
filename=13-26-21.mp4
nb_streams=1
nb_programs=0
format_name=mov,mp4,m4a,3gp,3g2,mj2
format_long_name=QuickTime / MOV
start_time=0.000000
duration=8.246000
size=37517117
bit_rate=36397882
probe_score=100
TAG:major_brand=isom
TAG:minor_version=512
TAG:compatible_brands=isomiso2avc1mp41
TAG:encoder=Lavf58.20.100
[/FORMAT]
sdevrieze commented 3 years ago

I can confirm this issue. Motioneye version is 0.42.1 and motion version is 4.3.1. So this is the same. I installed it in Raspbian buster with the latest updates (also rpi-update).

I have several cameras and as far as I remember, I did not experience this with a resolution of 640x480 (the affected camera is using 1280x960 resolution so the files are bigger).

I have found some more insights about this bug:

Can anyone confirm the same behaviour? So that when a specific recording cannot be played when accessed via the hub, it still can be played when connecting the the IP of the specific camera?

starbasessd commented 3 years ago

I would like to try to confirm. Which Pi? (for the individual Camera)? Which Pi4 for the hub? What video format(s) are you using? Have you tried 'Pass Through' on the hub? Which source of instructions for installing motion/motionEye? What Desktop are you using? Win7, 8,8.1, 10? MacOS Version? Linux flavor and version?

sdevrieze commented 3 years ago

Camera: Raspberry Pi 3 Model B Plus Rev 1.3 Hub: Raspberry Pi 4 Model B Rev 1.1 2GB

If you mean the option Movies->Movie Passthrough the answer to your question is yes, but it does not help. At least not for viewing old recordings (maybe it helps for new recordings?) Also, it just configures the option on the camera itself and not the hub, right?

https://github.com/ccrisan/motioneye/wiki/Install-On-Raspbian + rpi-update + I installed the newer motion 4.3.1 version instead of the older 4.2.2 in the tutorial. I haven't tried with the newest 4.3.2 version so far. I am running this on Raspbian Buster.

Ubuntu 18.04 with the Dell respositories. I do not see how this can help you though :-)

starbasessd commented 3 years ago

Thanks for the responses. May I suggest using the newer Install on Ubuntu 20.04 or Newer instructions. I am thinking about updating the Raspberry Pi OS instructions to match due to the issues with the upstream repositories and the death of Pythn 2.7 on 31/12/2020 support. Have you tried the 4.2.2? I know there was some discussion here and elsewhere about changes to motion upstream that broke stuff. I run a VM and a Lenovo TFF desktop Hubs with Ubuntu 20.04 and motion 4.3.1 that works well with a number of cameras. I can reproduce a lot of environments here between VMs, OSs, any Pis (except 3a, and the Compute Modules) so knowing how you installed / what you installed helps a lot. Let me know if you try 4.2.2. BTW, when I don't use Movie Pass Through, I use several other formats that do NOT include OMX, which is what I've found problematic. As to still can't play back older videos, no, it won't change how the older files were recorded, or their playback through WebGUI, just any future videos recorded.

On Mon, Nov 16, 2020 at 9:27 AM sdevrieze notifications@github.com wrote:

Camera: Raspberry Pi 3 Model B Plus Rev 1.3 Hub: Raspberry Pi 4 Model B Rev 1.1 2GB

If you mean the option Movies->Movie Passthrough the answer to your question is yes, but it does not help. At least not for viewing old recordings (maybe it helps for new recordings?) Also, it just configures the option on the camera itself and not the hub, right?

https://github.com/ccrisan/motioneye/wiki/Install-On-Raspbian + rpi-update + I installed the newer motion 4.3.1 version instead of the older 4.2.2 in the tutorial. I haven't tried with the newest 4.3.2 version so far.

Ubuntu 18.04 with the Dell respositories. I do not see how this can help you though :-)

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

-- 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?

sdevrieze commented 3 years ago

Video format: H.264/OMX

As written before, some video files do not cause problems and it always is possible to watch all recorded videos if I connect to the camera directly with my browser instead of trying to view them via the hub. If a video cannot be watched via the hub, it is also impossible to download it. To me it looks like the problem lies in some caching issue between the camera and the hub.

On my laptop from work I do not have motion(eye) installed. It should not be the cause of the problem. I do not want to upgrade yet as it is running very well on 18.04.

I did not yet try to debug with the older version. The reason I installed the latest version, is that I hope it is more energy efficient. I am using LS-POE-B0525 PoE splitters to power my cameras. One of the cameras also has an LiFePO4wered/Pi+ battery (backup UPS for additional protection) and my splitter may technically not provide enough power for the combination.

As there are today no people in front of the camera, I can only test with other motion versions later this week.

sdevrieze commented 3 years ago

Ok, I installed motion 4.3.2 on both the hub and the camera. It is now possible to watch recordings from the hub interface that were not watchable yesterday which is strange as I do not see how motion would be involved in displaying existing recordings.

Maybe it just has been temporarily resolved because I had to restart motioneye to load the new motion version? I will keep the camera creating recordings for a week and then check again.

One thing that I notice though, is that I still see the debug frames and the text overlay (camera name and time) on the new recordings, even when I download them. I enabled the Movie Passthough option yesterday. May this be caused by the 4.3.x issues you wrote about?

starbasessd commented 3 years ago

It is more likely that the software which is used for encoding and decoding the videos is corrected in the version of motion. OMX has issues which is discussed, and why I recommend using a non-OMX protocol. There are other issues that are discussed over in the motionEyeOS about having to make manual changes to motion when building for motionEyeOS, too. The debug frames are written to the video file (like the time/date stamp and camera name stamp) so, yes, they are still visible, in old recordings. If you turn it off, they will no longer show in new recordings. Motion Passthrough just doesn't do any re-encoding of the type (like if your source is mjpeg and you turn on h264/omx, it gets written in h264/omx mp4 format. Turn on Movie Pass through and the format will be mjpeg instead.) By using Movie Pass Through, you take a load off of the Pi by not re-encoding the data. The rest of the system can still work (motion detection, show motion frames, etc)

On Tue, Nov 17, 2020 at 5:40 AM sdevrieze notifications@github.com wrote:

Ok, I installed motion 4.3.2 on both the hub and the camera. It is now possible to watch recordings from the hub interface that were not watchable yesterday which is strange as I do not see how motion would be involved in displaying existing recordings.

Maybe it just has been temporarily resolved because I had to restart motioneye to load the new motion version? I will keep the camera creating recordings for a week and then check again.

One thing that I notice though, is that I still see the debug frames and the text overlay (camera name and time) on the new recordings, even when I download them. I enabled the Movie Passthough option yesterday. May this be caused by the 4.3.x issues you wrote about?

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

-- 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?

sdevrieze commented 3 years ago

ok, I thought the webbrowser was doing all the decoding. We'll see next week if all is working correctly now.

What I was saying is that I enabled the Movie Passthought option yesterday and that whilst it is still enabled today, all new recordings still contain the text overlay and debug frames encoded in the video which is using H264 codec. So, it looks like there is a bug that breaks this feature.

Note that I am not using an USB camera but the Raspnerry camera interface (MMCAL; not V4L).

I prefer to use omx as that should reduce CPU usage. I think that is important as my cameras are almost constantly recording when the store is open.

starbasessd commented 3 years ago

Did you disable text overlay in Settings, toggle to Off? (BTW, it's necessary to have Time/Date/Camera stamps to use the files in most court situations, to show evidence of when something happened...) Did you disable Show Motion Frames in Settings, Motion Detection, Show Frame Changes, and Create Debug Media Files for EACH Camera?

On Tue, Nov 17, 2020 at 8:39 AM sdevrieze notifications@github.com wrote:

ok, I thought the webbrowser was doing all the decoding. We'll see next week if all is working correctly now.

What I was saying is that I enabled the Movie Passthought option yesterday and that whilst it is still enabled today, all new recordings still contain the text overlay and debug frames encoded in the video which is using H264 codec. So, it looks like there is a bug that breaks this feature.

Note that I am not using an USB camera but the Raspnerry camera interface (MMCAL; not V4L).

I prefer to use omx as that should reduce CPU usage. I think that is important as my cameras are almost constantly recording when the store is open.

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

-- 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?

sdevrieze commented 3 years ago

No, no, yes.

starbasessd commented 3 years ago

Then it is behaving as expected/designed for Show Motion Frames and Timestamp.

On Tue, Nov 17, 2020 at 9:21 AM sdevrieze notifications@github.com wrote:

No, no, yes.

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

-- 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?

sdevrieze commented 3 years ago

But I enabled the Passthrough option that says it will not record the overlays when enabled... It either needs to say it will only work when you also disable other options, or else it should do what it is telling it would do.

starbasessd commented 3 years ago

Interesting. I never noticed that in the tooltip. @ccrisan @jasaw is that a bug, or a feature change?

On Tue, Nov 17, 2020 at 11:06 AM sdevrieze notifications@github.com wrote:

But I enabled the Passthrough option that says it will not record the overlays when enabled... It either needs to say it will only work when you also disable other options, or else it should do what it is telling it would do.

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

-- 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?

zagrim commented 3 years ago

Let me get this straight @sdevrieze : You've enabled "Movie Passthrough" in MotionEye, but you still get text overlay added in the videos? I've been running like that for long and it shouldn't be like that, although I've still not upgraded to the version of ME where there's built-in support for the passthrough switch (so in case there's an implementation flaw I wouldn't know it).

zagrim commented 3 years ago

@sdevrieze You've stated:

Note that I am not using an USB camera but the Raspnerry camera interface (MMCAL; not V4L).

Motion docs say of the "motion_passthrough" parameter:

When using a RTSP, RTMP, mjpeg and some V4l2 cameras, create movie files of the motion with the packets obtained directly from the camera.

I read this so that your camera is actually set up / interfaced in a way that is not supported by the passthrough feature in Motion.

I think the GUI option for passthough should actually be modified to take the camera setup type into account and not show the option for incompatible cameras.

sdevrieze commented 3 years ago

Yes, "Movie Passthrough" option is enabled and I still see the text overlay added.

Camera is connected to the local MMAL inferface. If it is incompatible, it indeed should be more userfriendly to hide or grey out the option.

sdevrieze commented 3 years ago

ok, I thought the webbrowser was doing all the decoding. We'll see next week if all is working correctly now.

It took less than a week. This afternoon a video of 9 minutes and 34 secs was recorded with which I got the same error. Wating the video on the camera IP works but takes some time to start. I tried to restart motioneye on both the hub and the camera, but that did not work. Also downgrading to version 4.2.2 of motion on both the hub and the camera does not help to play that specific recording on the hub. It does play on the camera IP.

I will now see and wait if I get the same problem with motion 4.2.2

sdevrieze commented 3 years ago

I will now see and wait if I get the same problem with motion 4.2.2

I can confirm the same issue is happening with motion 4.2.2. I thus guess motion is not the problem, but it is a bug in motioneye that involves a caching problem when viewing through the hub.

A few files that now do not want to play on the hub are 462.8 MB, 477.6 MB, but even 11.3 MB in size. They play fine if I access the recordings of that motioneye camera by connecting to the camera IP directly. It also looks like motioneye refuses to watch any new recording as soon as the error appears. I have a restart motioneye on the hub to be able to watch other recordings.

One thing that I also notice is that loading the big files take a lot of time on the hub, whilst they almost instantly load when trying the view them on the motioneye interface of the camera itself directly.

Could it be possible that motioneye on the hub downloads the files first in RAM (causing long load times) and then not cleaning up this cache afterwards (causing this bug when a certain limit is reached and only a restart of motioneye allows to watch other recordings)?

If you want to reproduce this bug, these are my camera settings:

Swekkerooni commented 3 years ago

I am experiencing similar issues. Some time ago, I've switched to an IP camera instead of USB 640x480 webcam, causing me to hit a bottleneck in processing power. It runs on a dual core PC, which should be capable of handling this particular set-up.

The camera puts out: 1920x1080 at 20FPS, in H.265. The direct RTSP stream is perfect in frame rate and consistency.

The only way I can get this camera working in all browsers is by transcoding the incoming H.265 stream to H.264/OMX and setting the "Movie Quality" to 95%. The first 2 seconds are a good 20 FPS, the rest of the video is unusable choppy. Using htop I've been able to gather some more clues. CPU spikes to 99% during the first few seconds, and then it crashes to almost baseline(30%) use. I guess... it just gives up?

Using Movie Passthrough, I can not watch the movies in any of my browsers on any of my devices. It kicks the error as in the topic title.

Dragging the video into browsers on my Mac, I found out that this file probably won't play in Safari, but it did work in Chrome, when playing the download from a local folder. Using chrome is no problem at all. If you check htop with Movie Passthrough enabled, it goes up to a nice 60% on both cores for the duration of the recording and everything works perfectly... It just doesn't play the videos not in the browser.

Conclusion: Media files only want to play in browsers/Chrome after transcoding, and only with the movie quality set to something other than 100%. In turn, this requires a lot more CPU power than needed.

I feel like this issue could be solved. Motioneye is a good piece of kit!

starbasessd commented 3 years ago

Cannot reproduce with my d-link cameras at 800x600 and pass-through in Safari on my Mac. Will report with rtsp: foscam 1280x720 pass-through when I get some activity on it. With Safari and my default (not passthrough) won't play it, it forces me to download it, then I play it with VLC. I write that off to MacOS, though. Win10 & Linuxs work fine in Chrome, FireFox, Edge, etc...

zagrim commented 3 years ago

Just to have a recap on this somewhere:

Getting "Media format unsupported" with pass-through enabled depends on a whole lot of parameters, like the encoding format and parameters of the video received from the camera, and also whatever video codecs the browser being used supports. I do not know if the major browsers support same codecs on all platforms (operating systems), or if that varies by platform, or if that somehow even varies by some other software having been installed (although I'd suppose browsers don't use any external codecs since that would likely open some possibilities for vulnerability). Also the device hardware might be involved, since the most efficient packing encoding formats do have significant processing power demands and may thus require hardware support (usually provided by the GPU). One just can't view video encoded in H264 "High 4:4:4 Predictive Profile" on an mobile phone (yet, maybe some time in the future it will be ok though).

Getting "Media format unsupported" with H264/MP4 re-encoded by Motion (behind the user interface provided by MotionEye) with the highest movie quality settings also depends on the browser and/or operating system and/or device hardware capability to decode some of the H264 higher Profiles. So, what is the highest usable movie quality percentage for some individual user again depends on the browser/OS/device.

So, whether some combination works for some or not, there is no bug or flaw in MotionEye, nor Motion (which relies on ffmpeg and/or some other external libraries (depending on how it was configured to be built). And there's definitely no way for MotionEye to "know" which settings should work in any given installation.

zagrim commented 3 years ago

The first 2 seconds are a good 20 FPS, the rest of the video is unusable choppy. Using htop I've been able to gather some more clues. CPU spikes to 99% during the first few seconds, and then it crashes to almost baseline(30%) use.

@Swekkerooni I don't know if ffmpeg does somehow adapt the encoding parameters when the device just can't keep up with the demand, but that might explain what you seen. You mention using H264/OMX which could use hardware support if the ffmpeg you have has been built to include such support AND if the PC you use has hardware that is supported by OMX, but since the CPU load goes so high I guess it ends up doing all the work in the CPU.

The following is the standard recipe for this kind of situations: Have you tried at setting the movie quality lower than 95%, like 80% or 75%? I know it will lose some details from the video, but at least that's better than none? You could also try to find a usable balance between movie quality and frame rate (lower frame rate allows a bit higher quality and vice versa).

eckerj commented 1 year ago

I know this is an old issue, but I believe I found the cause (at least in my situation).

I have several raspberry pi-based motioneyeOS cameras all feeding into a motioneye instance running on an Ubuntu file server. When connecting to the file server's motioneye instance, when I play recordings, they are downloaded from the pi-based cameras to the file server and placed under /tmp/MotionEye. These are then streamed to my browser.

I started receiving the "no video with supported format and mime type found" error recently and was unable to play recordings from the file server's motioneye instance.

Then I remembered that I had accidentally removed the /tmp/MotionEye directory when the file server had run out of space in the root filesystem.

I logged into the file server and restarted motioneye, it recreated the /tmp/MotionEye directory, and I'm now able to play recordings.

TL;DR - Make sure the /tmp/MotionEye directory exists (or can be created) on the motioneye instance you are connecting with a browser, that it is writable, and has enough space to store recordings.