[FFmpeg-user] Deinterlace and change framerate with -vcodec copy

[Peter Bašista]

>> But I assume it is not possible with -vcodec copy. Or am I mistaken?
> You are not mistaken. Deinterlacing only works on uncompressed video and
> changes the video data (or more accurately, it creates new video data
> based on the input), so it is impossible to deinterlace without decoding.

Thank you for pointing that out and explaining it in more detail. Mark
has already suggested the same view, so I think it is clear now.

>> To my knowledge, the deinterlace filters just somehow combine the frames together, but they do not change the framerate.
> It depends on the strategy used by the filter. Yadif, for example, can
> produce one frame for each field, doubling the framerate, or it can
> produce a frame for each pair of fields, leaving the framerate the same.

We have been discussing this as well. But thank you anyway for more information.

>>  And here, I _want_ the framerate to be changed from 50fps to 25fps. So, basically, I _want_ half of the frames to be deleted. But, I want the resulting frames to be complete, not just odd or even lines.
> 2 fields = 1 frame. Each field is half of the picture. Uncompressed, 50
> fields contain the same amount of data as 25 frames.

Yes, now I know that. Mark has pointed that out and explained some
details. It should be clear now.

>> Let's say I have managed to get a 25fps noninterlaced file movie.mkv. Is there any "easy" way to change the framerate to 24fps? By "easy" I mean without reencoding (or: with -vcodec copy).
> You could simply drop every 25th frame

Actually, according to information from Mark, this would require
reencoding. And I agree with that, because it sounds reasonable. You
have to somehow fill in the "blank spot" created by a dropped frame.

Let's say you delete frame number 100. Then you have to completely
change the way frame 101 is computed, because it was originally
computed from frame 100, which is now gone. So, you will have to
encode at least the transition from the frame 99 to 100 and from 100
to 101 into one new transition (from frame 99 to frame 101)... So, I
believe encoding is required, at least for the frames just after the
dropped frames. But, as I mentioned, this is not what I would like to
do.

> or simply change the headers (I recommend changing container
> headers) to tell the player to play 24fps
> (which will make it slower, and you'll lose sync if you don't adjust the
> audio). If you're trying to get the original 23.976fps of a movie from a
> 50i source, I can't really give much advice because I don't know all the
> details involved in handling film content in PAL broadcast systems.

All right, that's okay. Actually you made the point. This is exactly
what I am trying to achieve. Although I am not sure at the moment what
should the target frame rate be (24 fps or 23.976 fps), it is not
important right now. The challenge is to decrease the frame rate in
general without changing the number of frames and without reencoding.

>> This, in my opinion, should be possible, because it seems like a rather minor change. Here I would like to emphasize that what I want to change is the _framerate_ not the number of frames. So, I expect the video to be longer (take more time to play) after such a framerate change.
> In this case, you should be able to change the framerate in the
> container headers. mkvtoolnix would be suitable for manipulating
> Matroska containers.

Thank you for a suggestion. I will try that.

But even if I succeed in changing the container's headers in a way
that the video will play at 96% speed, I am not sure if I want to do
it. The reason is simple. If someone later extracts the video out of
this container, what would its frame rate be?

I suppose it will remain unchanged at the "old" value, which means 25
fps. And this is what I want to avoid. I want the fps change to be
more robust than that. I don't want the careless container changes to
blow the fps change away.

That's why I consider changing PTS (presentation time stamps) of the
video frames as suggested by Mark as better, more stable solution. The
only problem is I don't know how to do it. (yet) :)

Peter Basista