Added missing DASH-IF IOP profiles. #339
Conversation
|
Thank you very much for your addition. I have:
Still TODO:
Thanks again. Let us know if you have any remarks or update :) |
|
Hi, Romain! I've reviewed your changes, and here are some issues that I noticed (I also added some comments to some of your commits). DASH-IF IOP profiles You removed some profiles, and I don't understand why. And again, what MP4Box was using is DASH-AVC/264, which is described in the v2, section 6. I don't understand why valid and active profiles were removed.
Previous AVC/264 was "dash264". It's just one of the IOP profiles. It's in the IOP since the first version. My implementation wasn't changing anything regarding this. Old profile names were deprecated, and the new name is "dashif264", which is the same "dash264". IOP versions I noticed that you started to reference specific versions of IOP. This is not needed, because each IOP profile has its own unique identifier. Even if such profile will be deprecated, nobody will be allowed to reuse the old identifier. So, specifying the version of IOP is meaningless, and this may confuse people who will work with the code. For example, why the code says v2, if a specific profile is referenced in v1? This problem can be avoided by not referencing any version at all. And this is perfectly possible, since each profile has its own unique identifier. It doesn't really matter in which IOP version it was defined. About TODO It would be nice to see new IOP profiles before additional checks will be implemented. I'd propose to implement checks as a separate task. The reason is that new profiles would allow to produce correct IOP content, even without additional checks. Currently, people are locked to AVC DASH media up to 720p (dash264 profile). Proposed changes would enable people to go beyond this limitation, without the need to wait for some window in the 1st quarter of 2016 :). In other words, these checks are a nice usability addition, but it's not something super-important, without which it's not possible to use new profiles. |
|
Hi, thanks for taking the time to answer this. See my comments at eaeb430#commitcomment-14756422
I think you didn't realize the current option are now called IOP 2.0. I didn't finish the renaming of the new profiles you kindly introduced. This is internal stuff. I wanted to make sure we would agree on the principles.
I read them. That's how we chose the identifier with the involved people at that time (some from DASH-IF, see http://www.gpac-licensing.com/2014/08/21/ibc-2014-dash-avc264-support-in-gpac/). At a high level things seem clear but when reading the details it is not.
No, they are 3 different identifiers. But for the packager the code would be the exact same. Does it make sense?
They can already use the '-profile-ext' option from MP4Box :)
That more complex than that. We have thousands of users. We can deprecate, and hide the options, and update our docs. But as long as people use them and it costs us zero maintainance, we keep them alive. If we have to remove an option we have previously advertised, I would write a blog article to explain.
Yes, we can merge before the checks are done. |
|
I wrote on the DASH-IF mailing-list to ask for their vision. If the current way of adding IOPs is confirmed, I propose to revert my modification, merge the dash264#hd with the current code, and later finish the checks for all the other profiles. I'll keep you posted here. |
No, they're not just identifiers :) And their specific sections prove it. Let's take a look at IOP v2 for example. Compare sections 6 (dash264), 7 (dash264#sd) and 8 (dash264#hd). There are differences.
No, they can't. Extensions (table 2; It could work if we would need 720p content. In fact, section 8.1 of IOP v2 says: "Note: To signal conformance to both interoperability points, DASH-AVC/264 and DASH-AVC/264 HD, the @Profile attribute may contain both interoperability point indicators", but it's not clear what are the benefits of doing it.
Section 1 of IOP v3.1 says: "DASH-IF recommends to deprecate the IOPs in previous versions and deploy using one of the IOPs and extensions in this document". And what do we see in the table 1 and 2 down below? Yes, all profiles and extensions are there, and profiles introduced in previous versions of IOP have references to previous versions :). In other words, all profiles are still valid and active. Another proof is that if you'll take a look at how identifiers were adding throught the history (v1 => v2 => v3), you'll notice that profiles weren't changing. Every new version of IOP was simply adding new profiles. But, interestingly enough, section 8.1 of IOP v3.1 says: "Earlier versions of this document, especially version 2 [2] defines legacy IOPs". The only explanation I have for this is that profiles introduced in earlier versions (< v3) should not be used at all. This raises a question whether it makes sense to switch mapping from But even if it's true and only new profiles should be used, I guess it doesn't really affect initially proposed changes to MP4Box. For example, people who use v2 profiles will still be using these profiles until they'll switch to something else. Removing old profiles won't be easy, so there anyway will be some history in MP4Box. Given that, I guess it makes sense to support all profiles that were created until now, so that there won't be any gaps.
Let's see what they'll answer :). Would be nice if they would see this discussion, and maybe even join it. |
Agreed. My point was to say that the packaging is the exact same (aside from the URN and the possible checks).
Agreed. But the MP4Box option was not added for DASH-IF extensions but rather to support signal several profiles at the same time.
They expect the IOP v3 to only have extensions. They could deprecated the v1 and v2 profiles in the future if market shares are low. I agree with the philosophy of your patch. It just misses 'onDemand' versus 'live'. I'd like us to map the dashif(./#sd/#hd) to the current 'dashavc264' option. I propose to make a new branch based on that when I find time. Does it seem ok to you? |
Is it their answer? What exactly it means? They want to leave only extensions? What does v3 means in this context? I'm asking, because v3 introduced new profiles (sections 8.2-8.5). So, it's not clear what "only extensions" means.
But there's no such things in reality. "live" can also be used in the on-demand case (static MPD). It's more about segment addressing schemes. So, my changes remove this weird abstraction as "live" and "on-demand" (because readers of IOP won't find any mentions of these things in the document), and require from user to be more specific, whether
Changing mapping will be a breaking change. If this option was mapped to
I'm not sure I understand why it's needed. We already have 2 branches :), what's the point in the third one? |
This change resolves the issue #41. It adds missing DASH-IF IOP profiles, as well as obsoletes the current, wrong ones. Using obsolete profiles will produce a warning.
The logic of using DASH-IF IOP profiles was also changed. Previously, using
dashavc264:livewas implicitly enabling-url-template, for example. But since:liveand:onDemandparts are not included in the names of profiles anymore, users have to be more specific about what they want. For, example, in order to achieve the same behavior as in the previous example, the user must specify:-profile "dashif264" -url-template. For on-demand case, it will be something like this:-profile "dashif264" -single-segment.This change is only about correct identifiers for different DASH-IF IOP profiles. Strictly speaking, each profile has its own restrictions, so, ideally, MP4Box would generate some warnings or errors if the user wants to do something that is restricted. I'm not sure that it's needed, though. First of all, it would complicate MP4Box, which is bad. And another reason is that perhaps it's a job of validators to check for compliance.
Anyway, with this change, it's now possible to conform to different DASH-IF IOP profiles, using not only H.264/AVC, but H.265/HEVC as well.