ffmpeg RTMP input/output error

[Livio Tenze]

Dear all,

I am trying to use the push function of mistserver to publish a stream via mist.

I am using mistserver version 2.1.3. I set up the push stream as push://<ip>/test and I tried push://<ip>/live/test, but, when I use ffmpeg to send the live stream from a webcam:

1) in the ffmpeg command line I get rtpm://... Input/Output error (ffmpeg -f video4linux2 -r 15 -s 320x240 -i /dev/video0 -f alsa -i hw:0,0 -acodec aac -strict -2 -vcodec h264 -f flv rtmp://192.168.7.2/test/);

2) in the mistserver log I get some strange messages Push rejected - source host not whitelisted.

What is wrong in my procedure?

Best regards.

Livius

[Jaron Vietor]

Hello Livius,

The problem is your source is set to "push://<ip>/test" when it should be "push://<ip>".

Changing that setting should resolve your issue. Alternatively, if you use simply "push://", all IPs will be allowed to push.

By the way, the URL as used in the ffmpeg command should be rtmp://<ip>/live/<streamname>, but this is only checked after the IP is checked.

Regards,

Jaron

 

[Livio Tenze]

Thanks a lot, Jaron!

I will try as soon as possibile.

Thanks again.

Livius

[Livio Tenze]

Dear Jaron,

now the ffmpeg starts correctly, but in the mistserver webserver the live stream is tagged as unavailable.

The log file provides the following lines:

Nov 27 2014, 19:35:20 INFO MistOutRTMP|1393|src/output/output.cpp:154|Buffer has indicated that incoming track 2 should start writing on track 2, page 0

Nov 27 2014, 19:35:20 INFO MistInBuffer|1388|src/input/input_buffer.cpp:222|Re-push initiated for track 1004, from user 0, will replace final track number 2

Nov 27 2014, 19:35:18 INFO MistOutRTMP|1393|src/output/output.cpp:108|Starting negotiation for incoming track 2, at offset 1

Nov 27 2014, 19:35:18 INFO MistOutRTMP|1393|src/output/output.cpp:154|Buffer has indicated that incoming track 1 should start writing on track 1, page 0

Nov 27 2014, 19:35:18 INFO MistInBuffer|1388|src/input/input_buffer.cpp:222|Re-push initiated for track 1003, from user 0, will replace final track number 1

Nov 27 2014, 19:35:16 INFO MistOutRTMP|1393|src/output/output.cpp:108|Starting negotiation for incoming track 1, at offset 0

Nov 27 2014, 19:35:13 FAIL MistOutRTMP|1393|lib/shared_memory.cpp:825|Creating copy of semaphore /statistics failed: No such file or directory

Nov 27 2014, 19:35:13 FAIL MistOutRTMP|1393|lib/shared_memory.cpp:845|Creating semaphore /statistics failed: No such file or directory

Another strange thing: if I open the embed info link, the stream description shows always 640x480 resolution. Is it possible to chenge this property?

Best regards.

Livius

[Jaron Vietor]

Hello Livius,

Are you using an OS X build, perhaps? There's a known problem with the latest OS X builds, which prints errors like the ones you're experiencing. I'd recommend the linux builds (if possible), or the windows builds as a second option. The mac builds really aren't intended for production use.

If not, a reboot of the machine might help resolve the issue. It's crude, I know, but it works. Sometimes the memory segments the software uses for IPC get into a unrecoverable state and rebooting is the simplest way to reset them. This should not happen more than once - if it does, please let me/us know.

The resolution is normally automatically retrieved from the video track(s) you're pushing, but defaults to 640x480 if there was a problem reading this information (most likely the same reason it won't play). So if all goes well, you shouldn't have to manually override this anywhere.

Hope that helped,

Regards,

Jaron

--
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.

[Livio Tenze]

Hello Jaron,

I am trying to use the mistserver on a beaglebone black: maybe this platform could be too "poor" to execute the mistserver. What do you think? The mistserver has been compiled for linux and the version I am using is the 2.1.3. I will test your suggestions and I will tell you other infos.

Thanks a lot for your help!

Livius

[Livio Tenze]

Hi Javier,

I tested again mistserver on the beaglebone black board.

The problem was related to the shmall and shmmax settings: I increased those values (by using echo xxxx > /proc/sys/kernel/shmall and shmmax). After this setup, the stream has started without problems. Up to now I have never changed these values in linux: is it any reason which justifies this behaviour?

Best regards.

Livio

[Livio Tenze]

Another update. I checked the configuration of my PC and beablegone black:

debian@beaglebone:~$ ipcs -lm

------ Shared Memory Limits --------

max number of segments = 4096

max seg size (kbytes) = 32768

max total shared memory (kbytes) = 8388608

min seg size (bytes) = 1

livius@opera:~$ ipcs -lm

------ Shared Memory Limits --------

max number of segments = 4096

max seg size (kbytes) = 32768

max total shared memory (kbytes) = 8388608

min seg size (bytes) = 1

The config seems to be the same (the PAGE_SIZE value is the same in both systems).

Best regards.

Livius

[Jaron Vietor]

Hello Livio,

Ah, yes, that makes sense. Since MistServer isn't a single application but rather a group of applications working together, IPC is needed.

The fastest IPC method that works cross-platform is shared memory, so MistServer relies very heavily on shared memory to communicate stream buffers and such between all the various parts of the software.

Most systems never see much use of the shared memory, and thus limits are often set quite low without the users knowing about it.

So, yes, there is a reason that justifies this behavior. There should be no harm in increasing those values permanently, by the way.

Perhaps we should start detecting shared memory settings and print some warning messages if they are set too low... I'll look into that.

Regards,

Jaron