HTTP live streaming of udp/TS input contents

[Sajad]

Hi all

I want to use Mistserver to setup a HTTP live streaming system which receives input as udp/TS stream channels and then user clients can access HTTP stream of the channels by certain HTTP url. 

I could setup Mistserver and work with the web interface as explained in quick start. Also I can define some streams like "udp://224.11.11.11:2000" but I am confused how can I access corresponding HTTP url of my streams. I expect there be a url like: "http://<mistservetr_ip>:<some_port>/<some_path>" to access HTTP streams.

Can anybody help me to find any solution please.

[Jaron Vietor]

Hello Sajad,

If you look on the documentation wiki here:

http://wiki.mistserver.org/index.php?title=Category:Connectors

each of the connectors listed will have their media URLs mentioned at the bottom of their respective wiki pages. That is where/how you can request the streams.

When defining a source like you are, keep in mind Mistserver's default source URL behavior, as described here:

http://wiki.mistserver.org/index.php?title=Server_API#Source

Since ffmpeg supports udp:// URLs, it should "just work", but depending on the codecs used you may need to have ffmpeg also re-encode your source stream, using extra options (see the wiki page for more information on that).

Error messages from ffmpeg are not printed anywhere currently, so you may want to try out the commandline by hand until it works and then let the server do it automatically as soon as you have the options figured out.

Good luck!

Regards,

Jaron Viëtor

--
You received this message because you are subscribed to the Google Groups "Mistserver.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mistserver+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Sajad]

Thank you Jaron 

Documentations are OK and helpful; but I just want to know why when I add a protocol in web interface of the server; its status is illustrated as Unavailable. I saw here a document about this issue and I saw that maybe some protocols are inactive while I pay the fee. Also I saw this warning message successively in server logs: 

[WARN] HTTP Connector is enabled but no HTTP-based protocols are active!

 know please tell me how can I activate this protocols.

Thank you

sajad

[Jaron Vietor]

Hello Sajad,

It sounds like you've only added the main HTTP connector but not any of the other HTTP connectors (HTTPProgressive, HTTPDynamic, HTTPSmooth, HTTPLive).

The message in the logs should disappear as soon as you add at least one of them. Make sure to add all the protocols you wish to use, as the ones that are not activated will fail with a "gateway timeout" error message.

All currently supported protocols are available in the free edition of the server, by the way.

The "Unavailable" message should disappear after < 30 seconds, if not it has most likely failed to start for some reason.

Currently the server won't be able to tell you exactly what went wrong through the logs (not yet, anyway) but you can get more information by starting the controller in non-daemonized mode (command line option "-n") and reading the console output.

Hope that helps,

- Jaron

[Sajad]

Thanks for your guidances. 

I found out that I didn't made all files of Mistserver binary package executable. I needed just a 'chmod +x *' command  to do this and prevent errors. The problem was that the main process of server was unable to execute other files of the package; because they was not executable. Also I found out URL of my streams as: http://server_ip:stream_port/info_stream_name.js

successfully. 

Now I think that I have just one step to complete my job and it is when I define some UDP url as input stream; I see it's status is illustrated as inactive or invalid input stream. I send input to the mistserver using after transcoding by ffmpeg. Can you guide me about special kind of codec or container maybe I have to use for transcoding the stream. I suggested mp4 codec for video and aac for video be OK but I am not sure.

thank you

sajad

[Jaron Vietor]

Hello Sajad,

For best compatibility use the H264 video codec and AAC audio codec. Using the "-f flv" flag is also a good idea. You should be able to use ffmpeg to pull in the UDP stream, transcode it, and then output it to mistserver over RTMP all in a single step/command.

Something like this (edit to fit your situation):

ffmpeg -i udp://.... -acodec h264 ...... -vcodec aac ..... -f flv rtmp://server-address:1935/play/streamname

Good luck!

- Jaron

[Sajad]

Hello again and thanks 

Finally I succeed to setup my HLS system using Mistserver. I can receive UDP mpegts streams as input by the Mistserver and stream them using HTTP-progressive on the Mistserver. Also I can read from rtmp URLs.

Now I face a new problem: When the UDP input stream is stopped and played again; Mistserver can't play it until restarted. It seems that Mistserver investigates inputs just as starting up. I thought that if I use TCP or rtmp as input streams to the Mistserver this problem be solved; but not effective. Previously I had this problem by the crtmpserver and solved it by using tcp as input streams of the server. But now have and recommendations for input live streams to the server?

Thank you

sajad

[Jaron Vietor]

Hello Sajad,

Could you be a little more explicit in your definition of "stopped and played again"?

The normal behavior of the buffer is that if input is removed and comes back:

- the stream resumes if the timestamps are still increasing as seen from the position of the last buffer contents

- the stream resets if this is not the case

Most likely your setup is causing the timestamps to go backwards when reconnecting, thus resetting the stream. It should still allow new viewers in that setup, though (existing viewers will be disconnected if the stream resets).

If you really have to restart the whole server software, this might be a bug - in which case could you provide the exact command line arguments and settings you're using (both for mistserver and for ffmpeg), so we can try to reproduce it?

Thanks,

Jaron Viëtor

[matt...@ymir.it]

Hello Jaron.
I am jumping inside this thread, because I'm trying to accomplish exactly the same task, restream an udp stream with mistserver.
By using your suggestion (ffmpeg from cmd line) everything works as expected.
I can grab the udp stream, encode and push to rtmp, all by using a single command.

ffmpeg -y -f mpegts -i udp://.. -re -vcodec libx264  -profile:v baseline -level 30 -preset slow -maxrate 500k -s 960x540 -acodec libfaac -ar 48000 -ab 80k -f flv rtmp://..:1935/play/test

Next step is using mistserver to grab content, avoiding command line.
This does not work, ffmpeg dumps and mistcontroller keeps trying to relaunch the same command, with no success.
For reference, parameter string is

udp://... -vcodec libx264 -profile:v baseline -level 30 -preset slow -maxrate 500k -s 960x540 -acodec libfaac -ar 48000 -ab 80k

From log, MistController keeps launching

ffmpeg -re -async 2 -i udp://.. -vcodec libx264 -profile:v baseline -level 30 -preset slow -maxrate 500k -s 960x540 -acodec libfaac -ar 48000 -ab 80k -f flv - | /usr/bin/MistFLV2DTSC | /usr/bin/MistBuffer -t 120000 -s test

I did found the relative code  inside controller_streams.cpp.

ffmpeg command has the first 2 parameters hardcoded, then user input concatenated, and last output settings.

ffmpeg -re --async 2 -i [USER_PARAMETERS] -f flv -

Too bad, ffmpeg is extremely sensible to parameter positioning. By removing "-re" from start, and putting inside "USER_PARAMETERS" after the input stream, ffmpeg works correctly.
Thus I did modify source, compiled and tested the "new" version.
No success :(

By manually using the same command, launched from shell, I can make things work as expected.
Full command, grabbed from MistController log is

ffmpeg -async 2 -i udp://@... -re -vcodec libx264 -profile:v baseline -level 30 -preset slow -maxrate 500k -s 960x540 -acodec libfaac -ar 48000 -ab 80k -f flv - | /usr/bin/MistFLV2DTSC | /usr/bin/MistBuffer -t 120000 -s test

Simple copy&paste, and everything runs.

I don't know what makes MistController thinks command does not work, maybe response time from ffmpeg is too high due to buffer length?
I can read in log "Process test fully terminated." after less than a second, while when running from command line ffmpeg does need at least 5s to start outputting to stdout.



Regarding ffmpeg parameters, IMHO, we do have 2 options:
1. Write a small parser, which will check and reorder ffmpeg parameters. Complex and hard to maintain.
2. Remove hardcoded parameters and let user provide full input string, maybe along with some "presets" written somewhere in documentation.

Let me know if I can provide useful informations or help with debugging.

Regards
Matteo

[Jaron Vietor]

Hello Matteo,

It will most likely be option two in the future, yes - if only for maintainability and compatibility reasons. We also plan to support some protocols natively, without ffmpeg in between, starting at version ~1.3.

I suspect the problem may lie in the command parameter parser, which is quite... naive, currently. Most likely it does or doesn't escape something that it shouldn't or should. I'll try and add some extra debugging output to see why this goes wrong. The ffmpeg input most is the most untested of all modes, so it probably has the most bugs left.

Thanks for being so helpful in troubleshooting this issue - hopefully it can be fixed soon thanks to your information. Will keep you posted through here and ask for more information or help if needed.

Thanks again,

Jaron

[Emmi]

Hi all, know that the thread it from 2013. but could someone please kindly show me or guide me on how i can input a udp live stream. the links that are mentioned donst work any more..

BR

Emmi

[Balder Vietor]

Hello Emmi,

We're currently testing native live UDP support on MistServer internally, so it's not quite ready yet to be used, but one way to use UDP live streams right now would be using an application like ffmpeg in between.

To use FFMPEG and MistServer you'll need to do the following:

1. Create an MistServer live stream at the streams tab.

You'll need to use "push://ip_device_running_ffmpeg" but can use "push://" to accept a push from anywhere in a testing environment. Remember the stream name you've set for this stream, you'll need it in ffmpeg.

2. Verify the ports being open at the tab protocols.

You'll need at least the RTMP port, but easier (and more practical) is to have all protocols open as it'll allow you to use everything MistServer offers.

3. Now you'll need to set up ffmpeg.

You can run it on the same or another device, just be sure to change the IP addresses accordingly.

ffmpeg can ingest the udp stream and push it as an rtmp stream with the following command:

ffmpeg -re -i udp://stream_url -acodec copy -vcodec copy -f flv rtmp://MistServerIP:RTMPport/live/StreamName

you can opt to change the codecs to h264 baseline and aac if you'd want/need to. You'll just need to replace the "copy" parts from the -acodec and -vcodec.

"-vcodec libx264  -profile:v baseline -level 30 -tune zerolatency" - The tuning should make the conversion as fast as possible, thus keeping your stream "live".

"-acodec aac -strict -2" - to convert any audio codec to aac.

Now ffmpeg should be ingesting the UDP stream and pushes it as an RTMP stream towards MistServer, if the stream quality is bad you might need to tweak the encoding a bit.

With kind regards,

Balder Viëtor

Product Management & Head of testing

Amphoraweg 5  2332ED Leiden  The Netherlands

mistserver.org ddvtech.com

+31 10 8080 619 (NL)  +1 408 677 5212 (USA)

--

You received this message because you are subscribed to the Google Groups "Mistserver.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mistserver+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.