search

braice / MuMuDVB

A DVB IPTV streaming software
http://mumudvb.braice.net/
GNU General Public License v2.0
213 stars 133 forks source link

RFE: Multicast INPUT #154

Open lars18th opened 7 years ago

lars18th commented 7 years ago

Hi,

This tool is amazing! However, more and more EXTERNAL TUNERS are used (SAT>IP servers, Streamers, HDHomeRuns, Software Servers (TvH,etc.)...). Then, I suggest to start supporting these kind of "tuners". The first step can be quite simple:

So, you can define some network streams as "tuners" and the MuMuDVB can do the rest of the work.

Moreover, one MuMuDVB can be the input of other MuMuDVB instances! What is your opinion? Regards!

braice commented 7 years ago

Hello

I think the idea is a good idea. I don't have equipment here to test but I could draft some code and if you have some C knowledge you can help debugging it.

I'll think about the best way to do that. The architecture around the tuning code would have to be made a bit more generic.

Brice

2017-01-06 5:39 GMT-05:00 lars18th notifications@github.com:

Hi,

This tool is amazing! However, more and more EXTERNAL TUNERS are used (SAT>IP servers, Streamers, HDHomeRuns, Software Servers (TvH,etc.)...). Then, I suggest to start supporting these kind of "tuners". The first step can be quite simple:

  • Add support for multicast/unicast inputs.

So, you can define some network streams as "tuners" and the MuMuDVB can do the rest of the work.

Moreover, one MuMuDVB can be the input of other MuMuDVB instances! What is your opinion? Regards!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/braice/MuMuDVB/issues/154, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUUD2_B8oiih-rH1sz6zZLrOYF6_r9Vks5rPhnUgaJpZM4LcmRz .

lars18th commented 7 years ago

Hi Braice,

Great! For sure I can help for debugging and testing.

However, for testing I suggest this simple tool: tsplay (from the package "tstools" http://github.com/kynesim/tstools). You can use ANY transport stream (TS file) and loop it; the streaming output can be any unicast address or multicast (for multicast, only in Linux, not Windows). Here one simple example:

# ./tsplay file.ts 192.168.1.10:12345 -loop -hd -maxnowait off -buffer 4096

The "file.ts" can be any MPTS file, for example a full dump of a transponder.

Please, let me know how I can do it! ;)

m0yellow commented 7 years ago

little correction: it can play any MPTS which has sane timestamps. Which some ts-files straight out of offline encoding lack. This is caused usually from encoding video separately from audio.

So with this limitation, it can play any TS generated by a sane muxer. So check out multicat, and why does it need ingests on videolan.org.

My experience with external receivers: they are never constructed to give you full mpts, so they are dropping NIT packages at least. MumuDVB would have to deal with incomplete, and sometimes falsely recreated tables. Then you would need to have a pipe input at least, b/c we don't want to recreate libcurl, for dealing with and fetching from all this different http/https streamer implementations. If MumuDVB should deal with network input, we need the buffering (and maybe even reordering) code.

MumuDVB is very good in sending an arbitrary transponder coming out of a device (mpts) to different multicast addresses, and figures out the filters, multicast addresses, and what tables to recreate all by itself. This is MuMuDVB's USP.

TL;DR: "define" external tuners in config implies control over them. We are far from that. I would recommend accepting a pipe first, and deal with control and reception elsewhere (curl/shell/nc/multicat) for now.

I've tested some generic rtsp servers, GSS hardware, SAT>IP stuff, d-boxes and tv-headend streams to come to that conclusion.

lars18th commented 7 years ago

Hi m0yellow,

Good comment!

However, my suggestion is focused on "valid TS" inputs. Mainly, captured TS from air (DVB-S/T/C). With these files, it's difficult to have troubles, as are the same (or identical) to inputs from a tuner device (the current input for MuMuDVB). I don't recomend to focus on any IPTV input, only on "sane TS inputs).

My target is SAT>IP streamers (servers in continous play), so it's identical to a MuMuDVB server. However, I like to injest this on MuMuDVB for some processing. It's like a MuMuDVB-2-MuMuDVB. And for do this we need the unicast/muticast input.

Finally, multicat is a good tool. Quite complex, but powerful. But for this scenario (network input for MuMuDVB) is unnecessary. In any case, the idea of "PIPE INPUT" can be interesting. Using it with socat (better than nc) or curl is great. However, the control of the MuMuDVB when the stream stops or pause can be more robust with internal handling.

Regards!

m0yellow commented 7 years ago

I tried playing with socat and multicast, and socat couldn't handle the load of a MPTS! But curl (in http) can play 30Mbit/s quite nicely. Most SAT>IP stuff is only the reference implementation in different hardware and version. Did you have a chance to test this recently? My SAT>IP Tests are a few years back. I wonder if the clients support the m3u feature, because that would make them mumudvb compatible, and if the servers survive pid filter changes, like NDR changing local studios.

lars18th commented 7 years ago

Hi m0yellow,

I'm working at time with SAT>IP clients and servers, so I'm up to date. ;)

In any case I don't recomend to use the m3u feature, as it's only optional. Moreover, the main idea is enable multicast (or unicast) input to MuMuDVB... not HTTP streaming. Doing the transport using TCP isn't the best, and MuMuDVB is at time capturing from tuners. So, the most similar to a dvb tuner device is a UDP socket. Futhermore, the output of MuMuDVB is UDP/RTP unicast/multicast. Then is a good way to experiment with MuMuDVB-to-MuMuDVB functionality.

So, Braice what is your proposal? Are you considering to use libcurl? Or you prefer to handle udp sockets directly? You consider also that a pipe input is a good idea? The pipe can handle any external tool, like socat or ffmpeg.

Please, discuss this idea. I'm very interested on use MuMuDVB with network streams. Regards.

m0yellow commented 7 years ago

can you confirm the SAT>IP servers can do full transponder, or at least MPTS? I guess they have hardware filters, which won't pass all packets.

lars18th commented 7 years ago

Hi m0yellow,

can you confirm the SAT>IP servers can do at least MPTS?

Yes! All devices can do it. Pid filtering is fully supported, so you can select any combination of pids. So all the time is MPTS, never SPTS (even if only one program is output, as the PSI tables are for a MPTS).

can you confirm the SAT>IP servers can do full transponder?

No for all, but some. The protocol fully supports "pids=all". However, it depends on the hardware of the server. Some servers refuse this command (fortunately only a few), others try to send the full-TS but because the low performance a lot of packets are missed. And the best servers can server the full-TS without any trouble. This kind of the servers are the one that we like to support with MuMuDVB (they streams the full TS to the network and MuMuDVB process it).

I recomend, for example the DD OctopusNET. It can handle up to 8 different Transponders/Muxes at full-TS. Read the specifications for evaluate the support for full-TS. Some manufacturers indicates the maximum troughput supported.

I guess they have hardware filters, which won't pass all packets.

No, no. The pid filtering is controlled by the SAT>IP requests. You can filter any pid that you like, or request all. It's all user configurable. Identical to linux API for hardware tuners. In the SAT>IP environment "forced filtering" like ancient DVB tuners not exists.

m0yellow commented 7 years ago

can the SAT>IP servers configured to statically stream four frequencies, or do they require a client?

lars18th commented 7 years ago

Two options:

1) If you have a SAT>IP server with static streaming support (optional by the standard), you can statically stream a complete frequency TS, and if the server has 4 tuners, then you can statically stream the four. One device with this capability is the DD OctopusNET.

2) If your SAT>IP server don't have static streaming support, then you can use any of the open source tools to request the full TS (pids=all) and send to one multicast address. You only need to leave open the client (it's very lightweight).

3) And if your SAT>IP server doesn't support streaming to a multicast address, then you need to use one client as proxy.

My suggestion: purchase one OctopusNET!

m0yellow commented 7 years ago

just purchased a Max S8 this week for unicable tests . whoever wants to work on it can buy one. I would say you want it, right? As a suggestion I would comment out all the linuxdvb specific stuff in the source, and open a network socket with multicast from the OctopusNET instead of the device. This should work in theory.

lars18th commented 7 years ago

just purchased a Max S8 this week for unicable tests .

Me too! ;)

As a suggestion I would comment out all the linuxdvb specific stuff in the source, and open a network socket with multicast from the OctopusNET instead of the device. This should work in theory.

This is the goal: make MuMuDVB compatible with unicast/multicast upd/rtp input. No more LinuxDVB, please!

m0yellow commented 7 years ago

You can start with that if you have a OctopusNET, I'm soon out of reach of my DVB devices :( And braice is busy working. So If you have time to spare, do it!

lars18th commented 7 years ago

Hi m0yellow,

I'm also very busy, sorry! Also, from a testing/development view it's indiferent have a OctopusNET or MuMuDVB as server... if both send the full TS to a multicast (or unicast) address, you can't distinguish the source. Then, anyone can implement the network input for MuMuDVB.

braice commented 7 years ago

Hello

If I make you a way to skip the tuning part and get the data from a file would it be enough for you guys to start tinkering around network input ?

UDP/RTP inputs sounds the simplest (but with RTP we will have to handle the buffers and see how we manage out of order packets)

Brice

2017-01-25 16:16 GMT-05:00 lars18th notifications@github.com:

Hi m0yellow,

I'm also very busy, sorry! Also, from a testing/development view it's indiferent have a OctopusNET or MuMuDVB as server... if both send the full TS to a multicast (or unicast) address, you can't distinguish the source. Then, anyone can implement the network input for MuMuDVB.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/braice/MuMuDVB/issues/154#issuecomment-275235476, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUUD2UchTGxe_r0h-rhfKhRBZoHgazGks5rV7vLgaJpZM4LcmRz .

lars18th commented 7 years ago

Hi @braice ,

If I make you a way to skip the tuning part and get the data from a file would it be enough for you guys to start tinkering around network input ?

Yes. I offer, three options (select what you prefer):

1) FIFO input from file (perhaps the one you're thinking). 2) PIPE input (this is more simple for linking to other tools, however is very similar to fifos). 3) UDP unicast input without reordering and small buffers.

Regards!

lars18th commented 7 years ago

Hi @braice ,

Can you provide some skeleton to start developing/testing?

Regards!

braice commented 7 years ago

Hello

I have made an untested option : read_file_path which should allow you to specify a file instead of the dvb descriptors.

I am pretty sure it will fail somewhere because I have nothing to test it (I guess the specifying of the filters will not be happy)

So if someone may test and help me make it works it would be great

Brice

2017-02-17 4:32 GMT-05:00 lars18th notifications@github.com:

Hi @braice https://github.com/braice ,

Can you provide some skeleton to start developing/testing?

Regards!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/braice/MuMuDVB/issues/154#issuecomment-280601661, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUUD0msDLndnIu1jCYDbYcdBRpis4P4ks5rdWk4gaJpZM4LcmRz .

salvaaod commented 6 years ago

Hi Brace, I have a bunch of DVB-S/T to UDP-MPTS receivers, so, they will give me a whole transport stream in UDP without modifying anything,

Could you elaborate on how can I test this ? Anything in particular that you want me to test ?

lars18th commented 6 years ago

Hi,

I'm also interested on this. I recommend starting to support FIFO inputs. Why? Because using some other tool like socat it's quite easy to receive unicast/multicast streams and forward to the FIFO. Although a real UDP input in MuMuDVB will be desirable.

If you need some help, I can assist. Regards.

braice commented 6 years ago

Hello, If you have some code working I can merge it. The data acquisition is mostly done by mumudvb_poll.

The way I think would be the best to implement such feature would make an abstraction layer above the tuning part (that either tunes the card, connect the socket or just open the file) and an abstraction layer instead of the poll, depending on the source will address the proper one.

I don't have a lot of time to develop new features but I'll be happy to provide feedback, merge code or whatever can be helpful

Brice

AlbertEinsteinGlitchPoint commented 6 years ago

Hi lads

any further tests done on this IP tunner input data?

i will have some spare time within the next few weeks so i will start drafting a project for this.

as its definetly a must have option accept IP DVB tunner input

lars18th commented 6 years ago

Hi @AlbertEinsteinGlitchPoint ,

Thank you for your interest! Regarding this enhancement, all is stalled.

For example, with the "read_file_path" implemented by @braice

I have made an untested option : read_file_path which should allow you to specify a file instead of the dvb descriptors. I am pretty sure it will fail somewhere because I have nothing to test it (I guess the specifying of the filters will not be happy)

I do this test:

card=0
read_file_path=/tmp/multicast.in
multicast=0
unicast=1
ip_http=0.0.0.0
port_http=14068
autoconfiguration=full

However, if I use the HTTP API to see the TS, for example with "http://SERVER:14068/channels_list.json" I can't see any channel. So the conclusion is: this doesn't work!

Futhermore, using FIFOs you need to know that the server can close the socket if you stop to read. So a restart is needed.

I hope someone can work in a network input (multicast and/or multicast). I feel it can be more simple than file inputs, as it maintains the bitrate of the source.

Regards!

utelisysadmin commented 6 years ago

I am really struggling to understand why would you involve Mumudvb with a streams which is already converted to multicast / unicast. Isn't this somewhat redundant?

lars18th commented 6 years ago

Hi @utelisysadmin ,

I am really struggling to understand why would you involve Mumudvb with a streams which is already converted to multicast / unicast. Isn't this somewhat redundant?

Short answer: NO.

Large answer: Current implementation of Mumudvb uses only LinuxDVB as source. However, at time you can have a lot of other DVB sources. For example, a SAT>IP server, a HDHomeRun Server, a DVB-IP server, an IPTV source, etc. Even you can use another mumudvb instance as a source. And as the Mumudvb tool can do a lot of TS processing (PSI rewrite, SAP announces, CAM descrambling, HTTP unicast streaming, UDP to RTP conversion, etc.), then it will be interesting to support network (aka unicast/multicast) streams. In fact, it's a must have!

Regards.

Saentist commented 6 years ago

Some one make mistake between beckend and midware. Better use some iptv portal.

braice commented 6 years ago

Hello

Can you give the log, as I implemented without testing maybe there is a "stupid" mistake. On top of that if we fix simple file input it should make the implementation with proper sockets easier.

Brice

2018-05-02 12:12 GMT-04:00 lars18th notifications@github.com:

Hi @AlbertEinsteinGlitchPoint https://github.com/AlbertEinsteinGlitchPoint ,

Thank you for your interest! Regarding this enhancement, all is stalled.

For example, with the "read_file_path" implemented by @braice https://github.com/braice

I have made an untested option : read_file_path which should allow you to specify a file instead of the dvb descriptors. I am pretty sure it will fail somewhere because I have nothing to test it (I guess the specifying of the filters will not be happy)

I do this test:

  • I use "mumudvb" (or other similar tool, like dvblast; or a SAT>IP server) to stream a full MPTS to the multicast address 239.1.1.1:10000 from one DVB-S source.
  • I copy this MPTS to a FIFO file with the "multicat" tool: "multicat -u @239.1.1.1:10000 /tmp/multicast.in"
  • I check that this FIFO file works, for example with the "dvbsnoop" tool: "dvbsnoop -if /tmp/multicast.in".
  • I restart the multicat tool, and now I start the mumudvb tool (last version from the githug) with the command "mumudvb -d -vvv -c ./multicast.conf" and with this config file:

card=0 read_file_path=/tmp/multicast.in multicast=0 unicast=1 ip_http=0.0.0.0 port_http=14068 autoconfiguration=full

However, if I use the HTTP API to see the TS, for example with " http://SERVER:14068/channels_list.json" I can't see any channel. So the conclusion is: this doesn't work!

Futhermore, using FIFOs you need to know that the server can close the socket if you stop to read. So a restart is needed.

I hope someone can work in a network input (multicast and/or multicast). I feel it can be more simple than file inputs, as it maintains the bitrate of the source.

Regards!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/braice/MuMuDVB/issues/154#issuecomment-386033541, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUUDwNUKW9i_iEKCcAGQzOd0zMaUDDjks5tudsIgaJpZM4LcmRz .

lars18th commented 6 years ago

Hi @braice ,

Can you give the log, as I implemented without testing maybe there is a "stupid" mistake.

You can reproduce it in your environment:

card=0
read_file_path=/tmp/multicast.in
multicast=0
unicast=1
ip_http=0.0.0.0
port_http=14068
autoconfiguration=full

In my environment this doesn't work. And I don't know why. Can you check it, please?

Best.

braice commented 6 years ago

Hello

Unfortunately I am now in the US and I did not bought hardware compatible with the system here In short I think the logs of MuMuDVB (in very verbose mode) and wireshark should be a good place to start

Brice

2018-05-07 2:43 GMT-04:00 lars18th notifications@github.com:

Hi @braice https://github.com/braice ,

Can you give the log, as I implemented without testing maybe there is a "stupid" mistake.

You can reproduce it in your environment:

  • Use mumudvb to generate the streaming over one multicast address (ex. 239.1.1.1:10000).
  • make a FIFO, ex.: mkfifo /tmp/multicast.in
  • Fill the fifo with the multicast, ex.: multicat -u @239.1.1.1:10000 /tmp/multicast.in
  • Try the file input in mumudvb, ex.: mumudvb -d -vvv -c ./multicast.conf

card=0 read_file_path=/tmp/multicast.in multicast=0 unicast=1 ip_http=0.0.0.0 port_http=14068 autoconfiguration=full

In my environment this doesn't work. And I don't know why. Can you check it, please?

Best.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/braice/MuMuDVB/issues/154#issuecomment-386972691, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUUD3t-pUfE_s6NthyySG-pOn7qvmMEks5tv-0hgaJpZM4LcmRz .

lars18th commented 5 years ago

Hi @braice ,

Any news?

Unfortunately I am now in the US and I did not bought hardware compatible with the system here In short I think the logs of MuMuDVB (in very verbose mode) and wireshark should be a good place to start

Instead of a stupid and complex pcap capture, you can reproduce it using ANY valid TS file (for example captured from an ATSC tuner or DVB) as the source. You can replay it with any player (tsplay, for example) to the network, and then use my previous description.

From my point of view an alternative input for MuMuDVB besides the Linux DVB driver is a must have!

Regards.

braice commented 5 years ago

Hello

If you want to try debug it, I had written a "read_file_path" option some time ago

Unfortunately it seems that it is not working, probably because the tuning step is not properly skipped

If you have a file you can try and see what code get it stuck

I'll try to have a look next week on this

Thank you for your patience

Brice

Le jeu. 20 sept. 2018 à 17:13, lars18th notifications@github.com a écrit :

Hi @braice https://github.com/braice ,

Any news?

Unfortunately I am now in the US and I did not bought hardware compatible with the system here In short I think the logs of MuMuDVB (in very verbose mode) and wireshark should be a good place to start

Instead of a stupid and complex pcap capture, you can reproduce it using ANY valid TS file (for example captured from an ATSC tuner or DVB) as the source. You can replay it with any player (tsplay, for example) to the network, and then use my previous description.

From my point of view an alternative input for MuMuDVB besides the Linux DVB driver is a must have!

Regards.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/braice/MuMuDVB/issues/154#issuecomment-423335181, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUUDypiRFgAiCk74-WfohBO6NzwCCBOks5udATdgaJpZM4LcmRz .

braice commented 5 years ago

What can be complicated is the throttling from an hdd file, I just tried again it does not really work and I do not understand why.

I don't have a pipe input that is throttled properly.

If you have a chance can you try the read_file_path option and report your results ?

Thank you

Brice

Le jeu. 4 oct. 2018 à 20:54, Brice Dubost braice@braice.net a écrit :

Hello

If you want to try debug it, I had written a "read_file_path" option some time ago

Unfortunately it seems that it is not working, probably because the tuning step is not properly skipped

If you have a file you can try and see what code get it stuck

I'll try to have a look next week on this

Thank you for your patience

Brice

Le jeu. 20 sept. 2018 à 17:13, lars18th notifications@github.com a écrit :

Hi @braice https://github.com/braice ,

Any news?

Unfortunately I am now in the US and I did not bought hardware compatible with the system here In short I think the logs of MuMuDVB (in very verbose mode) and wireshark should be a good place to start

Instead of a stupid and complex pcap capture, you can reproduce it using ANY valid TS file (for example captured from an ATSC tuner or DVB) as the source. You can replay it with any player (tsplay, for example) to the network, and then use my previous description.

From my point of view an alternative input for MuMuDVB besides the Linux DVB driver is a must have!

Regards.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/braice/MuMuDVB/issues/154#issuecomment-423335181, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUUDypiRFgAiCk74-WfohBO6NzwCCBOks5udATdgaJpZM4LcmRz .

trollcop commented 2 years ago

I know this is an old request, but there's a bug with which fd is opened during read_file_path processing:

mumudvb.c:

-               iRet = open_fe (&fds.fd_frontend, tune_p.read_file_path, tune_p.tuner,1,1);
+               iRet = open_fe (&fds.fd_dvr, tune_p.read_file_path, tune_p.tuner,1,1);

If you open fd_frontend, card_read() later reads from fd_dvr.

braice commented 2 years ago

Hello

Looks right, could you please do a patch and a merge request ?

Thank you

On Fri, Apr 1, 2022 at 3:07 PM dongie @.***> wrote:

I know this is an old request, but there's a bug with which fd is opened during read_file_path processing:

mumudvb.c:

-

         iRet = open_fe (&fds.fd_frontend, tune_p.read_file_path, tune_p.tuner,1,1);

-

         iRet = open_fe (&fds.fd_dvr, tune_p.read_file_path, tune_p.tuner,1,1);

If you open fd_frontend, card_read() later reads from fd_dvr.

— Reply to this email directly, view it on GitHub https://github.com/braice/MuMuDVB/issues/154#issuecomment-1085878610, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACRID3QNGPGNB2LNOGGB33VC3YIZANCNFSM4C3SMRZQ . You are receiving this because you were mentioned.Message ID: @.***>

trollcop commented 2 years ago

Hm, Actually what I did was forked it to my account and made a fair bit of changes (goal was to make it build on Windows, which was completed). I also added a "named pipe" input mode where I have a tuner application locking a channel and creating a named pipe, and then mumudvb.exe reading from it. This avoids weird stdin/stdout piping etc.

Anyway, the changes are fairly minimal to make it build on windows, but because the project never had consistent indentation/tabbing style and lots of files had spaces at line ends and so on, the changes are quite severe as far as a patch goes.

Would you be interested if I opened a separate PR for this whole thing, or would it be a waste of time?

lars18th commented 2 years ago

Hi @trollcop ,

Great improvement! I hope @braice will want to merge your contribution. And please create a PR.

lars18th commented 2 years ago

Hi @trollcop ,

Thank your for the PR #290. 👍

One suggestion (for a future improvement) is to add support of the request in the head of this issue: the multicast input. When disabling the DVB-API (that has a lot of sense because not all platforms support it) the multicast input over the network continues to be valid. And a lot of devices/hardware/software could generate this multicast stream. So I hope someone will want to support it after your PR is merged.

Regards.

trollcop commented 2 years ago

Oh, good point. It should be less difficult to implement now with DVB-API optional.

On Tue, Apr 26, 2022 at 2:57 AM Lars The @.***> wrote:

Hi @trollcop https://github.com/trollcop ,

Thank your for the PR #290 https://github.com/braice/MuMuDVB/pull/290. 👍

One suggestion (for a future improvement) is to add support of the request in the head of this issue: the multicast input. When disabling the DVB-API (that has a lot of sense because not all platforms support it) the multicast input over the network continues to be valid. And a lot of devices/hardware/software could generate this multicast stream. So I hope someone will want to support it after your PR is merged.

Regards.

— Reply to this email directly, view it on GitHub https://github.com/braice/MuMuDVB/issues/154#issuecomment-1108869160, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDM5WFYDL37NDL6BPO5FCTVG3MILANCNFSM4C3SMRZQ . You are receiving this because you were mentioned.Message ID: @.***>

lars18th commented 2 years ago

Oh, good point. It should be less difficult to implement now with DVB-API optional.

Yes. However, we need to wait first until @braice will merge your PR. So be patient. 😉

braice commented 2 years ago

That should be done today :-)

On Wed, Apr 27, 2022, 08:44 Lars The @.***> wrote:

Oh, good point. It should be less difficult to implement now with DVB-API optional.

Yes. However, we need to wait first until @braice https://github.com/braice will merge your PR. So be patient. 😉

— Reply to this email directly, view it on GitHub https://github.com/braice/MuMuDVB/issues/154#issuecomment-1110606243, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACRID2FHNI6EXNVTEETJVTVHDO53ANCNFSM4C3SMRZQ . You are receiving this because you were mentioned.Message ID: @.***>

trollcop commented 2 years ago

I went ahead and implemented unicast/multicast input in commit https://github.com/trollcop/MuMuDVB/commit/f177c62eda6f5cda921343ae02ca58fcc326b54c

I've only tested unicast source as I don't have any quick way to test multicast. It should work with both ipv4 and ipv6 source addresses, and properly (i think?) handles multicast group joins.

I'll make a PR for this once the other stuff if/when the other stuff is merged.

On Wed, Apr 27, 2022 at 6:04 PM Brice Dubost @.***> wrote:

That should be done today :-)

On Wed, Apr 27, 2022, 08:44 Lars The @.***> wrote:

Oh, good point. It should be less difficult to implement now with DVB-API optional.

Yes. However, we need to wait first until @braice https://github.com/braice will merge your PR. So be patient. 😉

— Reply to this email directly, view it on GitHub https://github.com/braice/MuMuDVB/issues/154#issuecomment-1110606243, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AACRID2FHNI6EXNVTEETJVTVHDO53ANCNFSM4C3SMRZQ

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/braice/MuMuDVB/issues/154#issuecomment-1110753078, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDM5WEFEMSINA2CAMRNHILVHD7LVANCNFSM4C3SMRZQ . You are receiving this because you were mentioned.Message ID: @.***>

lars18th commented 2 years ago

Hi @trollcop ,

This sounds great. Unicast it's a good starting point. Because adding after multicast is straightforward.

trollcop commented 2 years ago

This sounds great. Unicast it's a good starting point. Because adding after multicast is straightforward.

multicast should already work with this code as-is, I just have no way to test it. You can pull the source and build, and try running it with

source_addr=multicast_ip and source_port=whatever_port

trollcop commented 1 year ago

it should already do multicast, i just have no way to test.

On Wed, Apr 27, 2022, 18:22 Lars The @.***> wrote:

Hi @trollcop https://github.com/trollcop ,

This sounds great. Unicast it's a good starting point. Because adding after multicast is straightforward.

— Reply to this email directly, view it on GitHub https://github.com/braice/MuMuDVB/issues/154#issuecomment-1110772675, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDM5WBVEXRY5Z7WCJLJNTLVHEBPDANCNFSM4C3SMRZQ . You are receiving this because you were mentioned.Message ID: @.***>

braice commented 1 year ago

Hello

First of all thank you !!! That seem like a great improvement. Indeed MuMuDVB has been made with several editors and several platforms without a linter so unfortunately spaces and indentation where "humanly consistent" A clean up is welcome !

On the windows patch, do you think you could also provide a binary that we could link on the website ? That would be a nice addition. The website is also under git so it should be fairly straightforward to make that change https://github.com/braice/braice.github.io

I will review the PR as soon as I can but overall I really want to merge it !

Thank you

Brice

On Fri, Apr 22, 2022 at 1:41 PM Lars The @.***> wrote:

Hi @trollcop https://github.com/trollcop ,

Great improvement! I hope @braice https://github.com/braice will want to merge your contribution. And please create a PR.

— Reply to this email directly, view it on GitHub https://github.com/braice/MuMuDVB/issues/154#issuecomment-1106431044, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACRID5Q6OP5EBETGQLUMLLVGKF6RANCNFSM4C3SMRZQ . You are receiving this because you were mentioned.Message ID: @.***>

trollcop commented 1 year ago

Hmm, I had auto-build workflow in my fork, if you want, you can copy that, and make one for the lunix build as well, and then you can automatically generate both .exe and lunix binary releases in your own fork as well: https://github.com/trollcop/MuMuDVB/blob/master/.github/workflows/msbuild.yml

It generated a binary few months ago but looks like that expired, I don't know enough how to make it re-run again.

The binary under releases is old

lars18th commented 1 year ago

Please @braice , could you try to merge the updates from @trollcop ? From my point of view the unicast/multicast input is a must have.

trollcop commented 1 year ago

hmm? this was already merged. i posted instructions how to use udp input a couple messages above

source_addr=multicast_ip and source_port=whatever_port

to do udp source. I've tested this before with ffmpeg as source

On Wed, Oct 12, 2022 at 18:40 Lars The @.***> wrote:

Please @braice https://github.com/braice , could you try to merge the updates from @trollcop https://github.com/trollcop ? From my point of view the unicast/multicast input is a must have.

— Reply to this email directly, view it on GitHub https://github.com/braice/MuMuDVB/issues/154#issuecomment-1275880302, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDM5WBUWWFURLNNA6JE5SLWC2BQNANCNFSM4C3SMRZQ . You are receiving this because you were mentioned.Message ID: @.***>

lars18th commented 1 year ago

Hi @trollcop ,

hmm? this was already merged. i posted instructions how to use udp input a couple messages above

I see a message on my email inbox today regarding this issue. So please, can you point to the corresponding merged PR? I don't found it.

trollcop commented 1 year ago

Hi @trollcop ,

hmm? this was already merged. i posted instructions how to use udp input a couple messages above

I see a message on my email inbox today regarding this issue. So please, can you point to the corresponding merged PR? I don't found it.

It was originally started here: https://github.com/braice/MuMuDVB/pull/290 documentation for UDP source updated here: https://github.com/braice/MuMuDVB/pull/294

Anyway, current -master branch has the udp receive code. You may have to build mumudvb with --disable-dvb-support to make sure it doesn't try opening DVB devices.