Streaming Codecs & Containers

[Luke 40111]

Done. Let me know if there are any issues.

[Luke 40111]

Tikuf,

I'm noticing it takes longer to play when resuming now, most likely due to the slow seek. We're slow seeking by 15 seconds. Can you find the smallest possible value that will work? Thanks.

[Tikuf 663]

Yup that is the hold up. I will seek the seek numbers.

[Luke 40111]

you should be able to test it just by changing the FastSeekOffsetSeconds constant in BaseStreamingHandler.

[Tikuf 663]

yup will have to test with Red and Scott to find the min. numbers. Have you considered perhaps making a resume roll back user configurable?

We can set the fast seek to x (yet to be determined) and the user could have the ability to have a small offset between y&z.

[Luke 40111]

If it gets requested we can add it, since it's not a bad idea. But I didn't put it in because it's not actually related to what we're trying to solve.

[Redshirt 1487]

Bringing this thread back on topic

 

I've converted my client to this new format. The android player appears to have various limitations in terms of codecs and bitrates. I have far greater success in getting playback to work if I specify the container/codec/bitrate for everything. Omitting anything pretty much ensures playback fails. That being said I'm still loving the new playback api. Far better for the clients to specify what we want rather than blanket values based on codec/container.

 

P.S... Luke, your not allowed to change the API today Last two days were hell adding and Java'izing all those data classes/enums and refactoring my code to work with the new itemlist & playback api calls.

[Luke 40111]

Hah, sorry. I think we're stable now. I've turned the streaming api into a dumb pipe, which is all I was planning to do. Back when I first started building it, I was trying to make the server smart about everything, and I had a feeling we would eventually have to move in this direction. I should have just gone with my gut.

[Tikuf 663]

Luke re hls are we still specifying the bitrate? We may have to to keep the segments under 5 meg. (I'm still finding my way through the changes)

[Luke 40111]

Tikuf,

Part of me thinks the same thing is going to end up happening with WEI. The smarter we try to make it, the more it's going to turn into guess work, and it will be hard to find values that work for all servers. Now that the ui has full control over quality, we could just leave it at that. If the user isn't getting great playback performance, they can just dial the quality down in ui settings.

 

What do you guys think?

[Luke 40111]

Yea, the api is unified for both streamers. UI controls the bitrate.

[Redshirt 1487]

I think we still need to have the server self aware to some degree. If a user requests a stream at a much higher bitrate than the server can transcode/stream. We don't want to have it pause and then have the user thinking mb3 is crap.

[Tikuf 663]

Im totally with you with the client specifying and the user having control (that way we cant be blamed lol). That being said to stay within spec for ios we are going to have to have an upper limit.

1900000 should keep all the segs below 5 meg easily.

[Luke 40111]

Or we could just supply WEI info to the UI's and provide guidelines as to what the default bitrates should be depending on the score.

[Luke 40111]

Im totally with you with the client specifying and the user having control (that way we cant be blamed lol). That being said to stay within spec for ios we are going to have to have an upper limit.

1900000 should keep all the segs below 5 meg easily.

 

That's fine. Ios can specify that. But other platforms don't need to be constrained by that.

[Tikuf 663]

Luke

The resume changes are not quite right the current code is producing

 

-ss 527.917 -i "input.avi" -ss 542.917 

 

which doesn't work.

 

We need to strip the milliseconds in the first -ss (fast seek) & subtract the FastSeekOffsetSeconds. The second -ss (slow seek) needs to be a separate value SlowSeekSeconds so that we can assign an offset value if required.

 

So the above command line would become if fast seek value was 15 and SlowSeekSeconds was 10 (which would rollback the resume point by 5 seconds).

 

-ss 512 -i "input.avi" -ss 10 

 

Currently the command fails on 2 levels, milliseconds are not stripped and we seek 527.917+542.917 into the video item.

 

I would like to be able to play with both these values separately, I may find that they will work as the same value but in doing this we could make a rollback time user configurable (to a degree) in the future.

[Redshirt 1487]

Just an update. I've tried Using 10 and 5 for the FastSeekOffsetSeconds. I didn't have a stopwatch handy or anything, but the resume is very fast and I honestly couldn't perceive a difference from 5,10,15 seconds.

[Luke 40111]

Do you still see the stuttering problem? Do you see it at 1?

[Redshirt 1487]

Haven't seen any stuttering for days. Just tried 1 and there's no perceivable difference from 5,10,15.

[Redshirt 1487]

I'd say leave it at 10-11 and call it done.

[Luke 40111]

The slow seek can be very slow at times, despite that it's working well for you now. No reason to waste server cpu cycles unless they're needed. I'm going to set it to 1 and if we see any issues we can always raise it.

[Tikuf 663]

Luke

Given that Red is seeing no time difference between values. I would suggest a higher value than 1 as the lower value of 1 may effect accuracy of the seek/resume (on long gop encoded source files) this may come into play with seeking within the file.

 

That being said I am not seeing any massive deviation in the final resume position on any of my files.