Good day.
It would be preferable to have a hard set length.
If we implement this setting, you should implement your own player to concatenate all the fragments to play them correctly, because fragment will start from P-frame, not I-frame, therefore most players like VLC will not be able to play the fragment.
So before implementing this feature, please try the following approach to normalize key frame interval in recordings:
1) Publish WebRTC stream
2) Start stream transcoder using REST API
Code:
/rest-api//transcoder/startup
{
"uri": "transcoder://tcode1",
"remoteStreamName": "stream",
"localStreamName": "streamT",
"encoder": {
"keyFrameInterval": 30,
"fps": 30
}
}
3) Find transcoder to detect mediaSessionId
Code:
/transcoder/find
{
"remoteStreamName": "stream"
}
this query returns
Code:
[
{"localMediaSessionId": "42a92132-bcd1-4436-a96f-3fec36b32b37","localStreamName": "streamT","remoteStreamName": "stream","uri": "transcoder://tcode1","status": "PROCESSED_LOCAL",
...
}
]
4) Start transcoded stream recording
Code:
/rest-api/recorder/startup
{
"mediaSessionId": "42a92132-bcd1-4436-a96f-3fec36b32b37"
"config": {
"fileTemplate": "{streamName}-{startTime}-{endTime}",
"rotation": "300"
}
}
In this case, recording workflow is more complex, but key frame interval in stream recording will be one per second, so file splitting should not differ from metadata. And it is not necessary to implement your own player to play fragments.
Note that stream transcoding requires more CPU resources (near 3 streams 480p per CPU core).
