Time difference between Test Runner reported media currentTime and actual media time ... =1.7976931348623157e+308

[jpiesing]

I see a lot of instances of the following in a report from the OF.

This is not something that can be investigated - 1.7976931348623157e+308 looks like a negative number printed as unsigned or a number that's not initialized at all.

Please change the error message to be something meaningful that can be used as the basis of an investigation.

The recording is available on request.

[yanj-github]

This issue is caused by the case that at current time 0.0 no correspondent video frame is found. timediff is calculated as "timediff = ct_event.current_time - mezzanine_qr_code.media_time", if there is no correspondent video frame is found in recording where the current time is reported timediff is set to max value which is 1.7976931348623157e+308.

I am considering the following options for fixing this:

• Change it to report “currentTime=0.0 no video frames presented and time_diff cannot be calculated” instead, this will fail the observation regardless of other currentTime
• Skip the checks (pass) for currentTime for those cannot find the matching video frame, this will pass the observation if all other currentTime pass

[jpiesing]

Surely there are 2 scenarios for how this could happen. 1) First frames are not visible - which should be another error and/or 2) First frames are visible but are delayed relative to currentTime, which may be another error depending on how much they're delayed by. If we review the tolerances (which we should) then it's quite possible that displaying the 1st frame of video when current time is 40ms is a pass.

[yanj-github]

@jpiesing will you be able to share the full result together with the currentTime diff csv file in log folder please? If you cannot get track of the result history will you be able to share the recording in email please? It would be helpful for further analysis. Regarding to: First frames are not visible - is captured on another observation which is "every sample is rendered".

[yanj-github]

Thanks @jpiesing for sharing the result. Now I am clear with where this issue is coming from. currentTime=0.0 1st time - no video rendered currentTime=0.0 2nd time - no video rendered currentTime=0.0 3rd time - no video rendered ... .. currentTime=0.0 last time - video is started to show time_diff is reported ... ...

Shall we simply ignore duplicated currentTime report at the begining and only check for the last 0.0 please?

I think it should be a pass, at the last currentTime=0.0 if the time_diff is within the tolerance. And fail if the time_diff is bigger than the tolerance? It depends the interval of test runner status report. @louaybassbouss and @FritzHeiden, how often does the test runner reports the currentTime status please?

[jpiesing]

@yanj-github I get the impression that you may be looking at this the wrong way round. The timeline of the media decoder is the master. currentTime needs to reflect that - not the other way round. currentTime can be zero for any number of frames.

[yanj-github]

Test Runner status is reported about every 200ms. When the start-up delay is longer than 200ms multiple currentTime=0.0 is reported. If we are happy that slow start-up is observed in a different observation, we can ignore duplicate ct=0.0 However, "when first frames are visible but delayed relative to currentTime, this may be another error depending on the length of delay" is not easy to observe. We can measure the delay from ct=0.0 till frame1, but the video play might have started anytime from last ct=0.0 till the next currentTime.

Following is an example of 25fps, I have put timeline in a table below where each square is representing 25ms.

ct=0.0							ct=0.0							ct=0.075
No video	No video	No video	No video	No video	No video	No video	No video	No video	No video	No video	No video	frame 1	frame 2	frame 3	frame 4
ct=0.0							ct=0.0							ct=0.175
No video	No video	No video	No video	No video	No video	No video	No video	frame 1	frame 2	frame 3	frame 4	frame 5	frame 6	frame 7	frame 8

When currentTime=0.0 we can ignore the duplicated status report. However, for the 2nd reported currentTime=0.0 both Frame 1 are presented but delayed, and the top one fails, while the bottom one passes. Based on this, I think we should ignore the checks for 1st currentTime status at the begining, in most cases ct=0.0.

[yanj-github]

@jpiesing and @louaybassbouss what I'd like to suggest is to skip the current time check at the begining where ct=0.0. Starting frame delay relative to currentTime is measured on start up delay anyway there is no point to duplicate the check here.

[jpiesing]

@jpiesing and @louaybassbouss what I'd like to suggest is to skip the current time check at the begining where ct=0.0. Starting frame delay relative to currentTime is measured on start up delay anyway there is no point to duplicate the check here.

I agree with skipping this check for all frames where ct=0 and there is no video except for the last frame where ct=0. If the last last frame with ct=0 has no video then that's an error isn't it?

Does the same issue apply to the random access tests when seeking to time=20s? I see error messages in these cases where time_diff is the same e+308 number but ct=20.0.

[yanj-github]

Does the same issue apply to the random access tests when seeking to time=20s? I see error messages in these cases where time_diff is the same e+308 number but ct=20.0.

I think we need to skip all where ct=0.0 and any special starting time e.g: ct = 20.0 for random access. Yes, they are same case.

If the last frame with ct=0 has no video then that's an error isn't it

For devices where the frame 1 is preloaded it will be always having video when last frame with ct=0. For others, in theory it is an error if the last frame with ct=0 has no video, but not measured on OF currently. How important is it to have this check included please? last frame with ct=0 is basically -1 recording frame of next ct report where with ct>0, and which measured current time match already.

[jpiesing]

September 12th meeting Agree with proposal in comment https://github.com/cta-wave/device-observation-framework/issues/48#issuecomment-1697593524 not to apply this observation for ct=0 when starting from the beginning of a stream and correspondingly for random access. Attempting to come up with an algorithm that works reliably for video frames shown when ct=0 risks being error prone and causing challenges from different manufacturers who believe their implementation is valid.

[yanj-github]

I have applied changes to the system to ignore the checks at the beginning where ct=0 or ct=random access time. The changes have been committed to the main branch.

[jpiesing]

I confirm this is fixed.