Fix opus silence potential to generate huge files

[neilkinnish]

This may not be the most optimal way to address the issue and I may be missing something. But this seems to work and resolve all the issues I have encountered where huge (example: 28gb) opus files can be generated.

[neilkinnish]

Looking deeper at this I think I can improve by checking next rather than passing the count, but I'd be interested in opinion / downsides of the general approach.

[lminiero]

I think it's already helpful to avoid those issues. Not sure about the impact on recordings, as sometimes they're caused by timestamp resets at unfortunate places and may mean some missing audio packets when the additional command line flags are not used, but it should be very few of them anyway. This looks fine to me already, but if you think this can be improved before we merge please do let me know.

[neilkinnish]

Updated to use tmp->next rather than pass the count.

[neilkinnish]

Not sure about the impact on recordings, as sometimes they're caused by timestamp resets at unfortunate places and may mean some missing audio packets when the additional command line flags are not used

I have tested across audio recordings that are fine and also 3 with issues.

It definitely resolves the issue of massive files which can impact the server / service quite badly and that I think is key (at least for me).

In all the results the audio was fine and playable. In one case of the 3 with issues it reported an issue with granulepos but played back okay and could be trasncoded to another format fine - I'm assuming this is because it didn't resolve some data issues with PTS at the beginning. Using -i and setting an arbitrary n also works and resolved the issue as it drops the frames with the issue I suppose, but you have to kind of guess the n and I would prefer not to.

[lminiero]

Thanks! I'll have to double check how this behaves with "normal" losses to compensate with silence, since they'd be much more frequent than GB files and we don't want to break those.

[neilkinnish]

@lminiero 👍

[lminiero]

Seems to be working as the current janus-pp-rec on an Opus recording with some occasional losses, so this looks good to me. Thanks, merging! 👍