Fix black photo issue on intel MIPI cameras (Bugfix)

[tomli380576]

Description

The gstreamer pipeline in the current camera_test.py was having trouble with cameras that require a "boot up time" because it was taking the 1st buffer, which is blank for these cameras, that reaches filesink. This PR adds a valve element that dynamically opens while the pipeline is running to allow the source to stay open for a few seconds before the photo is taken.

There was also an issue where <CameraTest>._width and <CameraTest>._height were never updated from 640x480 after we query the supported formats. This breaks on intel MIPI cameras because it only supports 1280x720 and it will complain about not-negotiated caps $\Rightarrow$ Error: Internal data stream error when <Pipeline>.set_state(Gst.State.PLAYING) is called. This is fixed as well but I'm not too sure if this was intentional. Do later tests depend on the image being 640x480?

Resolved issues

#1537

Documentation

The number of seconds to delay can be set by --wait-seconds <num_seconds>. Default is 3.

Tests

• Original unit tests.
• Validated on a few machines running 24.04 with intel MIPI cameras and the test runs normally. Machines with USB cameras are nice as usual and pass the test too.

[tomli380576]

Validated that valve exists on the default gstreamer installation on 16 and 18 so we should be good

[codecov]

Codecov Report

Attention: Patch coverage is 91.83673% with 4 lines in your changes missing coverage. Please review.

Project coverage is 48.88%. Comparing base (1938d60) to head (4d08d19).
Report is 184 commits behind head on main.

Files with missing lines	Patch %	Lines
providers/base/bin/camera_test.py	91.83%	1 Missing and 3 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1643      +/-   ##
==========================================
+ Coverage   48.85%   48.88%   +0.03%     
==========================================
  Files         370      370              
  Lines       40231    40265      +34     
  Branches     6793     6801       +8     
==========================================
+ Hits        19654    19685      +31     
- Misses      19857    19858       +1     
- Partials      720      722       +2     

Flag	Coverage Δ
provider-base	∅ <91.83%> (∅)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[tomli380576]

Just a quick note on multifilesink: I used it because with the way we are terminating the pipeline (time/num-buffers based EOS), filesink will write extra buffers after the initial valid buffer. Basically it made a file like this:

┌────┬────┬────┬────┐
│ F1 │ F2 │ F3 │ F4 │
└────┴────┴────┴────┘ 

where frame F1 is the actual photo we want, F2-F4 are the extra stuff that filesink kept writing until EOS was sent. This file is still open-able probably because the metadata only tells the image viewer to read up to F1 and just ignore the rest. This can make the image file excessively big if the image dimensions are big or the frame rate is high. I found that 1280x720 photos taken at 30fps was taking up to 7Mb of space when it only needs like ~200Kb.

It is doing extra file writes than necessary though, albeit I haven't found any negative side effects.

There are ways to do exactly 1 file write, for example valve ! jpegenc snapshot=True, valve ! identity eos-after=1, valve ! imagefreeze num-buffers=1, but they don't exist on ubuntu 16's gstreamer :(

EDIT: Another way to do 1 file write is to listen for an element message on the bus from GstMultiFileSink, and check that the message contains a file path. This doesn't apply to gst-launuch commands.

[fernando79513]

Good job here!
I think this implementation improves the current approach of ignoring the first frames and should be more robust in general.
I've left just some small comments here and there.

[fernando79513]

Good job!
LGTM +1