Getting either incorrect output resolution or FPS from ffmpeg

Question

I am capturing an RTSP stream from a security camera, and transcoding it for (live streaming) to iphone, using OSX as the encoding platform. I have it working correctly, and Im tuning it. However, it seems that it is not outputting the requested resolution. This is my script

/Applications/SecurityCamera/openRTSP -v -c -t rtsp://10.0.1.118/ch1-s1 | \
    /Applications/SecurityCamera/ffmpeg \
    -r 10 -i - \
    -y -an -ab 64000 -f mpegts -vcodec copy -s 960x640 \
    -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 \
    -subq 5 -trellis 1 -refs 1 -coder 0 -me_range 16  -keyint_min 25 \
    -sc_threshold 40 -i_qfactor 0.71 -bt 400k -maxrate 524288 -bufsize 524288 \
    -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -level 30 \
    -aspect 960:640 -r 10 -g 10 -async 2 -\
    |/Applications/SecurityCamera/mediastreamsegmenter -b http://localhost:8080/\
      -f /Library/WebServer/Documents/ -i stream.m3u8 -t 10 -s 4 -D

This is the status report:

Input #0, h264, from 'pipe:':

  Duration: N/A, bitrate: N/A
  Stream #0.0: Video: h264, yuv420p, 1600x1200, 10 fps, 10 tbr, 1200k tbn, 20 tbc
  [mpegts @ 0x10100c200] muxrate VBR, pcr every 1 pkts, sdt every 200, pat/pmt every 40 pkts
  Output #0, mpegts, to 'pipe:':
  Metadata:
    encoder         : Lavf52.93.0
    Stream #0.0: Video: libx264, yuv420p, 1600x1200 [PAR 1:1 DAR 4:3], q=2-31, 90k tbn, 10 tbc
Stream mapping:
  Stream #0.0 -> #0.0

You can see that its working, but it is outputting 1600x1200 for some reason. (possibly -vcodec copy copies all codec parameters, not just the codec type?)

If I change the -vcodec copy to -vcodec libx264 then I get the correct status report (stating 960x640, correct), but the streaming switches to 2 FPS (why? Im forcing both input and output!) and it halts after 54 frames (see output below)

Seems stream 0 codec frame rate differs from container frame rate: 20.00 (20/1) -> 10.00 (20/2)
Input #0, h264, from 'pipe:':
  Duration: N/A, bitrate: N/A
    Stream #0.0: Video: h264, yuv420p, 1600x1200, 10 fps, 10 tbr, 1200k tbn, 20 tbc
[buffer @ 0x100d02420] w:1600 h:1200 pixfmt:yuv420p
[scale @ 0x100d026f0] w:1600 h:1200 fmt:yuv420p -> w:960 h:640 fmt:yuv420p flags:0x4
[libx264 @ 0x10100d400] using SAR=1/1
[libx264 @ 0x10100d400] frame MB size (60x40) > level limit (1620)
[libx264 @ 0x10100d400] using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowCTZ SlowAtom
[libx264 @ 0x10100d400] profile Constrained Baseline, level 3.0
[mpegts @ 0x10100c200] muxrate VBR, pcr every 1 pkts, sdt every 200, pat/pmt every 40 pkts
Output #0, mpegts, to 'pipe:':
  Metadata:
    encoder         : Lavf52.93.0
    Stream #0.0: Video: libx264, yuv420p, 960x640 [PAR 1:1 DAR 3:2], q=10-51, 200 kb/s, 90k tbn, 10 tbc
Stream mapping:
  Stream #0.0 -> #0.0
read pmap fffps=  3 q=37.0 size=      37kB time=0.10 bitrate=3008.0kbits/s    bits/s    
video pid set at 100
found sequence start
  next segment value 1026000
written bytes 376 skipped 0
frame=   54 fps=  2 q=-1.0 Lsize=     160kB time=5.40 bitrate= 242.0kbits/s    
video:141kB audio:0kB global headers:0kB muxing overhead 12.872737%
frame I:6     Avg QP:34.68  size: 23524
[libx264 @ 0x10100d400] frame P:48    Avg QP:41.53  size:    75
[libx264 @ 0x10100d400] mb I  I16..4: 63.9%  0.0% 36.1%
[libx264 @ 0x10100d400] mb P  I16..4:  0.1%  0.0%  0.0%  P16..4:  0.8%  0.1%  0.0%  0.0%  0.0%    skip:99.0%
[libx264 @ 0x10100d400] final ratefactor: 38.54
[libx264 @ 0x10100d400] coded y,uvDC,uvAC intra: 57.7% 22.3% 2.0% inter: 0.0% 0.1% 0.0%
[libx264 @ 0x10100d400] i16 v,h,dc,p: 23% 35% 27% 15%
[libx264 @ 0x10100d400] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 23% 32% 16%  4%  3%  3%  7%  4%  8%
[libx264 @ 0x10100d400] i8c dc,h,v,p: 83% 11%  5%  0%
[libx264 @ 0x10100d400] kb/s:214.43

Answer 1

As you guessed, -vcodec copy doesn't mean "use the same type of encoding" it means "pass the data through unchanged". None of those myriad other options you're setting are doing anything with the codec set to copy.

I assume that setting it to libx264, and thus actually transcoding the video, slows it down because now it's having to do a lot of work. Especially if the input video is 1600x1200 h264.

Depending on your needs, scaling at the point of display will definitely be faster than transcoding, otherwise keep tuning.