Getting either incorrect output resolution or FPS from ffmpeg

[Reuben Martin]

I think you mis-understand the functionality of the “copy” option. It does not copy the codec type of the source video and re-encode it using the same codec. It takes the video stream as is, and dumps it to where ever your destination is. (e.g. the video stream in the output is bit-for-bit the same as it is in the source)

The encoding parameters (in your case things such as frame rate / frame size) can not be changed without re-encoding the video stream.

The FPS you are referring to is not the FPS of the video stream, but rather the speed that FFMPEG is encoding. (Which in this case means something elsewhere is probably screwed up)

The fps of the incoming video stream is shown as 20 framerate, 1 framebase with the transport container showing 20 framerate, 2 framebase. (This would generally imply 10 fps interlaced)

You have a lot of piping going on here. I would try starting from the source, and place a player at the end of each segment of the pipeline to make sure the output from each section is working as expected. (use something like ffplay, ffprobe can be informative too)

[Adam Langley]

Hi Reuben,

Thanks for the advice – I have made some progress.
I have ditched OpenRTSP for the time being, and have appended ?tcp to the RTSP url in ffmpeg – this seems to work correctly as far as not getting video corruption (which happens if ffmpeg attempts to use UDP).
I compiled all the software on my macbook pro – and copied the binaries to an Atom machine – so the code is exactly the same.
using a straight “ffmpeg -t rtsp://xxxxx output.mp4″ (with additional transcode options) it works perfectly on my macbook pro – but on the Atom computer, it only outputs 2fps, then dies after 50 or so frames.

The only difference I can see is on this…
Macbook: [libx264 @ 0x101027800] using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
Atom: [libx264 @ 0x10110ec00] using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowCTZ SlowAtom

So, I assume that libx264 has some significantly different code-paths resulting from “SlowCTZ” and “SlowAtom”.

What can I do to disable these ‘cpu optimizations’? I dont care if it consumes twice as much CPU… if it works!

Thanks again!

[Reuben Martin]

They are not optimizations, but rather work-arounds.

From FFMPEG’s source code:

#define X264_CPU_SLOW_CTZ 0x100000 /* BSR/BSF x86 instructions are really slow on some CPUs */
#define X264_CPU_SLOW_ATOM 0x200000 /* The Atom just sucks */

The problem may be more to do with the fact that an Atom is simply not designed with this type of processor intensive work load. If it cannon encode fast enough to keep up with the input from the pipe, that may be what forces it to close. You should probably benchmark ffmpeg encoding by itself from a source file of the same format, without all the streaming and pipes. That way you can get an idea of how fast it can encode with the settings you are using.

The corruption from UDP sources may simply be due to the way UDP works. If a packet is lost, or arrives out of order it is simply discarded, which can corrupt video content when parts of the stream are missing. TCP forces packets to arrive in order, and requests lost packets to be re-transmitted.

You might also look into using VLC from the command line. It has much more robust support for RTSP, and can probably take care of the http live streaming aspect as well. Doing all that within a single process eliminates a lot of overhead generated using pipes