Enhance ChunkDribbleDelay to include bitrate approximation

[beazlr02]

I love ChinkedDribbleDelay it lets us test our media playback adaptive bitrate switching.

When we write these kind of tests we have to load our media segment off of the disk to calculate its size in order to work out what size of delay we need to simulate a particular speed of network.

I've ended up embedding this in a Transformer as I have access to the file at that time, however, it would be better if I could elevate this to normal mappings explicit in the test.

See here https://github.com/bbc/exoplayer-testing-samples/blob/master/app/src/androidTest/java/wiremockextensions/WireMockStaticFileFromRequestPathTransformerWithChunkedDelay.java

I apologise for the poor quality code :)

Something like this might be nice

responseDefBuilder.withChunkedDribbleDelayAt(bpsInteger)

And it slices the response into 4k chunks, or something, with the appropriate delay.

Cheers!

Ross

[tomakehurst]

Hey, that's a very cool use case! Nice to hear it's being used for something challenging like that. Have you considered writing it up in a blog post?

I'd definitely be up for adding this to the core feature. Do you feel like creating a PR?

[beazlr02]

Great,

If you could possibly spare some time to tell me how you want the API to like (both JSON and java) and a list of tests you would expect I can certainly give it a go.

[tomakehurst]

Sure, I'll try to give it some attention mid next week. Up to my eyeballs in yak hair until then unfortunately.

[tomakehurst]

Could you provide an example of what you've done to implement this? Would be a useful starting point to think about the API.

[beazlr02]

I think the API that would be useful would be something like;

withChunkedDribbleDelayAtRate(int chunkSizeInBytes, int bitrateInBPS)

It all boils down to this kind of thing.

https://github.com/bbc/exoplayer-testing-samples/blob/master/app/src/androidTest/java/wiremockextensions/WireMockStaticFileFromRequestPathTransformerWithChunkedDelay.java#L71-L76

I might actually try and rework this example so the API looks correct.

Again, just to restate, the advantage of specifying a chunk size and bitrate is you can apply a general mapping to all files your serving rather than having to know ahead of time how big each file is

[tomakehurst]

Again, sorry for the long pause. Having looked at what you've done in the exoplayer project, I agree with your take on how the API should look, so if you feel like raising a PR to that effect I'd happy merge it.

One thought - when using other throttling tools, they tend not to trouble you with choosing a chunk size, just the bit rate. I wonder if it'd be worth looking into how they do it, to see if there's a clever algorithm for choosing a sensible chunk size?