Substream of camera should be recordable with custimizable settings like main record stream settings

[tearfulnumpty]

Describe what you are trying to accomplish and why in non technical terms
I want to be able to record the substream of a camera in Frigate. I am aware that the preview stream exists, but that does not contain audio and doesn't contain near the level of fidelity as the substream itself contains.

I'd like to make use of this substream recording for various live background tasks, of which I don't see the previews being appropriate.

Describe the solution you'd like
The substream should be recorded like the main stream, without having to create a separate "camera" object within Frigate. Recording configuration settings should be available for it, which should be nearly if not exactly identical to the existing recording options.

Perhaps multiple recording streams could be set for each Frigate camera, with a special designation to support scenarios beyond a single main and a single substream.

Describe alternatives you've considered
The only alternative which I can see is creating a new camera within Frigate which separates the substream from the main stream. I don't like that, as it will clutter the interface and make management unnecessarily difficult.

Additional context
This feature would be very useful to me and I imagine it will be useful to others as well. It is extremely nice to have.

[lordratner]

I can't see how this would be value-added. Adding the stream as a separate camera seems like the exact correct solution for your use case, which is treating the substream in a different manner than the main stream

[tearfulnumpty]

The value-added is to more than one user, as this has been a previously requested feature already: #2652

The use of a substream for recording purposes makes sense, as creating an additional camera in Frigate will clutter the user experience and ruin other aspects of functionality in the process, not to mention add a lot of extra configuration requirements. Logically, a single Frigate camera should respect a single physical camera. This behavior is already the motivation for allowing separate stream connections for live viewing, detection, and recording in the present feature set. The ability to record more than one stream seems only logical.

The substream doesn't need to be treated differently - it only needs to be recorded in addition to the main stream. It makes no sense to create a separate camera interface for the same camera as opposed to merely having the ability to record more than one stream.

This is all the more relevant due to Frigate developers making the conscious decision to prevent viewing livestreams from all cameras at once, and only allowing the viewing of screenshots of all cameras at once. Additional effort would have to be taken to view the standard system overview without duplicates via camera groups, all for no gain.

In addition, viewing recordings of the separate cameras again becomes more complicated, as you'll again have duplicate previews appear when viewing playback. Detection will either be fighting duplicate efforts against cameras, or will be limited to only one of the cameras, which will again make administration and manual review all the harder.

Substream recordings open many additional opportunities, which neither preview streams nor the main stream allow for due to quality and bandwidth reasons. The main stream is often too high of quality for efficient use, and the preview stream is far too low of quality, nor can the preview stream seemingly be exported immediately from Frigate. The simple ability to record them and allow their use in APIs makes perfect sense for enabling additional functionality and extensibility of Frigate. It shouldn't be much "new" code given that I'm not asking for a completely new feature, but rather the ability to record more than a single stream per camera, with retention settings per stream.

I can't see a single argument against it as a feature, and I'm extremely confused by your comment's motivation.

[hawkeye217]

This is all the more relevant due to Frigate developers making the conscious decision to prevent viewing livestreams from all cameras at once, and only allowing the viewing of screenshots of all cameras at once. Additional effort would have to be taken to view the standard system overview without duplicates via camera groups, all for no gain.

While this only indirectly relates to your feature request, I think it needs to be clarified that we have not made "the conscious decision to prevent viewing livestreams from all cameras at once". This is an entirely incorrect statement.

To be clear, viewing streams on multiple cameras is fully supported by the Live dashboard and camera groups.

If you're speaking about continuous streaming of those cameras on a camera group, then you should know that we want to provide the best experience possible for users while taking into account their varying levels of technical expertise as well as our support capacity, which is done purely on a volunteer basis. We have chosen not to merge the code a contributor wrote for this particular feature in favor of an implementation that helps users not "shoot themselves in the foot" as easily, and thus increase our support burden.

This does not mean the feature is not coming, nor does it mean we have made a conscious decision to prevent it. In fact, the code has already been written and will be merged for Frigate 0.16.

[tearfulnumpty]

I'll agree with you that it's a separate issue from this discussion, but I also think that there's a historical clarification to be made here. Historically, the development team has been consistent in how they've treated this issue. My claim is far from the first post on the topic, here's one I found just a few days ago which of course you were a part of: #12697 There are others of course, but this is the most recent one that I have personally viewed. You have recently mentioned that it is coming in the future, but that wasn't always the case.

Time and time again, the response has been that the development team has a concern of dealing with unnecessary support tickets for people who cannot support X number of livestreams at once, yet attempt to do so. That has been a conscious choice to not provide it as even an option for the user up to this point, and it absolutely has been explicitly provided as the reason for such a deliberate choice. I don't care to argue the merits of this decision one way or the other, but it is factual that this has been the decision. You make the case for me in your own comment, right here for this exact support reasoning. If that is changing in Frigate 0.16, that is a relatively new development either way, so the historical treatment has been as I described above.

Like I've said, I'm not arguing for it one way or the other (I wasn't attempting to do this with the mention above either, just to clarify). I have my opinion on the topic, but it's not the point I'm making here. My point is that I didn't pull this statement out of thin air, and that there's at least a solid amount of time to back up my statement. My original statement was merely reflecting the current status of the issue in Frigate and how it impacts the use case, nothing more. If it is changing in the near-ish future, that's great, but it's not like I just made up a claim with no basis at all, either. I hope you can see my perspective and understand where I'm coming from here, no ill will intended.

[NickM-27]

I think you are conflating two different features / behaviors here. Your description was

the conscious decision to prevent viewing livestreams from all cameras at once, and only allowing the viewing of screenshots of all cameras at once

but that is entirely false. 0.14 supports displaying multiple camera streams at the same time on the dashboard and camera groups. Continuous streaming, which is the ability to have cameras stream live on the dashboard when there is no motion or object activity occurring on the camera, is an entirely separate request.

[NickM-27]

This discussion is neither here nor there, but I think it is important that we be clear about what we are talking about, especially when making absolute statements about what is and is not supported, and the intentions around that.

In any case, I have pinned this feature so it will be implemented at some point in the future. if anyone wants to try and implement it I would highly encourage you to create a discussion or reach out to one of the maintainers about how you want to implement it so we can make sure that time is not wasted implementing it in a way that doesn't align with changes we are looking to make in other related areas.

[tearfulnumpty]

I wouldn't define them as separate in the slightest. If I want to view a live stream, that inherently means not a once per minute snapshot, but an actual stream. What I described in terms of feature set isn't satisfied by static images, definitionally.

You can only watch multiple streams on the dashboard when motion is detected in 0.14. Don't get me wrong, I love that behavior (static images updated once per minute unless motion is present) as a feature and prefer it most of the time, but I also want the option to force live streaming in some scenarios. Personally I think defining a once per minute, still, static image as a livestream is the incorrect move, and it's no wonder there is confusion over that.

I'll be happy to move along though - just sharing my perspective.

---

Thank you very much for the pin! I'll be very grateful for the support.

[hawkeye217]

Thanks for your comments and feedback, we really appreciate it.

[NickM-27]

Personally I think defining a once per minute, still, static image as a livestream is the incorrect move, and it's no wonder there is confusion over that.

Nowhere is a once per minute static image being defined as a live stream.

This seems to indicate that you have no idea how the UI works. For any camera where motion or object activity is detected a full res / full fps continuous stream is shown (assuming you have go2rtc setup). If all of your cameras are seeing activity then they will all be live showing continuous streams. If there is somewhere in the docs this is not clear then it would be great to know where so we can correct that and make it more clear.

[shinyzard123]

IMO a stream is a live stream even if it is only conditionally shown, which is the behavior I personally prefer.

As far as the sub stream recording goes, as a former blue iris user this was a great feature to have and I think it will allow more users to have "continuous" recording enabled where it is mostly the sub stream but changes to the main stream when an object is detected. I do think that would require more code changes though to ensure that no recordings are saved twice (once for each stream).

[tearfulnumpty]

Nowhere is a once per minute static image being defined as a live stream.

You literally just defined it as such in your previous comment. Here, I'll quote you: "0.14 supports displaying multiple camera streams at the same time on the dashboard and camera groups."

You said such after quoting me about the feature itself, and then suggested that what I described is already present. The 0.14 version of Frigate does not have a way to force a continuous livestream of dashboards, which is the only way that this feature as described is met, as discussed by hawkeye even.

This seems to indicate that you have no idea how the UI works. For any camera where motion or object activity is detected a full res / full fps continuous stream is shown (assuming you have go2rtc setup). If all of your cameras are seeing activity then they will all be live showing continuous streams. If there is somewhere in the docs this is not clear then it would be great to know where so we can correct that and make it more clear.

No, that's simply not the case. I already explicitly stated this above in plain English. Here, I'll quote myself this time: "You can only watch multiple streams on the dashboard when motion is detected in 0.14. Don't get me wrong, I love that behavior (static images updated once per minute unless motion is present) as a feature and prefer it most of the time, but I also want the option to force live streaming in some scenarios."

I directly acknowledged the behavior of the existing Frigate dashboard "livestream" here, which you claim I don't understand. I'll give you the benefit of the doubt and assume that you didn't read my comment, but it really just comes across as overly negative with your opening sentence to that paragraph.

---

My goal here wasn't to argue or debate this point, but please don't misrepresent what is clearly written above in my comments. That rubs me very much so the wrong way.

[tearfulnumpty]

As far as the sub stream recording goes, as a former blue iris user this was a great feature to have and I think it will allow more users to have "continuous" recording enabled where it is mostly the sub stream but changes to the main stream when an object is detected. I do think that would require more code changes though to ensure that no recordings are saved twice (once for each stream).

That's another great use for this! Previews cover this slightly already, but not in the same (or honestly, even comparable) fidelity. I will say however that I think the ability to record both the sub and main stream at the same time should optimally still be left as an option to the user, even in event-only recording environments. There can still be merit in utilizing the substream over the main stream for API utility purposes, though of course this wouldn't apply to everyone.

[lordratner]

What is the functional difference between seeing a screenshot of no movement and a live stream of no movement? Give actual practical examples of when this makes a difference please. I'm not understanding it.

This thread shows why your suggestion is not as clear cut as you represent it to be. Even those agreeing have different ideas for how it should be implemented.

I doubt you mean for it, but your comments come off as entitled and pushy. Unpaid volunteers are maintaining this, and even the time they take to engage with hundreds of users like you and me with very specific requests for customized alterations to the code is impressive.

But they are making a product for the masses, and the more they add, the less suitable it becomes for the not-power-users. Especially when you can implement your less-common request as a second camera, you just don't want to.

Further, why rely on a substream and limit your options to the camera hardware/software? I'd rather see an option to create a lower resolution stream(s) of my exact specifications from the high-resolution stream, then use that for your use-case and others, be it recording, detection, or live streaming. But this would also be resource intensive, and it demonstrates how even users with similar requests have different desired implementations.

[tearfulnumpty]

What is the functional difference between seeing a screenshot of no movement and a live stream of no movement? Give actual practical examples of when this makes a difference please. I'm not understanding it.

As I've said several times now, I didn't come here to argue or justify this feature. I merely mentioned it above because the existing functionality of it in Frigate is indeed relevant to having two Frigate cameras represent a single physical camera. You asked for justification for not wanting two Frigate cameras, and I gave it. I didn't choose to argue the merits of a dashboard continuous livestreaming as a feature, but apparently I'm not alone in thinking it should be a feature given that it is coming in 0.16. It was one reason of several as to why adding additional Frigate cameras for a single physical camera isn't a great fix.

This thread shows why your suggestion is not as clear cut as you represent it to be. Even those agreeing have different ideas for how it should be implemented.

I have no clue what you're referring to - no one is disagreeing on implementation at all. The closest anyone came was the discussion on an option for object only recordings, but that is solved with an option that makes everyone happy.

I doubt you mean for it, but your comments come off as entitled and pushy. Unpaid volunteers are maintaining this, and even the time they take to engage with hundreds of users like you and me with very specific requests for customized alterations to the code is impressive.

I made a feature request, and wanted to discuss the feature. I didn't choose to drag the conversation in this direction, and tried to exit this off topic discussion several times. However, twice I was accused of making up factual inaccuracies, but this is objectively not the case. I showed how this is objectively not the case. I don't see how that is me being pushy in the slightest, or disregarding the FOSS nature of the project or people's time. If you feel otherwise, I'd love for you to quote me to support your case. I feel like I've tried to be extremely respectful here even in direct response to being accused of making up lies and in direct response to someone not reading my comment at all yet still correcting me. I really don't see how an argument can be made that I'm somehow, "misbehaving."

But they are making a product for the masses, and the more they add, the less suitable it becomes for the not-power-users. Especially when you can implement your less-common request as a second camera, you just don't want to.

That simply isn't the case - adding options hurts no one. You are also the only person in this entire thread, or even in the previous thread, who feels like adding a second camera to Frigate is a valid solution here. And again, I can't see any motivation for this decision.

Further, why rely on a substream and limit your options to the camera hardware/software? I'd rather see an option to create a lower resolution stream(s) of my exact specifications from the high-resolution stream, then use that for your use-case and others, be it recording, detection, or live streaming. But this would also be resource intensive, and it demonstrates how even users with similar requests have different desired implementations.

Why would you ever want to re-encode your stream as opposed to utilizing the existing substream? Even if this is indeed what you want to do, the ability for Frigate to record two streams with a single camera would allow you to accomplish your goal (which I believe you only made to try to argue that people have different implementation goals, since previously that hasn't been the case here) via go2rtc. Currently you simply cannot do so without creating a second Frigate camera, which has the previously discussed drawbacks and limitations. But if the above feature is implemented, then go2rtc would already allow you to re-encode the stream if you so desire. For 99% of cameras however, I can't think of many times when someone wouldn't want to use the built-in substream as opposed to re-encoding it, but that's not really relevant to this feature's functionality. The new feature as has already been defined would satisfy your requirement too, via go2rtc.

[lordratner]

What is the functional difference between seeing a screenshot of no movement and a live stream of no movement? Give actual practical examples of when this makes a difference please. I'm not understanding it.

As I've said several times now, I didn't come here to argue or justify this feature. I merely mentioned it above because the existing functionality of it in Frigate is indeed relevant to having two Frigate cameras represent a single physical camera. You asked for justification for not wanting two Frigate cameras, and I gave it. I didn't choose to argue the merits of a dashboard continuous livestreaming as a feature, but apparently I'm not alone in thinking it should be a feature given that it is coming in 0.16. It was one reason of several as to why adding additional Frigate cameras for a single physical camera isn't a great fix.

This thread shows why your suggestion is not as clear cut as you represent it to be. Even those agreeing have different ideas for how it should be implemented.

I have no clue what you're referring to - no one is disagreeing on implementation at all. The closest anyone came was the discussion on an option for object only recordings, but that is solved with an option that makes everyone happy.

I doubt you mean for it, but your comments come off as entitled and pushy. Unpaid volunteers are maintaining this, and even the time they take to engage with hundreds of users like you and me with very specific requests for customized alterations to the code is impressive.

I made a feature request, and wanted to discuss the feature. I didn't choose to drag the conversation in this direction, and tried to exit this off topic discussion several times. However, twice I was accused of making up factual inaccuracies, but this is objectively not the case. I showed how this is objectively not the case. I don't see how that is me being pushy in the slightest, or disregarding the FOSS nature of the project or people's time. If you feel otherwise, I'd love for you to quote me to support your case. I feel like I've tried to be extremely respectful here even in direct response to being accused of making up lies and in direct response to someone not reading my comment at all yet still correcting me. I really don't see how an argument can be made that I'm somehow, "misbehaving."

But they are making a product for the masses, and the more they add, the less suitable it becomes for the not-power-users. Especially when you can implement your less-common request as a second camera, you just don't want to.

That simply isn't the case - adding options hurts no one. You are also the only person in this entire thread, or even in the previous thread, who feels like adding a second camera to Frigate is a valid solution here. And again, I can't see any motivation for this decision.

Further, why rely on a substream and limit your options to the camera hardware/software? I'd rather see an option to create a lower resolution stream(s) of my exact specifications from the high-resolution stream, then use that for your use-case and others, be it recording, detection, or live streaming. But this would also be resource intensive, and it demonstrates how even users with similar requests have different desired implementations.

Why would you ever want to re-encode your stream as opposed to utilizing the existing substream? Even if this is indeed what you want to do, the ability for Frigate to record two streams with a single camera would allow you to accomplish your goal (which I believe you only made to try to argue that people have different implementation goals, since previously that hasn't been the case here) via go2rtc. Currently you simply cannot do so without creating a second Frigate camera, which has the previously discussed drawbacks and limitations. But if the above feature is implemented, then go2rtc would already allow you to re-encode the stream if you so desire. For 99% of cameras however, I can't think of many times when someone wouldn't want to use the built-in substream as opposed to re-encoding it, but that's not really relevant to this feature's functionality. The new feature as has already been defined would satisfy your requirement too, via go2rtc.

I don't think you are capable of hearing anyone's voice but your own. You have somehow made yourself the victim in this interaction, when you are no such thing.

"I didn't come here to argue or justify this feature"

That's a very bold and entitled position for an open source community. Let me tell you how it sounds to others:

"I don't need to explain why you should spend your own time working to make something I want, you should just do it because I want it."

Good luck with that, dude.

[tearfulnumpty]

What is the functional difference between seeing a screenshot of no movement and a live stream of no movement? Give actual practical examples of when this makes a difference please. I'm not understanding it.

As I've said several times now, I didn't come here to argue or justify this feature. I merely mentioned it above because the existing functionality of it in Frigate is indeed relevant to having two Frigate cameras represent a single physical camera. You asked for justification for not wanting two Frigate cameras, and I gave it. I didn't choose to argue the merits of a dashboard continuous livestreaming as a feature, but apparently I'm not alone in thinking it should be a feature given that it is coming in 0.16. It was one reason of several as to why adding additional Frigate cameras for a single physical camera isn't a great fix.

This thread shows why your suggestion is not as clear cut as you represent it to be. Even those agreeing have different ideas for how it should be implemented.

I have no clue what you're referring to - no one is disagreeing on implementation at all. The closest anyone came was the discussion on an option for object only recordings, but that is solved with an option that makes everyone happy.

I doubt you mean for it, but your comments come off as entitled and pushy. Unpaid volunteers are maintaining this, and even the time they take to engage with hundreds of users like you and me with very specific requests for customized alterations to the code is impressive.

I made a feature request, and wanted to discuss the feature. I didn't choose to drag the conversation in this direction, and tried to exit this off topic discussion several times. However, twice I was accused of making up factual inaccuracies, but this is objectively not the case. I showed how this is objectively not the case. I don't see how that is me being pushy in the slightest, or disregarding the FOSS nature of the project or people's time. If you feel otherwise, I'd love for you to quote me to support your case. I feel like I've tried to be extremely respectful here even in direct response to being accused of making up lies and in direct response to someone not reading my comment at all yet still correcting me. I really don't see how an argument can be made that I'm somehow, "misbehaving."

But they are making a product for the masses, and the more they add, the less suitable it becomes for the not-power-users. Especially when you can implement your less-common request as a second camera, you just don't want to.

That simply isn't the case - adding options hurts no one. You are also the only person in this entire thread, or even in the previous thread, who feels like adding a second camera to Frigate is a valid solution here. And again, I can't see any motivation for this decision.

Further, why rely on a substream and limit your options to the camera hardware/software? I'd rather see an option to create a lower resolution stream(s) of my exact specifications from the high-resolution stream, then use that for your use-case and others, be it recording, detection, or live streaming. But this would also be resource intensive, and it demonstrates how even users with similar requests have different desired implementations.

Why would you ever want to re-encode your stream as opposed to utilizing the existing substream? Even if this is indeed what you want to do, the ability for Frigate to record two streams with a single camera would allow you to accomplish your goal (which I believe you only made to try to argue that people have different implementation goals, since previously that hasn't been the case here) via go2rtc. Currently you simply cannot do so without creating a second Frigate camera, which has the previously discussed drawbacks and limitations. But if the above feature is implemented, then go2rtc would already allow you to re-encode the stream if you so desire. For 99% of cameras however, I can't think of many times when someone wouldn't want to use the built-in substream as opposed to re-encoding it, but that's not really relevant to this feature's functionality. The new feature as has already been defined would satisfy your requirement too, via go2rtc.

I don't think you are capable of hearing anyone's voice but your own. You have somehow made yourself the victim in this interaction, when you are no such thing.

"I didn't come here to argue or justify this feature"

That's a very bold and entitled position for an open source community. Let me tell you how it sounds to others:

"I don't need to explain why you should spend your own time working to make something I want, you should just do it because I want it."

Good luck with that, dude.

It's really impressive how you refuse to read what I've wrote, but still make bold accusations against me. It seems you literally just read a single sentence and nothing else. If you had read more than a single sentence, you'd see that what you quoted is in reference to the continuous dashboard livestreaming feature and not this feature.

I don't see the point in arguing the justification for a feature which is largely irrelevant to this one, and has already been agreed to be added to Frigate 0.16 - sue me.