Tuesday, March 15, 2016

Streaming with ffserver fronted with ffmpeg video files and live IP camera video

So what's the point???
  1. edit later
  2. edit later
  3. edit later
  4. edit later
  5. edit later



Seeing the basic streaming concept in your mind eye

  1. Imagine a bucket. The bucket is empty.
  2. You drill a single hole in the bottom. Say 4mm in diameter.
  3. You hang the bucket from the branch of a tree.
  4. You plug the hole in the bottom with a stick of gum.
  5. You pour from another bucket, a bucket of water into the bucket hanging.
  6. You pull the stick of gum away and you get a stream of water pouring out onto the ground. At the basic level, streaming video concepts work in the same way!
  7. Image now that each drop of water that makes up a bucket of water is actually a still image. A still image that is one of thousands that make up an entire movie, video clip or live image from a video camera.
  8. Now think of the logic necessary  to view  these different kinds of video types.
    1. In general, you'll want to view a video stream at real time speeds. Not too fast, not too slow but just right!
    2. The speed at which the stream runs from the bucket will probably take a certain amount of time unless the hanging bucket is continuously being filled faster than it can empty out. Say from a live video camera.
    3. If the stream runs out of the bucket too fast, you can probably catch some of this in a container and cache it. Then only look at the streamed stills when you need to.
    4. If the stream runs too slow then you'll undoubtedly see jerky stop go kind of video!
    5. Once you've seen the stream you can probably discard it. ie: let it run out onto the ground!
    6. You can't see the stream without first filling up the bucket somewhat! So there is a certain amount of time between the two events. Therefore...
    7. In the event where you want to see live video from a camera that has been streamed, you should expect some delay in seeing the stream. 1 second, 2 seconds, even 5 seconds. Heck, 10 or 20 seconds might be acceptable even. A 1 minute delay, a 5 minute delay??? things start to get far from live and so quickly becomes undesirable. 
    8. For a video file (not for example a live IP camera)? you can probably afford to fill the bucket up as quickly as possible. Then just watch the stream at real time speeds.
    9. For a live camera video? The bucket is always going to be filling so you want to start viewing as soon as the bucket begins to fill otherwise it can hardly be considered live. If you wait to long to start viewing and your looking at all the stills you let run out onto the ground then you probably want to quickly skip all that and start viewing close to the exit of the bucket where fresh water (or video) is running out. ie as close as live as possible.
    10. With the buckets hole plugged up at the bottom, You could in theory fill up the bucket completely which might be the equivalent of a full length movie. It might for example take several minutes to fill up that bucket. Then when you remove the plug from the hole and watch the entire movie at real time speed it might take a couple of hours for the water to stream out!
  9. Consider the above logic when implementing your streaming application. Issues will most likely appear for very good reason. Think through the process as to what needs to happen for a smooth streaming then viewing experience.






Streaming a video file directly with ffserver NOT feeding the server with ffmpeg

Starting with baby steps, first we try streaming a video file by setting up ffserver to stream an mp4 and/or an mpg video file directly. In other words, we will stream without the need of feeding an input feed file with an ffmpeg command. 

This is my ffserver.conf file. 
You can place this file anywhere. You'll just need to specify it's location at the time you launch ffserver!
-------------------- HTTPPort 8090 # Port to bind the server toRTSPPORT 554HTTPBindAddress 0.0.0.0MaxHTTPConnections 2000MaxClients 1000MaxBandwidth 10000 # Maximum bandwidth per client CustomLog - # Input feed# ------------------------------#<Feed feed1.ffm> # File /tmp/feed1.ffm # FileMaxSize 1G # ACL allow 127.0.0.1 #</Feed> # Output stream# -------------------------------# Note, if you are going to put the file to stream directly in here rather than feed it in with ffmpeg# then you should comment out completely the input feed! At least that's what worked for me! <Stream ipcam.mpg> # Output stream URL definition #Feed feed1.ffm # Feed from which to receive video Format rtp #File "/home/mugwhy/Videos/hst_2.mpg" #Your mpg video file File "/home/mugwhy/Videos/quenenseg.mp4" #Or your mp4 video file #video settings #--------------- #VideoSize 640x480 #videobitrate 200000 #VideoBufferSize 150000 #VideoFrameRate 3 #VideoQMin 3 #VideoQMax 31 #Audio settings noaudio #Seem to get audio anyway buts that's OK for now! </Stream> <Stream status.html> # Server status URL Format status # Only allow local people to get the status ACL allow localhost ACL allow 192.168.0.0 192.168.255.255</Stream> <Redirect index.html> # Just an URL redirect for index # Redirect index.html to the appropriate site URL http://www.ffmpeg.org/</Redirect> --------------------


I'm starting the ffserver with...
sudo ffserver -f /home/mugwhy/ffserverConfigFiles/ffserver.conf
And I'm viewing the streamed video with... ffplay rtsp://192.168.1.16:554/ipcam.mpg
Or opening VLC and opening the stream with the following URL... rtsp://192.168.1.16:554/ipcam.mpg

I'm successfully flicking between video file types... mpg and mp4 and playback is currently playing perfectly! #Edit the stream section of the config file to see how to change video files and it's type!



To be continued...

Kotlin (Programming language)

Todo