Luke 37064 Posted December 8, 2012 Author Share Posted December 8, 2012 Done. Let me know if there are any issues. Link to comment Share on other sites More sharing options...
Luke 37064 Posted December 8, 2012 Author Share Posted December 8, 2012 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. Link to comment Share on other sites More sharing options...
Tikuf 663 Posted December 8, 2012 Share Posted December 8, 2012 Yup that is the hold up. I will seek the seek numbers. Link to comment Share on other sites More sharing options...
Luke 37064 Posted December 8, 2012 Author Share Posted December 8, 2012 you should be able to test it just by changing the FastSeekOffsetSeconds constant in BaseStreamingHandler. Link to comment Share on other sites More sharing options...
Tikuf 663 Posted December 8, 2012 Share Posted December 8, 2012 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. Link to comment Share on other sites More sharing options...
Luke 37064 Posted December 8, 2012 Author Share Posted December 8, 2012 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. Link to comment Share on other sites More sharing options...
Redshirt 1487 Posted December 9, 2012 Share Posted December 9, 2012 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. Link to comment Share on other sites More sharing options...
Luke 37064 Posted December 9, 2012 Author Share Posted December 9, 2012 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. Link to comment Share on other sites More sharing options...
Tikuf 663 Posted December 9, 2012 Share Posted December 9, 2012 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) Link to comment Share on other sites More sharing options...
Luke 37064 Posted December 9, 2012 Author Share Posted December 9, 2012 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? Link to comment Share on other sites More sharing options...
Luke 37064 Posted December 9, 2012 Author Share Posted December 9, 2012 Yea, the api is unified for both streamers. UI controls the bitrate. Link to comment Share on other sites More sharing options...
Redshirt 1487 Posted December 9, 2012 Share Posted December 9, 2012 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. Link to comment Share on other sites More sharing options...
Tikuf 663 Posted December 9, 2012 Share Posted December 9, 2012 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. Link to comment Share on other sites More sharing options...
Luke 37064 Posted December 9, 2012 Author Share Posted December 9, 2012 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. Link to comment Share on other sites More sharing options...
Luke 37064 Posted December 9, 2012 Author Share Posted December 9, 2012 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. Link to comment Share on other sites More sharing options...
Tikuf 663 Posted December 9, 2012 Share Posted December 9, 2012 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. Link to comment Share on other sites More sharing options...
Redshirt 1487 Posted December 11, 2012 Share Posted December 11, 2012 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. Link to comment Share on other sites More sharing options...
Luke 37064 Posted December 11, 2012 Author Share Posted December 11, 2012 Do you still see the stuttering problem? Do you see it at 1? Link to comment Share on other sites More sharing options...
Redshirt 1487 Posted December 11, 2012 Share Posted December 11, 2012 Haven't seen any stuttering for days. Just tried 1 and there's no perceivable difference from 5,10,15. Link to comment Share on other sites More sharing options...
Redshirt 1487 Posted December 11, 2012 Share Posted December 11, 2012 I'd say leave it at 10-11 and call it done. Link to comment Share on other sites More sharing options...
Luke 37064 Posted December 11, 2012 Author Share Posted December 11, 2012 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. Link to comment Share on other sites More sharing options...
Tikuf 663 Posted December 11, 2012 Share Posted December 11, 2012 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. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now