[Camera Support]: Cannot get live view to work with H264+ (Hikvision's own codec tweak) - how to enable jsmpeg for live view instead?

[LaurenceGough]

Describe the problem you are having

Hello,

I hope this is in the right place, perhaps it's better off in the general support area. Apologies in advance if I am in the wrong place.

Ever since Frigate 14 I haven't been able to view the live view of one Hikvision camera 95% of the time. The 5% when it does work it seems totally random, even then it can be a bit intermittent sometimes getting stuck. This is on Android or desktop Chrome browsers. This camera is using Hikvision's H264+ codec to save on storage space. If I switch to H264 it does work fine but it really does use over twice as much storage and I'm not sure if it'd still use more bandwidth for live streaming with go2rtc doing it's thing?

Hikvision's blurb:

Compared to H.264, H.264+ reduces storage by up to 50% with the same maximum bitrate in most scenes.
Notes:

1. Upgrade your video player to the latest version if live view or playback does not work properly due to compatibility.

I am using go2rtc internal with this main stream.

Of course it might just be that I need to disable this codec, but it did work OK in the previous Frigate for live viewing, it may have only been with jsmpeg before I cannot recall fully now.

Are there any tweaks recommended to try and get this working? Unfortunately I cannot change the i-frame interval at all with this codec version enabled, I have tried various bandwidth, FPS and quality settings but none have helped.

I have tested using VLC via network stream and it has similar issues, sometimes working instantly, sometimes within a few seconds and sometimes even up to 30 seconds before it works. I assume this might be some kind of i-frame issue?

Before we could manually switch to jsmpeg to ensure you can view the stream regardless to see what is happening or just to check in and it would remember the setting so it always worked. How can I enable jsmpeg in Frigate 14?

Another idea I just had is to try and set the detect substream as the live view if that is possible, but I'd imagine the quality of this would probably be even worse than jsmpeg?

I know I could try to restream it but I'd like to leave that as a last resort to avoid additional constant CPU usage, it might not work either.

To note that recordings and event viewings work perfectly fine.

I guess the ideal world would be I keep this h264+ codec and can get some form of live view that works without stressing my server CPU always ideally!

Thank you!

Version

0.14.0-da913d8

What browser(s) are you using?

No response

Frigate config file

ffmpeg:
  hwaccel_args: preset-vaapi

all rest is default / unspecified really.

Relevant Frigate log output

nginx output below as only logs that seem relevant, Frigate logs are clear.

############Working live view log output:

Type
info
Timestamp
2024-08-26 22:42:05
Tag
GET
Message
Client IP here - - [26/Aug/2024:22:42:05 +0100] "GET /api/go2rtc/streams/CamNameHere HTTP/1.1" 200 1796 "Server IP here/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36" "-"


Type
info
Timestamp
2024-08-26 22:42:12
Tag
GET
Message
Client IP - - [26/Aug/2024:22:42:12 +0100] "GET /live/mse/api/ws?src=CamNameHere HTTP/1.1" 101 1715283 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36" "-"



#############when live view attempt with issue:

Type
info
Timestamp
2024-08-26 22:46:32
Tag
GET
Message
ClientIP - - [26/Aug/2024:22:46:32 +0100] "GET /api/go2rtc/streams/Camnamehere HTTP/1.1" 200 1796 "ServerIP/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36" "-"


Type
info
Timestamp
2024-08-26 22:46:43
Tag
META
Message
127.0.0.1 - - [26/Aug/2024:22:46:43 +0100] "" 400 0 "-" "-" "-"


Type
info
Timestamp
2024-08-26 22:47:44
Tag
META
Message
127.0.0.1 - - [26/Aug/2024:22:47:44 +0100] "" 400 0 "-" "-" "-"

Relevant go2rtc log output

Go2rtc dashboard log is empty apart from startup.
no warnings looks fine

FFprobe output from your camera

libavutil      57. 28.100 / 57. 28.100
  libavcodec     59. 37.100 / 59. 37.100
  libavformat    59. 27.100 / 59. 27.100
  libavdevice    59.  7.100 / 59.  7.100
  libavfilter     8. 44.100 /  8. 44.100
  libswscale      6.  7.100 /  6.  7.100
  libswresample   4.  7.100 /  4.  7.100
  libpostproc    56.  6.100 / 56.  6.100
[rtsp @ 0x559db24a7140] max delay reached. need to consume packet
[rtsp @ 0x559db24a7140] RTP: missed 43 packets
[h264 @ 0x559db24ac0c0] concealing 2521 DC, 2521 AC, 2521 MV errors in P frame
[rtsp @ 0x559db24a7140] max delay reached. need to consume packet
[rtsp @ 0x559db24a7140] RTP: missed 10 packets
[h264 @ 0x559db24ac0c0] Increasing reorder buffer to 1
[h264 @ 0x559db24ac0c0] concealing 1372 DC, 1372 AC, 1372 MV errors in P frame
Input #0, rtsp, from 'xxxxxxxxxxx/Streaming/Channels/101':
  Metadata:
    title           : Media Presentation
  Duration: N/A, start: 0.150000, bitrate: N/A
  Stream #0:0: Video: h264 (Main), yuvj420p(pc, bt709, progressive), 2688x1520 [SAR 1:1 DAR 168:95], 20 fps, 20 tbr, 90k tbn



#################### Second attempt:

  --extra-version=20220731
  libavutil      57. 28.100 / 57. 28.100
  libavcodec     59. 37.100 / 59. 37.100
  libavformat    59. 27.100 / 59. 27.100
  libavdevice    59.  7.100 / 59.  7.100
  libavfilter     8. 44.100 /  8. 44.100
  libswscale      6.  7.100 /  6.  7.100
  libswresample   4.  7.100 /  4.  7.100
  libpostproc    56.  6.100 / 56.  6.100
[rtsp @ 0x56453cd68140] max delay reached. need to consume packet
[rtsp @ 0x56453cd68140] RTP: missed 71 packets
[h264 @ 0x56453cd6d0c0] concealing 9024 DC, 9024 AC, 9024 MV errors in I frame
[rtsp @ 0x56453cd68140] max delay reached. need to consume packet
[rtsp @ 0x56453cd68140] RTP: missed 326 packets
[h264 @ 0x56453cd6d0c0] concealing 11683 DC, 11683 AC, 11683 MV errors in P frame
[rtsp @ 0x56453cd68140] max delay reached. need to consume packet
[rtsp @ 0x56453cd68140] RTP: missed 245 packets
[h264 @ 0x56453cd6d0c0] Increasing reorder buffer to 1
[h264 @ 0x56453cd6d0c0] cabac decode of qscale diff failed at 112 8
[h264 @ 0x56453cd6d0c0] error while decoding MB 112 8, bytestream 262742
[h264 @ 0x56453cd6d0c0] concealing 14553 DC, 14553 AC, 14553 MV errors in P frame
Input #0, rtsp, from 'xxxxxxxxxxxxxxxx/Streaming/Channels/101':
  Metadata:
    title           : Media Presentation
  Duration: N/A, start: 0.050000, bitrate: N/A
  Stream #0:0: Video: h264 (Main), yuvj420p(pc, bt709, progressive), 2688x1520 [SAR 1:1 DAR 168:95], 20 fps, 20 tbr, 90k tbn



####################third attempt:

  libavutil      57. 28.100 / 57. 28.100
  libavcodec     59. 37.100 / 59. 37.100
  libavformat    59. 27.100 / 59. 27.100
  libavdevice    59.  7.100 / 59.  7.100
  libavfilter     8. 44.100 /  8. 44.100
  libswscale      6.  7.100 /  6.  7.100
  libswresample   4.  7.100 /  4.  7.100
  libpostproc    56.  6.100 / 56.  6.100
[rtsp @ 0x55c4ebe49140] max delay reached. need to consume packet
[rtsp @ 0x55c4ebe49140] RTP: missed 27 packets
[h264 @ 0x55c4ebe4e0c0] cabac decode of qscale diff failed at 90 52
[h264 @ 0x55c4ebe4e0c0] error while decoding MB 90 52, bytestream 93183
[h264 @ 0x55c4ebe4e0c0] concealing 7183 DC, 7183 AC, 7183 MV errors in P frame
Input #0, rtsp, from 'xxxxxxxxxxxxxxxxx/Streaming/Channels/101':
  Metadata:
    title           : Media Presentation
  Duration: N/A, start: 0.200000, bitrate: N/A
  Stream #0:0: Video: h264 (Main), yuvj420p(pc, bt709, progressive), 2688x1520 [SAR 1:1 DAR 168:95], 20 fps, 20 tbr, 90k tb

Frigate stats

No response

Operating system

Other Linux

Install method

Docker Compose

Object Detector

OpenVino

Network connection

Wired

Camera make and model

Hikvision

Screenshots of the Frigate UI's System metrics pages

Any other information that may be helpful

No response

[hawkeye217]

I'm not quite sure what magic Hikvision is doing, but you're correct - it definitely sounds like an i-frame issue. We recommend an i-frame interval that matches your frame rate if using standard H.264.

The live view type is not user-selectable in Frigate 0.14, but if you want to go back to jsmpeg, the easiest way would be to change the name of your camera or go2rtc stream so that they don't match, and remove any stream_name directives you have for that particular camera. If you're not using go2rtc, then you're already using the jsmpeg player.

Edit: The jsmpeg player in 0.13 always defaulted to the stream with the detect role set, so that's what you'd be going back to if you made the above change. Personally, I love a crisp and fluent live view. A little more storage usage is a cheap tradeoff for that, at least for me.

[LaurenceGough]

Hey hawkeye,

Thanks for your help.

After your reply I thought heck why not try the substream, it'll probably be better quality and have other advantages over jsmpeg.

For the benefit of anyone else potentially reading I found this page https://docs.frigate.video/configuration/live and I used this:

live:
  stream_name: **examplecamname_substream**

in my Frigate config under this problematic camera, and I changed the go2rtc config to restream the substream instead of restreaming the main record channel - I just changed that to point directly at the camera to record, as in the old days ;).

Now I have a fairly fast loading live view but still with full quality recording and events.

If I find the quality an issue I'll change to the normal h264 and buy a new 2TB 2.5" HDD!

P.S did you see the errors in the ffprobe? It sure seems to do some odd things the h264+ codec.

It's so nice having the live view working again for quick checks! :)

[hawkeye217]

Great. That's certainly another way to do it with minimal increase in resource usage.

I did notice the errors in ffprobe's output. They're definitely selectively cutting out i-frames. I bet that it sends i-frames more frequently when there's more motion on the camera and cuts them back when there's less motion. If you opened the stream with Live view or VLC and you had a lot of activity currently happening, I have a feeling it would start streaming much more quickly.

I actually just put up a docs PR to clarify a lot of these concepts. Hopefully it's helpful for more users.

[LaurenceGough]

I think you hit the nail on the head there, I had a hunch it was more successful when there was motion, but it was sometimes freezing anyway, I guess when things calmed down again. I mean if VLC is struggling I guess we don't have much chance of getting it to work with their codec variation. I had wishful thinking there might be some ffmpeg arguments or tweaks I could try, but I think this sort of workaround solution of using the substream will do for now.

I was looking at the h265 cameras but they then have their own issues it seems with live playback!!

Awesome thanks for that :).

I guess this can be closed now?

[hawkeye217]

Glad you found a solution! Happy to help.