Interlaced videos; best practice?

C++
1

I wonder how to handle interlaced videos in a right way.

  1. Treating an interlaced movie “raw” (as of progressive type)
    will lead to worse results than to deinterlace it first?

  2. If so the first step would be to identify the scan type.
    If I get it right there is no property of VideoCapture for it?

  3. If so I will have to either ask ffmpeg or derive it algorithmically
    with OpenCV? (Are there methods already?)

  4. If identified as interlaced the video should be deinterlaced
    before any futher processing.
    (I just found an external source for that:
    GitHub - bdvstg/cvDeinterlace: deinterlace library for opencv)

  5. All in all: if I read in an interlaced video with VideoCapture
    and instantly write it out with (any kind of) Videowriter
    it will be technically of progressive type but contents-wise
    still of interlaced type? (Which would be very bad I might think)
    This would mean, I would always have to check and eventually
    deinterlace.

Am I right with my assumptions?

2

don’t use opencv for this. use ffmpeg.

deinterlacing is a significant but required step.

I repeat: do NOT use opencv for any kind of video transcoding. use ffmpeg.

there is no “technically”. interlaced is interlaced. it may be represented in stupid ways but it’s still interlaced. packing two fields in one “progressive” frame is still interlaced, just hidden and easier to fuck up.

OpenCV is happily unaware of any interlacing. it just asks ffmpeg for progressive frames. ffmpeg doesn’t insert any filters to remove the interlacing either. it just packs two fields into one frame and hands it over.

if you have interlaced material, preprocess (deinterlace) it with ffmpeg into progressive material. then you have material that is progressive. then you can stop worrying about this accident of history, this war crime. interlaced is a plague. any devices that produce interlaced material should be ceremoniously destroyed and the debris sent to the designers.

2 Likes
4

That’s what I call a straight statement! :wink:

Thank you for the clearance.

Still…

Identifying the true scan type of a movie is accomplished by ffmpeg’s idet filter.
(You shall NOT rely on the meta data!).

If you now think at a workflow of having arbitrary videos
you don’t know the scan type of it would be quite impractical to
determine the scan type and in case interlaced: deinterlace and
encode the movie lossless to read the result into OpenCV.

I understand that OpenCV isn’t for video transcoding,
but in the sketched case it would be nice to have an idet in OpenCV
to do it “on the fly”/ framewise?