Add back the MPEGTS over HTTP streaming functionality with some extensions #71
Conversation
perexg
commented
Mar 8, 2012
perexg
commented
- for service, allow MPEGTS streaming with PAT/PMT tables
- optimize the loop mutex locking inside http_stream_run()
…sions - for service, allow MPEGTS streaming with PAT/PMT tables - optimize the loop mutex locking inside http_stream_run() Signed-off-by: Jaroslav Kysela <perex@perex.cz>
|
I added it my tree as I'm not satisfied with the mkv http streaming either. Works => thanks mkv streaming does not work with mplayer2 or vlc 2 while ts streaming works. I have a comment. instead of play/MTS why did you not enhance the play menu and alway have a default as when is no VLC plugin, it already propose different method (direct url, m3U, or local window as when the plugin is found). |
This saves about 30-40% of the CPU for MPEG-TS streaming (less thread wakeups and locking, optimized write() calls). Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Do not stop stream when an reconfigured event occurs. Signed-off-by: Jaroslav Kysela <perex@perex.cz>
|
The optimization part breaks ts recoding in my branch git://github.com/EricV/tvheadend.git |
|
My extpull-tsrec branch solves the ts recording clashes. |
|
Le 10/04/2012 10:45, perexg a écrit :
Thanks. Will have a look when back from vacation. I think the clone --eric |
|
I tested your branch and indeed it was working=> thanks. Can I abuse and ask what the latest patch fix the MTS reconfigure event" is supposed to cover and why mkv is not affected? |
|
If anyone is interested, initial support for libavformat is available at: What this means is that the stream is remuxed to either matroska or mpegts, while still allowing modifications to the stream (like pid filtering, image manipulation, transcoding, tagging and so on). to choose between muxers, either do: the libav dependency is optional and can be replaced with the built-in matroska muxer during compile time. |
|
The problem is not to have it in a tree. There are at least 4 trees that have TS support for both streaming and recording. Either its important for end users or not. If it is it should be mainstream. If not who cares... |
|
EricV, if it is going to end up in the main tree, it needs to be tested by people, don't you agree? |
|
My tree (and not my code) has been well tested ;-) |
|
EricV, I'm very well aware of the TS HTTP streaming code in your branch (I wrote the initial starting point). |
|
For someone that did the commit removing TS streaming this sound quite a curious statement. And your tree lacks TS recording that people use and like for time shifting/watch and record. Waiting to know where tvheadend is heading... |
|
EricV, What is it you find curious about that statement? |
|
You pretend you want to add back TS streaming support while you explicitly removed it at the first place. FInd that curious BYMMV. |
|
EricV, What makes you think I'm pretending? |
|
I tend to trust facts better than statement I guess. Facts proves you removed it. Statement is currently that you want to add it back. I will fully believe you when I will see TS streaming and recording back upstream. The more changes you and adam commit mainstream, the more complicated reintegration may be. I certainly would have merged pending pull request BEFORE starting modification unless you want to make architectural change first. But in the mean time, fact is, users currently have no mainstream TS support. |
|
Facts also prove I added initial TS support (under a different nick though since this was during the svn days, but still my work). That gotta count for something? |
|
In fact you primarily added streaming (that's clear in the changelog). And yes streaming is a nice feature! Streaming TS was simpler because you had no mkv remux to do. Then you removed TS streaming in favor of MKV streaming. Why? As explained, for me, there is no technical advantages of MKV streaming over TS when source is TS in general plus TS->MKV remux using tvheadend code is far from perfect (of course using ffmpeg remuxing is far better but also more costly in term of code size, dependency and CPU cycles. I doubt for example many NAS have libav ported). |
|
EricV, don't you think the plugin-like system I wrote yesterday would allow you to pass through the raw source as well? That would give you the option to use either libav, builtin mkv or raw source. |
|
Raw is the complete mux containing several TS for me. If by raw, you mean already remuxed TS, then yes it may be convenient. The question remain whether anybody will stand up to provide ready to go code that streams and record in TS in this new architecture. If you provide only the plugin system upstream and do nothing else, you make it even more complicated for user to add back TS as now there are trees and binary packages that juts do it. |
|
EricV, this pull request is regarding HTTP streaming. If you would like to discuss recording to disk, you should do so elsewhere. Regarding the mpegts pass through feature I initially added to the http server, the same thing will eventually end up inside my little plugin-system. I just haven't gotten around doing it yet. |
|
There are other PR for that namely ekass one. This one was just becaise you removed TS streaming Support. People wanting TS wants both (recording AND streaming). Why should I comment elsewhere. I just warm people that your plugin architecture will not provide TS recording and frankly speaking I do not think you really care adding it. .For records, It still thinks DLNA is better suited to perform transcoding. Unless you provide it, I still think you do not really care about TS and worse that adding the plugin subsystem will complicate enduser life until someones takes the time to readd TS. And BTW, the actual mainstream code does not handle EAC3 correctly meaning HD recording and streaming in whatever format would be broken in France. |
|
Again, this topic is about HTTP streaming. There are perfectly good bug reports for TS recording, EAC3, DLNA and so on. |
|
Its not about HTTP streaming in general its about TS streaming via HTTP. So saying your tree provides an alternative is somewhat misleading to say the least. And as adam stated you do not care about TS, I just wanted to put things back at their place. Commit TS streaming in your tree first using internal tvheadend muxer and then I will let you say it is an alternative. |
|
@EricV |
|
You wrote : "Regarding the mpegts pass through feature I initially added to the http server, the same thing will eventually end up inside my little plugin-system. I just haven't gotten around doing it yet." I see fixes that popped up just few minutes ago... |
|
Anyhow, if anyone else is interested in trying out my branch, feedback is appreciated. |
|
Will do when back home. No DVB hardware ATM. Side question what are the plan and timing for merging this code? |
|
The timeplan is as with many other open source projects, when its ready :) |
|
End users badly needing TS will appreciate the precision :-) This makes me question where now should someone add back TS streaming and recording support? In your tree, in the main tree? |
|
Eric there is no need to add the support back in, John is already adding the support. He has, in my opinion, created a very neat framework for handling this. He started with WEB streaming as that was probably easiest place for him to test etc... I would hazard a guess he's got at least a week or so to clean up the code and test stuff etc... And I'm sure he'd really appreciate any feedback on the performance of his fork. |
|
OK. Will wait then. But currently no TS recording and some bug fixes (EAC3, PAT/PMT periodic generation) and optimization for streaming missing currently AFAIKT. |
ghost
assigned
|
Most of the things have been merged with upstream now, including some of the optimizations. I did some benchmarks on my router and it seems to run pretty smooth. If something is missing, please file a bug report on redmine and I'll see what we can do about it. |
