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

[Mark Himsley]

On 21/05/2011 23:37, Peter Bašista wrote:
>>>> No, I very much doubt that is true. There are no DVB broadcasters that I
>>>> know of which transmit at 100 fields per second, which is what you are
>>>> implying. Please supply the output of "ffmpeg -i DVBchannel.mpegts"
>>>
>>> Okay, I am sorry, you are right. I have posted something
>>> that is definitely confusing.
>>>
>>> I should have written 50 fields per second, not frames per second.
>>> By "interlaced at 50fps" I was trying to tell that the video contains
>>> 50 fields (or half frames) per second. But I did not know about
>>> the difference between frames and fields before you replied.
>>> So, thank you for pointing that out.
>>
>> Ok. So you say you have a video that is encoded at 25i (50 fields per
>> second)(and if anyone wants the 25i verses 50i argument then please
>> start a new thread, I'll be happy to join in ;-).
>>
>> I hope you understand that each frame will contain 2 fields, that is,
>> two picture each taken 20 milliseconds apart that are encoded onto
>> alternating lines of the frame.
> 
> Yes, that I understand.
> 
>> And what you want to do is output 25 frames per second without throwing
>> away any data and without re-encoding?
> 
> Precisely. That is what I originally wanted to do.
> 
>> Before I go much further, I think I should point out that that will look
>> horrible. Turning an interlaced frames into progressive frames without
>> doing some de-interlacing will leave you with comb artefacts on all
>> movement.
> 
> Ok, that's not good. I am sorry, now I see it would be "a little"
> weird to do that.
> 
> I recall that my original intention to deinterlace like that came from
> (obviously incorrect) idea, that the two adjacent fields of an
> interlaced video are actually formed from a single original frame.
> 
> That would mean that in 25 fps interlaced video some of the adjacent
> fields would be 40 ms apart and some would be 0 ms apart. I just
> wanted to merge the ones that are 0 ms apart into single frames. And I
> thought it might be posiible without (much) reencoding.

That would be called Segmented Field and has a shorthand of 25PsF. Most
films are broadcast as 25PsF in 50Hz territories although the MPEG
frames will indicate that they are interlaced.

http://en.wikipedia.org/wiki/Interlaced
http://en.wikipedia.org/wiki/Progressive_segmented_frame

> Now I know it can not be done like this. There are not any adjacent
> fields which are 0 ms apart. That's why it would be inappropriate to
> simply merge them.
> 
>> It is not something I would want to do, but I do have a vague
>> recollection of some bit of software being able to twiddle with the
>> flags on an mpeg2 video stream to alter the interlaced/progressive
>> flags. But since, in general, doing so would be horrible, I've forgotten
>> what it is.
> 
> Now I am a little bit confused. Just to make it clear, here you are
> talking about video format or video codec? Mpeg-2 transport stream
> (mpegts) or mpeg-2 video codec (mpeg2video)?

Each MPEG2/4 frame includes a flag to indicate if that frame is
interlaced and whether its top-field-first or bottom field first.

> But either way, I thought that you have just been trying to point out
> that what makes a video interlaced or deinterlaced is the whole nature
> of encoding the frames, fileds, etc. And now you say something about a
> flag that could change a video from interlaced to deinterlaced and
> vice versa? Just like that? By altering flag? How is that possible?

It is possible to have a piece of software that reads the transport
stream and alters the interlaced/progressive/TFF/BFF flags on each
frame. I do not know of software that can do that.

>>> You wanted me to post output from ffmpeg -i DVBchannel.mpegts, so here it is:
>>>
>>> Seems stream 0 codec frame rate differs from container frame rate:
>>> 50.00 (50/1) -> 50.00 (50/1)
>>> Input #0, mpegts, from 'DVBchannel.mpegts':
>>>  Duration: 01:23:55.58, start: 54068.412678, bitrate: 5916 kb/s
>>>  Program 1
>>>    Stream #0.0[0x44d]: Video: h264 (Main), yuv420p, 1440x1080 [PAR
>>> 4:3 DAR 16:9], 55.22 fps, 50 tbr, 90k tbn, 50 tbc
>>>    Stream #0.1[0x44e](eng): Audio: mp2, 48000 Hz, stereo, s16, 192 kb/s
>>
>> Interesting that FFmpeg says the file is 55.22 fps... FFmpeg generally
>> tells you the field rate for interlaced files - but that is a strange rate.
> 
> I agree, it is strange, but that's what ffmpeg says. I have another
> video from the same source and the reported fps is 59.81. So, the
> reported value is "unstable" :) and I think it is just estimated
> incorrectly.
> 
> As far as I know, ffmpeg estimates fps from the first a few
> milliseconds (or frames, Bytes, I am not sure) of the video. In mpegts
> recorded from DVB, I think it might be possible that the leading part
> of the file is recorded incorrectly due to the delay caused by
> overhead of starting the recording. I have also forgotten to mention
> that when I run ffmpeg -i DVBstream.mpegts, there is a lot of warnings
> like this:
> 
> [h264 @ 0xce3c20] non-existing PPS referenced
> [h264 @ 0xce3c20] non-existing PPS 0 referenced
> [h264 @ 0xce3c20] decode_slice_header error
> [h264 @ 0xce3c20] no frame!
> ...
> [mpegts @ 0xcde6c0] max_analyze_duration 5000000 reached at 5016000
> 
> So, something is definitely wrong and that might, in my opinion,
> result in wrong frame rate detection.
> 
>>> I have reformulated the remaining part of my original email, so I repost it.
>>>
>>> I want the final file to play as simply as possible
>>> (e.g. without the deinterlace filters), so I would like to deinterlace
>>> the video in advance. But I assume it is not possible with -vcodec copy.
>>> Or am I mistaken?
>>>
>>> My point here is that I do not want to reencode the video "just"
>>> to deinterlace it. I want to do it as simply as possible, utilizing
>>> as much previous encoding work as possible. But as far as I know,
>>> it is necessary to completely reencode the video in order to
>>> use the deinterlace filters. Am I correct?
>>>
>>> To my knowledge, the deinterlace filters just somehow
>>> combine the fields (half frames) together, but they do not change
>>> the framerate. So, my first question is: Is there a video codec
>>> for which it is possible to deinterlace video with -vcodec copy?
>>> I would really appreciate if it would be possible for h264.
>>
>> The yadif filter can take the 50 fields and convert them into 50 frames,
>> which doubles the frame rate. It can also drop every other field -
>> preserving the 25 fps.
> 
> So, I have two options: either double the frame rate to 50 fps (double
> the number of frames) and dramatically increase the video size or
> leave the fps at 25 but lose the smoothness of 50 fields per second.
> Hmm ... I think I will stick to the interlaced video and, despite my
> original intention, keep using the real time deinterlace filter.
> 
> If I use the one which doubles the video framerate, I should be happy
> enough. I will not lose smoothness and my video size remains the same.
> The only drawback would be the deinterlacing overhead.
> 
>>> And my second question is about the framerate itself.
>>>
>>> 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).
>>
>> That's an easy answer. No.
> 
> Oh, that's too bad!
> 
>>> 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.
>>
>> Ok. Think about how h.264 is encoded. It contains few 'I' frames
>> (effectively a full frame - only compressed) but it also contains 'P'
>> frames and 'B' frames that both just encode the differences between
>> other frames and this frame. If you just simply throw away frames, as
>> your opinion suggests should be possible, then you are just throwing
>> away frames that OTHER frames REQUIRE in order to be able to create them.
> 
> All right, here we completely don't understand each other. I do not
> suggest that it is possible to throw away frames. By far not!
> 
> I just want the frames to "remain longer on the screen" when playing
> :) ... For example, a frame will not to be displayed for 1/25th of a
> second but for 1/24th of a second. And that, in my opinion, should be
> pretty simple to achieve, ... I would expect that changing some video
> codec flag would do the trick.
> 
>> So, no, you cannot just throw away frames in a h.264 stream (unless your
>> h.264 stream is 'I' frame only, which yours will not be).
> 
> All right, we made that clear and I know I can not.

Each frame of video and audio in your transport stream includes a
Presentation Time Stamp. Audio frames are a different size to video
frames. The PTS is used to (a) present the video/audio in sync and (b)
to present the video/audio at the correct speed.

It is not inconceivable for a piece of software to read the transport
stream and alter the PTS of every frame to make the video run slow. Now,
what happens to the audio. The audio stream is encoded at (say) 48,000
samples per second. If you have altered the PTS of the video and audio
frames so that they are presented at 96% of full speed then the audio
sample rate needs to be altered to 46,080 samples per second - which is
not (as far as I know) something that can be done.

I think your idea of messing with the file is doomed.

>>> So, I expect the video to be longer (take more time to play)
>>> after such a framerate change. Here:
>>> http://www.hdslr-cinema.com/news/workflow/convert-between-framerates/
>>> the author mentions that such a framerate change
>>> is referred to as "conforming".
>>>
>>> I tried the intermediate rawvideo format method described
>>> on the mentioned website, but it is of no use for me,
>>> because it requires reencoding. I would really like to do it
>>> with -vcodec copy. Is is possible? If it is, which codecs
>>> allow for framerate changes like this? Does h264 support it?
>>
>> No. To change frame rate you have to decode, throw away 'baseband' 'I'
>> frames, and re-encode.
> 
> I don't understand why. I mean, why can't I just flag the video to be
> played at the slower speed "by default"? It would then be very simple
> to change frame rate. If it is not possible in every video codec, does
> at least h264 support it? If not, why?
> 
> Thank you for your former response and for taking part in this discussion.
> 
> Peter Basista