<div dir="ltr">On Sun, May 19, 2013 at 12:31 PM, Jean-Baptiste Kempf <span dir="ltr"><<a href="mailto:jb@videolan.org" target="_blank">jb@videolan.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
</div><div>This is what I said:<br>
<br>
>  - Do your first commits with the old code and transition. A rewrite<br>
>  from scratch is not going to be accepted;<br>
<br>
</div>But moving to C++ does not mean rewrite from scratch.</blockquote><div><br></div><div style>HLS version 4 multiplies the number of stream paths that can be taken. Now, in addition to offering streams with different bandwidths, an m3u8 file can also specify, among other things, multiple renditions for every bandwidth. Therefore, there are a greater number of states that the HLS player can be in.</div>
<div style><br></div><div style>Right now, the state of the player is maintained through a series of variables. In order to make it easier to manage the growing number of states brought by version 4, I would have liked to change the state management paradigm from variable-based to state-machine-based. C++ would lend itself well to that because each state could be represented by an inherited class derived from a base State class.</div>
<div style><br></div><div style>If I do that, however, I will have to change the current variable-based code to state-machine-based code or else the state will be maintained by two different methods and it will be confusing. But of course, this does not mean that everything is rewritten from scratch. For example, the code that parses the m3u8 file would be re-used, the encryption code as well, and possibly also the code that selects the stream based on bandwidth, the download code, etc. It's basically just the outer shell that would change.</div>
<div style><br></div><div style>Kevin</div></div><br></div></div>