AnimeSuki Forums

Meltingice · 2009-04-29, 12:27

It is most likely a filter conflict/issue.

That1GuyTim · 2009-04-29, 12:52

But why would it happen with only 2 more frames left?

Meltingice · 2009-04-29, 15:36

Quote:

Originally Posted by That1GuyTim

Hey guys, I've got a problem that I need some help with. I couldn't find any answers elsewhere, so I'm turning to y'all.

Last night I started to run a lossless in VirtualDub and everything was going fine. Cut to right now and I have this error message that has popped up and caused the encode to stop prematurely by 2 frames:

Now, I clicked OK and it still gave me a video, but it's missing the very last 2 frames that the original source had. Any idea what this error means or is causing it?

Quote:

Originally Posted by That1GuyTim

But why would it happen with only 2 more frames left?

Who knows?

edogawaconan · 2009-05-02, 22:57

how about telling us what's your avisynth plugins folder contents, and the .avs causing that error.

That1GuyTim · 2009-05-07, 10:36

Nevermind, I believe it was a problem with the raw I was using. I used a different raw with the same avs and same settings and it worked just fine.

SHiN-gx · 2009-06-24, 23:10

I need some suggestions on how to remove this artifact (sorry, don't know what it's called.)

I used FFT3D and fluxsmoothst() but it really didn't do much.

Thanks in advanced.

Akatsuker · 2009-06-24, 23:24

"AVISource: couldn't locate a decompressor for fourcc WVC1"

My AvsP keeps telling me that, even when I configure my FFDShow codec to decode it, whatever, libavcodec or wmv9. I couldn't find anything about a good decoder for this. It's Microsoft.

Directshowsource opens the file, but since I heard that it could be a little frame inaccurate, I ask you:

- "DirectShowSource() is not totally accurate"...? Is it true?
- Being it or not, what do you guys do (or would do...) when you was in that trouble? Any suggestions?

P.s.: I've got this message after I was manipulating some MKV vfr raw.

Thanks a lot.

Zycle · 2009-06-25, 15:37

SHiN-gx, try gradfun2db.

SHiN-gx · 2009-06-27, 11:56

Quote:

Originally Posted by Zycle

SHiN-gx, try gradfun2db.

Hot dang, this worked like a charm!

Thanks!

EDIT:

I'm kinda stuck here. I can't seem to get the desired output. I can't get the ending credits for Candy Boy episode 7 to scroll smoothly (source is DVD). I used two methods namely tritical's tdecimate and animeivtc() to make a VFR encode but none of them worked.

I know I'm doing this wrong but I don't know what I'm missing...

K!R4 · 2009-06-27, 19:01

I thought gradfun2db sole purpose is for post processing (during playback), not for preprocessing (encode) because this filter wont work unless you have a higher bitrate for your encode.

To see what Im talking about: encode your video with this filter then once its done play it on mediaplayer classic. While its playing, check ffdshow video decoder below your right taskbar (there are two of these: the red and blue icons) right click the red one, it will list some filters. you will see gradfun and it has check mark, heres a interesting part of this filter: turn off gradfun and you will see the real outcome of your encode. Either your encode will look shit (banding are back on your encode) or your encode will look good because you have higher bitrate you used in your encode to compensate.

Scab · 2009-06-28, 02:07

x264 can retain the grain pretty well thanks to AQ/psy-rd at very reasonable bitrates, but yes, gradfun was designed as a postprocessing filter. Unless CCCP has started using it by default hardly anyone has it activated on playback though, so it's really not such a ass backwards idea to apply it before encoding if you know how to retain the effect.

TheFluff · 2009-06-28, 20:08

Quote:

Originally Posted by SHiN-gx

Hot dang, this worked like a charm!

Thanks!

EDIT:

I'm kinda stuck here. I can't seem to get the desired output. I can't get the ending credits for Candy Boy episode 7 to scroll smoothly (source is DVD). I used two methods namely tritical's tdecimate and animeivtc() to make a VFR encode but none of them worked.

I know I'm doing this wrong but I don't know what I'm missing...

if they were anything like the credits in an earlier ep I looked at a while ago, it's one of those cases where you get to pick if you want to make the background or the credits jerky; there is no way to get both smooth

Yumi` · 2009-06-29, 20:27

Quote:

Originally Posted by TheFluff

if they were anything like the credits in an earlier ep I looked at a while ago, it's one of those cases where you get to pick if you want to make the background or the credits jerky; there is no way to get both smooth

Somebobber().p60to24p()
Might make the credits too blurry though.

TGBatman · 2009-07-04, 18:46

Hi there guys. I have a question, regarding cropping and stuff.

I've read once that it was OK to crop 8 pixels from X and -X always when using DVD sources, but I never really found why. I've been doing it since then supossing it was true, as I've read it from this topic I think.

I mean, I've my source at 720x480, without any black borders on the side, but somewhere I've read that the 8 pixels at the right/left were not used, so I always crop 8 pixels at x and 8 pixels at -x, and it ends being 704x480.

Is it true? If so, why?

Kazu-kun · 2009-07-04, 21:24

Quote:

Originally Posted by TGBatman

Hi there guys. I have a question, regarding cropping and stuff.

I've read once that it was OK to crop 8 pixels from X and -X always when using DVD sources, but I never really found why. I've been doing it since then supossing it was true, as I've read it from this topic I think.

I mean, I've my source at 720x480, without any black borders on the side, but somewhere I've read that the 8 pixels at the right/left were not used, so I always crop 8 pixels at x and 8 pixels at -x, and it ends being 704x480.

Is it true? If so, why?

No, it isn't. You only crop if the picture has black borders on the side. If it doesn't, then of course leaving the full 720x480 is the way to go.

The whole "8 pixels at the right/left are not used" thing only applies when they're not really used (aka, when the picture has black borders on the side).

To sum it up, some DVDs use 704 pixels (has black borders) and some use the full 720 pixels (doesn't have black borders). You can tell just by looking.

TGBatman · 2009-07-04, 22:10

Oh crap, what have I been doing until now

.

Thanks for the answer, I think I might have missread the whole think.

Scab · 2009-07-05, 06:48

You're not wrong, Kazu-kun is. You crop to 704x480 to get closer to the AR of 710.85x486, i.e. the real active picture size, while staying mod16. If you don't, your encodes will have a slight AR error. Alternatively, you could of course keep it 720x480 and AR-flag the stream accordingly to compensate, i.e. 8640/4739 if your source is 16/9 or 6480/4739 if your source is 4/3.

Read this.

Kazu-kun · 2009-07-05, 10:13

Quote:

Originally Posted by Scab

Alternatively, you could of course keep it 720x480 and AR-flag the stream accordingly to compensate, i.e. 8640/4739 if your source is 16/9 or 6480/4739 if your source is 4/3.

He didn't say anything about resizing so I assumed he was going to use AR flags to beging with. And it really makes no sense to crop if that the case.

TGBatman · 2009-07-05, 10:33

Wow, that's a really complete guide, but a bit hard to understand.

Well, yeah, I tend to use the AR flags in Matroska and try to avoid resizing when it's not needed, so I guess cropping at the sides when there's no blackbars at all is pointless.

But I didn't get the "8640/4739 if your source is 16/9 or 6480/4739 if your source is 4/3." part. Aren't those some BIG numbers there? I tend to check the AR error ratio with Yatta, 853/480 seems to be the one with less of it if I crop the black bars at the sides, and 872/480 seems to be the one with less AR error if I don't crop them (when not needed, of course). And that's supossing I don't have black bars in Y and -Y.

I better always check the AR error in Yatta from now on

.

Also, another question. If I have a 4:3 DVD NTSC source, what's the best idea? Not doing ANY resize in avisynth (only the needed cropping if any), setting the display size in Matroska as 640x480, or is a better idea to use 768x576, OR resizing at the desired resolution?

I've always done the third one (cropping and resizing, and that's to 640x480), but I'd like to know your opinion.

Thanks for the help guys.

Scab · 2009-07-05, 13:54

They are big to avoid decimals. If you don't do any cropping, they're correct.

Not resizing is always the best idea if possible; resizers are nothing but bad for quality. Upscaling just a few pixels has a negative effect on the full frame and downscaling obviously kills resolution. That goes for your 4:3 content as well. Ideally, just do a crop() to get rid of the edge padding and AR flag the stream accordingly. DAR can be confusing and requires recalculation based on how much you've cropped, so unless you absolutely want to flag it in the container, consider using --sar in the x264 command line instead. It flags the pixel aspect ratio of your clip which stays the same no matter how you've cropped it.

2009-05-02, 22:57	Link #364
edogawaconan Hi Fansubber Join Date: Aug 2006	how about telling us what's your avisynth plugins folder contents, and the .avs causing that error. __________________ >2014 >blog

2009-06-27, 19:01	Link #370
K!R4 Freelance Join Date: Apr 2009 Location: Mars	I thought gradfun2db sole purpose is for post processing (during playback), not for preprocessing (encode) because this filter wont work unless you have a higher bitrate for your encode. To see what Im talking about: encode your video with this filter then once its done play it on mediaplayer classic. While its playing, check ffdshow video decoder below your right taskbar (there are two of these: the red and blue icons) right click the red one, it will list some filters. you will see gradfun and it has check mark, heres a interesting part of this filter: turn off gradfun and you will see the real outcome of your encode. Either your encode will look shit (banding are back on your encode) or your encode will look good because you have higher bitrate you used in your encode to compensate. Last edited by K!R4; 2009-06-27 at 19:14.

2009-04-29, 12:27	Link #361
Meltingice Klipsch Join Date: Oct 2007 Location: Frontier	It is most likely a filter conflict/issue.

2009-04-29, 12:52	Link #362
That1GuyTim Moe~ Moe~ Kyun~ Fansubber Join Date: Jan 2008 Location: Allen, TX	But why would it happen with only 2 more frames left?

2009-05-07, 10:36	Link #365
That1GuyTim Moe~ Moe~ Kyun~ Fansubber Join Date: Jan 2008 Location: Allen, TX	Nevermind, I believe it was a problem with the raw I was using. I used a different raw with the same avs and same settings and it worked just fine.

2009-06-24, 23:10	Link #366
SHiN-gx Wanderers Fansubber Join Date: Sep 2007	I need some suggestions on how to remove this artifact (sorry, don't know what it's called.) I used FFT3D and fluxsmoothst() but it really didn't do much. Thanks in advanced.

2009-06-24, 23:24	Link #367
Akatsuker Forever Espada Fansubber Join Date: Oct 2007 Location: Conn	"AVISource: couldn't locate a decompressor for fourcc WVC1" My AvsP keeps telling me that, even when I configure my FFDShow codec to decode it, whatever, libavcodec or wmv9. I couldn't find anything about a good decoder for this. It's Microsoft. Directshowsource opens the file, but since I heard that it could be a little frame inaccurate, I ask you: - "DirectShowSource() is not totally accurate"...? Is it true? - Being it or not, what do you guys do (or would do...) when you was in that trouble? Any suggestions? P.s.: I've got this message after I was manipulating some MKV vfr raw. Thanks a lot.

2009-06-25, 15:37	Link #368
Zycle :3 Graphic Designer Join Date: Aug 2008 Location: GP, BW, GER Age: 32	SHiN-gx, try gradfun2db.

2009-06-28, 02:07	Link #371
Scab Saizen Fansubber Join Date: Jun 2004 Age: 39	x264 can retain the grain pretty well thanks to AQ/psy-rd at very reasonable bitrates, but yes, gradfun was designed as a postprocessing filter. Unless CCCP has started using it by default hardly anyone has it activated on playback though, so it's really not such a ass backwards idea to apply it before encoding if you know how to retain the effect.

2009-07-04, 18:46	Link #374
TGBatman Junior Member Join Date: Feb 2009	Hi there guys. I have a question, regarding cropping and stuff. I've read once that it was OK to crop 8 pixels from X and -X always when using DVD sources, but I never really found why. I've been doing it since then supossing it was true, as I've read it from this topic I think. I mean, I've my source at 720x480, without any black borders on the side, but somewhere I've read that the 8 pixels at the right/left were not used, so I always crop 8 pixels at x and 8 pixels at -x, and it ends being 704x480. Is it true? If so, why?

2009-07-04, 22:10	Link #376
TGBatman Junior Member Join Date: Feb 2009	Oh crap, what have I been doing until now . Thanks for the answer, I think I might have missread the whole think.

2009-07-05, 06:48	Link #377
Scab Saizen Fansubber Join Date: Jun 2004 Age: 39	You're not wrong, Kazu-kun is. You crop to 704x480 to get closer to the AR of 710.85x486, i.e. the real active picture size, while staying mod16. If you don't, your encodes will have a slight AR error. Alternatively, you could of course keep it 720x480 and AR-flag the stream accordingly to compensate, i.e. 8640/4739 if your source is 16/9 or 6480/4739 if your source is 4/3. Read this.

2009-07-05, 10:33	Link #379
TGBatman Junior Member Join Date: Feb 2009	Wow, that's a really complete guide, but a bit hard to understand. Well, yeah, I tend to use the AR flags in Matroska and try to avoid resizing when it's not needed, so I guess cropping at the sides when there's no blackbars at all is pointless. But I didn't get the "8640/4739 if your source is 16/9 or 6480/4739 if your source is 4/3." part. Aren't those some BIG numbers there? I tend to check the AR error ratio with Yatta, 853/480 seems to be the one with less of it if I crop the black bars at the sides, and 872/480 seems to be the one with less AR error if I don't crop them (when not needed, of course). And that's supossing I don't have black bars in Y and -Y. I better always check the AR error in Yatta from now on . Also, another question. If I have a 4:3 DVD NTSC source, what's the best idea? Not doing ANY resize in avisynth (only the needed cropping if any), setting the display size in Matroska as 640x480, or is a better idea to use 768x576, OR resizing at the desired resolution? I've always done the third one (cropping and resizing, and that's to 640x480), but I'd like to know your opinion. Thanks for the help guys.

2009-07-05, 13:54	Link #380
Scab Saizen Fansubber Join Date: Jun 2004 Age: 39	They are big to avoid decimals. If you don't do any cropping, they're correct. Not resizing is always the best idea if possible; resizers are nothing but bad for quality. Upscaling just a few pixels has a negative effect on the full frame and downscaling obviously kills resolution. That goes for your 4:3 content as well. Ideally, just do a crop() to get rid of the edge padding and AR flag the stream accordingly. DAR can be confusing and requires recalculation based on how much you've cropped, so unless you absolutely want to flag it in the container, consider using --sar in the x264 command line instead. It flags the pixel aspect ratio of your clip which stays the same no matter how you've cropped it.