Transcoding to H.264

[Greblys]

Are you not considering to add transcoding support to other codecs so that streams over internet would be more sustainable?

[lars18th]

Hi Greblys,

Use TVheadend for this. MuMuDVB has other target.

[m0yellow]

This has been a topic multiple times, this is a topic of another software connecting to mumudvb, there would be too much to duplicate. (ffmpeg/vlc/gstreamer).

[lars18th]

Hi m0yellow,

When MuMuDVB will have multicast/unicast streaming input will be possible to use ANY tool for transcoding, such as FFmpeg, VideoLAN or GStreamer. The config will be:

Source-->Transcoding Tool-->MuMuDVB-->Client

And, if you like the source can be also a MuMuDVB instance. I hope the implementation starts soon.

[m0yellow]

all tools mentioned have multicast output. none of them needs a feature in MuMuDVB. Transcoding doesn't happen in MPTS, so ...

MuMuDVB source (MPTS) -> transcoding software -> output (multicast SPTS) ...

what should MuMuDVB do with the SPTS? It is already in the right output format.

[lars18th]

Hi,

all tools mentioned have multicast output. none of them needs a feature in MuMuDVB.

Please, enumerate the functions that have FFmpeg, VideoLAN & GStreamer from this list:

Features overview
~~~~~~~~~~~~~~~~~

- Stream channels from a transponder on different multicast IPs
- Support for scrambled channels (if you don't have a CAM you can use sasc-ng, but check if it's allowed in you country/by your broadcaster)
- Support for automatic configuration i.e channels discovery and follow changes, see <<autoconfiguration,Autoconfiguration>> section
- Generation of SAP announces, see <<sap,SAP>> section
- Support of DVB-S2, DVB-S, DVB-C, DVB-T and ATSC
- Possibility to partially rewrite the stream for better compatibility with set-top boxes and some clients. See <<pat_rewrite,PAT Rewrite>> and <<sdt_rewrite,SDT Rewrite>> sections.
- CAM menu access while streaming (using a web/AJAX interface - see WEBSERVICES.txt and CAM_menu_interface.png for screenshot)
- Software descrambling through oscam dvbapi and libdvbcsa

Think on this: At time MuMuDVB can only have one type of inputs: physical tuners. That we need is support for other inputs, like network inputs, SAT>IP servers, Streamers, PIPE, etc.

If you need transcoding, then MuMuDVB can be in the chain after the transcoding or before. You don't need to care about it if MuMuDVB can read from the network.

So, it's really needed transcoding inside MuMuDVB? I don't think so! But, it needs network/pipe input? I think so! You need transcoding? Then use network input/output from MuMuDVB (network input on road).

Regards.

[m0yellow]

Feature	FFmpeg	VideoLAN	GStreamer	Note
Stream channels from a transponder on different multicast IPs	Yes	Yes	Yes	only VLC in one instance
Support for scrambled channels	ext.	ext.	Yes	ext. e.g. tsdecrypt
channels discovery and follow changes	No	Yes	Probably	this would need full transponder in the network, also for MuMuDVB
SAP announces	ext.	Yes	Probably	minisapServer can do this.
DVB-S2, DVB-S, DVB-C, DVB-T and ATSC	on linux	Yes	Probably
rewrite stream PAT/SDT/PMT	Yes	Always	Yes
CAM menu access	No	Yes	Yes
oscam dvbapi	No	Unknown	Yes	dvbapi can't be accessed through network!

That we need is support for other inputs, like network inputs, SAT>IP servers, Streamers, PIPE, etc.

If you need transcoding, then MuMuDVB can be in the chain after the transcoding or before. You don't need to care about it if MuMuDVB can read from the network.

this needs to be refuted.

1. things like CAMs are tightly coupled with the receiving hardware. I did get tsdecrypt to work, but get it to work with oscam across the network was way more work than moving decryption to the receiving machine.
2. MuMuDVB would need to have the transcoder create MPEG-TS compliant tables. If the transcoder does that, I don't know any transcoder not capable of multicasting it. If not, socat will do.
3. the only reason why you would need MuMuDVB after a transcoder is when you replace the original programme with the transcoded one. But this would need a super muxer, which can fill with NUL packets, or rebase the datarate. But I can't come up with a scenario why you would need the original mux. You need transcoding? Then use network input/output from MuMuDVB (network input on road). on the road? MuMuDVB is made for constant, continuous streaming. A road warrior use case needs HLS or MPEG DASH streaming, which ffmpeg, VLC or GStreamer can provide, but MuMuDVB can't.

So please here is my diagram, what is missing:

/dev/dvb->MuMuDVB->239.255.255.n:1234->transcoder->HLS->Client /dev/dvb->MuMuDVB->239.255.255.n:1234->Client /dev/dvb->MuMuDVB->tomcast->(remote)239.255.255.n:1234->Client

BTW: what can't be done with MuMuDVB alone, you can use the excellent software from http://georgi.unixsol.org. He is also did commits to https://github.com/gfto/dvblast

[Greblys]

I like the idea of using transcoder tool after MuMuDVB, but wouldn't it be possible to integrate transcoding tool more tightly with MuMuDVB so that you would need to install, configure and run only one package and the external transcoding tool could be added as a dependency to MuMuDVB?

I tried TVheadend today and got transcoding running. Video was still scattered, but probably because of different reasons now - poor hardware choice. But it seems that there is big flaw with TVheadend that it will transcode video separately for each connected client which is heavy on hardware resources. It would be much more efficient if you would transcode the live video once and multiple clients could stream the same transcoded version at the same time.

Also could I ask what are the biggest MuMuDVB advantages compared to the other similar tools?

[lars18th]

Hi m0yellow,

this needs to be refuted.

We comment here for better understanding. ;)

I like to clarify some key questions:

1) What you think is more relevant: adding "network input" to MuMuDVB or adding "transcoding" to it?

From my opinion, the first is a must have! At time, the physical tuner inside the same device that executes the MuMuDVB process is a no way for the future. More and more, all tuners be "external": USB, SAT>IP, STBs, etc. And more and more, the processes are executed in black boxes: containers, virtual machines, etc. So, capture from "/dev/dvb" will be useless in the near future. Alternatives? Capture from direct multicast/unicast... this is the output of a MuMuDVB instance. Then, you can use one instance to feed another instance in some other point of a network.

Futhermore, if you have several tools like FFmpeg, VideoLAN, GStreamer that can do transcoding and can read and write from/to the network... why not use them in combination with MuMuDVB to do the work? With network input (the only function not implemented at time in MuMuDVB) any combination will be possible.

2) Some of your assumptions are not fully true. Let me comment some of them:

• "rewrite stream PAT/SDT/PMT": This is very, very, very limited and faulty in FFmpeg, and not fully supported in VideoLAN and GStreamer.

• "dvbapi can't be accessed through network!": This is only true if you don't considere other protocols than can work over TCP sockets. The dvbapi can be compiled as a library to any linux tool and speak with other process using network sockets. Therefore, you don't need to care about it!

• "things like CAMs are tightly coupled with the receiving hardware": Completly false. The only requirement for a working CAM (CI, not CI+) is send all (or the relevant part) of the TS to the CAM device and read the output TS from the CAM. This can be inside the same device, or in another device. If you think about a "remote descrambling" then this is not allowed. But if you think on "remote tuning", like a SAT>IP server or a remote MuMuDVB instance, and a local player with CAM support... or a local MuMuDVB process with CAM support, then it's fully supported.

• "But this would need a super muxer": No, a DVB compilant muxer is only required for a CBR MPTS (or SPTS as pseudo-MPTS). Only when you need to bradcast a TS is strictly enforced to use a CBR, as the L1 medium is a synchronous network. In any other scenario, you can use without problems a VBR TS with a medium bitrate.

Finally, if you like transcoding inside MuMuDVB... it's a great idea. I gree! However, first this amazing tool needs to support "network inputs", like multicast/unicast udp/rtp. That's my oppinion. Regards.

[m0yellow]

To keep it short:

1. SAT>IP et al do already mangle tables, so MuMuDVB will have a hard time to work. Is there any tuner right now actually delivering MPTS?
2. rewrite in MuMuDVB is also very limited, it is basically a MPTS (compliant) to SPTS (somehow) converter.
3. have you actually tried to get tsdecrypt+oscam to work?

If you like it, do it. Just clone the source and try to get network input to work. Hack level one. If it works, great! I just assume there are lots of unknown roadblocks ahead, b/c I can't think of a source that works besides a dreambox MPTS output. To be fair, I have a 2x MPTS receiver sitting in the basement which would do, but a new receiver card (8x DVB-S2) costs not even half of that beast.

BTW: CI+ is only CI with a protected brand name.

[lars18th]

Hi,

SAT>IP et al do already mangle tables

No, SAT>IP only tunes and re-sends the TS over IP... nothing more, nothing less, except that it can filter. It's identical to any hardware tuner with pid-filtering using LinuxAPI. With the difference of a network access.

rewrite in MuMuDVB is also very limited

Not really! It can do several things!

have you actually tried to get tsdecrypt+oscam to work?

I use a software SAT>IP server that incorporates oscam support and one hardware SAT>IP sending the stream to it. Try minisatip or SatPI!

CI+ is only CI with a protected brand name.

CI+ it's just the same as CI with encrypted connection between the host and the CAM. So if you don't certificate the host, then you can't use the CI+ only CAM.