1

I am trying to implement the live streaming video from raspberry pi cam. I am a java developer having little knowledge of Linux.

I have successfully implemented the raspivid command to stream the live video on the web page using following command;

raspivid -t 0 -w 960 -h 540 -fps 25 -b 500000 -vf -o - | ffmpeg -i - -vcodec copy -an -f flv -metadata streamName=myStream tcp://0.0.0.0:6666

I am trying to add some controls on running live video steam like adding contrast and brightness etc

--contrast, -co Set image contrast (-100 to 100)
--brightness, -br Set image brightness (0 to 100)

but it needs to restart the complete raspivid command to take effect on web, like first to kill the raspivid process add the corresponding control and restart the complete raspivid command again. Is it possible to run separate commands for raspivid controls I mean different raspivid command to start streaming and different to add contrast and brightness without interrupting the previous command. If not then how we can do this?

Is there any way to write a sub process within a main process so that we can restart the sub process without affecting the main running process?

Thanks in advance

Raman
  • 1,945
  • 3
  • 19
  • 30

3 Answers3

0

This thread might help if all you want to do is fire the commands in different processes. However I'm not sure that will solve the problem. I would also read the info doc for rapsivid as the info docs are usually easier to read than the man pages. Just type info rapsivid at the command prompt.

How to execute system commands (linux/bsd) using Java

Community
  • 1
  • 1
Dan
  • 1,874
  • 1
  • 16
  • 21
  • Thanks for responding but thing is same for info docs and man pages. I haven't find anything regarding the raspivid controls to control the video stream with different processes. – Raman Aug 22 '14 at 11:14
0

For accepting (additonal) external controls, the raspvid application must be written in such logic. The easier way would be:

  • allows read program parameters from a file
  • on the some signal, e.g. SIGUSR2 - reread arguments from the above file

Currently it is not designed this way. Here is an idea pause/run the program on the signa SIGUSR1, but re-reading its runtime arguments. Therefore, you cant do what you want with a simple way.

What you really can do:

First - the best way:

  • patch the raspvid to allow the above functionality. It is written in C. So, need implement two subroutines:

    • one for reading arguments from an file
    • subroutine for signal handling for the SIGUSR2

Could be not very hard, but you must know C and understand how raspvid works.

Second:

  • write a wrapper (in java, or bash or any programming language), what would:
    • in some intervals (or on some signal) will read an file with the arguments
    • checks the processes for the runnning raspvid
    • if exists - kill it
    • and start it with the new arguments from the file

So, the main cycle would be:

  • add all needed (not only the contrast, but all) arguments to an defined file
  • send the SUGUSR1 signal to
    • raspvid process (in case of patching the respvid)
    • to wrapper script (in the second case)
  • and it will
    • restart itself (in case of 1)
    • kill&restart (in case of 2)

The second solution is doable easily - you should google "bash signal hangling" or "bash trap signals"... Many examples already on the net.

clt60
  • 62,119
  • 17
  • 107
  • 194
  • Thanks for the, I have already implemented the same, I am setting all the arguments dynamically and kill&restart the command. – Raman Aug 27 '14 at 11:44
0

The only way you can do so is using named FIFOs

In your example could be something like this:

$ mkfifo /tmp/FIFOVIDEO
$ raspivid -t 0 -w 960 -h 540 -fps 25 -b 500000 -vf -o /tmp/FIFOVIDEO &
$ ffmpeg -i /tmp/FIFOVIDEO -vcodec copy -an -f flv -metadata streamName=myStream tcp://0.0.0.0:6666

In this case you can stop and start process number 2 for short periods of time.

Be aware the named FIFO has a certain amount of buffer to fill, if it gets full the first process most probably die.

hector
  • 1