Allow unsigned integers in adaptation set id #487
Conversation
tonihei
force-pushed
the
allow_unsigned_int_for_adaptation_set_id
branch
from
114cf04
to
58baeeb
Compare
This avoids issues with potential number clashes with ID_UNSET. Also fixes some further parsing where adaptation set ids are referenced from manifest properties.
tonihei
force-pushed
the
allow_unsigned_int_for_adaptation_set_id
branch
from
729311f
to
4169386
Compare
|
After some further discussion during internal review, we switched the parsing to |
|
@tonihei thanks for making the changes. looks good to me 👍 |
|
@tonihei are we good with these changes? If you need any further information from my side, please do let me know. |
|
Yes, it's all merged in our internal codebase and you'll see it merged here too the next time we update our changes (~once a week). |
|
@tonihei Please help us understand the Media3 vs Exoplayer situation. We are still on the old Exoplayer and the migration is not planned any time soon because of some other dependencies. So how would we proceed here? Would all the changes that are being contributed to Media3 also be ported to Exoplayer, and vice versa? How long would the team continue supporting the old Exoplayer? Is there any difference in the timelines that the changes would be released, between the two? Would appreciate any information that you can share with us to handle this situation. Thanks! |
|
The code base is 100% identical and we push the same code to both repositories (just that we rewrite package names for ExoPlayer in the process).
I'm curious about this part. What kind of dependency prevents you from migrating? The migration step for your code should be very straight-forward with the migration script that does everything for you. As pointed out above, the code is fully identical, so this is really just about renaming package imports.
Given this is a bug fix, it will be part of any Media3 1.1.1 release and ExoPlayer 2.19.1 (which will be identical again). There is no guarantee we actually do such a bug fix release, but it's not too unlikely because there will always be a few things worth fixing in a release. We will also continue to push changes to both repositories for a while, but we are not planning to release ExoPlayer 2.20 (matching Media3 1.2.0). |
We depend on some third parties for their proprietary analytics and SSAI, who we work with using Exoplayer components. They are not planning to migrate yet, effectively blocking us too from doing it.
I just saw that 2.19.0 has been released and everything has been marked as deprecated. So can you please confirm that we will get another minor release that will have this change?
We are trying to understand your timelines so that we can bring those third parties to the table and plan the migrations accordingly. Would it be fair to assume that any fixes / enhancements you make for another month will be released on the old Exoplayer also? Appreciate the help, thanks! |
That's interesting. But I guess it's the same as them not updating from ExoPlayer version 2.x to 2.y, meaning you are blocked on 2.x?
I can't really confirm it, but we usually wait a bit to see what kind of bug fixes we accumulate and make a new bug fix release if needed. We've almost always done one in the past, so I'm fairly sure we end up doing Media3 1.1.1. and ExoPlayer 2.19.1 too. Your change isn't included in the main 2.19.0 yet because it happened after the internal branch cut off.
We just push to the |
Yep, that's basically it. Thanks a lot for the information @tonihei ! This is really helpful for us to plan our roadmap. |
…daptation_set_id PiperOrigin-RevId: 544601945 (cherry picked from commit 9513f2c)
Fixes #485