2 ms·

MaryJane MJPEG server in < 30 lines of Python. Here is a demo: http://18.116.60.15:8080/maryjane/ http://18.116.60.15:8080/maryjane/ Here's the 30 lines of Py

MaryJane MJPEG server in < 30 lines of Python. Here is a demo: http://18.116.60.15:8080/maryjane/ http://18.116.60.15:8080/maryjane/ Here's the 30 lines of Python: https://raw.githubusercontent.com/bootrino/maryjane/master/mjpegserverpython.py https://raw.githubusercontent.com/bootrino/maryjane/master/m... Here is the github: https://github.com/bootrino/maryjane https://github.com/bootrino/maryjane Browsers are able to display images such as PNG, JPG and GIF. A less known capability of browsers is to display a stream of JPG images. This is called MJPEG (motion JPEG). All you need to do is specify the MPJEG server address in an image tag and it just works. It's written in less than 30 lines of async Python. This project is MIT licensed.

tdeck 5y ago
If I understand multipart/x-mixed-replace right, this could be used with other image formats as well? Really cool use of an almost forgotten technology.
- bawolff 5y ago
  Typically though other image formats have better options. gif, apng, webm, etc (and chrome killed support for the non image case). The main place x-mixed-replace makes sense is a dead simple webcam that takes a picture every x seconds. Even then, in the modern world it probably makes more sense to just implement some streaming video stuff. MJPEG is not bandwidth efficient.
  - ramses0 5y ago
    #but-it-just-works
    - andrewstuart 5y ago
      The fact that "it just works" by putting an address in an IMG tag is really important. Streaming setups can get complex fast and sometimes it's worth paying the bandwidth penalty of mjpeg in order to build something super simple.
  - andrewstuart 5y ago
    As mentioned in a different comment - mjpeg is certainly less bandwidth efficient, but it's super simple to implement - just the Python code I've posted plus an image tag. Also, streaming protocols tend to have a number of seconds latency, which for certain types of applications isn't acceptable. That's when mjpeg might do the job because it just instantly starts blasting frames down the tubes.
    - monocasa 5y ago
      > Also, streaming protocols tend to have a number of seconds latency, which for certain types of applications isn't acceptable. That's when mjpeg might do the job because it just instantly starts blasting frames down the tubes. In this case you might run into issues there. This demo is all on TCP which means head of line blocking. That's why you typically see MJPEG wrapped in rtp rather than http.
    - bawolff 5y ago
      I agree that mjpeg is super simple and streaming support can get complicated very fast. There a certainly use cases where mjpeg is the correct trade off. But don't under estimate bandwidth scaling requirements - i think if you have 20 clients streaming 1080p@24 fps, you're already maxing out a 1 gbps line. Even still though, latency can't be that bad for video formats with actual temporal compression in low latency mode. I'm not an expert in this area, but WebRTC is widely supported, uses vp9. When i do video conferencing with people the latency is pretty low, so this must be a solved problem.
    - vlovich123 5y ago
      I’ll have to disagree with you there. Oculus Link uses a (HW) h264 encoder and run at pretty high resolutions without multiple seconds of latency. Latency is in the network layer mostly (and maybe improper tuning of codecs) and that’s helped more by sending smaller data, not larger. Maybe if you don’t have HW acceleration, but that’s rare as even CPUs have Hw encoding blocks (Intel’s QuickSync for example).
sitkack 5y ago
Great name. I wrote this in Tornado a bunch of years ago. Where do you go next? What else could you do?
- andrewstuart 5y ago
  A fun thing to do might be have write on on demand video thumbnail player. To do this you'd have a bunch of video files at the back end, specify which one you want in the URL, then get Python to run ffmpeg, extracting jpeg frames from the specified video and writing the frames to the ramdrive /dev/shm. As the user rolls the mouse over, some JavaScript changes the img tag to point to the mjpeg server and the video plays. It should be possible to do this in only four or five extra lines I think. See the github readme for the correct ffmpeg command line to do this. I do wonder if there's a way to stream audio in sync.
  - foxhop 5y ago
    I like that. Could be neat if uploaded could specify key frames to jump to to start the preview.
  - nemosaltat 5y ago
    Also seems like a hacky way to get video to play on my Tesla browser. I could probably couple this with a Raspberry Pi and pipe the audio to Bluetooth for the speakers, then stream the video content from the Pi to a web server that I access through the Tesla browser.
deleted 5y ago
[deleted]

tdeck 5y ago

If I understand multipart/x-mixed-replace right, this could be used with other image formats as well? Really cool use of an almost forgotten technology.

bawolff 5y ago
Typically though other image formats have better options. gif, apng, webm, etc (and chrome killed support for the non image case). The main place x-mixed-replace makes sense is a dead simple webcam that takes a picture every x seconds. Even then, in the modern world it probably makes more sense to just implement some streaming video stuff. MJPEG is not bandwidth efficient.
- ramses0 5y ago
  #but-it-just-works
  - andrewstuart 5y ago
    The fact that "it just works" by putting an address in an IMG tag is really important. Streaming setups can get complex fast and sometimes it's worth paying the bandwidth penalty of mjpeg in order to build something super simple.
- andrewstuart 5y ago
  As mentioned in a different comment - mjpeg is certainly less bandwidth efficient, but it's super simple to implement - just the Python code I've posted plus an image tag. Also, streaming protocols tend to have a number of seconds latency, which for certain types of applications isn't acceptable. That's when mjpeg might do the job because it just instantly starts blasting frames down the tubes.
  - monocasa 5y ago
    > Also, streaming protocols tend to have a number of seconds latency, which for certain types of applications isn't acceptable. That's when mjpeg might do the job because it just instantly starts blasting frames down the tubes. In this case you might run into issues there. This demo is all on TCP which means head of line blocking. That's why you typically see MJPEG wrapped in rtp rather than http.
  - bawolff 5y ago
    I agree that mjpeg is super simple and streaming support can get complicated very fast. There a certainly use cases where mjpeg is the correct trade off. But don't under estimate bandwidth scaling requirements - i think if you have 20 clients streaming 1080p@24 fps, you're already maxing out a 1 gbps line. Even still though, latency can't be that bad for video formats with actual temporal compression in low latency mode. I'm not an expert in this area, but WebRTC is widely supported, uses vp9. When i do video conferencing with people the latency is pretty low, so this must be a solved problem.
  - vlovich123 5y ago
    I’ll have to disagree with you there. Oculus Link uses a (HW) h264 encoder and run at pretty high resolutions without multiple seconds of latency. Latency is in the network layer mostly (and maybe improper tuning of codecs) and that’s helped more by sending smaller data, not larger. Maybe if you don’t have HW acceleration, but that’s rare as even CPUs have Hw encoding blocks (Intel’s QuickSync for example).

sitkack 5y ago

Great name. I wrote this in Tornado a bunch of years ago. Where do you go next? What else could you do?

andrewstuart 5y ago
A fun thing to do might be have write on on demand video thumbnail player. To do this you'd have a bunch of video files at the back end, specify which one you want in the URL, then get Python to run ffmpeg, extracting jpeg frames from the specified video and writing the frames to the ramdrive /dev/shm. As the user rolls the mouse over, some JavaScript changes the img tag to point to the mjpeg server and the video plays. It should be possible to do this in only four or five extra lines I think. See the github readme for the correct ffmpeg command line to do this. I do wonder if there's a way to stream audio in sync.
- foxhop 5y ago
  I like that. Could be neat if uploaded could specify key frames to jump to to start the preview.
- nemosaltat 5y ago
  Also seems like a hacky way to get video to play on my Tesla browser. I could probably couple this with a Raspberry Pi and pipe the audio to Bluetooth for the speakers, then stream the video content from the Pi to a web server that I access through the Tesla browser.

deleted 5y ago

[deleted]