[FFmpeg-user] Woah, can I not change frame rate with 1:1 mapping?

[Thomas Worth]

On Sat, Oct 22, 2011 at 2:43 AM, Nicolas George
<nicolas.george at normalesup.org> wrote:
> Le decadi 30 vendémiaire, an CCXX, Thomas Worth a écrit :
>> That works, but why not allow the use the -r option ahead of -i like
>> with image sequences? That seems more intuitive. Otherwise, I have do
>> do some math to figure out what the PTS values should be.
>
> Frame rate is not something that really makes sense. Some formats do not
> have such thing as frame rate, they only have timestamps for the packets.
> Sure, some formats could take the -r option into account and currently do
> not, but I do not think it would be a good thing.

I understand this. In fact, there is no such thing as frame rate with
image sequences but -r still works with them. Is there any downside to
making -r specify frame rate (for containers that support it) between
packet boundaries? In other words, we know each packet will contain a
frame (like each PNG file contains a frame) so why can't this work the
exact same way it does with image sequences?

IMHO, if -r for input is not even implemented (instead giving an
error), it should at least be enabled for containers that support
frame rates like MOV or AVI. It's just so convenient.


> Just think to the -r option that way: the input format does not specify
> timestamps nor frame rate, I must specify it myself, or I will use the
> arbitrary default built in the library.

Yeah but we could just as easily override the input container's frame
rate (or packet boundary) with -r if this was supported. The PTS
filter is a bit hacky and subject to rounding errors, especially for
fractional frame rates like 59.94, 29.97 and 23.976.

All I'm saying is it would be nice to just say -r 23.976 so the muxer
thinks the input frame rate is 23.976. If frame rates aren't supported
with the container, then the value could be ignored. It seems like a
no-brainer, but if I am overlooking something then please explain.