Are you scaling before or after deinterlacing?  videoscale attempts to do interlaced-aware scaling (ffvideoscale does not) and could explain the differences in the outputs.

Nevertheless, videoscale's method for scaling interlaced video is questionable at best.  But it's still better than pretending that it's progressive.

(For the record, the best way currently in gstreamer to scale between interlaced formats is to deinterlace, then scale, then reinterlace.  Um, except for the part where you'd need to write an interlacing element.)

> Are you scaling before or after deinterlacing?

There is no interlace.  The input is 24F 1080p.  But.. given the
doubled-line nature of the broken output, I think you're probably
right.  Something thinks the stream is interlaced.

> videoscale attempts to do
> interlaced-aware scaling (ffvideoscale does not) and could explain the
> differences in the outputs.

Right. Is there a way to force the stream cap to progressive to test?

Monty

capssetter is usually recommended for forcing different caps.

If I hadn't been insanely lazy and made invtelecine only work with 720x480, I would recommend trying that out to recreate the progressive content.

Not sure what you mean... the content is progressive to start with.  It is never, at any point, actually interlaced.  Something must be marking or treating it as interlaced by accident.

Could you make the original video or a single image of it available?

Bilboed requested samples of the various modes the HV40 supports so he could look at how things are actually marked in the stream.

The camera allegedly supports:

HDV (30fps interlaced 1440x1080)
HDV PF30 (30fps progressive, recorded and streamed as interlaced 1440x1080)
HDV PF24 (24fps progressive, recorded and streamed as telecined/interlaced 30fps 1440x1080)
HDV 24F (24fps progressive, recorded and streamed as 24fps progressive)
DV Widescreen (30fps interlaced 720x480 with 1.2111:1 pixels)
DV (30fps interlaced with 10:11 pixels)

I have been recording in HDV 24F, and it appears this is being mishandled/marked as interlaced.

Test grabs for each mode at:

http://people.xiph.org/~xiphmont/hv40_for_ed/

The 24F clip in this case is encoded as 60i, with encoded pictures alternating between 2 and 3 fields in duration.  So setting 'interlaced=true' in the caps is technically correct, just happens to screw up videoscale because it's trying to be sohpisticated but fails.

Are you sure?  I'm definitely seeing that in the PF24 file, I'm not seeing that in the 24F file.  Canon's documentation states explicitly that the 24F mode is not recorded as telecined or interlaced.

Noticed a bug along the way, mpeg2dec was losing the tff/rff flags. That should now be fixed with the following commit:

commit 2c94b415d4390eca06c81a189fa225fdba8f43a6
Author: Edward Hervey <bilboed@bilboed.com>
Date:   Wed Apr 14 09:27:14 2010 +0200

    mpeg2dec: copy over all buffer flags when copying buffers.
    
    Avoids losing the tff/rff video buffer flags


videoscale still needs to be fixed to *grop* the flags properly.

Should we rename this bug to:
* videoscale's interlaced handling is non-optimal,
* or mpeg2dec should detect progressive content and mark it as such
* or have two bugs

?

Both perhaps?

Progressive content should not be being handled as interlaced.

Videoscale's interlaced handing looks bad, even on interlaced content.  Eg, downscale an interlaced input by a factor of two in both x and y with ffvideoscale, and the result still looks better than the videoscale output.

mpeg2dec detects progressive content already, it checks if the sequence header has the progressive flag.

What would be the solution for videoscale? Handling interlaced content the same way as progressive content again (resulting in mixing of lines of both fields and making deinterlacing impossible afterwards) or including some kind of deinterlacing and interlacing algorithm in videoscale?

(In reply to comment #12)
> mpeg2dec detects progressive content already, it checks if the sequence header
> has the progressive flag.

This is a flag for interlaced encoding, not progressive content.  These are two entirely separate concepts.  As an example, DVDs of films are almost always 24 fps progressive *content*, but are *encoded* interlaced at 50/60 fps.  GStreamer passes around the encoding flag, not the content flag.  Whether or not the content is interlaced or progressive can only be determined by heuristics.  Some of the heuristic inputs are in the MPEG-2 bitstream (RFF flag), some are guessed by analysing pictures.

The most effective and straightforward method of scaling interlaced content, e.g., from 480i to 1080i, would be to deinterlace, scale reconstructed full-size fields, then reinterlace.  Scaling progressive content that is interlaced-coded is similar: inverse telecine, scale frames, then telecine.  Of course, we don't have elements that do half of those operations, and the inverse telecine element needs some work to be useful.  One could combine these operations into a single element, but that seems like a step to be taken once the functionality exists.

commit 58c77eb1b4ba619f79a1123855cee2068295c09a
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Fri Jul 16 20:41:02 2010 +0200

    videoscale: Remove interlaced scaling again
    
    This behaviour was not preferred and caused visible image quality
    degradations. The real solution would be, to apply a real
    deinterlacing filter before scaling the frames.
    
    Fixes bug #615471.