2014-10-20T04:02:03Z

Video Streaming with Flask

I'm sure by now you know that I have released a book and a couple of videos on Flask in cooperation with O'Reilly Media. While the coverage of the Flask framework in these is fairly complete, there are a small number of features that for one reason or another did not get mentioned much, so I thought it would be a good idea to write articles about them here.

This article is dedicated to streaming, an interesting feature that gives Flask applications the ability to provide large responses efficiently partitioned in small chunks, potentially over a long period of time. To illustrate the topic I'm going to show you how to build a live video streaming server!

NOTE: there is now a follow-up to this article, Flask Video Streaming Revisited, in which I describe some improvements to the streaming server introduced here.

What is Streaming?

Streaming is a technique in which the server provides the response to a request in chunks. I can think of a couple of reasons why this might be useful:

  • Very large responses. Having to assemble a response in memory only to return it to the client can be inefficient for very large responses. An alternative would be to write the response to disk and then return the file with flask.send_file(), but that adds I/O to the mix. Providing the response in small portions is a much better solution, assuming the data can be generated in chunks.
  • Real time data. For some applications a request may need to return data that comes from a real time source. A pretty good example of this is a real time video or audio feed. A lot of security cameras use this technique to stream video to web browsers.

Implementing Streaming With Flask

Flask provides native support for streaming responses through the use of generator functions. A generator is a special function that can be interrupted and resumed. Consider the following function:

def gen():
    yield 1
    yield 2
    yield 3

This is a function that runs in three steps, each returning a value. Describing how generator functions are implemented is outside the scope of this article, but if you are a bit curious the following shell session will give you an idea of how generators are used:

>>> x = gen()
>>> x
<generator object gen at 0x7f06f3059c30>
>>> next(x)
1
>>> next(x)
2
>>> next(x)
3
>>> next(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration

You can see in this simple example that a generator function can return multiple results in sequence. Flask uses this characteristic of generator functions to implement streaming.

The example below shows how using streaming it is possible to generate a large data table, without having to assemble the entire table in memory:

from flask import Response, render_template
from app.models import Stock

def generate_stock_table():
    yield render_template('stock_header.html')
    for stock in Stock.query.all():
        yield render_template('stock_row.html', stock=stock)
    yield render_template('stock_footer.html')

@app.route('/stock-table')
def stock_table():
    return Response(generate_stock_table())

In this example you can see how Flask works with generator functions. A route that returns a streamed response needs to return a Response object that is initialized with the generator function. Flask then takes care of invoking the generator and sending all the partial results as chunks to the client.

For this particular example if you assume Stock.query.all() returns the result of a database query as an iterable, then you can generate a potentially large table one row at a time, so regardless of the number of elements in the query the memory consumption in the Python process will not grow larger and larger due to having to assemble a large response string.

Multipart Responses

The table example above generates a traditional page in small portions, with all the parts concatenated into the final document. This is a good example of how to generate large responses, but something a little bit more exciting is to work with real time data.

An interesting use of streaming is to have each chunk replace the previous one in the page, as this enables streams to "play" or animate in the browser window. With this technique you can have each chunk in the stream be an image, and that gives you a cool video feed that runs in the browser!

The secret to implement in-place updates is to use a multipart response. Multipart responses consist of a header that includes one of the multipart content types, followed by the parts, separated by a boundary marker and each having its own part specific content type.

There are several multipart content types for different needs. For the purpose of having a stream where each part replaces the previous part the multipart/x-mixed-replace content type must be used. To help you get an idea of how this looks, here is the structure of a multipart video stream:

HTTP/1.1 200 OK
Content-Type: multipart/x-mixed-replace; boundary=frame

--frame
Content-Type: image/jpeg

<jpeg data here>
--frame
Content-Type: image/jpeg

<jpeg data here>
...

As you see above, the structure is pretty simple. The main Content-Type header is set to multipart/x-mixed-replace and a boundary string is defined. Then each part is included, prefixed by two dashes and the part boundary string in their own line. The parts have their own Content-Type header, and each part can optionally include a Content-Length header with the length in bytes of the part payload, but at least for images browsers are able to deal with the stream without the length.

Building a Live Video Streaming Server

There's been enough theory in this article, now it is time to build a complete application that streams live video to web browsers.

There are many ways to stream video to browsers, and each method has its benefits and disadvantages. The method that works well with the streaming feature of Flask is to stream a sequence of independent JPEG pictures. This is called Motion JPEG, and is used by many IP security cameras. This method has low latency, but quality is not the best, since JPEG compression is not very efficient for motion video.

Below you can see a surprisingly simple, yet complete web application that can serve a Motion JPEG stream:

#!/usr/bin/env python
from flask import Flask, render_template, Response
from camera import Camera

app = Flask(__name__)

@app.route('/')
def index():
    return render_template('index.html')

def gen(camera):
    while True:
        frame = camera.get_frame()
        yield (b'--frame\r\n'
               b'Content-Type: image/jpeg\r\n\r\n' + frame + b'\r\n')

@app.route('/video_feed')
def video_feed():
    return Response(gen(Camera()),
                    mimetype='multipart/x-mixed-replace; boundary=frame')

if __name__ == '__main__':
    app.run(host='0.0.0.0', debug=True)

This application imports a Camera class that is in charge of providing the sequence of frames. Putting the camera control portion in a separate module is a good idea in this case, this way the web application remains clean, simple and generic.

The application has two routes. The / route serves the main page, which is defined in the index.html template. Below you can see the contents of this template file:

<html>
  <head>
    <title>Video Streaming Demonstration</title>
  </head>
  <body>
    <h1>Video Streaming Demonstration</h1>
    <img src="{{ url_for('video_feed') }}">
  </body>
</html>

This is a simple HTML page with just a heading and an image tag. Note that the image tag's src attribute points to the second route of this application, and this is where the magic happens.

The /video_feed route returns the streaming response. Because this stream returns the images that are to be displayed in the web page, the URL to this route is in the src attribute of the image tag. The browser will automatically keep the image element updated by displaying the stream of JPEG images in it, since multipart responses are supported in most/all browsers (let me know if you find a browser that doesn't like this).

The generator function used in the /video_feed route is called gen(), and takes as an argument an instance of the Camera class. The mimetype argument is set as shown above, with the multipart/x-mixed-replace content type and a boundary set to the string "frame".

The gen() function enters a loop where it continuously returns frames from the camera as response chunks. The function asks the camera to provide a frame by calling the camera.get_frame() method, and then it yields with this frame formatted as a response chunk with a content type of image/jpeg, as shown above.

Obtaining Frames from a Video Camera

Now all that is left is to implement the Camera class, which will have to connect to the camera hardware and download live video frames from it. The nice thing about encapsulating the hardware dependent part of this application in a class is that this class can have different implementations for different people, but the rest of the application remains the same. You can think of this class as a device driver, which provides a uniform implementation regardless of the actual hardware device in use.

The other advantage of having the Camera class separated from the rest of the application is that it is easy to fool the application into thinking there is a camera when in reality there is not, since the camera class can be implemented to emulate a camera without real hardware. In fact, while I was working on this application, the easiest way for me to test the streaming was to do that and not have to worry about the hardware until I had everything else running. Below you can see the simple emulated camera implementation that I used:

from time import time

class Camera(object):
    def __init__(self):
        self.frames = [open(f + '.jpg', 'rb').read() for f in ['1', '2', '3']]

    def get_frame(self):
        return self.frames[int(time()) % 3]

This implementation reads three images from disk called 1.jpg, 2.jpg and 3.jpg and then returns them one after another repeatedly, at a rate of one frame per second. The get_frame() method uses the current time in seconds to determine which of the three frames to return at any given moment. Pretty simple, right?

To run this emulated camera I needed to create the three frames. Using gimp I've made the following images:

Frame 1 Frame 2 Frame 3

Because the camera is emulated, this application runs on any environment, so you can run this right now! I have this application all ready to go on GitHub. If you are familiar with git you can clone it with the following command:

$ git clone https://github.com/miguelgrinberg/flask-video-streaming.git

If you prefer to download it, then you can get a zip file here.

Once you have the application installed, create a virtual environment and install Flask in it. Then you can run the application as follows:

$ python app.py

After you start the application enter http://localhost:5000 in your web browser and you will see the emulated video stream playing the 1, 2 and 3 images over and over. Pretty cool, right?

Once I had everything working I fired up my Raspberry Pi with its camera module and implemented a new Camera class that converts the Pi into a video streaming server, using the picamera package to control the hardware. I will not discuss this camera implementation here, but you can find it in the source code in file camera_pi.py.

If you have a Raspberry Pi and a camera module you can edit app.py to import the Camera class from this module and then you will be able to live stream the Pi camera, like I'm doing in the following screenshot:

Frame 1

If you want to make this streaming application work with a different camera, then all you need to do is write another implementation of the Camera class. If you end up writing one I would appreciate it if you contribute it to my GitHub project.

Limitations of Streaming

When the Flask application serves regular requests the request cycle is short. The web worker receives the request, invokes the handler function and finally returns the response. Once the response is sent back to the client the worker is free and ready to take on another request.

When a request that uses streaming is received, the worker remains attached to the client for the duration of the stream. When working with long, never ending streams such as a video stream from a camera, a worker will stay locked to the client until the client disconnects. This effectively means that unless specific measures are taken, the application can only serve as many clients as there are web workers. When working with the Flask application in debug mode that means just one, so you will not be able to connect a second browser window to watch the stream from two places at the same time.

There are ways to overcome this important limitation. The best solution in my opinion is to use a coroutine based web server such as gevent, which Flask fully supports. With the use of coroutines gevent is able to handle multiple clients on a single worker thread, as gevent modifies the Python I/O functions to issue context switches as necessary.

Conclusion

In case you missed it above, the code that supports this article is this GitHub repository: https://github.com/miguelgrinberg/flask-video-streaming/tree/v1. Here you can find a generic implementation of video streaming that does not require a camera, and also an implementation for the Raspberry Pi camera module. This follow-up article describes some improvements I made after this article was published originally.

I hope this article shed some light on the topic of streaming. I concentrated on video streaming because that is an area I have some experience, but streaming has many more uses besides video. For example, this technique can be used to keep a connection between the client and the server alive for a long time, allowing the server to push new information the moment it becomes available. These days the Web Socket protocol is a more efficient way to achieve this, but Web Socket is fairly new and works only in modern browsers, while streaming will work on pretty much any browser you can think of.

If you have any questions feel free to write them below. I plan to continue documenting more of the not well known Flask topics, so I hope you connect with me in some way to know when more articles are published. I hope to see you in the next one!

Miguel

441 comments

  • #151 Mostapha Benhenda said 2016-06-09T15:49:31Z

    How can I customize the size of the display? My pictures are displayed too big.

  • #152 Miguel Grinberg said 2016-06-09T18:24:50Z

    @Mostapha: Are you using the Raspberry Pi camera? Look in the picamera package documentation, you can set a smaller video size when you initialize the camera.

  • #153 Samry D said 2016-06-12T09:02:26Z

    Is this adaptable to the django framework? The whole process? and our processor is an Arduino Mega 2560. Any ideas if that will be an issue?

  • #154 Miguel Grinberg said 2016-06-15T14:43:05Z

    @Sammy: I'm not aware of a similar implementation based on Django, but I don't see why one could not be written.

  • #155 Hanna said 2016-06-15T17:15:08Z

    Hey,

    I adapted your source code (camera.py) to using opencv for webcam streaming. I said "Threaded=True" (gevent does not work so far - import errors which I can't fix atm), because I want that multiple clients can access the webstream.

    Camera.py looks like the following now:

    import the necessary packages

    from threading import Thread import cv2

    class Camera:

    def __init__(self, src=0): # initialize the video camera stream and read the first frame # from the stream print("init") self.stream = cv2.VideoCapture(src) (self.grabbed, self.frame) = self.stream.read() # initialize the variable used to indicate if the thread should # be stopped self.stopped = False def start(self): print("start thread") # start the thread to read frames from the video stream t = Thread(target=self.update, args=()) t.daemon = True t.start() return self def update(self): print("read") # keep looping infinitely until the thread is stopped while True: # if the thread indicator variable is set, stop the thread if self.stopped: return # otherwise, read the next frame from the stream (self.grabbed, self.frame) = self.stream.read() def read(self): # return the frame most recently read return self.frame def stop(self): # indicate that the thread should be stopped self.stopped = True

    The problem here is, that I don't know how to destroy the threads when leaving the browser (calling stop). So it seems to work but the number of threads is increasing and never released. Some other people posted another adaptation of your camera.py without using threads but with

    def del(self): self.video.release()

    This doesn't work for me because then I get "python stopped working"-messages which makes sense because other clients can't access the livestream anymore if another client releases it.

    Any idea how I could solve the problem? I'm trying now for days.. which is a bit frustrating :(

    Best, Hanna

  • #156 Hanna said 2016-06-15T19:02:41Z

    I think I could solve my problem with the threads (I didn't look into the camera_pi.py file before). This is what my camera.py looks now:

    import the necessary packages

    import threading

    from threading import Thread

    import cv2 import time

    class Camera: thread = None # background thread that reads frames from camera frame = None # current frame is stored here by background thread last_access = 0 # time of last client access to the camera

    def initialize(self): if Camera.thread is None: print("thread is none") # start background frame thread Camera.thread = threading.Thread(target=self._thread) Camera.thread.start() # wait until frames start to be available while self.frame is None: time.sleep(0) def get_frame(self): Camera.last_access = time.time() self.initialize() return self.frame @classmethod def _thread(cls): print("videocapture") stream = cv2.VideoCapture(0) while True: if time.time() - cls.last_access > 10: print("client left") break # otherwise, read the next frame from the stream (grabbed, cls.frame) = stream.read() cls.thread = None

    Does this makes sense? Now I have another strange behavior... If I open a tab in firefox accessing the stream everything's fine. But if I reload the tab the memory of the firefox.exe process increases continously until firefox crashes. For chrome everything is fine. Any idea what the reason could be for this strange behaviour?

    Best, Hanna

  • #157 Miguel Grinberg said 2016-06-16T01:58:02Z

    @Hanna: the firefox behavior cannot be related to the server in any way. That sounds like a Firefox issue, which isn't cleaning up properly when the page is reloaded. I don't know how you implemented the page, so I can't really make a guess as to what the problem is. The code looks good to me.

  • #158 Hanna said 2016-06-16T08:47:09Z

    Thanks Miguel. The html file is rather simple:

    within a div. I also tried iframe instead of img.

    The behavior in EDGE is somehow strange, too: it wants to download the videofeed and doesn't display anything.

    It seems that webcam streaming via a browser does not work as easy as I thought..

  • #159 Miguel Grinberg said 2016-06-18T18:15:50Z

    @Hanna: Note that the edge browser did not exist when I wrote this article in 2014. I have never tested it, the two browsers I work with the most are Chrome and Safari.

  • #160 Hanna said 2016-06-22T11:45:55Z

    I wanted to extend the functionalities of the server to also provide an interface for requesting a single image instead of mjpeg (because e.g. firefox has problems with it). I tried to set the mimetype to mimetype='image/jpeg' instead of mimetype='multipart/x-mixed-replace; boundary=frame' but it doesn't work. Do you have an idea what could be wrong? The browser says that the image cannot be displayed because it contains errors.

  • #161 Miguel Grinberg said 2016-07-14T17:42:58Z

    @Hanna: did you inspect the image to see what the contents look like. That may give you some clues.

  • #162 mostafa said 2016-07-20T21:02:21Z

    If the connection is interrupted, streaming stops and is not restored. How can I overcome this limitation?

  • #163 Miguel Grinberg said 2016-07-28T05:36:48Z

  • #164 Terry said 2016-07-29T20:34:50Z

    Miguel, Thank you very much for this. I haven't programmed in python in 12ish years and even then it was just a part of semester at college. I am designing a web interface for a security/backup/trail camera project. A week ago, I hadn't even heard of flask, now I have the ability to view a stream remotely over wifi. Now on to the "simple" stuff of creating a button to start / stop a python program, textboxes to modify a config file that is read on program start, and a button that displays the last X pictures captured by the motion sensor. By simple, I mean "hope I can find some examples". Thank you again! This has either saved me months of frustration, or completely giving up. Terry

  • #165 sztef said 2016-08-10T20:14:19Z

    Hi! I'm facing some trouble with latency and lag. For first few seconds after refreshing everything works perfect, but after that it is getting worse and worse. Have anyone experienced similar issue?

  • #166 Miguel Grinberg said 2016-08-16T19:44:48Z

    @sztef: Do you know if it is the server that is increasingly doing more work, or the client? Look at the process list to see which of the sides is the one slowing down.

  • #167 Miladkt said 2016-08-22T06:48:39Z

    Hello Miguel please help me! I need streaming for long time but this method that you introduced goes off after 3seconds. Do you have any solution?!?

  • #168 Miguel Grinberg said 2016-08-25T05:25:05Z

    @Miladkt: not sure why the streaming stops for you. Any error messages?

  • #169 Nathan Sinclair said 2016-09-06T01:30:32Z

    Just one question, killing the python task doesn't stop the program (because of the threading?) it does if it hasn't started serving any videos. how do you stop the program? Ctrl-C doesn't seem to work.

  • #170 Miguel Grinberg said 2016-09-10T17:54:20Z

    @Nathan: I believe the inability to stop the Flask development server is a bug. Sometimes you have to hit Ctrl-C two times to make the server stop. Or else, killing the app might be necessary.

  • #171 Nathan said 2016-09-23T06:45:55Z

    Hi Miguel,

    Iḿ running this code through UWSGI and trying to get it to display a stream however it comes up with this error:uwsgi_response_write_body_do() TIMEOUT !!! is this to do with the threads that iḿ using? any help is appreciated!

    Nathan

  • #172 Miguel Grinberg said 2016-09-23T14:40:18Z

    @Nathan: I'm not sure, but my guess is that your uwsgi is configured to timeout requests that take too long. Since this is a request that will run for a very long time, you have to disable timeouts for it to work.

  • #173 Toj said 2016-09-23T16:18:54Z

    Hi Miguel, Do you have any advice on how to setup Nginx to serve the live stream? The image is currently streaming perfectly on my localhost:1234, on multiple browsers via the use of gunicorn. When I try to view it from another location, the image remains static. My nginx file performs standard reverse proxying for the moment.

    server { listen 4444;

    server_name localhost; location / { proxy_pass http://127.0.0.1:1234; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }

    }

    Also thanks for all the help and tutorials. They've been invaluable to me.

  • #174 Miguel Grinberg said 2016-09-24T17:43:53Z

    @Toj: Try adding "proxy_buffering off" to your configuration. Also make sure the browser that you are using from the remote location supports MJPEG.

  • #175 Nathan Sinclair said 2016-09-26T01:10:19Z

    Hey Thanks Miguel.

    I followed the proxy example to get a working feed. However the FPS on the video is very slow.

    the log of the camera is showing that our app is connecting to the video stream, here's an example of the status updates:

    127.0.0.1 - - [2016-09-26 00:58:57] "GET / HTTP/1.0" 200 308 0.040675 127.0.0.1 - - [2016-09-26 00:59:00] "GET /favicon.ico HTTP/1.0" 404 361 0.037260 127.0.0.1 - - [2016-09-26 00:59:50] "GET /video_feed HTTP/1.0" 200 114777104 53.018593 127.0.0.1 - - [2016-09-26 01:02:45] "GET /video_feed HTTP/1.0" 200 65000895 134.852934 127.0.0.1 - - [2016-09-26 01:02:45] "GET /video_feed HTTP/1.0" 200 68975415 141.020384 127.0.0.1 - - [2016-09-26 01:02:45] "GET /video_feed HTTP/1.0" 200 108716539 165.457638 127.0.0.1 - - [2016-09-26 01:02:45] "GET /video_feed HTTP/1.0" 200 72722032 144.627390 127.0.0.1 - - [2016-09-26 01:02:45] "GET /video_feed HTTP/1.0" 200 88844344 157.838455 127.0.0.1 - - [2016-09-26 01:02:45] "GET /video_feed HTTP/1.0" 200 31101696 80.799705

    This is because the app we develop will process a new request every time the phone changes orientation.

    The code used is just the same as the ones that you've developed, only i have changed the app run command to the following code: http_server = WSGIServer('', 5000), app) http_server.serve_forever()

    how could i get FPS up?

Leave a Comment