LiveView performance issues 1.34.10 (h264 passthrough)

[Bluemax]

I've updated from 1.34.7 to 1.34.10. Now, when using a chrome based browser on Android (Bromite) i've noticed a clearly noticeable lag/delay on 'video start'. It sometimes needs 2-3 seconds until the video starts. In my opinion this was faster before. That's also the reason i prefer the ZM web frontend over ZM-Ninja (due to speed/responsiveness). My daily usage is mostly skipping through videos as many events are simply useless.
I have a network throughput overlay running all the time at the top of my mobile and i can see it pushes data at constant 4.5MB/s that is max on my wifi net so it doesn't seem to "hang" somewhere serverside (waitstate). The problem is somehow related to a new buffer/cache strategy i think.

When using my desktop browser (Firefox) the video starts nearly instantly but the seek bar is jumping around wildly that might be caused by fluctuating (or asynchronously filled) buffers (wild guess). But this clearly is a difference to 1.34.7. Seekbar was stable. I guess this "fluctuating" buffer behavior also seems to "irritate" the chrome based browser described above.

Long story short, i think something has changed fundamentally on h264 passthrough and maybe it has it advantages. The question is, is this a side effect, a bug, intended behavior, something we have to live with or can this be fixed/improved/be made optional?

Or is it i just me? Anyone else noticed this as well?

[iconnor]

So the only change that relates is that we are now saving fragmented mp4's. This allows us to view an event that is currently being recorded.

So it may be that more of the data has to be downloaded before it can play... or something. how large are your events? Does file size matter?

I suppose we should make this setting configurable.

[Bluemax]

how large are your events? Does file size matter?

Yes, i think file size matters. The shorter the better. Events that go several minutes need more time to start. My current events are between 00m:25s (39MB) - 09m:00s (799MB).
This guy seems to have noticed the same behavior.

The "jumpy timeline" is caused by a constantly updated "video total time" (seen at the bottom of the web player). The "total time" increases with every jump. Once it stabilizes to the correct time the seekbar is normal again. Usually this happens between the first 6-15secs.

Edit: It probably has (only) something to do with the MP4 file itself. I've taken a "jumpy" file, passed it through ffmpeg (simple mp4 remux/copy) and it worked properly again in ZoneMinder. Not sure how the mp4 fragments are joined atm in ZoneMinder but i think that's the culprit.

Edit2: Difference between these files is missing metadata: nb_frames (AVStream Struct: Number of frames in this stream if known or 0). Buggy file has 'N/A', fixed file has defined value indeed. So, looks like the web player is updating as good as it can as data is flowing in but the final 'total_time' is unknown until all data/fragments got processed.

Code: Select all

ffprobe -v error -show_format -show_streams 11543-video.mp4 |grep nb_frames
ffmpeg -i "11543-video.mp4" -c copy "11543-video-fixed.mp4"

[iconnor]

Have been doing some reading. Our use of empty_moov may be what the problem is. I was under the impression that space was reserved for it and filled in at the end, but apparently it is just left empty.

So if you'd like to alter line 411 and get rid of the +empty_moov that might help.
Other things to try might be:
av_dict_set(&opts, "movflags", "frag_keyframe+rtphint", 0);

[Bluemax]

When removing +empty_moov the video is 1sec only (in any case).
'frag_keyframe+empty_moov+rtphint' doesn't change anything (the rtp hint track is definitely included, shown by Mediainfo)
Fwiw, i've also tried 'frag_keyframe+empty_moov+faststart' but doesn't change anything either. I think its ignored on +frag_keyframe anyway (at least the manual says so). Just saw someone mentioning it on the net. Theoretically, that's exactly what we need. Another pass that adds the final metadata when the file is finished.

Currently, i've removed the commit/line completely to benchmark the old behavior again.

You said +frag_keyframe has been introduced to watch events during recording. I usually would agree, but did you test that practically? Does it work for you at all? If i do it here the video is still not playable until recording stops (Firefox/Desktop).

[iconnor]

It does work well. In progress videos play almost instantly.

I am not seeing the problem that you describe, although others are.

without frag_keyframe it is not possible to view the in progress video at all.

The problem with faststart is that it goes through the file again to write that header. It can add more than a second to finishing writing a file. A second during which we are not recording. So it needs to be a background process that happens after the event is complete. Which is doable.

[Bluemax]

It does work well. In progress videos play almost instantly.

Maybe its a webserver config issue on my side. I'm using nginx and didn't spent too much time in configuration yet. The only options i've set for mp4 are 'mp4_buffer_size 5M;' and 'mp4_max_buffer_size 10M;'. I will do some testing here. What i can say so far is that non-fragmented output is way faster on anything i threw it at.

The problem with faststart is that it goes through the file again to write that header. It can add more than a second to finishing writing a file. A second during which we are not recording. So it needs to be a background process that happens after the event is complete. Which is doable.

I couldn't notice any effect though. If i get it right '+faststart' only works on non-fragmented files (but i'm not sure on this indeed). The manual says:

-movflags faststart
Run a second pass moving the index (moov atom) to the beginning of the file. This operation can take a
while, and will not work in various situations such as fragmented output, thus it is not enabled by
default.

---------------

I suppose we should make this setting configurable.

Yes, good idea.

In case you haven't seen the 'jumpy timeline' yet.

[LBDG]

Hello

I am also encountering this problem with 1.34.10 on Ubuntu 18.04 and also 20.04 (iconnor repo)

In my case, I use mocord (30 minute section lengths) and I have to wait or press the end of the timeline many times so that whole 30 minutes shows up on the progress bar and the alarm line up with the red indicator. This renders viewing alarms impossible.

How can I revert to the old behavior? Should I go back to a previous release or is there a simple edit I can do in the zm files. The thread is not clear.

Thanks in advance

[Bluemax]

There is 1.34.11 now. Not sure if it's configurable now. I will update in some minutes.
If it didn't make it into the current release yet you either have to recompile it or downgrade to an older version until its fixed.

Edit: Looks like nothing has changed. If you want to patch it comment out this line. I've patched 1.34.11 in the first place.

[jzigzone]

I also see the slow load times and jumpy timelines.

This is with Mocord and 10 minute segments and h264 passthrough.

However, I only see the jumpy timeline in Zoneminder on Windows 10 and Firefox (76.0).
On Linux Mint 19.1 and FireFox (76.0) the timeline seems to be ok, but still have the slow load times (this is the machine hosting ZM).

[LBDG]

There is 1.34.11 now. Not sure if it's configurable now. I will update in some minutes.
If it didn't make it into the current release yet you either have to recompile it or downgrade to an older version until its fixed.

Edit: Looks like nothing has changed. If you want to patch it comment out this line. I've patched 1.34.11 in the first place.

I commented line 412 described on 1.34.12 and built from source (via do_debian_package.sh) and still see the jumpy behaviour over my network. I think the script downloads the source release everytime ignoring my local changes. How do I invoke the build package script to use the local amended files? (I would still like to know this)

Also I seem to have found a solution in firefox by increasing the "media.cache_resume_treshold" and "media.cache_readhead_limit"
https://support.mozilla.org/en-US/questions/1168957
It stills takes a few second to load the full 30 minute timeline but at least it is functional.