<p>summary: yes, depending on content, with a good encoder h.264 can look pretty good at 240kib/s video bitrate, at NTSC 720x480p30.</p>

<p>With modern codecs, you don't need to downscale the rez too far.  If there isn't a lot of noise in your source, you're just putting the same complexity into fewer pixels.  You shouldn't encode 1080p at 270kb/s, though :P.  There is overhead to having more macroblocks, and diluting the complexity across too many pixels probably means worse results from quantizing the DCT coefficients.  Lower resolution lets you turn up the CPU-usage knob on your codec while still being realtime, though.</p>

<p>For a test encode, I have a lossless source of the <a href="https://www.youtube.com/watch?v=JHVkegpW_ok" rel="nofollow">sintel trailer</a>.  (3D animation with fades between scenes, and significant amount of changeless).  So it's probably actually a really bad test case...</p>

<pre><code>ffmpeg -i sintel.y4m -pix_fmt yuv420p -vf crop=1920:816:0:132,scale=640:-1 -ssim 1 -psnr -tune animation -preset slow -b:v 270k 640x272.x264.270k.mkv
</code></pre>

<p>That does quite well, with an average QP of 18.03(I) / 23.44(P) / 24.93(B).  SSIM Mean Y:0.9852979, PSNR Global:44.801 at 231.37 kib/s.  (a still section at the end leaves x264 undershooting the target bitrate for one-pass).  I left psy optimizations enabled, so x264 is trying to do what looks best, not what scores highest on SSIM or PSNR.  Just useful as a ballpark figure.</p>

<p>I have a live-action source that's not too noisy.  I picked a portion that just has one actor moving around on stage, everyone else standing still, and no camera motion.  So it might be similar in compressibility to a someone talking while looking at a webcam, in front of a mostly-constant background.  (stuff like this matters a LOT for compressibility).  About 1/3 of the screen is black background.  (so black the encoder knows you can't see anything, and hardly spends any bits, I assume.)</p>

<pre><code>ffmpeg -ss 2410 -t 30 -i vid.yadif3.1,mcdeint3.1.10.ffvhuff.mkv -c:a opus -b:a 32k -pix_fmt yuv420p -r 30 -vf framestep=2 -ssim 1 -psnr  -preset slow -b:v 240k  2410+30.slow.opus.230k.mkv
</code></pre>

<p>Source is 60p deinterlace output, from NTSC DV or something.  Anyway, with those ffmpeg options, it stays as 720x480@30p (with non-square pixels, display aspect ratio = 16:9).  Output looks pretty darn good considering the bitrate, and the singing sounds good, but has some artifacts.  (audio source is not noisy, and there's no accompaniment, just soloist + chorus.)</p>

<pre><code>frame=  900 fps= 35 q=-1.0 LPSNR=Y:inf U:inf V:inf *:inf size=     990kB time=00:00:30.01 bitrate= 270.3kbits/s
video:854kB audio:120kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.635424%
[libx264 @ 0x2400360] frame I:4     Avg QP:22.63  size: 23294  PSNR Mean Y:44.02 U:48.68 V:47.86 Avg:45.00 Global:42.71
[libx264 @ 0x2400360] frame P:239   Avg QP:22.23  size:  2492  PSNR Mean Y:43.64 U:48.67 V:47.52 Avg:44.67 Global:44.47
[libx264 @ 0x2400360] frame B:657   Avg QP:24.97  size:   282  PSNR Mean Y:43.38 U:48.52 V:47.37 Avg:44.43 Global:44.24
[libx264 @ 0x2400360] consecutive B-frames:  0.6%  0.0% 19.0% 80.4%
[libx264 @ 0x2400360] mb I  I16..4: 27.0% 58.0% 15.0%
[libx264 @ 0x2400360] mb P  I16..4:  0.2%  0.4%  0.1%  P16..4: 22.1%  5.1%  6.7%  0.0%  0.0%    skip:65.4%
[libx264 @ 0x2400360] mb B  I16..4:  0.0%  0.0%  0.0%  B16..8: 12.5%  0.4%  0.1%  direct: 0.1%  skip:87.0%  L0:23.6% L1:74.4% BI: 2.1%
[libx264 @ 0x2400360] final ratefactor: 22.98
[libx264 @ 0x2400360] 8x8 transform intra:59.0% inter:71.2%
[libx264 @ 0x2400360] direct mvs  spatial:99.7% temporal:0.3%
[libx264 @ 0x2400360] coded y,uvDC,uvAC intra: 50.7% 48.1% 24.7% inter: 2.8% 5.1% 0.2%
[libx264 @ 0x2400360] i16 v,h,dc,p: 36% 38%  7% 19%
[libx264 @ 0x2400360] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15%  4% 22%  8% 12% 11% 12%  8%  8%
[libx264 @ 0x2400360] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 14%  3%  5% 12% 15% 16% 12% 12% 10%
[libx264 @ 0x2400360] i8c dc,h,v,p: 48% 27% 18%  7%
[libx264 @ 0x2400360] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 0x2400360] ref P L0: 66.9%  8.4% 14.9%  3.5%  4.6%  1.6%
[libx264 @ 0x2400360] ref B L0: 85.5% 10.8%  2.9%  0.8%
[libx264 @ 0x2400360] ref B L1: 92.3%  7.7%
[libx264 @ 0x2400360] SSIM Mean Y:0.9730952 (15.702db)
[libx264 @ 0x2400360] PSNR Mean Y:43.450 U:48.564 V:47.412 Avg:44.498 Global:44.292 kb/s:232.89
</code></pre>

<p>And 35fps on my E6600 (2.4GHz dual core first-gen c2duo) is not bad.  If you're trying to live-stream from a phone, you're going to be much more constrained, though.  You could use lower rez or lower framerate (25 fps, or 24, or 20?)</p>

<p>I was actually surprised at how well x264 did with <code>-preset veryfast</code>.  I guess on this content, even <code>veryfast</code> finds most of the same redundancy to eliminate.</p>

<pre><code>frame=  900 fps= 90 q=-1.0 LPSNR=Y:inf U:inf V:inf *:inf size=     994kB time=00:00:30.01 bitrate= 271.5kbits/s    
video:859kB audio:120kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.612045%
[libx264 @ 0x37b6420] frame I:4     Avg QP:21.51  size: 24840  PSNR Mean Y:44.16 U:48.09 V:47.20 Avg:44.99 Global:42.15
[libx264 @ 0x37b6420] frame P:227   Avg QP:21.22  size:  2649  PSNR Mean Y:43.57 U:48.08 V:46.72 Avg:44.50 Global:44.26
[libx264 @ 0x37b6420] frame B:669   Avg QP:22.30  size:   267  PSNR Mean Y:43.32 U:48.04 V:46.67 Avg:44.29 Global:44.02
[libx264 @ 0x37b6420] consecutive B-frames:  0.9%  0.0%  0.0% 99.1%
[libx264 @ 0x37b6420] mb I  I16..4: 24.0% 45.9% 30.1%
[libx264 @ 0x37b6420] mb P  I16..4:  1.4%  2.8%  0.1%  P16..4: 20.9%  4.2%  3.1%  0.0%  0.0%    skip:67.5%
[libx264 @ 0x37b6420] mb B  I16..4:  0.1%  0.2%  0.0%  B16..8:  1.7%  0.6%  0.1%  direct: 2.1%  skip:95.2%  L0:23.9% L1:45.7% BI:30.3%
[libx264 @ 0x37b6420] final ratefactor: 20.78
[libx264 @ 0x37b6420] 8x8 transform intra:60.6% inter:38.4%
[libx264 @ 0x37b6420] coded y,uvDC,uvAC intra: 39.1% 40.2% 10.5% inter: 2.7% 3.1% 0.1%
[libx264 @ 0x37b6420] i16 v,h,dc,p: 73% 11% 13%  3%
[libx264 @ 0x37b6420] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12%  7% 73%  1%  1%  1%  2%  1%  1%
[libx264 @ 0x37b6420] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 13% 14%  5%  8%  9%  8%  6%  6%
[libx264 @ 0x37b6420] i8c dc,h,v,p: 76%  8% 15%  1%
[libx264 @ 0x37b6420] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 0x37b6420] SSIM Mean Y:0.9737951 (15.816db)
[libx264 @ 0x37b6420] PSNR Mean Y:43.390 U:48.047 V:46.685 Avg:44.343 Global:44.068 kb/s:234.13
</code></pre>

<p>bitrate ended up 2kib/s higher, with about the same PSNR, and higher SSIM.  </p>

<p>With <code>-tune ssim</code> to disable psychovisual optimizations (don't do this for real use),<br>
veryfast gets: Y-SSIM: 15.891db, PSNR Global:44.294, kb/s:233.26.<br>
slow gets: Y-SSIM: 16.097db, PSNR Global:44.752, kb/s:232.86</p>

<p>So that's what x264 can do with h.264 High@L3.0 profile, at 0.023 bits/pixel/frame.</p>

<p>tested x265:<br>
<code>ffmpeg -ss 2410 -t 30 -i vid.yadif3.1,mcdeint3.1.10.ffvhuff.mkv -c:a opus -b:a 32k -pix_fmt yuv420p -r 30 -vf framestep=2 -ssim 1 -psnr -c:v libx265 -preset slow -b:v 240k -aspect 16:9 x265.2410+30.slow.opus.230k.mkv</code></p>

<pre><code>ffmpeg version N-68044-gb9dd809 Copyright (c) 2000-2015 the FFmpeg developers
  built on Jan 14 2015 23:21:08 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
  configuration: --enable-gpl --enable-version3 --enable-nonfree --disable-doc --disable-ffserver --enable-libbluray --enable-libschroedinger --enable-libtheora --enable-libx264 --enable-libx265 --enable-libmp3lame --enable-libopus --enable-libwebp --enable-libvpx --disable-outdev=oss --disable-indev=oss --disable-encoder=vorbis --enable-libvorbis --enable-libfdk-aac --disable-encoder=aac --disable-decoder=jpeg2000 --enable-libvidstab
  libavutil      54. 16.100 / 54. 16.100
  libavcodec     56. 20.100 / 56. 20.100
  libavformat    56. 18.101 / 56. 18.101
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5.  7.101 /  5.  7.101
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  1.100 /  1.  1.100
  libpostproc    53.  3.100 / 53.  3.100
Input #0, matroska,webm, from 'vid.yadif3.1,mcdeint3.1.10.ffvhuff.mkv':
  Metadata:
    ENCODER         : Lavf56.15.102
  Duration: 01:22:11.94, start: 0.000000, bitrate: 95843 kb/s
    Stream #0:0: Video: ffvhuff (FFVH / 0x48564646), yuv420p, 720x480, SAR 186:157 DAR 279:157, 59.94 fps, 59.94 tbr, 1k tbn, 1k tbc (default)
    Metadata:
      ENCODER         : Lavc56.14.100 ffvhuff
    Stream #0:1: Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s (default)
Codec AVOption ssim (Calculate and print SSIM stats.) specified for output file #0 (x265.2410+30.veryfast.opus.230k.mkv) has not been used for any stream. The most likely reason is either wrong type (e.g. a video option with no video streams) or that it is a private option of some encoder which was not actually used for any stream.
x265 [info]: HEVC encoder version 1.4+286-a12080554342
x265 [info]: build info [Linux][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
x265 [warning]: --psnr used with AQ on: results will be invalid!
x265 [warning]: --tune psnr should be used if attempting to benchmark psnr!
x265 [info]: Main profile, Level-3 (Main tier)
x265 [info]: WPP streams / frame threads / pool  : 15 / 1 / 2
x265 [info]: CTU size / RQT depth inter / intra  : 32 / 1 / 1
x265 [info]: ME / range / subpel / merge         : hex / 57 / 1 / 2
x265 [info]: Keyframe min / max / scenecut       : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt        : 15 / 4 / 0
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 1
x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-240 kbps / 1.0 / 0
x265 [info]: tools: rd=2 early-skip deblock sao signhide fast-intra tmvp 
Output #0, matroska, to 'x265.2410+30.veryfast.opus.230k.mkv':
  Metadata:
    encoder         : Lavf56.18.101
    Stream #0:0: Video: hevc (libx265), yuv420p, 720x480 [SAR 32:27 DAR 16:9], q=2-31, 240 kb/s, 30 fps, 1k tbn, 30 tbc (default)
    Metadata:
      encoder         : Lavc56.20.100 libx265
    Stream #0:1: Audio: opus (libopus) ([255][255][255][255] / 0xFFFFFFFF), 48000 Hz, stereo, flt, 32 kb/s (default)
    Metadata:
      encoder         : Lavc56.20.100 libopus
Stream mapping:
  Stream #0:0 -&gt; #0:0 (ffvhuff (native) -&gt; hevc (libx265))
  Stream #0:1 -&gt; #0:1 (ac3 (native) -&gt; opus (libopus))
Press [q] to stop, [?] for help
frame=  900 fps= 24 q=0.0 LPSNR=Y:inf U:inf V:inf *:inf size=     998kB time=00:00:30.01 bitrate= 272.4kbits/s    
video:861kB audio:120kB subtitle:0kB other streams:0kB global headers:1kB muxing overhead: 1.713292%
x265 [info]: frame I:      4, Avg QP:21.87  kb/s: 5097.48   PSNR Mean: Y:43.899 U:48.345 V:47.187  SSIM Mean: 0.968502 (15.017dB)
x265 [info]: frame P:    177, Avg QP:18.74  kb/s: 710.27    PSNR Mean: Y:43.347 U:48.274 V:47.041  SSIM Mean: 0.973469 (15.763dB)
x265 [info]: frame B:    719, Avg QP:20.83  kb/s: 89.99     PSNR Mean: Y:43.113 U:48.231 V:47.010  SSIM Mean: 0.972552 (15.615dB)
x265 [info]: global :    900, Avg QP:20.42  kb/s: 234.24    PSNR Mean: Y:43.163 U:48.240 V:47.017  SSIM Mean: 0.972714 (15.641dB)
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 0.6% 0.0% 0.0% 0.6% 98.9% 
</code></pre>

<p>(Note that I needed <code>-x265-params ssim=1</code>, because the ffmpeg libx265 interface doesn't pick up a lot of the commandline options.)</p>

<pre><code>    slow: 253.245kbit/s fps=1.7  Y PSNR:44.228 unknown SSIM, forgot to turn it on
veryfast: 244.347kbit/s fps= 24  Y PSNR:43.163 15.641dB SSIM.
</code></pre>

<p>perceptually, the x265 veryfast output has less blocking than the x264 slow output.  I think x265 looks better.</p>

<p>x264 and x265 both from the git / hg repos, updated Jan 10th.</p>

CC BY-SA 3.0
2015-01-15T13:09:20.030Z
Doing a test-encode now with x265.  It's 15 times slower, but should do well at low bitrate.
Peter Cordes
CC BY-SA 3.0
2015-01-15T13:29:17.613Z
Amazing. I see you are using ffmpeg and have seen some instructions on how to compile ffmpeg for iOS but couldn't do so successfully.
Joe
CC BY-SA 3.0
2015-01-15T13:37:32.757Z
for iOS?  So you need this to run on a phone?  yeah, don't even think about x265 then.  x264 has some ARM asm optimizations for ARM CPUs with a vector unit, and can prob. run in realtime with low rez.  You'd be trading more battery usage for better video quality, compared to using the hardware h.264 encoder.
Peter Cordes
CC BY-SA 3.0
2015-01-15T13:40:01.740Z
check out http://demos.webmproject.org/ios/vp9.  Amusingly, they too chose the Sintel trailer as their source.
Peter Cordes
CC BY-SA 3.0
2015-01-15T13:55:04.727Z
Also, you don't need ffmpeg.  It's just a convenient commandline frontend to the encoding library.  You might want some of the various libav libraries to handle muxing your video+audio into a standard container format, instead of reinventing the wheel with either a custom protocol for carrying the bitstreams, or writing your own code for muxing them into mkv.
Peter Cordes
CC BY-SA 3.0
2015-01-15T13:57:51.123Z
If you expect people to watch these streams on phones, not just send them from phones to desktops, then h.264 has the advantage of a high installed-base of power-efficient hardware DECODERS to save battery life on the receive end.  I'd recommend h.264 + opus, unless h.264 patents are a problem.  Then VP9.
Peter Cordes
CC BY-SA 3.0
2015-01-15T16:20:04.690Z
Yes it will be watched on iOS devices only.
Joe
CC BY-SA 3.0
2015-01-15T16:21:42.360Z
I tried approaching the problem by getting frame samples, compressing them to jpeg with a 0.75 quality but they remain way too large (approx 20kB/frame) which is huge data for a 15fps stream. How could I stream otherwise? Short 4-5sec sequenced h.264 encoded clips?
Joe
CC BY-SA 3.0
2015-01-15T17:14:57.483Z
Sounds like you need to ask on stackoverflow how to do streaming media on iOS.  I'd guess it'd be something like:  Pick a streaming media protocol, find a library for it, and use it.  Find out how to get either raw video to feed through x264, or how to feed camera data through the hardware h.264 encoder, and feed that to your streaming media library.  Same for the audio: If there's built-in iOS support for HE-AAC, using it instead of opus might be an easier first step.  None of this should ever involve jpeg...  Use good standard video formats, don't re-invent MJPEG.
Peter Cordes
CC BY-SA 3.0
2015-01-15T13:06:07.693Z
2015-01-15T13:34:04.737Z
2015-01-15T13:34:04.737Z
Peter Cordes
<p>I am working on a project involving live streaming. My goal is to reach a data rate of no more than 200 - 267 kb/s when streaming. Is it possible to reach such low rate while keeping an acceptable fps and resolution? If so what would the fps and frame resolution?</p>

<p>Also, what compression method will I need to use? </p>

<p>Thank you.</p>

CC BY-SA 3.0
2015-01-15T12:01:21.367Z
So that's 205 to 273kbit/s.  Is that including audio?  Opus or HE-AAC can sound good for speech at 32kbit/s, and Opus is acceptable for speech at 10kb/s.
Peter Cordes
CC BY-SA 3.0
2015-01-15T12:10:32.883Z
Yes including audio.
Joe
CC BY-SA 3.0
2015-01-15T12:10:50.737Z
Voice?  Or music?
Peter Cordes
CC BY-SA 3.0
2015-01-15T12:21:33.820Z
Voice. It is a video captured from a phone's camera
Joe
CC BY-SA 3.0
2015-01-15T13:11:08.823Z
How much CPU power do you have for encoding.  Realtime on a phone with an ARM CPU?  Or realtime on a 4-core hyperthreaded i7 with AVX2, at 3GHz?
Peter Cordes
CC BY-SA 3.0
2015-01-15T13:12:38.523Z
Oh, and do you need to distribute an app that uses this?  If so, you'll probably want to use a codec that isn't encumbered with patent royalties.  (so x264 and x265 might be ruled out.)  Then vp9 would be probably the best choice.
Peter Cordes
CC BY-SA 3.0
2015-01-15T13:16:59.627Z
For audio, Opus is not patent-encumbered, and it has a special speech-specific portion it can use at low bitrates.  And it sounds at least as good as AAC, according to listening tests.  And it's optimized for low latency, which is important for 2-way chat.  Irrelevant for streaming to an audience, but not a downside.
Peter Cordes
<file-formats><compression>
Need to reach a low data rate of about 1.5 - 2 MB/min (200 - 267 kb/s)
Joe
# Need to reach a low data rate of about 1.5 - 2 MB/min (200 - 267 kb/s)

(Asked by: username_0 on 2015-01-15)

I am working on a project involving live streaming. My goal is to reach a data rate of no more than 200 - 267 kb/s when streaming. Is it possible to reach such low rate while keeping an acceptable fps and resolution? If so what would the fps and frame resolution?

Also, what compression method will I need to use?

Thank you.

**Tags:** file-formats, compression

> **Comments:**
> **username_1**: So that's 205 to 273kbit/s.  Is that including audio?  Opus or HE-AAC can sound good for speech at 32kbit/s, and Opus is acceptable for speech at 10kb/s.  
> **username_0**: Yes including audio.  
> **username_1**: Voice?  Or music?  
> **username_0**: Voice. It is a video captured from a phone's camera  
> **username_1**: How much CPU power do you have for encoding.  Realtime on a phone with an ARM CPU?  Or realtime on a 4-core hyperthreaded i7 with AVX2, at 3GHz?  
> **username_1**: Oh, and do you need to distribute an app that uses this?  If so, you'll probably want to use a codec that isn't encumbered with patent royalties.  (so x264 and x265 might be ruled out.)  Then vp9 would be probably the best choice.  
> **username_1**: For audio, Opus is not patent-encumbered, and it has a special speech-specific portion it can use at low bitrates.  And it sounds at least as good as AAC, according to listening tests.  And it's optimized for low latency, which is important for 2-way chat.  Irrelevant for streaming to an audience, but not a downside.  

---

## 1 answers

### Answer by username_1 on 2015-01-15. Score: 2 | Accepted answer

summary: yes, depending on content, with a good encoder h.264 can look pretty good at 240kib/s video bitrate, at NTSC 720x480p30.
With modern codecs, you don't need to downscale the rez too far.  If there isn't a lot of noise in your source, you're just putting the same complexity into fewer pixels.  You shouldn't encode 1080p at 270kb/s, though :P.  There is overhead to having more macroblocks, and diluting the complexity across too many pixels probably means worse results from quantizing the DCT coefficients.  Lower resolution lets you turn up the CPU-usage knob on your codec while still being realtime, though.
For a test encode, I have a lossless source of the sintel trailer.  (3D animation with fades between scenes, and significant amount of changeless).  So it's probably actually a really bad test case...
ffmpeg -i sintel.y4m -pix_fmt yuv420p -vf crop=1920:816:0:132,scale=640:-1 -ssim 1 -psnr -tune animation -preset slow -b:v 270k 640x272.x264.270k.mkv

That does quite well, with an average QP of 18.03(I) / 23.44(P) / 24.93(B).  SSIM Mean Y:0.9852979, PSNR Global:44.801 at 231.37 kib/s.  (a still section at the end leaves x264 undershooting the target bitrate for one-pass).  I left psy optimizations enabled, so x264 is trying to do what looks best, not what scores highest on SSIM or PSNR.  Just useful as a ballpark figure.
I have a live-action source that's not too noisy.  I picked a portion that just has one actor moving around on stage, everyone else standing still, and no camera motion.  So it might be similar in compressibility to a someone talking while looking at a webcam, in front of a mostly-constant background.  (stuff like this matters a LOT for compressibility).  About 1/3 of the screen is black background.  (so black the encoder knows you can't see anything, and hardly spends any bits, I assume.)
ffmpeg -ss 2410 -t 30 -i vid.yadif3.1,mcdeint3.1.10.ffvhuff.mkv -c:a opus -b:a 32k -pix_fmt yuv420p -r 30 -vf framestep=2 -ssim 1 -psnr  -preset slow -b:v 240k  2410+30.slow.opus.230k.mkv

Source is 60p deinterlace output, from NTSC DV or something.  Anyway, with those ffmpeg options, it stays as 720x480@30p (with non-square pixels, display aspect ratio = 16:9).  Output looks pretty darn good considering the bitrate, and the singing sounds good, but has some artifacts.  (audio source is not noisy, and there's no accompaniment, just soloist + chorus.)
frame=  900 fps= 35 q=-1.0 LPSNR=Y:inf U:inf V:inf *:inf size=     990kB time=00:00:30.01 bitrate= 270.3kbits/s
video:854kB audio:120kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.635424%
[libx264 @ 0x2400360] frame I:4     Avg QP:22.63  size: 23294  PSNR Mean Y:44.02 U:48.68 V:47.86 Avg:45.00 Global:42.71
[libx264 @ 0x2400360] frame P:239   Avg QP:22.23  size:  2492  PSNR Mean Y:43.64 U:48.67 V:47.52 Avg:44.67 Global:44.47
[libx264 @ 0x2400360] frame B:657   Avg QP:24.97  size:   282  PSNR Mean Y:43.38 U:48.52 V:47.37 Avg:44.43 Global:44.24
[libx264 @ 0x2400360] consecutive B-frames:  0.6%  0.0% 19.0% 80.4%
[libx264 @ 0x2400360] mb I  I16..4: 27.0% 58.0% 15.0%
[libx264 @ 0x2400360] mb P  I16..4:  0.2%  0.4%  0.1%  P16..4: 22.1%  5.1%  6.7%  0.0%  0.0%    skip:65.4%
[libx264 @ 0x2400360] mb B  I16..4:  0.0%  0.0%  0.0%  B16..8: 12.5%  0.4%  0.1%  direct: 0.1%  skip:87.0%  L0:23.6% L1:74.4% BI: 2.1%
[libx264 @ 0x2400360] final ratefactor: 22.98
[libx264 @ 0x2400360] 8x8 transform intra:59.0% inter:71.2%
[libx264 @ 0x2400360] direct mvs  spatial:99.7% temporal:0.3%
[libx264 @ 0x2400360] coded y,uvDC,uvAC intra: 50.7% 48.1% 24.7% inter: 2.8% 5.1% 0.2%
[libx264 @ 0x2400360] i16 v,h,dc,p: 36% 38%  7% 19%
[libx264 @ 0x2400360] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15%  4% 22%  8% 12% 11% 12%  8%  8%
[libx264 @ 0x2400360] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 14%  3%  5% 12% 15% 16% 12% 12% 10%
[libx264 @ 0x2400360] i8c dc,h,v,p: 48% 27% 18%  7%
[libx264 @ 0x2400360] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 0x2400360] ref P L0: 66.9%  8.4% 14.9%  3.5%  4.6%  1.6%
[libx264 @ 0x2400360] ref B L0: 85.5% 10.8%  2.9%  0.8%
[libx264 @ 0x2400360] ref B L1: 92.3%  7.7%
[libx264 @ 0x2400360] SSIM Mean Y:0.9730952 (15.702db)
[libx264 @ 0x2400360] PSNR Mean Y:43.450 U:48.564 V:47.412 Avg:44.498 Global:44.292 kb/s:232.89

And 35fps on my E6600 (2.4GHz dual core first-gen c2duo) is not bad.  If you're trying to live-stream from a phone, you're going to be much more constrained, though.  You could use lower rez or lower framerate (25 fps, or 24, or 20?)
I was actually surprised at how well x264 did with -preset veryfast.  I guess on this content, even veryfast finds most of the same redundancy to eliminate.
frame=  900 fps= 90 q=-1.0 LPSNR=Y:inf U:inf V:inf *:inf size=     994kB time=00:00:30.01 bitrate= 271.5kbits/s    
video:859kB audio:120kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.612045%
[libx264 @ 0x37b6420] frame I:4     Avg QP:21.51  size: 24840  PSNR Mean Y:44.16 U:48.09 V:47.20 Avg:44.99 Global:42.15
[libx264 @ 0x37b6420] frame P:227   Avg QP:21.22  size:  2649  PSNR Mean Y:43.57 U:48.08 V:46.72 Avg:44.50 Global:44.26
[libx264 @ 0x37b6420] frame B:669   Avg QP:22.30  size:   267  PSNR Mean Y:43.32 U:48.04 V:46.67 Avg:44.29 Global:44.02
[libx264 @ 0x37b6420] consecutive B-frames:  0.9%  0.0%  0.0% 99.1%
[libx264 @ 0x37b6420] mb I  I16..4: 24.0% 45.9% 30.1%
[libx264 @ 0x37b6420] mb P  I16..4:  1.4%  2.8%  0.1%  P16..4: 20.9%  4.2%  3.1%  0.0%  0.0%    skip:67.5%
[libx264 @ 0x37b6420] mb B  I16..4:  0.1%  0.2%  0.0%  B16..8:  1.7%  0.6%  0.1%  direct: 2.1%  skip:95.2%  L0:23.9% L1:45.7% BI:30.3%
[libx264 @ 0x37b6420] final ratefactor: 20.78
[libx264 @ 0x37b6420] 8x8 transform intra:60.6% inter:38.4%
[libx264 @ 0x37b6420] coded y,uvDC,uvAC intra: 39.1% 40.2% 10.5% inter: 2.7% 3.1% 0.1%
[libx264 @ 0x37b6420] i16 v,h,dc,p: 73% 11% 13%  3%
[libx264 @ 0x37b6420] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12%  7% 73%  1%  1%  1%  2%  1%  1%
[libx264 @ 0x37b6420] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 13% 14%  5%  8%  9%  8%  6%  6%
[libx264 @ 0x37b6420] i8c dc,h,v,p: 76%  8% 15%  1%
[libx264 @ 0x37b6420] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 0x37b6420] SSIM Mean Y:0.9737951 (15.816db)
[libx264 @ 0x37b6420] PSNR Mean Y:43.390 U:48.047 V:46.685 Avg:44.343 Global:44.068 kb/s:234.13

bitrate ended up 2kib/s higher, with about the same PSNR, and higher SSIM.  
With -tune ssim to disable psychovisual optimizations (don't do this for real use),
veryfast gets: Y-SSIM: 15.891db, PSNR Global:44.294, kb/s:233.26.
slow gets: Y-SSIM: 16.097db, PSNR Global:44.752, kb/s:232.86
So that's what x264 can do with h.264 High@L3.0 profile, at 0.023 bits/pixel/frame.
tested x265:
ffmpeg -ss 2410 -t 30 -i vid.yadif3.1,mcdeint3.1.10.ffvhuff.mkv -c:a opus -b:a 32k -pix_fmt yuv420p -r 30 -vf framestep=2 -ssim 1 -psnr -c:v libx265 -preset slow -b:v 240k -aspect 16:9 x265.2410+30.slow.opus.230k.mkv
ffmpeg version N-68044-gb9dd809 Copyright (c) 2000-2015 the FFmpeg developers
  built on Jan 14 2015 23:21:08 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
  configuration: --enable-gpl --enable-version3 --enable-nonfree --disable-doc --disable-ffserver --enable-libbluray --enable-libschroedinger --enable-libtheora --enable-libx264 --enable-libx265 --enable-libmp3lame --enable-libopus --enable-libwebp --enable-libvpx --disable-outdev=oss --disable-indev=oss --disable-encoder=vorbis --enable-libvorbis --enable-libfdk-aac --disable-encoder=aac --disable-decoder=jpeg2000 --enable-libvidstab
  libavutil      54. 16.100 / 54. 16.100
  libavcodec     56. 20.100 / 56. 20.100
  libavformat    56. 18.101 / 56. 18.101
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5.  7.101 /  5.  7.101
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  1.100 /  1.  1.100
  libpostproc    53.  3.100 / 53.  3.100
Input #0, matroska,webm, from 'vid.yadif3.1,mcdeint3.1.10.ffvhuff.mkv':
  Metadata:
    ENCODER         : Lavf56.15.102
  Duration: 01:22:11.94, start: 0.000000, bitrate: 95843 kb/s
    Stream #0:0: Video: ffvhuff (FFVH / 0x48564646), yuv420p, 720x480, SAR 186:157 DAR 279:157, 59.94 fps, 59.94 tbr, 1k tbn, 1k tbc (default)
    Metadata:
      ENCODER         : Lavc56.14.100 ffvhuff
    Stream #0:1: Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s (default)
Codec AVOption ssim (Calculate and print SSIM stats.) specified for output file #0 (x265.2410+30.veryfast.opus.230k.mkv) has not been used for any stream. The most likely reason is either wrong type (e.g. a video option with no video streams) or that it is a private option of some encoder which was not actually used for any stream.
x265 [info]: HEVC encoder version 1.4+286-a12080554342
x265 [info]: build info [Linux][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
x265 [warning]: --psnr used with AQ on: results will be invalid!
x265 [warning]: --tune psnr should be used if attempting to benchmark psnr!
x265 [info]: Main profile, Level-3 (Main tier)
x265 [info]: WPP streams / frame threads / pool  : 15 / 1 / 2
x265 [info]: CTU size / RQT depth inter / intra  : 32 / 1 / 1
x265 [info]: ME / range / subpel / merge         : hex / 57 / 1 / 2
x265 [info]: Keyframe min / max / scenecut       : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt        : 15 / 4 / 0
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 1
x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-240 kbps / 1.0 / 0
x265 [info]: tools: rd=2 early-skip deblock sao signhide fast-intra tmvp 
Output #0, matroska, to 'x265.2410+30.veryfast.opus.230k.mkv':
  Metadata:
    encoder         : Lavf56.18.101
    Stream #0:0: Video: hevc (libx265), yuv420p, 720x480 [SAR 32:27 DAR 16:9], q=2-31, 240 kb/s, 30 fps, 1k tbn, 30 tbc (default)
    Metadata:
      encoder         : Lavc56.20.100 libx265
    Stream #0:1: Audio: opus (libopus) ([255][255][255][255] / 0xFFFFFFFF), 48000 Hz, stereo, flt, 32 kb/s (default)
    Metadata:
      encoder         : Lavc56.20.100 libopus
Stream mapping:
  Stream #0:0 -> #0:0 (ffvhuff (native) -> hevc (libx265))
  Stream #0:1 -> #0:1 (ac3 (native) -> opus (libopus))
Press [q] to stop, [?] for help
frame=  900 fps= 24 q=0.0 LPSNR=Y:inf U:inf V:inf *:inf size=     998kB time=00:00:30.01 bitrate= 272.4kbits/s    
video:861kB audio:120kB subtitle:0kB other streams:0kB global headers:1kB muxing overhead: 1.713292%
x265 [info]: frame I:      4, Avg QP:21.87  kb/s: 5097.48   PSNR Mean: Y:43.899 U:48.345 V:47.187  SSIM Mean: 0.968502 (15.017dB)
x265 [info]: frame P:    177, Avg QP:18.74  kb/s: 710.27    PSNR Mean: Y:43.347 U:48.274 V:47.041  SSIM Mean: 0.973469 (15.763dB)
x265 [info]: frame B:    719, Avg QP:20.83  kb/s: 89.99     PSNR Mean: Y:43.113 U:48.231 V:47.010  SSIM Mean: 0.972552 (15.615dB)
x265 [info]: global :    900, Avg QP:20.42  kb/s: 234.24    PSNR Mean: Y:43.163 U:48.240 V:47.017  SSIM Mean: 0.972714 (15.641dB)
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 0.6% 0.0% 0.0% 0.6% 98.9% 

(Note that I needed -x265-params ssim=1, because the ffmpeg libx265 interface doesn't pick up a lot of the commandline options.)
    slow: 253.245kbit/s fps=1.7  Y PSNR:44.228 unknown SSIM, forgot to turn it on
veryfast: 244.347kbit/s fps= 24  Y PSNR:43.163 15.641dB SSIM.

perceptually, the x265 veryfast output has less blocking than the x264 slow output.  I think x265 looks better.
x264 and x265 both from the git / hg repos, updated Jan 10th.

> **Comments:**
> **username_1**: Doing a test-encode now with x265.  It's 15 times slower, but should do well at low bitrate.  
> **username_0**: Amazing. I see you are using ffmpeg and have seen some instructions on how to compile ffmpeg for iOS but couldn't do so successfully.  
> **username_1**: for iOS?  So you need this to run on a phone?  yeah, don't even think about x265 then.  x264 has some ARM asm optimizations for ARM CPUs with a vector unit, and can prob. run in realtime with low rez.  You'd be trading more battery usage for better video quality, compared to using the hardware h.264 encoder.  
> **username_1**: check out http://demos.webmproject.org/ios/vp9.  Amusingly, they too chose the Sintel trailer as their source.  
> **username_1**: Also, you don't need ffmpeg.  It's just a convenient commandline frontend to the encoding library.  You might want some of the various libav libraries to handle muxing your video+audio into a standard container format, instead of reinventing the wheel with either a custom protocol for carrying the bitstreams, or writing your own code for muxing them into mkv.  
> **username_1**: If you expect people to watch these streams on phones, not just send them from phones to desktops, then h.264 has the advantage of a high installed-base of power-efficient hardware DECODERS to save battery life on the receive end.  I'd recommend h.264 + opus, unless h.264 patents are a problem.  Then VP9.  
> **username_0**: Yes it will be watched on iOS devices only.  
> **username_0**: I tried approaching the problem by getting frame samples, compressing them to jpeg with a 0.75 quality but they remain way too large (approx 20kB/frame) which is huge data for a 15fps stream. How could I stream otherwise? Short 4-5sec sequenced h.264 encoded clips?  
> **username_1**: Sounds like you need to ask on stackoverflow how to do streaming media on iOS.  I'd guess it'd be something like:  Pick a streaming media protocol, find a library for it, and use it.  Find out how to get either raw video to feed through x264, or how to feed camera data through the hardware h.264 encoder, and feed that to your streaming media library.  Same for the audio: If there's built-in iOS support for HE-AAC, using it instead of opus might be an easier first step.  None of this should ever involve jpeg...  Use good standard video formats, don't re-invent MJPEG.  

---

