FORUMS: list search recent posts

Getting either incorrect output resolution or FPS from ffmpeg

COW Forums : Compression Techniques

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
Adam Langley
Getting either incorrect output resolution or FPS from ffmpeg
on Oct 31, 2011 at 7:59:15 pm

Hi, I have posted a query to SO here ( so I wont repeat it here.

Can you see what might be going wrong?
Ultimately, I need to use OpenRTSP to capture the stream, because using the built in ffmpeg rtsp support results in corrupted video for some reason (big blurry chunks in the picture). I need to use ffmpeg to encode a few streams from this source, at iPhone native res (960x640). This is to support the iPhone adaptive streaming support for low bandwidths...
I believe that because I am using -vcodec copy, it copies ALL codec parameters (not just the codec type) which is what's causing it to ignore my -s 960x640 request. However, if I switch to -vcodec libx264, I get the problems mentioned in the post... early stream termination and a FPS of 2 or 3.

This is confusing the heck out of me.

Thanks in advance for any light you can shed on the matter.

Return to posts index

Reuben Martin
Re: Getting either incorrect output resolution or FPS from ffmpeg
on Nov 1, 2011 at 5:28:15 am

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)

Return to posts index

Adam Langley
Re: Getting either incorrect output resolution or FPS from ffmpeg
on Nov 2, 2011 at 9:11:28 am

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!

Return to posts index

Reuben Martin
Re: Getting either incorrect output resolution or FPS from ffmpeg
on Nov 3, 2011 at 5:25:08 am

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

Return to posts index

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
© 2020 All Rights Reserved