[MEncoder-users] interlaced/non-interlaced (was: mencoder: mp2->mp4 autoaspect question)

[Toerless Eckert]

Ok. Not sure what happened, but now it works also for me with the latest
SVN build of ffmpeg *sigh*. Will have to find some more time trying to
translate all remaining parameters from mencoder to ffmpeg. I seem to be
missing some encoding parameters in ffmpeg, but that would be strange because
i thought that mencoder was just relying on the ffmpeg libraries anyhow.

As far as yadif is concerned, i am still confused as to the benefit
of deinterlacing during encoding as opposed to when displaying the media.

So, i do have PAL TV media sent as 720i50 MPEG2. I don't think there
is any indication in the MPEG stream whether or not the content is actually
interlaced or not. As far as i know it's always indicated to just be
720i50 MPEG2. Factually 50% of the content is actually interlaced and 
the other 50% is non-interlaced: it was recorded with 720p25 cameras
and is just sent as 720i50 (aka: anything newer usually is recorded
progressive). So ultimately, i do not know what content type it is.

So, when i do have original 720p25 content i receive as 720i50 and i
use a deinterlacer like yadif then i should always loose resolution/sharpness
due to the interpolation happening in the deinterlacer. Right ?

For such content the best encoding would simply be to merge both fields
back and encode as progressive 720p25. I think this is what would happen
in ffmpeg if i would not specify progressive encoding, but not specify any
deinterlacer. Right ?

Now, when i do have original interlaced content, and i would not deinterlace
it during encoding, but just want to display the interlaced 720i50 content
on a progressive display (like LCD), then i would apply a deinterlacer
that converts the content into 720p50 so that i do not loose temporal
resolution. Eg: I would not want to deinterlace into 720p25 because then
sports would look more stuttering [ Of course, original 720p25 content
would have the same problem, but when it is actually generated with 720p25
camera settings, the camera man is aware of the problem and will control
the motion appropriately ].

But if i would do deinterlacing into 720p50 before re-encoding into mpeg4
then i would have just have doubled the number of bits to encode over
the origianl 720i50 input i had. Are you really claiming that if i re-encode
into eg: 1500 kbps mpeg4 (part 2 ;-), that i do get a better result
with the deinterlaced 720p50 input as opposed to the interlaced 720i50 
input (given the duplicate number of input bit's ) ???? 

My current conclusion is that i really do not need a deinterlacer for
the content, but i need a detection whether the input is real 720i50
content or interlaced sent 720p25 content. If it's original 720p25
content i would like  it to be encoded as 720p25 (after simple field merge),
and if it was original 720i50 content then i would prefer to encode it
as interlaced 720i50. Of course, something like a deinterlacer algorithm
would be required to decide whether or not the content was interlaced or
not. And because the TV recording will switch mid-stream between either
case, this decision would need to be made continuous resulting in a
media stream switching between 720i50 and 720p25 - and the encoder should
according encode interlaced and progressive.

If ffmpeg could do that, it would really be a mayor step forward for
my TV encoding ;-)) Short of that it still sounds most prudent to continue
encoding interlaced everything as 720i50.

Cheers
    Toerless


On Mon, Sep 27, 2010 at 10:46:58AM +0000, Carl Eugen Hoyos wrote:
> Toerless Eckert <Toerless.Eckert <at> Informatik.Uni-Erlangen.de> writes:
> 
> > P.S.:As far as de-interlacing is concerned: I just have not found the time
> > to figure out the best possible de-interlacer/parameters , so i am
> > delaying that decision to the decoder where i can change it over time.
> 
> I forgot to add that yadif should be the de-interlacer of your choice: mcdeint
> is significantly slower, and I am not convinced you can spot any difference.
> 
> Originally this meant you had to use mencoder, but since yesterday, FFmpeg also
> supports yadif;-)
> 
> Carl Eugen
> 
> _______________________________________________
> MEncoder-users mailing list
> MEncoder-users at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mencoder-users