MPEG1 upscale?

[feisty2]

The VCD I got is progressive PAL (no doubt just deinterlaced from the crappy source); but yeah, a widescreen version in higher res *does* exist somewhere! :)

you will be able to get a 1080p version if the director hasn't thrown the 16mm movie material away as garbage and would love to rescan and remaster the movie someday

[asarian]

that's bullcrap
when you're signing up a new account in US iTunes Store, after filling in basic information like email address and password, you'll go to this payment choosing page
http://thumbnails109.imagebam.com/34829/1e96a4348287578.jpg (http://www.imagebam.com/image/1e96a4348287578)
as you can see, there're various payment methods you can choose
VISA MasterCard PayPal, they are clearly international online banking systems.
you can get a visa credit card from any bank with the time of a blink
EDIT: when you're done getting everything you need in US iTunes Store, you can switch back to your old account in iTunes Store, there's no problem of messing your old stuff


Well, 'bullcrap''notwithstanding, it can't be done. :( I should have known better. They (very aggressively) require a USA billing address and USA funding source. Even using paypal as funding source, they (equally aggressively) require that paypal account has a USA billing address.

In simple terms, they won't let me use a USA store, ever; and I just (*&$%^&*( wasted $12 bucks on an US iTunes gift card.

EDIT: P.S. Gift card must be redeemed from USA iTunes store too, btw. So I'm effed all the way.

[feisty2]

Did you try this
http://thumbnails109.imagebam.com/34847/0d83aa348461154.jpg (http://www.imagebam.com/image/0d83aa348461154)
they must have a backup plan for Americans that don't live in the states, I think this is the plan, when I registered the jp account, I clicked this

[asarian]

Did you try this
http://thumbnails109.imagebam.com/34847/0d83aa348461154.jpg (http://www.imagebam.com/image/0d83aa348461154)
they must have a backup plan for Americans that don't live in the states, I think this is the plan, when I registered the jp account, I clicked this

That option does not exist for me. In fact, they're so aggressive about it, when I start up, thet even says: "This Apple ID is only valid for purchases in the Dutch iTunes store."

[feisty2]

That option does not exist for me. In fact, they're so aggressive about it, when I start up, thet even says: "This Apple ID is only valid for purchases in the Dutch iTunes store."

you gotta change your country to US before you sign up a new account, did you forget that?
EDIT: and sign out your old account before everything!

[ChiDragon]

Guess you don't want that Canadian card anymore.

Remember, you're not the first person to have to deal with Apple's nonsense. There are guides on how to sign up and purchase things from other countries' iTunes stores. I'm not sure which are up-to-date.

http://lifehacker.com/5524520/create-a-dummy-account-to-get-around-app-store-restrictions

You'll also need to be careful which version you use to purchase it, as I don't know the newest version that Requiem supports.

The VCD I got is progressive PAL (no doubt just deinterlaced from the crappy source)
VCDs can't contain interlacing. Typically they just drop one of the fields, which leads to obvious aliasing of sharp onscreen titles.

[feisty2]

iTunes crap has been solved now, I guess the reason why iTunes sets all those outrageous region restrictions is for the price differences, like the screenshots I showed earlier, if there was no region restriction, all Americans would download the movie from Canadian iTunes store, which greedy Apple assumes that sucks!
edit: autocorrect sucks! it gives me more typos than I do it myself

[Reel.Deel]

You'll also need to be careful which version you use to purchase it, as I don't know the newest version that Requiem supports.


Requiem 4.1 supports iTunes 10.7 (http://support.apple.com/kb/DL1576). (works very well, Requiem is the only reason I buy (hard to find) content from iTunes)

[asarian]

iTunes crap has been solved now, I guess the reason why iTunes sets all that outrageous region restrictions is for the price differences, like the screenshots I showed earlier, if there was no region restriction, all Americans would download the movie from Canadian iTunes store, which greedy Apple assumes that sucks!
edit: autocorrect sucks! it gives me more typos than I do it myself

Yup, iTunes certainly be annoying. :) Thanks again for all your help, guys!

Meanwhile, back at the ranch, on a test clip of my other source, this code suddenly makes my Avisynth process hang:

blocky=smdegrain (tr=6,thsad=650,thsadc=650,prefilter=3,lsb_out=true)
deblock=last.smdegrain (tr=12,thsad=2000,blksize=4,search=3,prefilter=3,mode=-1,lsb_out=true).dither_repair16 (blocky,mode=13)
super=blocky.ditherpost (mode=-1).msuper (pel=2)
vectors=super.manalyse (search=4,searchparam=2,pelsearch=4)
motionmask=blocky.ditherpost (mode=-1).mmask (vectors,kind=0,gamma=2,ml=5)
Dither_merge16_8 (blocky,deblock,motionmask)


It does the "blocky=smdegrain" line, but anything else afterwards, and the process just permanently drops to 3% CPU. I guess maybe because it exhaustively tries to look for blocks that are not there?! :P

Is there any way to do just do the dither_repair16() on blocky, sans the rest? And still keep the 16bit output for the next upscaling pass? Cuz that dithering alone seems better than GradFunDB().

^^ EDIT: Would just "smdegrain (tr=6,thsad=650,thsadc=650,prefilter=3,lsb_out=true).dither_repair16 (blocky,mode=13)" do it?

[feisty2]

if your new clip is not blocky, a simple smdegrain call would be fine
and you can't use ediresize16 with those old parameters cuz that would be too soft for not so crappy clips
im on the cellphone at the moment, talk to you later

[asarian]

if your new clip is not blocky, a simple smdegrain call would be fine

Cool. But won't I need the dithered 16-bit output for the second-pass upscaling?

[feisty2]

set lsb_out=true, you will get 16bpc output

[asarian]

set lsb_out=true, you will get 16bpc output

Most peculiar. After this:

smdegrain (tr=6,thsad=650,thsadc=650,prefilter=3,lsb_out=true)

The process comes to a virtual halt, exactly after frame 62. But when I do this:

DeBlock_QED()
smdegrain (tr=6,thsad=650,thsadc=650,prefilter=3,lsb_out=true)

Then the process keeps running. Hmm, I need to examine this some more. :)

[feisty2]

how's your another clip you're working on right now
is the quality crappy, passable, good or ultra high

[feisty2]

for general high quality filtering, follow these steps
dither_convert_8_to_16 ()
ediresize16 (output="rgb48y")
#16 bpc denoise, sharpen, blah blah#
ediresize16 (x,y,curve="709",tv_range=false)
dither_convert_rgb_to_yuv (selectevery (3,0),selectevery (3,1),selectevery(3,2),lsb=true,output="yv24",mode=-1)
#you gotta separate r g b channels to single independent clips first if you wanna apply some temporal filters on it#

[asarian]

how's your another clip you're working on right now
is the quality crappy, passable, good or ultra high

The new source is quite a step up from the old one. :) Thanks for asking. It still has an overall bitrate of only ~1,673 Kbps (@ 640x480, with a 16:9 DAR), but it's MPEG-4, and thus, for that reason alone, far superiorly compressed than that lowly MPEG-1 source. And it appears to be severely deblocked already. The latter wasn't done entirely properly, I think, as there is quite some banding in several spaces.

It's quite illuminiating, btw, what info iTunes put inside it, like:

Encoded date : UTC 2014-05-15 23:55:32
Color primaries : BT.601 NTSC
Transfer characteristics : BT.709
Matrix coefficients : BT.601

If I'm reading the "BT.709" part right, it was remastered from an original HD source (so, not a crappy VCD upscale). So I'm still holding out hope for a Blu-Ray, one day. :)

It also says,

Muxing mode : Final Cut

Which is, of course, *not* all that encouraging. Or... it could mean nothing at all. :p

[feisty2]

no, that's not correct, transfer characteristics is actually the gamma compress curve, not matrix
almost all videos, sd or hd use bt 709 for the gamma compress curve

[asarian]

for general high quality filtering, follow these steps
dither_convert_8_to_16 ()
ediresize16 (output="rgb48y")
#16 bpc denoise, sharpen, blah blah#
ediresize16 (x,y,curve="709",tv_range=false)
dither_convert_rgb_to_yuv (selectevery (3,0),selectevery (3,1),selectevery(3,2),lsb=true,output="yv24",mode=-1)
#you gotta separate r g b channels to single independent clips first if you wanna apply some temporal filters on it#

Ah, where would I be without you?! :) Thanks yet again!

Based on what I saw in the other thread, I had already prepared something (for the second-pass upscale phase):

Dither_convert_yuv_to_rgb (matrix="601", output="rgb48y", noring=true, lsb_in=true)
Dither_convert_rgb_to_yuv (SelectEvery (3, 0), SelectEvery (3, 1), SelectEvery (3, 2), matrix="709", noring=true, lsb=true, mode=0)

ediresize16 (1920, 1080, kernel_u="bicubic", noring=true)
ditherpost (mode=6)

Guess I did that wrong. :) If I'm reading you correctly, I think it should be more something like:

ediresize16 (1920, 1080, kernel_u="bicubic", noring=true, curve="601", tv_range=false, output="rgb48y")
ditherpost (mode=6)
Dither_convert_rgb_to_yuv (SelectEvery (3, 0), SelectEvery (3, 1), SelectEvery (3, 2), lsb=true, output="yv24", mode=-1)

Right?

[feisty2]

srgb is not a linear display system, there's something called gamma compress, widely used in low precision images, it enhances the precision of dark part and sacrifices precision of bright part, because human eyes are more sensitive to dark part, this would minimize the banding problem
edit: stupid typos, i'm gonna throw this smart?phone away soon

[asarian]

srgb is not a linear display system, there's something called gamma compress, widely used in low precision images, it enhances the precision of dark part and sacrifices precision of bright part, because human eyes are more sensitive to dark part, so this would minorize the banding problem

Ah. Learn something every day. :) Thx.

[feisty2]

that's wrong
you gotta convert your clip to rgb BEFORE upscale, but what you did, it converts your clip to rgb after upscale, that's pointless. and don't use noring, it gives you troubles like aliasing and bluring, its useless for high quality source upscale, the edi core is already ringing free

[feisty2]

and dont use bicubic kernel, that's too soft for high quality clips, just leave most parameters to its default, like i wrote earlier

[feisty2]

fine, i give up, i will make typos many as i can with or without autocorrect anyway
maybe off the topic, but any advice?

[asarian]

and dont use bicubic kernel, that's too soft for high quality clips, just leave most parameters to its default, like i wrote earlier

Ah. The "kernel_u="bicubic", noring=true" I had taken from an earlier ediresize16 example by you in this thread. :)

So, this gives me a grand total of:

ediresize16 (output="rgb48y")
ediresize16 (1920, 1080, curve="709", tv_range=false)
ditherpost (mode=6)
Dither_convert_rgb_to_yuv (SelectEvery (3, 0), SelectEvery (3, 1), SelectEvery (3, 2), lsb=true, output="yv24", mode=-1)

[feisty2]

remove that ditherpost stuff, why would you convert rgb48 to rgb24 before convert it to yuv colorspace, that's an avoidable and unnecessary precision loss

[asarian]

remove that ditherpost stuff, why would you convert rgb48 to rgb24 before convert it to yuv colorspace, that's an avoidable and unnecessary precision loss

Hehe. I had just copied these parameters over from the other source examples. :) Thx again, ditherpost() is gone!

[feisty2]

and the script returns the processed clip in yuv444p16 format, you have to set the colorspace "i444" when you encode it with x264

[asarian]

and the script returns the processed clip in yuv444p16 format, you have to set the colorspace "i444" when you encode it with x264

That was actually a copy-error on my part: should have been 'lsb=false.'

From the dither manual, I got this code:

MPEG2Source ("video_sd.d2v")
Dither_convert_8_to_16 ()
Dither_resize16 (1280, 720)
Dither_convert_yuv_to_rgb (matrix="601", output="rgb48y", lsb_in=true)
r = SelectEvery (3, 0)
g = SelectEvery (3, 1)
b = SelectEvery (3, 2)
Dither_convert_rgb_to_yuv (r, g, b, matrix="709", lsb=false, mode=0)

So, maybe I just shouldn't set the output colorspace at all, as I'm rather confused now what x264 wants. :)

[feisty2]

thats a basic colormatrix convert example, the goal of that script is different from yours, you didn't do anything wrong, just keep the previous script and lsb=true is correct, you are doing different things, keep that

[asarian]

and dont use bicubic kernel, that's too soft for high quality clips, just leave most parameters to its default, like i wrote earlier

What about Spline36, btw? Cuz yeah, that bicubic thingy makes it look a wee too soft.

[feisty2]

the default kernel is 32taps spline, way much better than spline36 when resizing in linear light like what you're doing

[asarian]

the default kernel is 32taps spline, way much better than spline36 when resizing in linear light like what you're doing

LOL. See?! I should just have listened to you and keep the defaults, like you said! :P

and the script returns the processed clip in yuv444p16 format, you have to set the colorspace "i444" when you encode it with x264

So, this won't output it in 8-bit then?

Dither_convert_rgb_to_yuv (SelectEvery (3, 0), SelectEvery (3, 1), SelectEvery (3, 2), lsb=true, output="yv24", mode=-1)


Cuz that will have been the final stage, before compressing it with x264.

[feisty2]

32 taps spline = spline4096resize
everything inside ediresize16 is set to placebo precision by default
you don't need to tweak much if you're a quality freak

[asarian]

32 taps spline = spline4096resize
everything inside ediresize16 is set to placebo precision by default
you don't need to tweak much if you're a quality freak

And that's why I love your EDIResize16 script. :) It's wickedly slow, but I only want the best! And besides, that's what I bought my i7 980X for to begin with. :)

[feisty2]

i suggest you should encode at 10bpc to avoid banding pickles
how to encode at 10bpc is written in dither document

[feisty2]

actually ediresize16 is just a supporting function I wrote for the experimental function package I'm working on, for superclip generating in msuper, but can be used as a high quality resizer also, I wrote the package trying to restore the common dvd video back to ntsc broadcast quality, the package is not useful tho, it's extremely slow, so just for tests

[feisty2]

https://www.sendspace.com/file/oz3e28
the package is here, test it if you want, you can apply "last.edgehd16 (warp=last.warp16 (str=8,edi="nnedi",tv_range=false),tv_range=false)"
right after ediresize16 upscale if you want HD look thin and sharp edge

[asarian]

i suggest you should encode at 10bpc to avoid banding pickles
how to encode at 10bpc is written in dither document

Hmm, never even considered that. :)

That may require a 10-bit x264 (naturally). And I probably have to do this differently too:

"c:\x264\avs2yuv.exe" "f:\jobs\%1.avs" -o - | "c:\x264\x264.exe" - --demuxer y4m ....

Which is how I normally call x264 (from a cmd file). If I recall correctly, that was a trick by Lord_Mulder, so as to maximize available memory to the x264 process. But it will likely ruin the 10-bit color-space.

[asarian]

thats a basic colormatrix convert example, the goal of that script is different from yours, you didn't do anything wrong, just keep the previous script and lsb=true is correct, you are doing different things, keep that

Hmm, obviously I'm doing something wrong, after all. :)

EDIResize16 (output="rgb48y")
EDIResize16 (1920, 1080, curve="709", tv_range=false)
Dither_convert_rgb_to_yuv (SelectEvery (3, 0), SelectEvery (3, 1), SelectEvery (3, 2), lsb=true, output="yv24", mode=-1)

That gives me a 16-bit output (which is good, I reckon), but I'm getting this (ediresize16?) warning:

resize [warning]: converting from yuv444p16le to yuv420p16le

[feisty2]

the output clip is yuv 4:4:4 (full sampling), the format got the best quality of all yuv formats, common videos are yuv 4:2:2 or 4:2:0
you have to set both input and output colorspaces "i444" and set the input depth 16 and add dither_out at the end of the script

[asarian]

the output clip is yuv 4:4:4 (full sampling), the format got the best quality of all yuv formats, common videos are yuv 4:2:2 or 4:2:0
you have to set both input and output colorspaces "i444" and set the input depth 16 and add dither_out at the end of the script

Thx. :) I found out about the correct piping for x264-10b now too (I just needed to add a few extra parameters, like '-raw' and one for input depth and resolution). Final encoding is on its way. :)

Thx again for all your help!

[asarian]

Well, can you believe this %^&*()(*&^$# crap?! I had decoded original stream with DGIndexNV, which pegged the file at 25fps. So, 50+ hours and two lossless passes later, when I'm ready to mix in the audio, and it appears out of sync, turns out movie was 23.976fps, after all!

Well, that's the very last time I'll ever use DGIndexNV again!

[feisty2]

you can force a new framerate within container properties

[asarian]

you can force a new framerate within container properties

Wait, you mean I don't have to recode everything again? :) :goodpost: That would be awesome! Gonna try it rightaway!

[asarian]

you can force a new framerate within container properties

So, is I use tsMuxeR to just set it to 23.976, and remix, would that work? Or would I lose frames like that?

[feisty2]

that would work, the container framerate got the higher priority than stream framerate, both only control the play speed, harmless to video quality

[asarian]

that would work, the container framerate got the higher priority than stream framerate, both only control the play speed, harmless to video quality

Brilliant!! Looks like I won't have to redo everything, after all! Thx! :)