Open SteveR-PMP opened 6 months ago
@cosmin @joeyparrish this is from some testing after the PR for https://github.com/shaka-project/shaka-packager/issues/1393 was merged. looks like its still failing from what @SteveR-PMP is testing.
I think the problem comes from here. https://github.com/shaka-project/shaka-packager/blob/v3.2.0/packager/mpd/base/period.cc#L147-L155
// Iterate thru AdaptationSets and add them to one big Period element.
// Also force AdaptationSets Id to incremental order, which might not
// be the case if force_cl_index is used.
int idx = 0;
for (const auto& adaptation_set : adaptation_sets_) {
auto child = adaptation_set->GetXml();
if (!child || !child->SetId(idx++) || !period.AddChild(std::move(*child)))
return std::nullopt;
}
It's reseting the AdaptationSet id without updating the adaptation-set-switching SupplementalProperty during the MPD generation.
It feels unnecessary to me considering that the AdaptationSets have already been sorted in the beginning of the function (i.e. Period::GetXml).
System info
Operating System: all Shaka Packager Version: latest
Issue and steps to reproduce the problem
Issue 1393 was created to address a problem with adaptation-set-switching using representationIDs instead of adaptationsetIDs. The fix has a problem with the _--force_clindex. If _--force_clindex=false is set, the manifest is correct.
Packager Command: The problem becomes obvious with a large set of input files where the forced ordering makes a large difference. When used without _--force_clindex=false, the resulting manifest looks like this (grep "Adap|switching"):
What is the expected result? When used with _--force_clindex=false, the correct manifest is created: