Let's Reverse Engineer Discord

Re:Let's Reverse Engineer Discord by jagger27 on Monday January 13, 2020 @12:54PM (#22036792)

Wouldn’t it be possible to send a stream cipher encrypted packet of audio to a hub server where the codec has a “progressive” decoding mode? If I’m not mistaken, Opus can already do something like this. That way a client could set their desired bitrate and the server would truncate the packets before passing them off and doesn’t need to be re-encoded. This only works with a stream cipher though.

Maybe an audio engineer or cryptographer could chime in?

[ Parent | on HN ]

Re:Let's Reverse Engineer Discord by caffeinewriter on Monday January 13, 2020 @01:50PM (#22037326)

It looks like Ogg Vorbis has theoretical support in the spec for something called "Bitrate Peeling"[1], but there is no functional implementation for this yet, and there's been an open bounty on it since 2004.[2]

This is a really neat idea though. Truncating the packet to change the bitrate per client without re-encoding.

[1]: https://en.wikipedia.org/wiki/Bitrate_peeling

[2]: https://wiki.xiph.org/index.php?title=Bounties&diff=196&oldi...

[ Parent | on HN ]

Re:Let's Reverse Engineer Discord by duskwuff on Monday January 13, 2020 @03:51PM (#22038419)

Peeling has been a goal for many audio/video codecs in the past. Nobody's been able to make it work acceptably, though -- either the low-bitrate version sounds awful, or the high-bitrate version increases in size to the point that it might as well just have a low-bitrate version alongside it.

[ Parent | on HN ]

Re:Let's Reverse Engineer Discord by jagger27 on Monday January 13, 2020 @10:17PM (#22041487)

So in that case you could peel off whichever stream you don’t need, but you waste some upload bandwidth over simply negotiating a bitrate in advance.

[ Parent | on HN ]