Video tests utils and refactor

[awolant]

Description

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactoring (Redesign of existing code that doesn't affect functionality)
• Other (e.g. Documentation, Tests, Configuration)

What happened in this PR

• It adds new feature needed because of we want to be able to compare frames on avarage difference
• Refactoring to improve naming in video loader

Checklist

Tests

• Existing tests apply
• New tests added
  • Python tests
  • GTests
  • Benchmark
  • Other
• N/A

Documentation

• Existing documentation applies
• Documentation updated
  • Docstring
  • Doxygen
  • RST
  • Jupyter
  • Other
• N/A

DALI team only

Requirements

• Implements new requirements
• Affects existing requirements
• N/A

REQ IDs: N/A

JIRA TASK: DALI-2252

[awolant]

!build

[jantonguirao]

nitpick: the name sounds as if you were comparing the average of each frame. Maybe AvgError would do

[awolant]

Done

[dali-automaton]

CI MESSAGE: [3756531]: BUILD STARTED

[awolant]

@JanuszL @jantonguirao I have a question about this PR for you. I have some more utilities in the video test that I use for myself for test/debug purposes. One is SaveFrame method in the tests that allows me to save the frame as image and look at it. Second is this improvement to Compare... methods where I compare pixels in parallel. This gives me a significant boost in performance, when I run those video tests.
Do you think I could include them in this PR for future use, even if for example SaveFrame will not be called anywhere in the tests? I think this might be useful to others in the future, and since I already have that I think it would be ok, but wanted to consult it with you.

[JanuszL]

@JanuszL @jantonguirao I have a question about this PR for you. I have some more utilities in the video test that I use for myself for test/debug purposes. One is SaveFrame method in the tests that allows me to save the frame as image and look at it. Second is this improvement to Compare... methods where I compare pixels in parallel. This gives me a significant boost in performance, when I run those video tests. Do you think I could include them in this PR for future use, even if for example SaveFrame will not be called anywhere in the tests? I think this might be useful to others in the future, and since I already have that I think it would be ok, but wanted to consult it with you.

Yes, I think it would be useful to add it, even add it into the test but ifdef out so during debugging it can be easily turned on.

[dali-automaton]

CI MESSAGE: [3756531]: BUILD PASSED

[jantonguirao]

o you think I could include them in this PR for future use, even if for example SaveFrame will not be called anywhere in the tests?

Yes, I think those would be useful.

[awolant]

!build

[dali-automaton]

CI MESSAGE: [3757039]: BUILD STARTED

[JanuszL]

Can you add a docstring to describe how to use it?
What is the meaning of frame_id, sample_id, and batch_id?

[awolant]

Done

[dali-automaton]

CI MESSAGE: [3757039]: BUILD PASSED

[jantonguirao]

A suggestion: You could get a more even distribution of work per thread doing something like this:

for (int i = 0; i < nb_threads; ++i) {
  int start = nb_elements * i / nb_threads;
  int end = nb_elements * (i+1) / nb_threads;
  threads[i] = std::thread(func, start, end, i);
}

This way you also don't need to treat the last batch differently.

[awolant]

Done

[jantonguirao]

Suggested change

	std::string folder_path,
	const std::string &folder_path,

[awolant]

Done

[awolant]

!build

[dali-automaton]

CI MESSAGE: [3757576]: BUILD STARTED

[dali-automaton]

CI MESSAGE: [3757576]: BUILD PASSED