Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-01-15T13:09:20.030Z
Answers.Text: Doing a test-encode now with x265.  It's 15 times slower, but should do well at low bitrate.
Answers.UserDisplayName: Peter Cordes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-01-15T13:29:17.613Z
Answers.Text: 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.
Answers.UserDisplayName: Joe
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-01-15T13:37:32.757Z
Answers.Text: 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.
Answers.UserDisplayName: Peter Cordes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-01-15T13:40:01.740Z
Answers.Text: check out http://demos.webmproject.org/ios/vp9.  Amusingly, they too chose the Sintel trailer as their source.
Answers.UserDisplayName: Peter Cordes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-01-15T13:55:04.727Z
Answers.Text: 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.
Answers.UserDisplayName: Peter Cordes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-01-15T13:57:51.123Z
Answers.Text: 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.
Answers.UserDisplayName: Peter Cordes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-01-15T16:20:04.690Z
Answers.Text: Yes it will be watched on iOS devices only.
Answers.UserDisplayName: Joe
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-01-15T16:21:42.360Z
Answers.Text: 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?
Answers.UserDisplayName: Joe
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-01-15T17:14:57.483Z
Answers.Text: 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.
Answers.UserDisplayName: Peter Cordes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-01-15T13:06:07.693Z
Answers.LastActivityDate: 2015-01-15T13:34:04.737Z
Answers.LastEditDate: 2015-01-15T13:34:04.737Z
Answers.UserDisplayName: Peter Cordes
Body: <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>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-01-15T12:01:21.367Z
Comments.Text: 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.
Comments.UserDisplayName: Peter Cordes
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-01-15T12:10:32.883Z
Comments.Text: Yes including audio.
Comments.UserDisplayName: Joe
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-01-15T12:10:50.737Z
Comments.Text: Voice?  Or music?
Comments.UserDisplayName: Peter Cordes
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-01-15T12:21:33.820Z
Comments.Text: Voice. It is a video captured from a phone's camera
Comments.UserDisplayName: Joe
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-01-15T13:11:08.823Z
Comments.Text: 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?
Comments.UserDisplayName: Peter Cordes
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-01-15T13:12:38.523Z
Comments.Text: 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.
Comments.UserDisplayName: Peter Cordes
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-01-15T13:16:59.627Z
Comments.Text: 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.
Comments.UserDisplayName: Peter Cordes
Tags: <file-formats><compression>
Title: Need to reach a low data rate of about 1.5 - 2 MB/min (200 - 267 kb/s)
UserDisplayName: Joe
ThreadText: # 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](https://www.youtube.com/watch?v=JHVkegpW_ok). (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.  
  
  ---
  
  