[vlc-devel] [PATCH] Fix deinterlacing in transcode pipeline.

[Steinar H. Gunderson]

On Tue, Jun 11, 2013 at 08:38:13PM +0300, Rémi Denis-Courmont wrote:
>> 0002-In-transcoding-move-frame-output-into-its-own-functi.patch
> s/nad/and/

Done.

>> 0003-Make-the-video-transcoder-support-filter-chains-that.patch
> It would be a lot easier if there were a single chain. Oh well...

Yes, I haven't really understood why they are not. I've heard about static
vs. dynamic somehow, but I can't find anything that actually changes any of
them on-the-fly.

>> 0004-In-video-transcode-use-the-correct-format-for-calcul.patch
> Why does the frame rate get special treatment here? The comments insists on it 
> but fails to give a rationale.

I guess the question here is: Do we want this to be the filter output format
with width/height/chroma/SAR/etc. changed, or the encoder input format with
the frame rate changed? I would guess they are mostly equivalent, but there
are a lot of changes done in transcode_video_filter_init() that we'd need to
pick up.

>> 0005-Set-up-the-encoder-after-the-transcode-filter-chain.patch
> That seems logical. However traditionally, VLC has initialized the "output" of 
> the chain against the input format. Indeed, the same method is applied for 
> regular video and audio filter chains.
> 
> I don't mind when it comes to transcode. But I gave up "fixing" this for audio; 
> at the very least, it would have broken S/PDIF pass-through.

I'm not entirely sure what you are referring to here; by “output”, do you
mean the filter chain or the encoder? Generally I'm not sure what I'm doing
that would be in conflict with what you say.

As an aside, I'm a bit surprised at the amount of code duplication between
the transcode and vout chains; in retrospect it's less surprising that
yadif2x was broken in one but not the other.

>> 0006-Fix-deinterlacing-of-packed-YUV-formats.patch
> Well, it works but ideally it would not be hard-coded in transcode. The same 
> problem exists in the regular video output, but worse. I claim it is worse as 
> the video output chroma cannot be forced like the stream output chroma 
> (transcode{vcodec=I420}).

Well, ideally filter_chain_AppendFilter() would take care of this...

I guess I could make a utility function in deinterlace.c that did basically
AppendDeinterlaceFilter but used inside knowledge of the allowed formats
(the top part of Open()) to avoid resetting the chain all the time? I have no
idea how this works if the deinterlace module for some reason is not
available, though (I don't know the VLC module system very well).

/* Steinar */
-- 
Homepage: http://www.sesse.net/