Enable longer output duration than input source

[nicholas-fr]

For long duration playback tests, the mezzanine source content may not be long enough (ToS is 12min14s).

Consequently, it would be useful to adapt the test script to loop the input source content (e.g. using ffmpeg -stream_loop -1), to generate longer annotated output.

[dsilhavy]

Related to testcase 8.19 as defined here: https://docs.google.com/document/d/1a4yroEi76U88k71iisdRzwhzcTFD7KxHHSJo4thsczA/edit#

I suggest to use content high bitrates. MSE implementations only allow a certain amount of data in the buffers before throwing a QuotaExceededError, see also Dash-Industry-Forum/dash.js#3853 as an "extreme" example.

Content suggestion:

• One CMAF Switching Set for video, one for audio
• One CMAF track per CMAF Switching Set
  • CMAF Video Track
    • Resolution: 1920x1080
    • Bitrate: 8000 kbit/s
    • Framerate: 30 fps
    • Codec: H.264 Main Profile, Level 4.0
  • CMAF Audio Track
    • Bitrate: 128 kbit/s
    • Sampling Rate: 44100
    • Codec: AAC

[jpiesing]

Is there any particular reason for 30fps rather than 25fps?
TP Vision may consider generating an IMSC1 subtitle track as well for DVB-I use-cases that use a native DASH player.

[dsilhavy]

Is there any particular reason for 30fps rather than 25fps? TP Vision may consider generating an IMSC1 subtitle track as well for DVB-I use-cases that use a native DASH player.

No, we can also go for 25fps, I was checking this for reference: http://dash.akamaized.net/WAVE/index.html

[nicholas-fr]

I suggest a duration of 2 hours, as the majority of movies last between 80-120min apparently.

I propose to generate 2 mezzanine streams:

• 1080p25 SDR 120min using Croatia
• 1080p30 SDR 120min using ToS

With the same annotations and audio as the current mezzanine streams.

Does anyone think a 1080p29.97 stream is also needed?

Please share any alternative proposals or changes.
Hopefully we can agree on this in our next call, and I can then go about generating these 2 streams.

[yanj-github]

* One CMAF Switching Set for video, one for audio
* One CMAF track per CMAF Switching Set

Is there any specific reason to have a switching set please do we want to test switching for long duration test? Or do you mean a CAMF track?

[jpiesing]

Is there any specific reason to have a switching set please do we want to test switching for long duration test? Or do you mean a CAMF track?

As far as I remember, since we are using a DASH MPD to describe all content, there is no such thing as a stand-alone CMAF track in our system. A stand-alone CMAF track is actually a CMAF Switching Set with one CMAF track.

[yanj-github]

On OF point of view length of duration is limited with spec of the recording device.
Long duration recording will not be a problem for professional cameras.
However, I just wanted to highlight that on some cameras:

• it overheated when capturing high frame rate for long duration and power off for cooling down
• Battery limitation for those only powered by battery
• Storage disk size (1hour recording is around 35GB)
• Also, long duration means longer downloading time and longer processing time on OF.

To support long duration test, user need to select a camera that supports long duration recording as well as suitable sized SD card.
Also, we suggest this test to be run on its own rather than with other tests in a same test session.

[jpiesing]

• it overheated when capturing high frame rate for long duration and power off for cooling down

  • Battery limitation for those only powered by battery

In another place, they are experimenting with a GoPro Hero 10 recording at 1080p100 or 1080p120 with the battery removed & just running off an external power supply. Stepping down from 2160p to 1080p was found to help with overheating. There's lots of discussion online about how to reduce overheating with this particular camera as well usage on the SD card.

[jpiesing]

Feb 15th meeting
Conclusion
1080p25 SDR 120min using Croatia
1080p30 SDR 120min using ToS

[nicholas-fr]

The first long duration mezzanine file has been uploaded here:
https://dash.akamaized.net/WAVE/Mezzanine/under_review/2022-07-20/

• 1080p30 SDR 120min using ToS --> tos_LD1_1920x1080@30_7200.mp4
• 1080p25 SDR 120min using Croatia --> in progress (expect to upload this on Monday 25/07 when I’m back in the office)

Same annotations and audio as the other mezzanine streams.

Related to cta-wave/Test-Content#39 and cta-wave/Test-Content-Generation#17

[rbouqueau]

Great, I can certainly process them next week when Croatia is available. Please let me know if there is a preferred place for storage (otherwise I will put it in a folder named after the date, as we had done with the splicing).

[cta-source]

What is the test strategy for long duration? Since it doesn't use the white noise audio, it must be manual?

An alternative is to loop the white noise PN1 file every 60 seconds and replace the current audio with that. I think I had offered to test a version of that if we went that route.

[nicholas-fr]

@rbouqueau The second file has been uploaded to the same folder:
https://dash.akamaized.net/WAVE/Mezzanine/under_review/2022-07-20/

• 1080p30 SDR 120min using ToS --> tos_LD1_1920x1080@30_7200.mp4
• 1080p25 SDR 120min using Croatia --> croatia_LD1_1920x1080@25_7200.mp4

Let me know if new versions of the 2 long duration mezzanine streams are needed to address the audio testing, to make it easier to generate the test content.
I can change the audio track to a loop of PN01v02.wav if that is useful.

[cta-source]

@nicholas-fr, I put some response and made a suggestion in Issue #46, can you please take a look there and consider that?

[nicholas-fr]

@cta-source Sorry for the delay Mike, your proposal looks good to me. I've generated the 2 streams suggested (10 min "Looping" and "Mixed" mentioned in issue #46), and will upload them tomorrow morning (CEST) from the office.

[nicholas-fr]

@cta-source The 2 test streams can be found here:

• tos_LD1_1920x1080@30_600_PN01v02_looped
• tos_LD1_1920x1080@30_600_PN01v02_mixed

[mbergman42]

@cta-source The 2 test streams can be found here:

• tos_LD1_1920x1080@30_600_PN01v02_looped
• tos_LD1_1920x1080@30_600_PN01v02_mixed

OK, there seems to be a glitch at each 30 seconds in the audio. Can you take a look? Up to that point of T=30s, every audio fragment (960 samples in length is my observation period) is correct. After that point, the results are difficult to understand.

[mbergman42]

@nicholas-fr, on further inspection: It looks like the initial 30 sec is what I expect, up until it's close to the 30 second mark. Then there may be a fade-out (note, my alignment may NOT match yours--my samples at e.g. 30s may be yours at e.g. 30.126s). Then there is a fade-in of the new audio. In the image below, the fade-out starts around 29.48s, then there is random noise and hum, then the new signal begins at about 30.007s.

The new signal is a copy of the old. So what I'm seeing is:
A. About 30s of audio with fade out
B. Fade in to restart the same audio as in A, again
C. Fade out again, after the audio in B has played about 30s
D. Go to B and repeat until 10 minutes.

Here's a visual:

[rbouqueau]

Is there an update on this?

[nicholas-fr]

I found a couple of issues that explain the problems, which should now be solved.
One issue was caused by the misconfiguration of an ffmpeg audio filter (amix).
Another issue is dependent on when the audio is encoded and packaged with the video (encoding it separately before packaging it with the video results in a small audio offset at the start).

The two updated test streams can be found here for @cta-source to evaluate:
http://dash-large-files.akamaized.net/WAVE/Mezzanine/under_review/2022-09-27/

[gitwjr]

@cta-source
Done for video. Audio needs more work. Mike will provide the updated script for generation. Plan to incorporate into the next mezzanine content update.

[mbergman42]

@nicholas-fr ; @rbouqueau ; @yanj-github : I've updated the base PN0x files ("build 3") and sent to you by WeTransfer. Changes:

1. Removed the silence (~75 audio samples, an artifact of filtering) from the front of PN01 to make PN01v03; this changes the MD5 hash value.
2. Renamed PN02v02-PN04v02 to PN02v03-PN04v03 (no changes otherwise to these files)
3. Updated the CSV file of hashes to include the new hash value of PN01v03

Testing indicates PN01 works looped up to 10 minutes and should be fine for longer durations.

[nicholas-fr]

Updated PN audio (PN01-04) and long duration content using looped PN01 audio was generated and included in mezzanine release v4:

• croatia_LD1_1920x1080@25_7200.mp4
• tos_LD1_1920x1080@30_7200.mp4

Further improvements to the audio are being worked on (#55), this issue has been resolved.