View Full Version : HD 1080i to DVD (all interlaced) - how?
smok3
23rd July 2008, 18:33
Right, but the whole reason interlacing was standardized in the first place was its ability to maintain motion fluidity while reducing bandwidth requirements.
it was actually about the flicker, basically there are two min frequencies;
a. freq1 - enough for motion
b. freq2 - enough to eliminate the flicker
c. freq2 > freq1
more motion was a bonus basically.
Blue_MiSfit
23rd July 2008, 23:54
Fair enough :)
~MiSfit
florinandrei
15th August 2008, 09:27
I guess I will have to compare shift/interleave with blur with x either 0.75 or 1.0.
I did the comparison.
Short story:
The best looking on the native 480i screen is SeparateFields/Shift/Resize/Interleave.
Long Story:
With the screen in 16:9 mode (the scan lines are squashed vertically, so the active screen area becomes 16:9) and the DVD player told to output to a 16:9-capable TV, the connection from DVD to TV is a component cable, there's no doubt, shift/interleave looks great. There is ZERO aliasing. There's no perceivable blur from the normal viewing distance. I can't find any issues. Oh, and it's pretty fast.
Yadif + Blur 0.75 still has a little bit of aliasing.
Yadif + Blur 1.00 is virtually identical to shift/interleave. I thought there might be some aliasing, but it could be my imagination.
With the screen and the DVD player in 4:3 mode, all 3 movies look the same: there's a little amount of aliasing and the vertical resolution is not that great.
So, if nobody comes up with a better idea, this is what I'm going to use to convert 1080i to 480i:
Global NewHeight=480
Global NewWidth=720
DirectShowSource("hd.m2ts", audio=false)
AssumeTFF()
SeparateFields()
Shift=(Height()/Float(NewHeight/2)-1.0)*0.25
Tf=SelectEven().Spline36Resize(NewWidth, NewHeight/2, 0, -Shift, Width(), Height())
Bf=SelectOdd().Spline36Resize(NewWidth, NewHeight/2, 0, Shift, Width(), Height())
Interleave(Tf, Bf)
Weave()
In my tests, I used Lanczos instead of Spline36, but I assume spline will look slightly better (supposedly less ringing). I will test it, of course.
Many thanks to everyone. I learned a lot from all of you. :thanks:
2Bdecided
15th August 2008, 10:02
It's funny, I was just thinking about this thread when watching the Olympics yesterday. Many (all?) of the feeds are HD, and I'm watching the BBC's SD coverage. At least some of it must be downconverted from HD.
It's very sharp, with lots of aliasing - too much, really. However, it suggests that whoever designed the downconverter had basically the opposite subjective opinion of you florinandrei, or else simply did the job badly.
Cheers,
David.
florinandrei
15th August 2008, 18:03
It's funny, I was just thinking about this thread when watching the Olympics yesterday. Many (all?) of the feeds are HD, and I'm watching the BBC's SD coverage. At least some of it must be downconverted from HD.
It's very sharp, with lots of aliasing - too much, really. However, it suggests that whoever designed the downconverter had basically the opposite subjective opinion of you florinandrei, or else simply did the job badly.
Or maybe they did the best out of a really nasty job. It was real time, wasn't it? It's difficult.
By the way, the sharp, aliased methods don't look that sharp on the native SD (480i) screen. The difference in sharpness between Yadif (without Blur) and shift/interleave is minimal, vanishing really. But the difference in aliasing is big and noticeable. I do like sharpness (e.g. I actually think my Canon HF100 HD camera is too "soft" :rolleyes:), but not at the expense of big nasty visible aliasing.
If you try to "fix" Yadif with Blur, then it looks very similar to shift/interleave, except it's slower.
On an HD screen (or computer monitor) it's a different story, but then again, the SD movie is for SD displays.
All my SD tests were done with a pretty good Sony Wega CRT screen. It was all the rage and pretty expensive in 2001. So I think what I did is relevant for most SD users.
halsboss
15th August 2008, 23:17
There seems to be a related thread which talks about deinterlacing as a part of resizing... http://forum.doom9.org/showthread.php?t=140218
florinandrei, over there (maybe I should have posted it here instead) after testing I settled on the same as you (separate-shift-resize-weave with Spline36)... I also ask after a 2-pass HC.ini using lossless :)
2Bdecided
18th August 2008, 10:41
Or maybe they did the best out of a really nasty job. It was real time, wasn't it? It's difficult.The Alchemist manages much harder tasks in real time ;)
Cheers,
David.
2Bdecided
18th August 2008, 15:25
I've had a look on various TVs (50Hz CRT, 100Hz CRT, plasma)...
By the way, the sharp, aliased methods don't look that sharp on the native SD (480i) screen. The difference in sharpness between Yadif (without Blur) and shift/interleave is minimal, vanishing really.The difference in sharpness looks significant to my eyes. I split screened it, and as objects move from the "sharp" side to the "blured" side it looks like someone added some softening gel to them. But...
But the difference in aliasing is big and noticeable.Agreed. The aliasing in the sharp version is really objectionable / distracting. It depends on the content, but at worst it's simply not acceptable.
If you try to "fix" Yadif with Blur, then it looks very similar to shift/interleave, except it's slower.It depends what you do. It's hard to get rid of all the aliasing, maintain sharpness, and avoid halos, but there are other compromises between very sharp and very blurred. (see below).
On an HD screen (or computer monitor) it's a different story, but then again, the SD movie is for SD displays.I was surprised how similar they were, considering. The SD CRT maintained the sharpest look (unless you try something stupidly slow like mcbob on the PC, which can also be sharp), but the aliasing was nasty on all of them.
If you're happy with what you've found, then use it - it save a lot of time and hassle!
If you have more time to waste, there are useful suggestions in this thread...
http://forum.doom9.org/showthread.php?t=139948&page=2
...which is about 1080p25 to 576i50 without flicker - but of course after deinterlacing, our 1080i50 becomes 1080p50 and you can use the same tricks.
*.mp4 guy's filter (note: optimised for 576p; maybe he can do a version for 480p too?)...
# add interlaced source here
# add whatever bob here
#then...
mt_convolution(horizontal=" 1 ", vertical=" 0.038210901657426959 -0.037550193209593907 \
-0.071321291957842009 -0.089513860956413741 -0.059487989097957106 0.028344726218269046 \
0.149710222693422800 0.255497189418900370 0.297427044507872330 0.255497189418900370 \
0.149710222693422800 0.028344726218269046 -0.059487989097957106 -0.089513860956413741 \
-0.071321291957842009 -0.037550193209593907 0.038210901657426959 ", u=2, v=2)
spline36resize(704,576)
assumetff()
separatefields().SelectEvery(4,0,3).Weave()
...this is really sharp and increases visibility of small details, keeps aliasing down, but is ringy
My alternative...
# add interlaced source here
# add whatever bob here
#then..
spline36resize(704,576)
limitedsharpenfaster().Sharpen(0.5,0.0).Blur(0.0,1.0).Sharpen(0.0,0.5)
assumetff()
separatefields().SelectEvery(4,0,3).Weave()
...this is less sharp than above, but less ringy, and doesn't change the visibility of details much
(you might need assumebff(), and you will need 480 in place of 576 for the height)
When I was playing around with this and putting the various versions onto DVD to compare, I realised the major problem is encoding the result well enough to do justice to the quality, whichever method you use. Obviously the softer methods are slightly easier to encode, but I couldn't get QuEnc to maintain the quality of the originals. :(
the SD movie is for SD displaysWell, for a few years yet I think SD DVD will remain the mainstream distribution format for the majority of people - I know lots of people with HD displays without any way of feeding HD to them. However, the compromises involved in converting HD to SD make me want to give anyone with a PC a WMV or Xvid or X264 1280x720p50 version instead! The problem then is that there are different compromises, not least the difficulty in playing that file back as smoothly on a PC as it would look on a TV.
Cheers,
David.
florinandrei
21st August 2008, 00:08
# add interlaced source here
# add whatever bob here
#then..
spline36resize(704,576)
limitedsharpenfaster().Sharpen(0.5,0.0).Blur(0.0,1.0).Sharpen(0.0,0.5)
assumetff()
separatefields().SelectEvery(4,0,3).Weave()
So, how did you came up with the sharpen/blur sequence above? What was the rationale? Or was it trial and error?
2Bdecided
21st August 2008, 10:34
I just threw in some numbers to try to match the perceived sharpness of mp4 guy's filter, while trying to avoid ringing and too much aliasing. Because of what mp4 guy has done, even a very sharp resize with no filtering looks far softer than his filtered version.
So, sorry, no rationale!
I was noticing on the BBC news last night how studio shots look quite sharp, with absolutely no aliasing and little ringing, while downconverted HD, and standard "inferior" SD, often does have aliasing. Whether the HD with aliasing looks sharper than the alias-free studio shots, I'm not sure. I'd love to know the various approaches the professionals take to this.
Cheers,
David.
florinandrei
22nd August 2008, 06:10
I just threw in some numbers to try to match the perceived sharpness of mp4 guy's filter, while trying to avoid ringing and too much aliasing. Because of what mp4 guy has done, even a very sharp resize with no filtering looks far softer than his filtered version.
I compared these scripts:
AssumeTFF()
SeparateFields()
Shift=(Height()/Float(NewHeight/2)-1.0)*0.25
Tf=SelectEven().Spline36Resize(NewWidth, NewHeight/2, 0, -Shift, Width(), Height())
Bf=SelectOdd().Spline36Resize(NewWidth, NewHeight/2, 0, Shift, Width(), Height())
Interleave(Tf, Bf)
Weave()
AssumeTFF()
Yadif(mode=1)
Spline36Resize(720,480)
LimitedSharpenFaster().Sharpen(0.5,0.0).Blur(0.0,1.0).Sharpen(0.0,0.5)
AssumeTFF()
SeparateFields()
SelectEvery(4,0,3)
Weave()
On an HD screen, the first one looks very smooth. Maybe a bit blurry. No aliasing.
The second one looks apparently sharp, but it's pretty clear the sharpness is artificial. It's like one of those TV screens with sharpness turned way up to attract customers in the store. Also has a bit of aliasing.
On an SD screen, the second script looks good and appears sharper than the first, but it's hard to tell whether it actually provides more detail, not just the subjective impression of sharpness. I couldn't find any details that were actually not visible with the first script. The difference in terms of aliasing is small.
Something that I'd like to do at this point is to test eye fatigue. One problem with apparently sharp images is that they fool the eye on the short term, but long term produce fatigue. I became aware of this after calibrating my TV for the first time - it made a huge difference in the quality of image and comfort of viewing.
Unfortunately, this kind of test requires a lot of time, and that's something I don't have.
I'm still leaning towards the first script, based on everything I've seen so far.
At some point I'll start dumping all my HD home videos on DVD (1080i AVCHD, a.k.a. poor man's Blu-Ray) because right now they're on a hard-drive and it's filling up. At that moment I'll definitely have to make a decision, since that's when I need to also make the DVD 480i versions.
2Bdecided
22nd August 2008, 09:49
At some point I'll start dumping all my HD home videos on DVD (1080i AVCHD, a.k.a. poor man's Blu-Ray) because right now they're on a hard-drive and it's filling up. At that moment I'll definitely have to make a decision, since that's when I need to also make the DVD 480i versions.IME if the DVD versions are for other people, they'll probably be happy with whatever you give them. If they're for you, you'll never be happy, having seen the HD source.
If you want to keep your home videos long term, I think it's risky just keeping a single copy. For the raw footage, I currently keep the original HDV tapes, and the m2t files on a HDD. The costs of DV tape and HDDs are similar now - the tapes will last longer (the machine to play them may not!) but the HDD is more convenient. Data redundancy is good. I can do the same for edited footage, but haven't done yet.
I guess with an AVCHD source, HDD and DVD-R are a good choice - but choosing just one or the other is like saying "one day I'll dump all this footage".
If you have that much footage, IanB's method has the huge advantage of being the fastest. If HD>SD is trivial, then you only have to backup the HD versions IMO. If HD>SD is mcbob-like slow, you have to backup both to preserve the time/effort investment you made in converting (again, IMO!). YMMV.
Cheers,
David.
EDIT: P.S. - for the kind of difficult comparisons you're making (i.e. are there any more "real" details with method X or Y), it might be worth shooting or sourcing an HD test card. It might not be very representitive of real life footage though!
florinandrei
22nd August 2008, 10:29
Very good points.
The DVDs are for other people. I was just trying to do my best but yeah, they will probably think the DVDs are fine no matter what.
I am aware of the issues with single copy and long term archival. Currently, my old SD videos are 3 copies, on at least 2 different kinds of DVDs, stored on different continents. :) (one copy here, two other copies with my parents and my wife's parents in a different country)
HD is more difficult. I was planning to burn at least 2 copies, on 2 different kinds of DVDs, and store them in geographically dispersed locations. But the HDD suggestion sounds good. I'll have to think about that. The price per TB is going down fast.
IanB's method is definitely the fastest. I can afford to use a high quality resize without dragging it down too much.
One day I'm hoping to upgrade to something like Scarlet (http://www.red.com/) and then storage will be even more difficult. :mad: But by then BD will be more affordable, hopefully. Also the price per TB.
Gavino
22nd August 2008, 11:20
@florinandrei
As I think you are working with YV12 material, you should keep an eye on the other thread where we are discussing a correction to IanB's resizing method. Basically, the original method produces a slight error in the chroma for YV12.
See here and following.
halsboss
23rd August 2008, 16:36
Thanks, this post seems to finally say that the right thing to do for this method (given PAL HDTV 1080i->576i) is
SetMTmode(mode=2,threads=4) # mode=2 for temporal multi-threading (interleaved frames) ??????????
Global NewWidth=720 # or maybe 704 ? ... 704 could mean lesser area but hence leaving higher bitrate for that lesser area ?
Global NewHeight=576
SeparateFields()
Shift=(GetParity() ? -0.25 : 0.25) * (Height()/Float(NewHeight/2)-1.0)
E = SelectEven().Spline36resize(NewWidth, NewHeight/2, 0, Shift)
O = SelectOdd( ).Spline36resize(NewWidth, NewHeight/2, 0, -Shift)
Ec = SelectEven().Spline36Resize(NewWidth, NewHeight/2, 0, 2*Shift)
Oc = SelectOdd( ).Spline36Resize(NewWidth, NewHeight/2, 0, -2*shift)
Interleave(E, O)
IsYV12() ? MergeChroma(Interleave(Ec, Oc)) : Last
Weave()
Aassuming we use MT.
EDIT: can some knowledgeable person please confirm that SetMTmode won't muck this up in terms of interleave etc ?
*.mp4 guy
23rd August 2008, 17:35
low ringing (and low detail) lowpass for 1080i->480i.
mt_convolution(horizontal=" 255 ", \
vertical=" -0.00457430142084469586164799888191 -0.91092031121042564306650907803944 -2.7215434011820571965496188952936 -4.2381040109875854130339774799147 -2.7739456768086984932442890697262 4.556137386140445570028490752454 18.505136047840382914953022942635 36.000435907859456703965425655238 50.797650942298968076309880259519 56.609999970907811068675436793984 50.797650942298968076309880259519 36.000435907859456703965425655238 18.505136047840382914953022942635 4.556137386140445570028490752454 -2.7739456768086984932442890697262 -4.2381040109875854130339774799147 -2.7215434011820571965496188952936 -0.91092031121042564306650907803944 -0.00457430142084469586164799888191 ", u=3, v=3)
2Bdecided
23rd August 2008, 19:18
*.mp4 guy,
Could you do 1080i>576p please? If you have time.
Cheers,
David.
florinandrei
23rd August 2008, 23:29
low ringing (and low detail) lowpass for 1080i->480i.
Is that "black magic" :) explained somewhere? I'm looking at the numbers and I can't figure out exactly what's going on.
What makes it low ringing? What makes it low detail? What do I need to change to make it "high detail" or anything in between if I want to?
What does it do beyond a simple yadif().spline36resize().separatefields().selectevery().weave() ?
P.S.: I know what "convolution" means in general, and I'm familiar with this concept from audio processing (i.e. convolution filters to mimic the reverb of a cathedral), but in this particular case I have no idea what's happening.
halsboss
24th August 2008, 01:51
low ringing (and low detail) lowpass for 1080i->480i.
mt_convolution(horizontal=" 255 ", \
vertical=" -0.00457430142084469586164799888191 -0.91092031121042564306650907803944 -2.7215434011820571965496188952936 -4.2381040109875854130339774799147 -2.7739456768086984932442890697262 4.556137386140445570028490752454 18.505136047840382914953022942635 36.000435907859456703965425655238 50.797650942298968076309880259519 56.609999970907811068675436793984 50.797650942298968076309880259519 36.000435907859456703965425655238 18.505136047840382914953022942635 4.556137386140445570028490752454 -2.7739456768086984932442890697262 -4.2381040109875854130339774799147 -2.7215434011820571965496188952936 -0.91092031121042564306650907803944 -0.00457430142084469586164799888191 ", u=3, v=3)
Nice, if a little cryptic :) Any suggestions for 1080i->576i ?
IanB
24th August 2008, 10:19
@*.mp4 guy,
Yes, it might be nice if you share the maple script or whatever you are using to generate the coefficients to this 19 tap filter. And are you sure about your parameters, the provided filter seems to low pass at about 60 lines, I would expect it to be somewhere between 120 and 240 lines.
*.mp4 guy
25th August 2008, 04:33
It does lowpass between 120 and 240 lines, but because it is low ringing and has a low number of sample points (relatively speaking, you need more and more sample points the more frequencies you eliminate) it loses a lot of frequency amplitude all the way to around 60 lines. This filter is a simple chebyshev windowed sinc fir filter.
frequency response graphs:
The filter I posted (http://img135.imageshack.us/img135/4205/frequencyresponsecd2.png)
A bit more aggressive filter (http://img82.imageshack.us/img82/8654/frequencyresponse2gg6.png)
non windowed sinc, with 2x the sample points (http://img135.imageshack.us/img135/5830/frequencyresponse3ip5.png)
The line shows the aproximate location of the ideal cut off point, the boxes indicate manifestations of ringing.
mikeytown2
25th August 2008, 06:27
@*.mp4 guy
would you mind explaining what software package you used to create the numbers/graphs?
My guess is http://octave.sourceforge.net/
found this graph with GNU Octave Code: http://en.wikipedia.org/wiki/Image:Phase_Plots.svg
web front end of Octave http://hara.mimuw.edu.pl/weboctave/
*.mp4 guy
25th August 2008, 21:09
In this case I used winfirdesigner (http://www.elektronikschule.de/~krausg/DSP/Dsp_CD/DSP_and_FFT_and_Digital_Filter_Programs/WinFIRDesigner/) which is a simple freeware fir filter design program that supplies some nice graphing functionality. I've never heard of Octave, but it looks interesting.
florinandrei
30th August 2008, 05:20
I tested the convolution script posted by *.mp4 guy but it's very slow and it's very blurry. The vertical resolution is bad and the conversion speed is like 0.5 fps on a fast machine.
I tested the new corrected shift/interleave script:
Global NewHeight = 480
Global NewWidth = 720
DirectShowSource("hd.m2ts", audio=false)
# Pick one manually, DirectShow has no idea
AssumeTFF()
#AssumeBFF()
SeparateFields()
Shift = (GetParity() ? -0.25 : 0.25) * (Height()/Float(NewHeight/2)-1.0)
E = SelectEven() . Spline36Resize(NewWidth, NewHeight/2, 0, Shift)
O = SelectOdd() . Spline36Resize(NewWidth, NewHeight/2, 0, -Shift)
Echr = SelectEven() . Spline36Resize(NewWidth, NewHeight/2, 0, 2*Shift)
Ochr = SelectOdd() . Spline36Resize(NewWidth, NewHeight/2, 0, -2*shift)
Interleave(E, O)
IsYV12() ? MergeChroma(Interleave(Echr, Ochr)) : Last
Weave()
Compared with the initial version (that didn't process chroma separately), this one looks very similar. I didn't do an A/B comparison, but viewing them successively I can't tell any difference.
The corrected version is a bit slower (10.3 fps vs 12.7 fps) but that's OK. This new script supposedly deals with chroma correctly, so I think I'll just use it.
Are we out of ideas yet? :)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.