Added support for additional tags

derjust commented 9 years ago

Hi!

This pull request adds support for the tags

EXT-X-I-FRAME-STREAM-INF
EXT-X-I-FRAMES-ONLY
EXT-X-PLAYLIST-TYPE
EXT-X-ENDLIST
EXT-X-FAXS-CM

based on the latest spec v14 and Adobe's "addition": https://helpx.adobe.com/adobe-media-server/dev/configuring-content-protection-hls.html -

Please let me know if I violated any basic ideas or something. Happy to adopt accordingly.

(I don't know what happend on the fork and why it forked it based on v0.0.2. The v0.0.3 commit appear with different hashes in this branch, too?!)

Wopple commented 9 years ago

I don't know where those identical commits with different hashes came from, but it won't matter when I rebase to master. I will only select the new commits.

Since Adobe is adding things to the specification, I think it would be a good idea for the user code to be able to configure the parser to support different features not in the standard. This will require some architectural changes so I would like to wait on EXT-X-FAXS-CM.

I think the initialization vector can be relaxed and remove ParseExceptionType.INVALID_IV_SIZE altogether so we won't need Constants.IV_SIZE_ALTERNATIVE. I see no reason to only allow AES 128.

Wopple commented 9 years ago

It looks like the tag handlers are going to have to learn some new tricks. I did not anticipate multiple handlers sharing the same attributes. I can probably accept the inheritance for now and refactor it to use composition afterwards.

derjust commented 9 years ago

EXT-X-FAXS-CM: I see your point. Maybe for an iterims period: The spec asks that clients should ignore unknown fields. The library for the moment just throws an exception. What about this approach: All non-comment #EXT* lines are put at least in a Map<String, String> so they can be consumed - but obvious do not have any kind of checking on them. Maybe combined with a "STRICT" parsing (throws exception as of today) and a "LENIENT" mode having this additional Map with all the un-parsed stuff in it. That would work for me in the short term, too
IV length If you want to relax it, that's fine with me. I would highly assume, that any vector will be always 2^n and > 16. Maybe having such a check.
Handlers with shared attributes Agreed

Wopple commented 9 years ago

Strict and lenient modes sound fine for now.

derjust commented 9 years ago

Hi!

I hope I addressed all the issues and removed EXT-X-FAXS-CM for the time being. I got this lenient mode in the works but like to finish that PR before opening up too many construction sites in parallel.

Please let me know if the current master works for you.

Wopple commented 9 years ago

This PR has been merged with some minor alterations. I removed some unused constants, fixed a little formatting, and changed the wording for a TODO.

Please be aware that I am "merging" changes in this repo with rebase / cherry-pick. The reason is to provide a much more legible history. I recommend using rebase to catch your local branches up with master rather than merge since merge and rebase don't play well together in many cases.

iheartradio / open-m3u8

Added support for additional tags #2