Multiple output muxers

[john-tornblom]

I've been trying to figure out a way to allow the user to decide in what container the media is to be muxed into.
This PR represents a starting point of that, not be confused with a finished product intended for end users. The reason for me making a pull request is to reach out to developers and advanced users who might like to help me. There is no ETA what so ever, but the more YOU can help improving the code, the faster we can get a reliable solution into the main tree.

At this point, two muxers can be used. The built-in matroska muxer, or a simple pass-through muxer that will dump whatever container the source is in onto a file or a socket.

There is no need to point out the lack of pmt generation for the pass-through muxer, missing UI configuration or incorrect file suffixes. Although bug reports are useful, the main question here is if the approach I'm taking is a good one.

Bets way to test this is by http streaming:
mplayer "http://localhost:9981/stream/channel/ChannelName?mux=pass"
or
mplayer "http://localhost:9981/stream/channel/ChannelName?mux=matroska"

Changing the muxer for file recording should also work but require manual editing in the dvr profile config files or source editing.

And no, vlc nor any other pmt dependent media player works with mpegts pass-through at this point.

[EricV]

Look, you ask the planet if your new design is good but did not take care to provide two real muxers, then you do not explain how the end user will be able to control what happens (and yes that's why I bring the GUI here) and furthermore give the impression, along all your comments that:
1) you will choose for the end user because you know better,
2) will not add what many users care about: mpegts (if ever!) after pretending you will in the PR 71 comments as already pointed above.

So do not be surprised I do not applaud!

BTW : On 6) you just pick up GUI but do not answer if your code actually does what you propose for having multiple muxers having the same containers.

[john-tornblom]

@EricV
Again, very helpful, thank you!

[EricV]

My pleasure :-)

[adamsutton]

@EricV @john-tornblom before you two kill each other, I'm gonna wade in with my own thoughts. First a disclaimer, I AM NOT A STREAMING EXPERT (you should both already know that) so commenting on the detailed technical aspects is NOT by area (though I may stray and feel free to correct me if I do and am way of base).

1. Transcoding is completely OFF TOPIC. Transcoding almost certainly WILL be included (as an optional feature) in TVH in the future. But when/if that happens it has NO bearing on this particular feature. If John has got both bits of code in the PR, that simply an artefact of his currently development model, not an indication that these features are in anyway tied (although there are possibly "some minor" crossovers, like use of libav etc...).
2. No one is suggesting that John's implementation is "superior" to that of what has already been suggested. However I personally think the modular approach he's taking is a very good one, and ultimately WILL be a better solution than those currently suggested. Note: I AM NOT commenting on the technical content of the individual muxers here, just the framework.
3. One thing that gives John's implementation the edge, and sorry if this offends, but he has taken the time to implement it AND he's willing to put his time behind supporting it. He has joined the new TVH dev team and therefore that will give weight to what he does. That's not to say everything he does/will do is amazing, but simply that he's given a commitment to the project and that counts for a lot.
4. Any help that can be provided to ensure we get the BEST possible muxer implementations is definitely welcome. If there are elements of the existing muxers (including stuff John is adding) that are not up to standard then do point those out. Eric I know you mentioned some audio related stuff.
5. The current goal that I've suggested to John is that he get the basic framework working and fully integrated into TVH. By this I mean that the new muxer API should be included in ALL pipelines, DVR, HTTP, others (don't think there are at the moment)? etc... This will as a bare minimum include the existing TVH MKV muxer, i.e. we have the same functionality as currently in TVH, but with modular framework to make adding the new stuff much easier. However I think John will also try to include the pass thru muxer.
6. DLNA is in the feature list (for the future). I've no understanding of it myself, John obviously has some, Eric you seem to have best knowledge. However I am not sure, at this point, that it directly relates to this PR. However if there are concerns about the technical content of the muxer API John is proposing that would somewhat limit effectiveness when we come to add DLNA, then do point those out.
7. I REALLY don't get the whole URL argument. They are both completely equivalent in my eyes, though John's is a bit more flexible and fits the current model better. For example it requires no extensive changes to the HTTP handling code to add lots of new URLs. Merely processing of OPTIONAL configuration settings (where a client wants explicit control rather than relying on defaults).
8. John has NOT included support for explicitly selecting the MUXER module that is used. However he has pointed at that it would be trivial to do and I had already suggested to him that it would be a good idea to do this for several reasons, so I've no doubt it will be included (even if not in the initial version). However the initial version is unlikely to include libav muxer and therefore its unlikely there will be more than one muxer providing any given container format.
9. John is NOT proposing he will choose on behalf of the client except where the client fails to specify options. In which case TVH would have some form of built-in prioritisation for muxer/container selection.
10. John has NOT currently included support for exposing the capabilities of the muxer system. NOT because it isn't important, but because he's been trying to get the basic framework in place first. It will be included, but we need to think how it will happen. For example at this stage the only real API we have for querying TVH is HTSP. However there have been plans for a better JSON API for non-HTSP aware clients.
11. GUI settings are, in my opinion, fairly superficial at this stage. Feel free to disagree but I think it far more important that we include the fundamental framework and get that working first. Those using it initially will most likely be people capable of hacking the code if they need to override any built-in defaults. Also GUI configuration is something that many others can do once they know WHAT configuration options are available, thus freeing John to work on getting the core code right.

Ok rant over. I'm sorry if I've glossed over, missed or duplicated some points. Hopefully I've covered most stuff though.

I "think" we're all trying to reach the same end goal so let's try and work together on getting things right. If there really are serious concerns about the framework John is proposing then we do need to hear those now. Issues surrounding content/capabilities of the muxers and configuration options are valid topics but of lesser importance (other than to check/note what will be possible).

Regards
Adam

[EricV]

Do not worry I'm not even beginning to be upset ;-) When I'm upset I usually simply shut up to be sure to stay polite...

1. You change a design BECAUSE you expect superiority of the new design. What are the goals of the new design? Could be asked for epg code BTW...
2. I think I already said a modular approach is fine in theory. The devil is in the details and the current test case proposed does not prove concurrent muxer and container code is correctly designed. Current non muxer plugin enabled code is able will little effort to add TS streaming and recording. I just would like to make sure the plugin architecture code for muxer does!
3. So? I'm old enough to commit to something only if I think its realistic. Without published design goals its hard to evaluate the effort. Having to readd TS streaming code in a new framework is just an overkill if no other meaningful muxers are proposed justifying extra work. As already said, before committing new code, I would have at least merged the the existing PR for features people have been asking for. You said TS recording and streaming was used by many people but did make change that do complexify merge of existing PR. The way things goes the least confidence I have to have enough time to invest. Merging PR in a tree is something. Redeveloping the same code for an undocumented new framework whith new bugs opping up is something else.
4. This also means that people having added, enhanced, fixed TS streaming and recording code, need to redo the changes if they want to have it upstream. This is were I start barking because you seems to neglect your user base and the time people have already invested in feature they need. The way PR have been processed is also a bit light to my taste if you really want to know...
5. it relates to this PR because the way of presenting a single media source in different format (container/codec/resolution) has already been worked over and instead of reinventing the wheel you should consider it, especially because at the end only URL are presented and http streaming is performed...
6. That's the problem. Since you have no GUI proposed, you do not care to imagine how the client will be able to select the correct URL. You need a list of muxer and a list of codec by muxer then only, you can expect the end user to create URL for a given syntax. The question is not the URL syntax but how the end user will know what he can put in the URL.
7. Trivial I'm not sure because when cloning packets to deliver the same stream via several muxer, you will probably need to factorize part current internal muxer code. Then if muxer are sophisticated like libav using multiple threads, locking and priorities of threads among muxers may be complicated,
8. he does not say how the client get the options in the first place and that where I pointed the DLNA standard,
9. Good you start realizing that strandard API enable to have more client. Web API is indeed a good way and JSON a good technical response. Again DLNA is just another possibility
10. Its seems to me that in UML you start designing interface between components. This avoid discovering that at the end info is missing and that end user will be unable to interact with your software. YMMV. A framework is designed to do something and offer service to clients. What are the clients and what service do you want to offer. I mentioned GUI just because you have to think to the data you want to expose. Saying for example you will select a default muxer without specifying what information enables to do it is just meaningless. You must specify something. If plugins becomes binary and you start using dlopen like in XBMC, each plugin may pretend they are the default muxer for each codec. How do you arbitrate?

[adamsutton]

1. OK, I was overly impolite, I'll be more blunt. John's code/suggestion is definitely better to what is currently available in TVH because of the added flexibility and much cleaner implementation (talking about framework again and NOT muxer specific code). It's also a considerably better solution than the various hacks I've seen elsewhere to try and work-around this lack of support.
2. If you have a problem with the EPG code then please address that elsewhere, I'd be more than happy to walk you through the benefits of the new code.
3. Following on from pt 1: From what I can tell the current code requires some pretty nasty hacks to add multi-container support. It can (and clearly has been done) but that in itself doesn't warrant inclusion. Of course people are free to fork the project or offer help and try to steer the project.
4. So, we should just merge PRs simply because someone has written some code that a) we don't agree with the approach and b) we wouldn't want to support? You yourself have stated on numerous occasions you cannot commit to helping a project when you cannot be sure up front how much support might be involved in maintaining code (that you've written). What on earth makes you think we are so amazing that we can commit to supporting code with unknown support effort and for code we didn't write or agree with?
5. This doesn't mean we don't listen to our users. If we didn't listen to our users, we'd be saying why the heck should we include TS support when we (Andreas, John and Myself as the current dev team) don't need it? Are we saying that? Or are we trying to find a better way to include said support that we're comfortable with maintaining?
6. If there are particular PRs that you feel we've not looked at properly, please let me know and I'll make sure they're re-visited. PRs relating to TS excepted of course, since I think they have and are be discussing thoroughly. And if this is actually in reference to redmine, then I apologise you don't agree with my approach. I'm more than willing to accept any help performing a more thorough review of the issues, but there is only so much 3 people (2 of whom are fresh to the project) can achieve.
7. If you can provide a link to a simple to use library that's got good cross platform support etc... That would be really helpful and may well be of interest.
8. You've obviously not read my comments correctly. No one said we'd not given any thought to required configuration options, though suggestions on what you think is needed are welcome. Nor had we disregarded the idea that we need to expose the options. But diff people have different approaches to solving a problem. And this PR is to get feedback and pick up on missing stuff.
9. OK, I might be misunderstanding. But now it sounds like your arguing that exposing the option to select muxer module is a BAD idea because it adds extra complexity to the muxer code. If not what relevance does this point have to giving the client the option to select?
10. Providing a link to such an example would be useful, saves time Googling around.
11. If by "start realising" you mean we officially re-started the project a couple of weeks ago, then yes. If you're talking about the "old" incarnation of the project, it was already in andoma's feature req list, but he never had the time to do anything about it. If we can find someone willing to add it, then we'll certainly be open to including it.
12. Yes we all accept that doing nice formal design is good, but we also live in the real world and are working on a small OSS project where its far more common that design is by evolution. The last sentence is nonsense, selecting a "default" in the absence of ANY other info provided by the client is easy, TVH MKV or libav MKV (whichever we decide is better). That's not because we don't think TS etc... isn't valid, but MKV is still the default.

Adam

[EricV]

3. current hack expose two URL one for mkv one for TS. This is not completely different!
4. I have no problem with current epg code as I haven't tested it. I just wonder if configuration and usage usage will be documented..
5. If you don't merge PR, you will for sure never get support from their author. If you ask them to rework it because you changed the code after the PR, they may be reluctant too. Now the people that have submitted code, will likely no more care about upstream code. I'm not sure its a better approach.
6. So far its not in. I trust the facts no just intention.
7. Yes I was talking about redmine.
8. I do not understand
9. That's what I did: multi muxer syntax, options exposed to end user. I would have preferred to be able to test concurrent muxing for real containers (same channle streamed in mkv and TS for example).
10. Not at all. I say you must expose options so that end user will be able to select them.
11. Example of what? JSON? DLNA?
12. You said that primary client is XBMC. Then HTSP is perfectly fine. I said I disagree because its too restricted. Now you propose to add other way to interact. I'm happy...
13. If two muxer provide a container, how can you select a default muxer one? Even for MKV, libav reencoding may be much more CPU demanding and just break a old atom/ion board. How does end user know what is the result of the default selection?

[bibinne]

........

[john-tornblom]

this is now merged with upstream, closing