-
Notifications
You must be signed in to change notification settings - Fork 147
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Bframe support #231
Comments
Seems like the error is being thrown here. moonfire-nvr/server/db/writer.rs Line 774 in 2e2de8c
Still trying to unpack what B-frame here is exactly doing. It seems B frame isn't common verbiage because I had some issues finding articles on it when I searched. Could just be I didn't know where to look. I found an FFMPEG tutorial that has some background on it. Suprisingly I found that tutorial code very similar to how the moonfire-nvr function is processing the PTS.
I still need to learn how Moonfire handles the PTS but according to that tutorial the receiver orders the frames to be played using the PTS. When B frames are involved they process information from the frame before and the frame ahead. The only way I can see that being possible is if it's a static file, or if you await the current frame until the next frame comes in. That does seem fairly complex and I could see why for simplicity there isn't a current implementation. Still looking into how I can help on this issue. |
Are you cameras all Axis? Someone else just posted a similar issue on Retina (the RTSP library that Moonfire uses) saying newer Axis cameras use B-frames. I'd never heard of an IP camera doing this before. B-frames I think are common in encoded TV shows/movies (Bluray, streaming services, etc.). I'm a little surprised to see IP cameras use B-frames because I think it means the cameras aren't configured for the lowest possible latency. As you've observed, Moonfire doesn't support B-frames today, but I'm totally open to changing that. I think a good first step would be to make Retina In Moonfire itself, the biggest problem is that the video index format needs to be changed to support them. So it will require a storage schema change. |
They are all Amcrest cameras. Yeah the concept seems weird to me but having worked in environments in the past with close to 1000 cameras I could see quite a bit of bandwidth savings from using B frames. As long as the guarantee is that the dependent frames come before the B frame you technically have all the info you need so it's basically compression logic. As far as what I've read on it. I don't think latency is an issue as long as you're processing the frame before the next refresh cycle you're technically completing the decompression before the next frame. I THINK . My participation is really pushing my abilities and experience programming so please do not defer to me. I also wonder if the issue here is really B frames. From what I read an identical PTS doesn't make sense for a B frame. It still should have a unique PTS because it represents a distinct frame it just has a "retro" PTS because the prior frames DTS had to be lower so you have all the data to build the "B" frame for presentation. So that would mean the difference would be negative? I still need to understand better how Moonfire is scheduling frames. The file this error is coming from is the writer so "scheduling" here is just ordering them to be written to the sample file I think. |
I notice on the other similar issue you linked. It's actually showing a negative -5400 PTS difference which makes sense. The B frame is put out of order after its dependent frames and therefore has a negative PTS value. What's weird to me is why I'm seeing duplicate PTS values. Why would we try to display two frames at the same time? Seems like it's a different issue and would explain why my cheap Amcrest cameras with which some are getting older have a feature only seen on Axis cameras (primo). |
I haven't studied how B frame pts/dts are supposed to be represented on the wire, but the authoritative reference should be this one: https://datatracker.ietf.org/doc/html/rfc6184 |
...and the main H.264 spec (although it's a dense, difficult read!). Links at https://github.com/scottlamb/moonfire-nvr/wiki/Standards-and-specifications |
Alright this is perfect. When I get some free time I'll get a pcap from tcpdump and see what the packets show. |
Any chance you could get that pcap? I'd like to see how this camera's sending it on the wire still. fwiw, I ran across the gstreamer 1.22 release notes, which include this:
Possibly the right thing to do is to copy their approach. |
No sorry ended up switching jobs and been having to table my side projects
a bit.
I'm still dabbling in Rust but trying to up my skills so I can be of more
help.
I have a cluster setup though I could try a specific version again and try
to get that PCAP.
Just remind me what you're wanting to see again.
Basically the cut out problem with the B frames again?
…On Wed, Feb 15, 2023, 8:32 PM 'Scott Lamb' via Applications < ***@***.***> wrote:
Any chance you could get that pcap? I'd like to see how this camera's
sending it on the wire still.
fwiw, I ran across the gstreamer 1.22 release notes
<https://gstreamer.freedesktop.org/releases/1.22/>, which include this:
Muxers are often picky and need proper PTS/DTS timestamps set on the input
buffers, but that can be a problem if the encoded input media stream comes
from a source that doesn't provide proper signalling of DTS, such as is
often the case for RTP, RTSP and WebRTC streams or Matroska container
files. Theoretically parsers should be able to fix this up, but it would
probably require fairly invasive changes in the parsers, so two new
elements h264timestamper and h265timestamper bridge the gap in the meantime
and can reconstruct missing PTS/DTS.
Possibly the right thing to do is to copy their approach.
—
Reply to this email directly, view it on GitHub
<#231 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFI7ZUP74QESLQRHF4BYU5TWXV7RHANCNFSM52PXF7TA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
No worries. I'd like to see a pcap of a RTSP stream including B-frames. The cut-out problem with Moonfire would be helpful; a stream from another RTSP client that doesn't cut out would probably be even better. |
Is https://hub.docker.com/r/scottlamb/moonfire-nvr still up to date?
I can test this out but would prefer to run it locally on Kubernetes if I
can.
…On Thu, Feb 16, 2023 at 1:41 AM 'Scott Lamb' via Applications < ***@***.***> wrote:
No worries. I'd like to see a pcap of a RTSP stream including B-frames.
The cut-out problem with Moonfire would be helpful; a stream from another
RTSP client that doesn't cut out would probably be even better.
—
Reply to this email directly, view it on GitHub
<#231 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFI7ZUJHYIZKYHNZLPW66S3WXXDZ3ANCNFSM52PXF7TA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
By the way, this should be easy to reproduce by using OBS and OBS-RTSPServer That's how I ran into this issue |
It looks like all of my cameras produce B frames and even after disabling smart-codec and resorting to H264B. (basic).
I'm unable to prevent the following error for my Amcrest cameras which as far as I can tell causes issues with eventual web socket loss, lagging streams, and finally the early flushing of recordings resulting in 10 second duration captures.
This issue is the main problem with my common usage of moonfire-nvr so I'd like to document my issue and proceed as best as I can.
The Models of camera I'm using:
IP8M-T2669EW-AI
IP8M-2493EW
IP2M-851EW
The text was updated successfully, but these errors were encountered: