[MEncoder-users] Trying to fully understand de-interlacing.

[Peter]

I'm the proud owner of a Sony HX5 digital camera, which is "OK" as a "nice"
camera, but has a movie mode which blows away the competition, at 1920x1080/60i
which I assume means that it produces fields of 1920x540, 60 times a second, and
that pairs of fields are packaged into frames at 30 frames per second. (I hope I
don't have my fields and frames mixed up.)

I see interlacing as a form of compression which was useful in the days of CRT
screens, whereby the processing in our eyes would make us think we were seeing
full resolution, full frame rate, even though only half the data rate was required.

I would like to make the best of this interlaced content, without discarding
either the 60 frames per second, or the 1920x1080 resolution. I want the
'impossible' holy grail of making a 1920x1080/60p file out of it. Of course, I
will then compress the file with H.264, but at that point, I will let H.264 do
its compression magic in a more appropriate and efficient way than the
interlacing did.

To let H.264 make the best file, I want it to start with the best data; so I
want to know how to make yadif create the best stream: neither discarding the
time data, nor the resolution data, but interpolating the missing data in time
and space in the same way that our eyes do when watching an old interlaced TV.

I realise that this is by no means an easy task. Stationary objects need to be
interpolated spatially, and moving objects need to be interpolated temporally.
Can yadif (mcdeint) do that?

I have been reading with interest, the thread "A good compromise for
deinterlacing camcorder-dv-files" and it looks like yadif pp=ci is the best
option. Is that right? will it produce a 1920x1080/60p stream?

Can anyone suggest a good command line? I have been trying to analyse Christian
Ebert's suggestion of
-vf yadif=1,mcdeint=2:1:10,softskip
against what I take to be the manual at:
http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.txt
and it looks like yadif produces 1920x540/60p, and then mcdeint does the
interpolation with mode=2 (slow) and parity=1 (is that telling it whether it's
tff or bff?) with qp set to 10. (Quality???)

That manual page has no mention of pp=ci ???

[Grozdan]

Post by Peter
I'm the proud owner of a Sony HX5 digital camera, which is "OK" as a "nice"
camera, but has a movie mode which blows away the competition, at
1920x1080/60i which I assume means that it produces fields of 1920x540, 60
times a second, and that pairs of fields are packaged into frames at 30
frames per second. (I hope I don't have my fields and frames mixed up.)
I see interlacing as a form of compression which was useful in the days of
CRT screens, whereby the processing in our eyes would make us think we were
seeing full resolution, full frame rate, even though only half the data rate
was required.

It's not a compression. Interlacing is a trick used to reduce
bandwidth in the old days as at that time, bandwidth was very limited.
So if you "split" the image in two (odd and even) and first send the
odd (or even) filed then the even (or odd) field, it will use less
bandwidth compared to sending the whole image at once

Post by Peter
I would like to make the best of this interlaced content, without discarding
either the 60 frames per second, or the 1920x1080 resolution. I want the
'impossible' holy grail of making a 1920x1080/60p file out of it. Of course,
I will then compress the file with H.264, but at that point, I will let
H.264 do its compression magic in a more appropriate and efficient way than
the interlacing did.
To let H.264 make the best file, I want it to start with the best data; so I
want to know how to make yadif create the best stream: neither discarding
the time data, nor the resolution data, but interpolating the missing data
in time and space in the same way that our eyes do when watching an old
interlaced TV.
I realise that this is by no means an easy task. Stationary objects need to
be interpolated spatially, and moving objects need to be interpolated
temporally. Can yadif (mcdeint) do that?
I have been reading with interest, the thread "A good compromise for
deinterlacing camcorder-dv-files" and it looks like yadif pp=ci is the best
option. Is that right? will it produce a 1920x1080/60p stream?

No, pp=ci will just deinterlace at normal frame rate so you'll get a
progressive image running at 29.970fps

if you want to create 60p (with an fps of 59.940) you have to use a
bobber like yadif=1 (and at your option combine it with mcdeint)

Post by Peter
Can anyone suggest a good command line? I have been trying to analyse
Christian Ebert's suggestion of
-vf yadif=1,mcdeint=2:1:10,softskip
http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.txt
and it looks like yadif produces 1920x540/60p, and then mcdeint does the
interpolation with mode=2 (slow) and parity=1 (is that telling it whether
it's tff or bff?) with qp set to 10. (Quality???)

parity=0 is tff while 1 is bff

qp is for motion vector fields and how "smooth" they are at expense of
individual vectors. Most people use a value of 10

Whether you'll see a (big?) difference between using yadif only and
yadif combined with mcdeint is up for discussion and depends on person
and content. A lot of people don't bother with mcdeint, either because
it's too slow or they can't see the difference between yadif only and
yadif + mcdeint

Post by Peter
That manual page has no mention of pp=ci ???

mplayer -pphelp

Post by Peter
--
Peter
____________________________________________________________
Publish your photos in seconds for FREE
TRY IM TOOLPACK at http://www.imtoolpack.com/default.aspx?rc=if4
_______________________________________________
MEncoder-users mailing list
https://lists.mplayerhq.hu/mailman/listinfo/mencoder-users

[Christian Ebert]

* Grozdan on Monday, June 28, 2010 at 08:26:58 +0200

Post by Grozdan
Whether you'll see a (big?) difference between using yadif only and
yadif combined with mcdeint is up for discussion and depends on person
and content. A lot of people don't bother with mcdeint, either because
it's too slow or they can't see the difference between yadif only and
yadif + mcdeint

A practical use for mcdeint -- where I do see a difference -- is
when the result is intended to be shown with a LCD projector.
Otherwise yadif=0 should be enough in almost all cases. But in
the end your eyes have to be the judge.

c

[Peter]

Post by Grozdan
It's not a compression. Interlacing is a trick used to reduce
bandwidth in the old days as at that time, bandwidth was very limited.
So if you "split" the image in two (odd and even) and first send the
odd (or even) filed then the even (or odd) field, it will use less
bandwidth compared to sending the whole image at once

You're taking me too literally! When I said "a form of" I meant that it achieved
the same results: halving the bandwidth, while delivering data that had a
perceived quality which is better than half. (Trust me, I know very well how it
works, LOL!)

Post by Grozdan
No, pp=ci will just deinterlace at normal frame rate so you'll get a
progressive image running at 29.970fps

Oh, that's no good then.

Post by Grozdan
if you want to create 60p (with an fps of 59.940) you have to use a
bobber like yadif=1 (and at your option combine it with mcdeint)

Right, thanks.

Post by Grozdan
parity=0 is tff while 1 is bff
qp is for motion vector fields and how "smooth" they are at expense of
individual vectors. Most people use a value of 10
Whether you'll see a (big?) difference between using yadif only and
yadif combined with mcdeint is up for discussion and depends on person
and content. A lot of people don't bother with mcdeint, either because
it's too slow or they can't see the difference between yadif only and
yadif + mcdeint

I think I want to use mcdeint. I will try various yadif/mcdeint suggestions from
this list and google searches, to see what seems best.

[Goga777]

Post by Peter

Post by Grozdan
Whether you'll see a (big?) difference between using yadif only and
yadif combined with mcdeint is up for discussion and depends on person
and content. A lot of people don't bother with mcdeint, either because
it's too slow or they can't see the difference between yadif only and
yadif + mcdeint

I think I want to use mcdeint. I will try various yadif/mcdeint suggestions from
this list and google searches, to see what seems best.

and after finishing of your tests send please here your results

will you use the pass or crf method ?

thanks

Goga

[Peter]

Post by Goga777

Post by Peter
I think I want to use mcdeint. I will try various yadif/mcdeint suggestions from
this list and google searches, to see what seems best.

and after finishing of your tests send please here your results

Yes, sure.

I made a test video which I thought would be hard for deinterlacing, and would
expose any problems. It's very short; it is a video of a hexbug
<http://www.hexbug.com/original> walking across a piece of paper with printing
on it. I was surprised that the test I did without mcdeint was better, and was
also much faster. It was not the result I expected.

I think two things have happened here. The test I made allowed the mcdeint
algorithm to become confused; one line moved over looked like a different
line... so some of the letters have ghosts in them.

But also, even though I think the images are really very good from my camera,
realistically, the focus is not so perfect that the interlaced data is
important, so we can't really tell if it's thrown away.

I will try to attach a torrent which will allow people to fetch the files if
they wish. This is what I have:

(the original MTS transport stream file as recorded by the HX5 camera)
F. yadif=1:0
G. yadif=3:0,mcdeint=2:1:10
H. yadif=3:0,mcdeint=3:1:10

I also experimented with discarding data to make a much smaller file, I think
the results are very good, although this was not my intention. I include it out
of interest. I threw away the interlacing, half the resolution and half the
field rate.

I. bitrate=1600
K. bitrate=800

index.txt includes the exact commands I used. The files will probably only be
available from 2010-07-01 to 2010-07-07, and only while my computer is switched
on, LOL!

Oh, one last thing; my computer, even though it's a quad-core fast-ish thing,
was unable to play the files F, G, and H! The only way I could do it, was to use
mplayer, and tell it to play in slow motion, e.g.

mplayer -speed .5 f.avi

and I have to imagine what it will be like when computers get faster.

[Goga777]

Post by Peter
<http://www.hexbug.com/original> walking across a piece of paper with printing
on it. I was surprised that the test I did without mcdeint was better, and was
also much faster. It was not the result I expected.

good to know this fact :)

Post by Peter
(the original MTS transport stream file as recorded by the HX5 camera)

with which resolution ?

Post by Peter
F. yadif=1:0
G. yadif=3:0,mcdeint=2:1:10
H. yadif=3:0,mcdeint=3:1:10

why do you use zero (yadif=x:0) ? According man this option was deprecated

==============================================================================
yadif=[mode[:field_dominance]]
Yet another deinterlacing filter
<mode>
0: Output 1 frame for each frame.
1: Output 1 frame for each field.
2: Like 0 but skips spatial interlacing check.
3: Like 1 but skips spatial interlacing check.
<field_dominance> (DEPRECATED)
Operates like tfields.
NOTE: This option will possibly be removed in a future
version. Use -field-dominance instead.
================================================================================


did you try yadif=1 and yadif=3 ? yadif=0 and yadif=2 ?


Goga

[Peter]

Post by Goga777

Post by Peter
(the original MTS transport stream file as recorded by the HX5 camera)

with which resolution ?

The highest - 1920x1080/60i

Post by Goga777

Post by Peter
F. yadif=1:0
G. yadif=3:0,mcdeint=2:1:10
H. yadif=3:0,mcdeint=3:1:10

why do you use zero (yadif=x:0) ? According man this option was deprecated

I didn't see that 'deprecated'. I copied suggested command lines from google
searches: however, I most commonly saw yadif=3:1,... but I quickly found that my
fields were reversed, I know that jiggle very well now! I checked the man page,
and switched to yadif=3:0,... and the jiggle was fixed.

Post by Goga777
did you try yadif=1 and yadif=3 ? yadif=0 and yadif=2 ?

Well I tried 1 and 3 for the high resolution. I did briefly try 0 for the lower
resolution test, but then I figured that it was putting out data that I was then
going to discard later with the 'scale' filter. I reasoned that using the
'tfields=0' filter was more sensible because it was not creating the data in the
first place, so it should be faster.

I chose the tests that I thought had a chance of being efficient... but if you
think it's interesting, I could do a full matrix of tests, even the insane ones!

Only one person downloaded the files so far, I'd be interested to know if this
person thought it was a good test for deinterlacing, because I 'designed' it to
be that.

[Andy Furniss]

Post by Peter
Only one person downloaded the files so far, I'd be interested to know
if this person thought it was a good test for deinterlacing, because I
'designed' it to be that.

It seems OK, but then I don't know what I am talking about :-)

One suggestion from my experiments ripping PAL SD camcorder tapes
(though I was actually keeping interlacing) is -

Have two saturated colours side by side on a horizontally moving object,
that way you can tell if the 4:2:0 colour space is being correctly
treated as interlaced, if for example you had other filters before the
de-interlace.

As I said, when I did it I wanted to keep the interlacing so I examined
weaved frames (You can't use xv for this as it only does progressive,
use -vo x11).

IIRC yadif will assume interlaced chroma - but I found when testing
4:2:2 (though pointless for PAL) that it only accepted 4:2:0, in which
cads it became important to specify -vf scale=-1:-1:1 (for the s/w
4:2:2 to 4:2:0) to avoid sharp vertical edges between saturated colours
being blurred after deinterlacing.

I admit that's a bit of an artificial case, but when working with
interlaced material, it's always worth remembering to "tell"
filters/codecs as 4:2:0 colour needs to be handles per field rather than
per frame.

[James Hastings-Trew]

Post by Andy Furniss

Post by Peter
Only one person downloaded the files so far, I'd be interested to know
if this person thought it was a good test for deinterlacing, because I
'designed' it to be that.

It seems OK, but then I don't know what I am talking about :-)
One suggestion from my experiments ripping PAL SD camcorder tapes
(though I was actually keeping interlacing) is -
Have two saturated colours side by side on a horizontally moving
object, that way you can tell if the 4:2:0 colour space is being
correctly treated as interlaced, if for example you had other filters
before the de-interlace.

Generally speaking, deinterlacing should always be the first filter in
the chain.

[Carl Eugen Hoyos]

Post by Andy Furniss
IIRC yadif will assume interlaced chroma - but I found when testing
4:2:2 (though pointless for PAL) that it only accepted 4:2:0, in which
cads it became important to specify -vf scale=-1:-1:1 (for the s/w
4:2:2 to 4:2:0) to avoid sharp vertical edges between saturated colours
being blurred after deinterlacing.

It doesn't matter in this case since if the camera would record something else
than 4:2:0, it could not be decoded;-)

Carl Eugen

[James Hastings-Trew]

Post by Peter

Post by Goga777

Post by Peter
I think I want to use mcdeint. I will try various yadif/mcdeint suggestions from
this list and google searches, to see what seems best.

and after finishing of your tests send please here your results

Yes, sure.
I made a test video which I thought would be hard for deinterlacing,
and would expose any problems. It's very short; it is a video of a
hexbug <http://www.hexbug.com/original> walking across a piece of
paper with printing on it. I was surprised that the test I did without
mcdeint was better, and was also much faster. It was not the result I
expected.
I think two things have happened here. The test I made allowed the
mcdeint algorithm to become confused; one line moved over looked like
a different line... so some of the letters have ghosts in them.
But also, even though I think the images are really very good from my
camera, realistically, the focus is not so perfect that the interlaced
data is important, so we can't really tell if it's thrown away.
I will try to attach a torrent which will allow people to fetch the
(the original MTS transport stream file as recorded by the HX5 camera)
F. yadif=1:0
G. yadif=3:0,mcdeint=2:1:10
H. yadif=3:0,mcdeint=3:1:10
I also experimented with discarding data to make a much smaller file,
I think the results are very good, although this was not my intention.
I include it out of interest. I threw away the interlacing, half the
resolution and half the field rate.
I. bitrate=1600
K. bitrate=800
index.txt includes the exact commands I used. The files will probably
only be available from 2010-07-01 to 2010-07-07, and only while my
computer is switched on, LOL!
Oh, one last thing; my computer, even though it's a quad-core fast-ish
thing, was unable to play the files F, G, and H! The only way I could
do it, was to use mplayer, and tell it to play in slow motion, e.g.
mplayer -speed .5 f.avi
and I have to imagine what it will be like when computers get faster.

Seems to be a problem with your source file, but the FPS is being
reported wrong by mplayer and mencoder. VLC shows (and displays the
file) at it's correct frame rate. In your command line you have "-fps
30000/1001" but the frame rate is actually 60000/1001.

[Peter]

Post by James Hastings-Trew
Seems to be a problem with your source file, but the FPS is being
reported wrong by mplayer and mencoder. VLC shows (and displays the
file) at it's correct frame rate. In your command line you have "-fps
30000/1001" but the frame rate is actually 60000/1001.

Yes, I seem to remember seeing a warning about the file being 'wrong'. It's
unfortunate that Field and Frame start with the same letter, because it opens
the possibility for confusion over what "FPS" stands for in interlaced content.
Frankly, it wouldn't surprise me at all if the good folks at Sony got it wrong,
because all they really care about is that it works properly with their own
Picture Motion Browser software.

It's my understanding that the stream should be 30000/1001 frames per second,
and 60000/1001 fields per second. You have the file exactly as it came out of
the camera.

Thank you for your interest, by the way.

[James Hastings-Trew]

Post by Peter

Post by James Hastings-Trew
Seems to be a problem with your source file, but the FPS is being
reported wrong by mplayer and mencoder. VLC shows (and displays the
file) at it's correct frame rate. In your command line you have "-fps
30000/1001" but the frame rate is actually 60000/1001.

Yes, I seem to remember seeing a warning about the file being 'wrong'.
It's unfortunate that Field and Frame start with the same letter,
because it opens the possibility for confusion over what "FPS" stands
for in interlaced content. Frankly, it wouldn't surprise me at all if
the good folks at Sony got it wrong, because all they really care
about is that it works properly with their own Picture Motion Browser
software.
It's my understanding that the stream should be 30000/1001 frames per
second, and 60000/1001 fields per second. You have the file exactly as
it came out of the camera.
Thank you for your interest, by the way.

Hmm. VLC reports the framerate at 59.94006 and when it plays back the
file, both the video and audio end at the same moment. When I play it
back in VLC, I get a 5 second clip.

mplayer reports the framerate as 29.970030. When I play it back with
mplayer, the sound stops at 5 seconds, and the video stops at 10 seconds.

using mplayer 20100629113956.m2ts -fps 60000/1001 has no effect
whatsoever - the frame rate is still reported incorrectly, and the video
playback is identical. That's not right, is it?

Ahhh. mplayer 20100629113956.m2ts -fps 60000/1001 -demuxer lavf makes it
play back correctly.

Alright. Anyway....

this produced good results (deinterlacing-wise) for me:

mencoder -o deint1.avi -oac pcm -ovc lavc -lavcopts vcodec=ffvhuff
20100629113956.m2ts -demuxer lavf -vf yadif

[Andy Furniss]

Post by James Hastings-Trew
Seems to be a problem with your source file, but the FPS is being
reported wrong by mplayer and mencoder. VLC shows (and displays the
file) at it's correct frame rate. In your command line you have "-fps
30000/1001" but the frame rate is actually 60000/1001.

For me using todays mplayer with no options shows

FPS seems to be: 29.970030 and if I framestep I need to press "." twice
for each frame.

mplayer -demuxer lavf shows

VIDEO: [H264] 1920x1080 0bpp 59.940 fps 0.0 kbps ( 0.0 kbyte/s)

and framestep works normally.

I can't tell whether it would try and play double speed as my old PC
can't even play this at 30fps.

mediainfo shows 29.970 fps

[Grozdan]

Post by Peter

Post by Grozdan
It's not a compression. Interlacing is a trick used to reduce
bandwidth in the old days as at that time, bandwidth was very limited.
So if you "split" the image in two (odd and even) and first send the
odd (or even) filed then the even (or odd) field, it will use less
bandwidth compared to sending the whole image at once

You're taking me too literally! When I said "a form of" I meant that it achieved
the same results: halving the bandwidth, while delivering data that had a
perceived quality which is better than half. (Trust me, I know very well how it
works, LOL!)

Yes, but there's still a distinction between the two, even though they
try to achieve a similar result (reducing bandwidth) but from a
different angle. Compression throws away data, interlacing doesn't, it
splits the image in odd and even lines, and shows the odd or even
field first ;)

Post by Peter

Post by Grozdan
No, pp=ci will just deinterlace at normal frame rate so you'll get a
progressive image running at 29.970fps

Oh, that's no good then.

Post by Grozdan
if you want to create 60p (with an fps of 59.940) you have to use a
bobber like yadif=1 (and at your option combine it with mcdeint)

Right, thanks.

Post by Grozdan
parity=0 is tff while 1 is bff
qp is for motion vector fields and how "smooth" they are at expense of
individual vectors. Most people use a value of 10
Whether you'll see a (big?) difference between using yadif only and
yadif combined with mcdeint is up for discussion and depends on person
and content. A lot of people don't bother with mcdeint, either because
it's too slow or they can't see the difference between yadif only and
yadif + mcdeint

I think I want to use mcdeint. I will try various yadif/mcdeint suggestions from
this list and google searches, to see what seems best.

Well, you make sure you have a powerful machine, then ;)

You're doing 1080i content, using x264 (which can be pretty slow) and
yadif+mcdeint (which is slow almost always). That'll slow things a lot

Post by Peter
--
Peter
____________________________________________________________
Send your photos by email in seconds...
TRY FREE IM TOOLPACK at http://www.imtoolpack.com/default.aspx?rc=if3
Works in all emails, instant messengers, blogs, forums and social networks.
_______________________________________________
MEncoder-users mailing list
https://lists.mplayerhq.hu/mailman/listinfo/mencoder-users

[Christian Ebert]

* Peter on Tuesday, June 29, 2010 at 00:48:13 -0400

Post by Peter
I think I want to use mcdeint. I will try various yadif/mcdeint suggestions from
this list and google searches, to see what seems best.

This page is quite informative:

http://guru.multimedia.cx/deinterlacing-filters/

(just ignore the stuff about the 2nd parameter to yadif, it's
wrong and by now -field-dominance should be used)

c

[Andrew Berg]

Post by Peter
I would like to make the best of this interlaced content, without discarding
either the 60 frames per second, or the 1920x1080 resolution. I want the
'impossible' holy grail of making a 1920x1080/60p file out of it. Of course, I
will then compress the file with H.264, but at that point, I will let H.264 do
its compression magic in a more appropriate and efficient way than the
interlacing did.

You will waste many bits if you go from 60 fields per second to 60
frames per second before encoding. You would be compressing generated
bits, since it's essentially upscaling. yadif is a very good (but slow)
deinterlacer and you will get good results with it going from 60 fields
to 30 frames per second. If you want really want to avoid going to 30
frames per second, you're better off compressing interlaced and using
yadif during playback. x264 is not optimized for handling interlaced
content, but it's still more efficient than doing 60p.

[Goga777]

Post by Andrew Berg

Post by Peter
I would like to make the best of this interlaced content, without discarding
either the 60 frames per second, or the 1920x1080 resolution. I want the
'impossible' holy grail of making a 1920x1080/60p file out of it. Of course, I
will then compress the file with H.264, but at that point, I will let H.264 do
its compression magic in a more appropriate and efficient way than the
interlacing did.

You will waste many bits if you go from 60 fields per second to 60
frames per second before encoding.

does this idea right and for PAL video ? 50 fields per second to 50 frames per second ?

Goga

[Grozdan]

Post by Goga777

Post by Andrew Berg

Post by Peter
I would like to make the best of this interlaced content, without discarding
either the 60 frames per second, or the 1920x1080 resolution. I want the
'impossible' holy grail of making a 1920x1080/60p file out of it. Of course, I
will then compress the file with H.264, but at that point, I will let H.264 do
its compression magic in a more appropriate and efficient way than the
interlacing did.

You will waste many bits if you go from 60 fields per second to 60
frames per second before encoding.

does this idea right and for PAL video ? 50 fields per second to 50 frames per second ?

Yes ....

Post by Goga777
Goga
_______________________________________________
MEncoder-users mailing list
https://lists.mplayerhq.hu/mailman/listinfo/mencoder-users

[Alexander Strange]

Post by Andrew Berg

Post by Peter
I would like to make the best of this interlaced content, without discarding
either the 60 frames per second, or the 1920x1080 resolution. I want the
'impossible' holy grail of making a 1920x1080/60p file out of it. Of course, I
will then compress the file with H.264, but at that point, I will let H.264 do
its compression magic in a more appropriate and efficient way than the
interlacing did.

You will waste many bits if you go from 60 fields per second to 60
frames per second before encoding. You would be compressing generated
bits, since it's essentially upscaling. yadif is a very good (but slow)
deinterlacer and you will get good results with it going from 60 fields
to 30 frames per second.

Yadif is not a particularly slow deinterlacer; like most of the
mplayer filters, it runs in realtime and there are (somewhat) better
ones which run (much) more slowly.
TempGaussMC is one:
http://avisynth.org/mediawiki/TempGaussMC

[Grozdan]

On Mon, Jun 28, 2010 at 8:08 PM, Alexander Strange

Post by Alexander Strange

Post by Andrew Berg

Post by Peter
I would like to make the best of this interlaced content, without discarding
either the 60 frames per second, or the 1920x1080 resolution. I want the
'impossible' holy grail of making a 1920x1080/60p file out of it. Of course, I
will then compress the file with H.264, but at that point, I will let H.264 do
its compression magic in a more appropriate and efficient way than the
interlacing did.

You will waste many bits if you go from 60 fields per second to 60
frames per second before encoding. You would be compressing generated
bits, since it's essentially upscaling. yadif is a very good (but slow)
deinterlacer and you will get good results with it going from 60 fields
to 30 frames per second.

Yadif is not a particularly slow deinterlacer; like most of the
mplayer filters, it runs in realtime and there are (somewhat) better
ones which run (much) more slowly.

Well, somewhat correct. IIRC there's an optimized version of yadif
(both quality and speed) floating around on doom9, which is faster
than the one in mplayer. If I'm not mistaken and from what I recall,
it was proposed to merge the patch in mplayer but it was rejected for
some reason

Post by Alexander Strange
http://avisynth.org/mediawiki/TempGaussMC
_______________________________________________
MEncoder-users mailing list
https://lists.mplayerhq.hu/mailman/listinfo/mencoder-users

[Carl Eugen Hoyos]

Post by Grozdan
Well, somewhat correct. IIRC there's an optimized version of yadif
(both quality and speed) floating around on doom9, which is faster
than the one in mplayer. If I'm not mistaken and from what I recall,
it was proposed to merge the patch in mplayer but it was rejected for
some reason

Could you point me to that version?

Carl Eugen

[Grozdan]

Post by Carl Eugen Hoyos

Post by Grozdan
Well, somewhat correct. IIRC there's an optimized version of yadif
(both quality and speed) floating around on doom9, which is faster
than the one in mplayer. If I'm not mistaken and from what I recall,
it was proposed to merge the patch in mplayer but it was rejected for
some reason

Could you point me to that version?

I think it is this thread (but am not sure)
http://forum.doom9.org/showthread.php?t=124284

It's the yadif port thread for avisynth where some peeps posted some
optimizations. I'm not sure if mplayer's yadif has SSE3 code, but the
one in avisynth has it. I'm also not sure how beneficial SSE3 is.
That's its changelog so you can go over and see what they
changed/added so far.

http://avisynth.org.ru/yadif/yadif.html

Post by Carl Eugen Hoyos
Carl Eugen
_______________________________________________
MEncoder-users mailing list
https://lists.mplayerhq.hu/mailman/listinfo/mencoder-users

[Carl Eugen Hoyos]

Post by Grozdan
It's the yadif port thread for avisynth where some peeps posted some
optimizations. I'm not sure if mplayer's yadif has SSE3 code, but the
one in avisynth has it. I'm also not sure how beneficial SSE3 is.
That's its changelog so you can go over and see what they
changed/added so far.
http://avisynth.org.ru/yadif/yadif.html

Thank you for the link!
I will forward it to ffmpeg-devel where a port is currently discussed.

Carl Eugen

[Peter]

Post by Andrew Berg
You will waste many bits if you go from 60 fields per second to 60
frames per second before encoding. You would be compressing generated
bits, since it's essentially upscaling.

It may sound weird, but in my heart I feel it should be 'better' because the
upscaling is the inverse of the interlacing "compression" (sorry Grozdan, I
don't mean it literally) which is like a CBR compression... the same everywhere
in the frame. Compare with REAL compression, which saves bits by different
amounts in different parts of the frame (like VBR adjusts over time) and so can
be more efficient by using the bits in the places where it's needed, and saving
them where there's nothing much happening.

Upscaling and then compressing afterward is indeed my objective.

Post by Andrew Berg
yadif is a very good (but slow)
deinterlacer and you will get good results with it going from 60 fields
to 30 frames per second.

I find that hard to believe; if it were true, there would be no point in
Interlacing. (And films would look nice instead of crap at 24fps.)

Post by Andrew Berg
If you want really want to avoid going to 30
frames per second, you're better off compressing interlaced and using
yadif during playback. x264 is not optimized for handling interlaced
content, but it's still more efficient than doing 60p.

Well, my source is already compressed interlaced... perhaps I should just learn
to live with that.

Thanks, guys.

[Christian Ebert]

* Peter on Tuesday, June 29, 2010 at 00:47:44 -0400

Post by Peter

Post by Andrew Berg
yadif is a very good (but slow)
deinterlacer and you will get good results with it going from 60 fields
to 30 frames per second.

I find that hard to believe; if it were true, there would be no
point in Interlacing. (And films would look nice instead of crap at
24fps.)

Ah, but 24fps is/was meant for non-digital material. I'm way old
fashioned and still prefer a good projection in a cinema to any
digital display (probably like vinyl vs. CD). Of course the
digital image is objectively sharper, but subjectively: to watch
"Gone With The Wind" digitally (and possibly on LCD) is crap ;-)
After all the human eye is (not yet) digital.

c

[Andy Furniss]

Post by Christian Ebert
* Peter on Tuesday, June 29, 2010 at 00:47:44 -0400

Post by Peter

Post by Andrew Berg
yadif is a very good (but slow)
deinterlacer and you will get good results with it going from 60 fields
to 30 frames per second.

I find that hard to believe; if it were true, there would be no
point in Interlacing. (And films would look nice instead of crap at
24fps.)

Ah, but 24fps is/was meant for non-digital material. I'm way old
fashioned and still prefer a good projection in a cinema to any
digital display (probably like vinyl vs. CD). Of course the
digital image is objectively sharper, but subjectively: to watch
"Gone With The Wind" digitally (and possibly on LCD) is crap ;-)
After all the human eye is (not yet) digital.

I can't argue about cinema vs LCD, but I also can't see what 24fps has
to do with it.

24fps was chosen when "talkies" came in, as a standard was needed that
the projectors/cameras of the time could do.

Film makers have to go out of their way to live with 24fps motion
judder, by just not even attempting some shots eg. no fast pans as they
would look terrible. There are probably many other tricks/no go shots
they have to do. One I've read of is de-focusing the background when
doing tracking shots as it keeps the viewers attention on the subject
rather that the motion judder going on behind it.

[Andrew Berg]

Post by Peter

Post by Andrew Berg
yadif is a very good (but slow)
deinterlacer and you will get good results with it going from 60 fields
to 30 frames per second.

I find that hard to believe; if it were true, there would be no point in
Interlacing.

There is defintiely reason to interlace in certain situations
(especially for TV broadcasting), and the fact that there are wonderful
deinterlacers out there are irrelevant in such situations. If 1080p30
were practical in broadcasting, it would be used instead of 1080i60.

[Carl Eugen Hoyos]

Post by Andrew Berg

Post by Peter
I find that hard to believe; if it were true, there would be no point in
Interlacing.

There is no point unless...

Post by Andrew Berg
There is defintiely reason to interlace in certain situations

you are using a CRT which has the exact framerate of your material and you want
to "double" the horizontal resolution.

Seriously: It was a catastrophe from the beginning: Since I use de-interlacers,
I see the interlacing in my old CRT-TV, I wish they would stop using it for new
material.

Carl Eugen

[Reimar Döffinger]

Post by Carl Eugen Hoyos
Seriously: It was a catastrophe from the beginning: Since I use de-interlacers,
I see the interlacing in my old CRT-TV, I wish they would stop using it for new
material.

I was wondering if anyone else had the problem of constantly seeing the
interlacing artefacts on normal old TV sets.
It's really annoying.
I guess if you have a smaller TV and keep far away it's not that noticeable
but still, it definitely was always visible...

[Andrew Berg]

Post by Carl Eugen Hoyos

Post by Andrew Berg
There is defintiely reason to interlace in certain situations

you are using a CRT which has the exact framerate of your material and you want
to "double" the horizontal resolution.

For regular end-users like you and I, there is rarely reason to have
interlaced material, but for broadcasting, the standard is to have
either 60 frames per second or 60 fields per second (50 for PAL).
1080p60 uses too much bandwidth, so 1080i60 is used. 24p content can be
telecined the same way it always has. I do not know exactly why, but one
cannot broadcast 1080p30 (or 1080p25), therefore all material intended
for broadcast is either recorded interlaced or telecined. 1080p60 or
even 1080p30 would be excellent for sports, but neither can be used for
broadcast, so they record at 1080i60. It is sad that interlacing is
still used with digital TV, but there is nothing we can do about it
except use a good deinterlacer (or use IVTC as appropriate) in order to
get progressive video.

[Carl Eugen Hoyos]

Post by Andrew Berg
For regular end-users like you and I, there is rarely reason to have
interlaced material,

rarely? Or never?

Post by Andrew Berg
but for broadcasting, the standard is to have
either 60 frames per second or 60 fields per second (50 for PAL).
1080p60 uses too much bandwidth, so 1080i60 is used.

I know, I don't doubt that, I am trying to explain that it is a _very_ bad idea
(if you don't have a HDTV CRT with 60fps - afaik, this can't be bought)

Post by Andrew Berg
24p content can be telecined the same way it always has.

Living in PAL country (and seeing different other bad things, like slowing a
movie - randomly doubling frames - to get more ad-breaks), I fortunately do not
suffer from telecine.

Post by Andrew Berg
I do not know exactly why, but one cannot broadcast 1080p30 (or 1080p25),

That's wrong: 24 (and 25) fps material is sent (in PAL country) in something
they call 1080i50, but it cannot be visually distinguished from 1080p25, which
makes it 1080p25 "for regular end-users like you and I".

My point was something else:
Movies and (modern) television series are no problem (as explained before) - at
least as long as we are talking about PAL, they are sent as 25 fps progressive
material (no matter how they call it), But live material recorded in 50 fields
is sent in something that the "display" (software, GPU or TV) has to process to
make it endurable for human eyes.
That's why I believe the original EBU decision to prefer 720p50 over 1080i50 was
correct for self-produced material and would especially make a huge (positive)
difference for sports if it would be recorded that way (which it isn't
supposedly because of the other broadcasters).

Does somebody know why it is not possible for the broadcaster to change between
720p50 and 1080"i"50 depending on the current program? Are those "certified"
receivers so bad that they can't decode it correctly?

Carl Eugen