creaothceann: I will install the ZMBV codec next time I need it, thanks.
I asked some years ago about stroked text and want to do that again, but I get a weird error "CACHE_GETCHILD_CACHE_MODE.87383360"
I have a question:What is interlacing?Is it like deblink?
What is the defferent betwen interlacing and deinterlacing?
Interlacing is old technique for reducing analog TV transmission bandwidth (basically only sending half of the lines, alternating between even and odd).
When digital revolution came, it should have been taken out and shot, but apparently wasn't.
Basically, if you can avoid dealing with it, avoid it.
can someone explain me what I'm doing wrong. just playing around with some encoding tests on my new system- I thought by doubling the resolution with pointresize and then converting it to yv12 the result should be colorwise the same as converting the original resolution to yv24. but in the result I can clearly see color mergings at pixel borders despite the chromaresample="point" argument. here is the script I used:
How are you viewing it? My guess is the conversion back to RGB to view is screwing it up. Otherwise it looks fine. Easy test? Add this to the end and view it again.
Edit: To give more information, there are a few ways on how the sample is converted back to RGB. If it's done wrong, you get what you saw, which is bleeding. If it's done right, then the problem wouldn't show. The problem is, since there is nothing standard in the stream to indicate which way to convert, things like this sometimes happen. More information here: http://www.mir.com/DMG/chroma.html under "Three Varieties of 4:2:0".
Edit 2: If you want to match what I would guess your computer is doing to convert back to RGB (MPEG 1 placement), I would use this line in your script instead:
with virtualdub (v1.10.4). adding your suggested line makes it actually worse:
https://imgur.com/a/PnGqt
edit: already played around with the chromaoutplacement argument. no difference at all, what I guess is exactly one would expect if the input clip was 2x-pointresized.
Check my edits above in case you missed something. Also in VDub, uncheck Options -> Allow video overlays and see if it helps.
Edit: Indeed adding ConvertToRGB32() still has a shift, but nothing like your screenshot. It's a lot less than without.
Edit 2: Something is very screwed up. It seems like you did the color conversion, then upscaled it again by 4. This is incorrect. The color conversion should be the last thing you do.
well this really confuses me. also tried the chromainplacement argument in the converttorgb32 function. well it gives different results but not one of them is correct. here is a little sample, maye a problem with the source?
https://anonfiles.com/file/4826998bd17c2a89f0b1c44cbcaea109 (msu screen capture lossless codec)
edit: I did nothing more than the script I posted. I only magnified a specific part of the screenshot to make the difference more viewable.
edit2: avisynth version is 2.6.0.
Yep, I'm a bit confused now too. I thought I got it working before, but I think the best I got was with that vertical shift with ConvertToRGB32(). I'll try asking the devs as seemly chromaplacement does nothing. Reading some comments, it seems this is the norm for resample="point" but right now I'm not sure why.
yeah I also found this thread in my search, this script only makes sense in the case of converting back to yv24. thanks for the help though. I started a thread on doom9 regarding this issue, let's see what the veterans have to say about this:
http://forum.doom9.org/showthread.php?p=1681752
Joined: 4/17/2010
Posts: 11492
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Dimon12321 wrote:
When I try to dump AVI on Dolphin 4.0.2, it writes me "Error dumping frames to AVI!". How to fix it? All folders in my documents are already created!
Sounds similar to my case. It just refused to do it no matter what I tweak. Maybe software/hardware/drivers are involved.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
yeah I also found this thread in my search, this script only makes sense in the case of converting back to yv24. thanks for the help though. I started a thread on doom9 regarding this issue, let's see what the veterans have to say about this:
http://forum.doom9.org/showthread.php?p=1681752
It will make sense not only in converting to YV24 for also RGB32. Great that you made a thread. I would like to see the answer. It could be I've been doing it wrong all this time...
ok now we know how to reverse the process. the actual pixel blendings in the yv12 seems to be based on how the croma plane is upscaled. so yeah, it's an application dependent thing. from the look of it virtualdub seems to use bilinear/bicubic for the chroma plane which I thought was an error in my color conversion.
But thanks to this, we know how to completely untouch the chroma in a 2x upscale. I'd say this is better than using ConvertToYV12() though I am unsure on how accurate the placement is.
Joined: 4/17/2010
Posts: 11492
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Nah, moving to non-cyrillic path didn't help.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Maybe because of containing russian not english letters in the derectory!? Some software can require this!
Yeah, I have seen software that fails (on Windows) if any parent directory of some file to open/create contains any non-ASCII character.
Basically, the problem is that normal Windows filesystem functions can't handle such things, one would have to use some exotic Unicode variants (and these aren't using any sane character set either).
just wanted to give some feedback. after I solved the issue with the color conversion (see a few posts back), I checked if i444 is indeed more efficient than i420. well visually and metric wise it is at the same bitrate. I kinda thought that with pixel art the encoder has more freedom to make errors at 2xPoint, where at the original resolution every small error is a big issue. but that's not the case and of course the encoding is way faster.
well maybe it was obvious but now I know it for sure!
For downloadable encodes, keeping it at 4:4:4 is the best, but for online streaming like YouTube, you are forced to use 4:2:0, so at least 2x point resize is needed.
