Annoying Anime problem [Archive]

_DW_

25th February 2009, 05:18

First of all you should make sure, that the "problem" is not caused by your decoder or one of the filters (especially the deinterlacer).

If (and only if) the problem doesn't appear at this stage, you can assume the the encoder is introducing the problem...

I'm working my way through the filters right now. I'm not exactly sure the encoder is the problem. I'm more inclined to doubt it would be than anything at this point. I'm hoping some one will say "hey stupid, here's your problem."

If I can't isolate the problem in stax I'm going to hall it over to the penguin box and see if I get the same problem with mencoder. But that will be tomorrow night.

ChronoCross

25th February 2009, 05:33

Post your AVS.

_DW_

25th February 2009, 05:54

There are 2 avs files in the temp directory.

The first one is.

DirectShowSource("D:\DVD Tools\Girls Bravo\206 - Bravo at the Part Time Job!.mkv", audio=false, convertfps=true, fps=29.970)
LoadCplugin("C:\AppData\Local\StaxRip\Applications\Yadif\yadif.dll") Yadif()

and the second one is.

DirectShowSource("D:\DVD Tools\Girls Bravo\206 - Bravo at the Part Time Job!.mkv", audio=false, convertfps=true, fps=29.970)

AVS files are something I know next to nothing about.

lexor

25th February 2009, 17:00

if that user name is your actual name, you might want to edit it out... privacy and all that.

[P]ako

25th February 2009, 17:40

Why are you encoding from the MKVs? It should always be better to encode from the DVDs. Do the MKVs show stuttering as well?

ChronoCross

25th February 2009, 17:45

_DW_

25th February 2009, 18:48

ako;1254643']Why are you encoding from the MKVs? It should always be better to encode from the DVDs. Do the MKVs show stuttering as well?

The MKV's are where I parsed the episodes. The show I'm converting has all the episodes in a single VOB set. VTS_05_1-6, or something like that. I want each episode in a file to itself. So I rip the video, audio, and subtitle stream to separate files. Then using mkvmerge I cut each episode to a file using the splitting feature. What comes out is a file with video, audio, and subs all cut to the correct length.

Since I use mkvmerge for this they come out as mkv files. The streams in the mkv are the original feeds from the dvd's, just remuxed into mkv. No, the original mkv files are perfect. That is actually how I noticed the shudder when comparing the recodes to the originals.

_DW_

25th February 2009, 18:55

Either way the problem is more than likely related to the fact that he's converting from mkv (using DSS no less) . if it's anime there is a good chance that it is a VFR encode and that transforming it using a ConvertFPS is throwing the framerate off and then that bad information is being passed to yadif.

Encode it from the original DVD source and you'll be fine.

The source mkv's are from the original dvd source just remuxed into a mkv container because of the tools I use.

I never considered that the DSS could be the problem. I've used the mkv cut and recode hundreds of times and never had this issue.

I'll reexamine that part of the process too.

Atak_Snajpera

25th February 2009, 18:56

I'm almost sure that your source is 23.976 fps converted to NTSC format (interlaced 29.97)

You forgot to remove duplicated frames. After Yadif add TDecimate()

ChronoCross

25th February 2009, 20:33

The source mkv's are from the original dvd source just remuxed into a mkv container because of the tools I use.

I never considered that the DSS could be the problem. I've used the mkv cut and recode hundreds of times and never had this issue.

I'll reexamine that part of the process too.

So what your saying is you put MPEG2 into mkv? Then try to encode it? Could you explain a bit the process that you do prior to putting it into an mkv as well as why you would do this?

_DW_

25th February 2009, 20:59

So what your saying is you put MPEG2 into mkv? Then try to encode it? Could you explain a bit the process that you do prior to putting it into an mkv as well as why you would do this?

Yes, I demux the original VOBs and put the streams into mkv files. I only do this on DVD's that have all the episodes in a single VOB set because I want each episode in its own file.

What I do is I use dvd decrypter to pull the VOB set in to one VOB. It will contain the video and the audio. Then rip the subs using a separate tool, vsrip usually. Not only do I want the episodes in separate files I usually want the audio and subs in different order, Japanese first most of the time.

Then I feed it to mkvmerge, split the file into separate episodes while remuxing the streams in the order and priority I want them. Then I feed them to the encoder.

What I get on the other end is encoded files, with the streams in the order and correct subs with correct audio. Sometimes I'll have to fine tune with staxrips cutting tool and goose some audio and sub sync issues but those are rare.

They are shoved into mkv's because that is the tool I like. They could be done into avi's or back into vob's if I used a different tool. I just happen to use mkvmerge for this because its a command line tool.

Probably an easier way to do it but this works for me and I've gotten so good at it I can rip, cut, and mux a whole dvd in under 30 mins.

26th February 2009, 10:51

Then you are using yadif in the wrong mode. To double the framerate by bobbing, use Yadif(mode=1). This will require more bitrate to encode since the framerate is ~60 fps, but motion will be smoother if the source is really interlaced. Tomsmocomp also bobs, but yadif is a better filter.

[P]ako

26th February 2009, 15:09

The MKV's are where I parsed the episodes. The show I'm converting has all the episodes in a single VOB set. VTS_05_1-6, or something like that. I want each episode in a file to itself. So I rip the video, audio, and subtitle stream to separate files. Then using mkvmerge I cut each episode to a file using the splitting feature. What comes out is a file with video, audio, and subs all cut to the correct length.

Since I use mkvmerge for this they come out as mkv files. The streams in the mkv are the original feeds from the dvd's, just remuxed into mkv. No, the original mkv files are perfect. That is actually how I noticed the shudder when comparing the recodes to the originals.

I see, you are doing the mkv path because of the subs. You could just rip the vobs by chapter or chapters in IFO mode (thus extracting just the episodes).

JEEB

26th February 2009, 16:49

So, as I see... you're encoding an anime DVD to H.264, am I correct (with every episode having its own file)?

Now, not only is DirectShowSource something I wouldn't recommend (at least use DSS2 if you absolutely need DirectShow filters etc.), but I guess you didn't even try tfm with tdecimate on the given anime? Now, I haven't checked the source myself, but 9 times out of 10 you would have 24000/1001fps in 30000/1001fps telecined form, which should be inverse-telecined (tfm) and then decimated to drop off the interlaced unneeded frames (or, if you have every frame encoded progressive via telecine just leave it as-is). Of course if you have only a certain part you want to really deinterlace, you should just perform it on the one place where it's needed.

A good read: clicky (http://www.mod16.org/hurfdurf/?p=12)

Of course if you have a different reason on using tomsmocomp and other stuff I'll digress.

Also, for inputting MPEG-1/2 I'd probably use dgindex for cutting and taking out the audio stream (cut at the right places; granted the DVD has to be decrypted for this) -> load the saved d2v file into avisynth and get surely surely the right frames -> filter & profit.

DirectShowSource is well known for its problems, and at least DSS2 seems work better with MKV or so (also I wonder what ffmpegsource2 would give you with interlaced content, since at least the MKV container seems to work quite well with it).

Edit: Saw the comment that you don't know much about AVS scripting. This just shows how you basically can't believe that a close-to-one-click solution would do it all for you and well. Let me recommend AvsP (link (http://avisynth.org/qwerpoi/)) for script writing and preview, as well I'll leave a snippet here:

MPEG2Source("C:\JEEB\Video\Index\Index01_HD.d2v", cpu=0, info=3)
tfm(mode=1).tdecimate(mode=1)

this is the basic usage of d2v files with Avisynth, and with the basic modes set for tfm and tdecimate. Also, please read up on fluff's page on how to check what kind of source you are dealing with so that you will A) know more and B) get better results with your encodes.

_DW_

26th February 2009, 19:41

ako;1254969']I see, you are doing the mkv path because of the subs. You could just rip the vobs by chapter or chapters in IFO mode (thus extracting just the episodes).

I could, now. But when I just started the switch from hardsubs to softsubs I really didn't know that much about subs and the in's and out's. I pretty much just dumped everything into autoagk and cut everything up with Virtualdub. Since the subs where burned in there was nothing to mess with.

Once I started using vsrip I came up with the mkvmerge rip and cut option I'm using now. The system works pretty good so I never changed. Creature of habit.

_DW_

26th February 2009, 19:55

So, as I see... you're encoding an anime DVD to H.264, am I correct (with every episode having its own file)?

Yes, exactly.

Now, not only is DirectShowSource something I wouldn't recommend (at least use DSS2 if you absolutely need DirectShow filters etc.), but I guess you didn't even try tfm with tdecimate on the given anime?

I'm working in that direction right now. I know a pretty good bit about a lot of things but not much to nothing about DDS and Avisynthh.

Of course if you have a different reason on using tomsmocomp and other stuff I'll digress.

Tomsmocomp didn't really help after all. It smooth out the test clip I did but once I threw those settings at a couple of episodes and left them to brew over night the jerking was still there and even worse in other places.

Over all these are the trickiest I've tried to do. Most of the time I just you yidif or ivtc and the anime comes out perfect.

I'm going to have to sit down with some instructions and figure out avisynth and the rest of the process that goes on under staxrip. Right now I'm going to haul the videos over to linux and work on them with mencoder. I have more control over there and eliminate the stuff I have questions about.

_DW_

26th February 2009, 21:58

Now, not only is DirectShowSource something I wouldn't recommend (at least use DSS2 if you absolutely need DirectShow filters etc.),

Hang on Gov. What is DSS2?

LoRd_MuldeR

26th February 2009, 23:40

What is DSS2?

DirectShowSource2. It's included in Haali's Media Splitter. The file is called "avss.dll". I'm not aware of any documentation for it.

_DW_

28th February 2009, 17:21

For reference recoding everything using mencoder cleared up the problem. I've examined all the spots where the jerking was present and its gone. Here is the mencoder options that did the trick.

mencoder -v ${i} -ovc x264 -o ${i/mkv/mp4} -x264encopts pass=2:b_adapt:bitrate=1500:threads=0:bframes=4:subq=5:weight_b:psnr:partitions=4x4:8x8dct:frameref=8:me=umh:b_pyramid:trellis=2:subme=7 -vf yadif -oac copy

JEEB

28th February 2009, 17:48

Still I don't think yadif is the thing for anime :/ (since IIRC yadif was a pure interlacer, while with clearly most anime you need IVTC instead to get the full progressive frames of the telecined video - read the stuff I linked to you, it has all the theory needed for checking out different sources). Also read the Avisynth wiki (http://avisynth.org/mediawiki/Main_Page) on different commands and how to use them in Avisynth.

Also, it shows how much stable input matters. And I will once more say this: "With Avisynth IMHO only AVISource() [can be replaced with FFMpegSource()], MPEG2Source() (dgdecode_ version; works for MPEG-1 as well) and FFMpegSource() should be used in any given 'normal' scenario. (AVI is for AVI, MPEG2Source for MPEG-1/2 video and ffmpegsource for mp4/mkv/wmv input and most of all other stuff you might end up looking at)" DSS2 or, in the worst case scenario, DSS should only be used if nothing else works or if you want decode something out of MKV with your directshow filters (which usually is not what you wish for).

Additionally, mencoder should be alright as long as it's relatively new and if there's no VFR (http://avisynth.org/mediawiki/VFR#encoding_to_vfr_.28mkv.29) for which you would end up making timecodes for as well (also remember to IVTC instead of yadif'ing should the source be telecined). Also remember that the best way to output H.264 from mencoder is to output into a raw stream (.264) - mencoder IIRC has issues with its muxers and you'd be better off with using mkvmerge for the mux in any case, as you have far more options there as well.

_DW_

28th February 2009, 20:03

Still I don't think yadif is the thing for anime :/ (since IIRC yadif was a pure interlacer, while with clearly most anime you need IVTC instead to get the full progressive frames of the telecined video -

Well I'm about to find out. Now that I've fixed the original problem and this set is about done using yadif I'm going to feed it back through the encoder using the suggestions mentioned here. I'm pretty impressed with what yadif is spitting out. Stepping through the original and encoded, other than interlacing, I can't see any difference between the two.

JEEB

1st March 2009, 03:00

Let's just say overall - a) read the stuff on IVTC (yes, the links - need I repeat myself? Also Doom9 has a LOT of text about the basics in its tutorials section) and understand that yadif is just plain wrong if you have something that just needs to be IVTC'd right (most of NTSC anime), and b) you're just not noticing where yadif fails:

Comparison I did by just scrolling frames until I got to one that yadif failed at: yadif (http://img3.imageshack.us/img3/2564/yadifframe10897.png) - TFM (http://img3.imageshack.us/img3/5773/tfmframe10897.png) .

Edit: the crop was done after the filters were applied.

In a nutshell: Enjoy your fail, and have a nice day. I hope I could at least be a bit of assistance in making you want to reach out for those docs and read.

_DW_

1st March 2009, 07:37

In a nutshell: Enjoy your fail, and have a nice day. I hope I could at least be a bit of assistance in making you want to reach out for those docs and read.

You know, there comes a time when you really need to stop focusing on the little imperfections and just enjoy life. The difference between those two frames is not even worth worrying about. Nobody is going to notice that at 23, 24, 25 or 29 fps.

And really, this has nothing to do with the original problem. Neither yadif or ivtc made any difference in correcting the original twitching. It was in the DSS layer or in Avisynth, which means it was a flaw in the processing, not the filters applied.

One I moved to mencoder on a penguin box I eliminated those layers the results where perfect. An for the record I made two runs. One with ivtc and one with yadif. To my eyes there was no differences, but then again I didn't scroll through them frame by frame till I found them.

Shinigami-Sama

1st March 2009, 21:36

you'll notice its not fluid motion if you deinterlace something that needs to be IVTC'd

and if you can't - its time to see the eye doctor... might be a danger on the road

buba king

1st March 2009, 21:53

Did you use -vf pullup,softskip to IVTC? It usually does a perfect IVTC job. For pure interlaced material -vf yadif usually does the job but pure interlace NTSC is very unusual.

JEEB

1st March 2009, 22:45

You know, there comes a time when you really need to stop focusing on the little imperfections and just enjoy life. The difference between those two frames is not even worth worrying about. Nobody is going to notice that at 23, 24, 25 or 29 fps.
Ignorance is bliss it seems, and I didn't even have to scroll for long to find something like this. And it will look bad, esp. if played on full screen.

And really, this has nothing to do with the original problem. Neither yadif or ivtc made any difference in correcting the original twitching. It was in the DSS layer or in Avisynth, which means it was a flaw in the processing, not the filters applied.
Only partially true, the fact that I'm trying to give you advice on handling material the right way (checking per-field as in TheFluff's text really helps you understand what's that stuff you're dealing with, which then helps you do better decisions on your sources).

Also, yes - the DSS was the reason for abrupt frame etc. what you had. Although this is because DSS bases onto DirectShow and therefore can't be sure it even gets the right frames through. Its problems are clearly known and should you have used the usual d2v route you would've had no problems, I guess (mpeg2source gets used etc.). Automatic encoding software usually just backs off to directshow when the file you're trying to open is not of the AVI/D2V range (I wonder why meGUI still isn't using ffms2 :/ ).

And let's point this out once more, Avisynth would've been able to deal with the source very nicely should the right filter have been used (mpeg2source / ffmpegsouce for vob(d2v)/mkv).

One I moved to mencoder on a penguin box I eliminated those layers the results where perfect. An for the record I made two runs. One with ivtc and one with yadif. To my eyes there was no differences, but then again I didn't scroll through them frame by frame till I found them.
Basically, yes - and mplayer/mencoder is good as such. Just remember to output to raw H.264 stream instead of MKV/MP4/AVI (because almost everything except for AVI seems to be a bit broken there, at least more than if you remux after getting the stream done). Especially since you're doing that vob->mkv thing, so you can just re-mux the audio via mkvmerge.

As for "little imperfections" - there's one rule: Why do it the worse way when you can do it better? In any case the encoding will take time, so checking the source and selecting the best possible filter isn't really going to take that much of time and you'd know that you've made the "best" selection you could've for the given source. I'm not going to go into post-processing, since that's another topic - but having some thought on what you're doing is usually a good idea ;) . Also, with Avisynth you can easily preview your output (that will be given to x264) and check if you have problems. Someone on #mplayer said that mplayer would have a same kind of function, but I've still to look into it. That would make doing preview checking much easier on *nix native stuff as well.

Anyways, you've even got some more help on this thread for the mencoder part, so have fun and, most importantly, keep on trying your best with encoding.

_DW_

2nd March 2009, 00:26

you'll notice its not fluid motion if you deinterlace something that needs to be IVTC'd

and if you can't - its time to see the eye doctor... might be a danger on the road

Yes it will, and I'll redo it if I need too. But still, it doesn't matter if the source is IVTC, or interlaced, or needs a goat sacrificed to it in this case. Interlacing had nothing to do with the problem.

Jeez people.

_DW_

2nd March 2009, 00:29

Did you use -vf pullup,softskip to IVTC? It usually does a perfect IVTC job. For pure interlaced material -vf yadif usually does the job but pure interlace NTSC is very unusual.

Thank you for some useful advice. I'll run some of the original sources through and see what kind of difference that makes.

_DW_

2nd March 2009, 00:48

Ignorance is bliss it seems, and I didn't even have to scroll for long to find something like this. And it will look bad, esp. if played on full screen.

I'm not ignorant of deinterlacing issues. I've actually been doing this for several years. I've ran the video's that I made on a 52" screen. If there was going to be an issue I would have seen it and went back to correct it. You are assuming that this is my first goat .....

Only partially true, the fact that I'm trying to give you advice on handling material the right way (checking per-field as in TheFluff's text really helps you understand what's that stuff you're dealing with, which then helps you do better decisions on your sources).

An I appreciate it and the guide was very interesting but I was not dealing with a deinterlacing issue. I also was not going to allow myself to be distracted with another issue. Now that I've cleared up what cased the original problem I can look at better methods to do things.

Especially since you're doing that vob->mkv thing, so you can just re-mux the audio via mkvmerge.

Not doing that anymore, at least not for encoding. The process is flawed. I'm pulling out the dozen or so series that I did using it and planing to redo them. Now I'm just going to use the preview/cutting feature on staxrip instead. Since that doesn't do very good with subs I'll still use the process to cut and mux the subs. I really hate working with subs.

Anyway. I think you overreacted but not going to worry about it. Hard to get upset at a MegaTokyo fan.

JEEB

2nd March 2009, 01:33

Ok, I overreacted, but mainly because the first contact I had with you was bashing the CCCP pack, which showed that either you had flawed information or were completely ignorant to the fact that people are trying to make a good directshow playback pack that doesn't break anything and has sane defaults.

Also, yes - I assumed this was your first goat since you seemed at least somewhat clueless about Avisynth, ways of deinterlacing/IVTC at all, and other things that relate.

The reason for me jumping at the problems with the way I did was because only two things were wrong in your original script: DSS() usage and yadif, which is an interlacing plugin (although can also match fields when needed IIRC, which looked actually pretty good until it failed on that given source I tested it with - of course without checking for those frames that should be decimated and would end up looking worse in any case; additionally I checked on #mplayer whether or not that given filter should be used for such content, and got an answer that it's just a quick deinterlacer made for deinterlacing-while-playing back content). As the problem itself was quite simple (DSS() usage) and went away during the thread, I of course began adding pressure on the fact that things should be filtered the "right" way. As an additional comment, it is very rare and probably even impossible for x264 to actually break something like that, so that's the reason there was no need for extra checkups.

Also, nice to hear that you are going towards the more-or-less default ways of doing things. I'm not sure if the preview/cutter of staxrip is just a frontend for the dgindex application, but I guess the subs issue could be fixed with using dgindex itself instead of any extra play with mkvmerge etc. Frontends aren't bad for making encode queues, but unfortunately they usually aren't the best thing to leave the Avisynth script generation or input preparation to.

Also, I'd like to see how your ripping process goes and maybe comment on it, if possible. #avisynth on the Freenode IRC server is usually a good place to ask questions about it, and I'm one of the people who frequents there.

Anyways, enough of tl;dr for this thread :3 .

2nd March 2009, 01:55

I'm not ignorant of deinterlacing issues. I've actually been doing this for several years. I've ran the video's that I made on a 52" screen. If there was going to be an issue I would have seen it and went back to correct it. You are assuming that this is my first goat .....
The reason for our concern is that most NTSC anime releases are telecined, so we are a bit doubtful whether your source really is completely interlaced (a sample clip from the source video might convince me).

If you only check the type of the source by watching a deinterlaced and IVTC'd sample and look for differences in motion fluidity, you might not spot the difference if your display refresh rate is not a multiple of the video framerate. For example, if the monitor/TV refresh rate is 60 Hz and your source is telecined progressive film, both the 30 fps deinterlaced video and the 24 fps IVTC'd version will look similar in motion. However, if the refresh rate is dropped to 48 Hz or raised to 72 Hz, the 24 fps video will play smoother than the deinterlaced output at 60 Hz. That's one of the reasons why looking at consecutive still frames from the source video and recognizing the pattern is a better way.

Don't shoot the messenger. We're just trying to help and make sure that you don't lose video quality, time and disk space by deinterlacing and encoding a telecined source at 30 fps instead of recovering the original 24 fps video and encoding that.

_DW_

2nd March 2009, 02:45

Ok, I overreacted, but mainly because the first contact I had with you was bashing the CCCP pack,

Ahh yes, I had completely forgotten all about that. You are correct, I spoke in ignorance there. I was thinking of some hacker codecs that I had gotten a hold of a while back. Totally screwed my system up.

Also, yes - I assumed this was your first goat since you seemed at least somewhat clueless about Avisynth, ways of deinterlacing/IVTC at all, and other things that relate.

I'm not somewhat clueless about avisynth. I'm totally clueless.:cool: I've been concentrating on mastering x264, besweet, and mkv's right now. I actually know a pretty good bit about deinterlacing. Most of everything I've been doing is simply examining things with DGIndex and mpc and throwing whatever seems to fit at it. Most of the time ivtc is the way to go. In this case I don't think it was.

Of course I could be wrong.

Also, I'd like to see how your ripping process goes and maybe comment on it, if possible. #avisynth on the Freenode IRC server is usually a good place to ask questions about it, and I'm one of the people who frequents there.

I'm off in a different direction now but in defense the vob->mkv process worked really well in most cases. I'm thinking of putting together a simple guide, submitting it, and getting some feedback on it.

Anyways, enough of tl;dr for this thread :3 .

Agreed. The original problem has been fixed but not solved. Once I get some more knowledge about avisynth and dss I'm going to revisit the issue and see what the problem really was.

_DW_

2nd March 2009, 03:00

The reason for our concern is that most NTSC anime releases are telecined, so we are a bit doubtful

Don't shoot the messenger. We're just trying to help and make sure that you don't lose video quality, time and disk space by deinterlacing and encoding a telecined source at 30 fps instead of recovering the original 24 fps video and encoding that.

I understand and a lot of what was said was useful information but really had nothing to do with the issue at hand. Well at least the ivtc vs yadif issues. But it was enough to make me rethink the usefulness of yadif.

I kind of felt like I was getting bitched at for no reason. But anyway, I'm hoping any ruffled feathers have been smoothed.

neuron2

2nd March 2009, 03:26

All this silliness could be avoided if you would post an unprocessed sample of your source.

_DW_

2nd March 2009, 04:30

All this silliness could be avoided if you would post an unprocessed sample of your source.

Actually I doubt it would have because the "silliness" has nothing to do with the problem. It wasn't a filter problem, it was a problem with the process I was using. Once I removed the Dss and avisynth level the problem went away. Applying ether the ivtc or the yadif, which I did; neither fixed the problem. Only by changing from staxrip to mencode and removing the dss layer did the problem go away.

ChronoCross

2nd March 2009, 07:31

_DW_

2nd March 2009, 14:59

Your method is still quite silly and un-necessary.

Really? I suppose you've tried it and have some constructive feedback. Please enlighten.

me7

2nd March 2009, 15:35

Short: you deinterlace a video that is not interleaced in the first place

Long: let's imagine we were talking about numbers
original video is: 1 2 3 4 5
NTSC DVD version is: 1 1 1 2 2 3 3 3 4 4 5 5 5
IVTC would reconstruct the original video: 1 2 3 4 5
yadif blurs the video into something like: 1 1,5 2,5 3 4 4,5 5 (I know this is not the real algorothm :) )

Dou you understand the problem?

EDIT: this has nothing to do with DirectShow or FFVideoSource, you originally had TWO problems, a bigger one (DirectShow) that has been fixed and this smaller one that still remains

_DW_

2nd March 2009, 16:28

Short: you deinterlace a video that is not interleaced in the first place

Long: let's imagine we were talking about numbers
original video is: 1 2 3 4 5
NTSC DVD version is: 1 1 1 2 2 3 3 3 4 4 5 5 5
IVTC would reconstruct the original video: 1 2 3 4 5
yadif blurs the video into something like: 1 1,5 2,5 3 4 4,5 5 (I know this is not the real algorothm :) )

Not entirely correct. There are some parts of the video that are progressive but there are some that is interlaced. The ideal way would have been to cut out those sections and deinterlaced/ivtc them and paste them back in.

Yadif might not have been the best solution but it worked pretty well in this case.

If I delete the first post in this thread will it delete the whole thread? I think any conversation on subject would be pointless.

2nd March 2009, 17:32

Not entirely correct. There are some parts of the video that are progressive but there are some that is interlaced. The ideal way would have been to cut out those sections and deinterlaced/ivtc them and paste them back in.
Most of the good IVTC algorithms and scripts deinterlace automatically when they encounter interlaced sequences. This results in variable framerate (VFR) video that may require special care when muxing, depending on the tools used.

ChronoCross

2nd March 2009, 17:49

Really? I suppose you've tried it and have some constructive feedback. Please enlighten.

Yeah mashing them together into a single file and then attempting to encode them using FFMPEG rather than just producing the individual parts (using AVISynth) and then muxing them at the end is a bad thing and is more than likely dropping the quality from what it could be. Anime is one of them things where you really can't cheap out on the encoding method because more often than not you will end up with so many problems that make it unwatchable. We could probably give you additional hints if you could give us a useable source file.

_DW_

2nd March 2009, 18:03

Most of the good IVTC algorithms and scripts deinterlace automatically when they encounter interlaced sequences. This results in variable framerate (VFR) video that may require special care when muxing, depending on the tools used.

So are you saying that yadif is not a good deinterlacer for something like this? I have no problem abandoning it like a cheap hooker on prom night. I'm currently thinking to go back an examine the Girls Bravo encodes and run them through ivtc with the same parameters in mencoder. Got any recommendations on a "filter chain" to try or should this be enough?

-x264encopts pass=2:b_adapt:bitrate=1500:threads=0:bframes=4:subq=5:weight_b:psnr:partitions=4x4:8x8dct:frameref=8:me=umh:b_pyramid:trellis=2:subme=7 -vf ivtc

2nd March 2009, 18:35

So are you saying that yadif is not a good deinterlacer for something like this?
Yadif is decent as a deinterlacer, but I don't think MEncoder can currently handle hybrid progressive+interlaced sources and produce VFR output automatically. The HTML documentation (http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-telecine.html) only suggests IVTC by pullup or filmdint filters if the video is mostly progressive, or deinterlacing if the smoothness of the interlaced parts is more important. That's pretty much what you have been doing previously.

AviSynth is the way to go if you want to handle hybrid sources properly. JEEB and other AviSynth users will probably give more specific advice on what filters to use and how. However, these things have been discussed many times over, so just fire up Google or use the forum search :)

_DW_

2nd March 2009, 19:28

Yadif is decent as a deinterlacer, but I don't think MEncoder can currently handle hybrid progressive+interlaced sources and produce

It never even dawned on me that mencoder might have problems with hybrid sources.

AviSynth is the way to go if you want to handle hybrid sources properly.

Looks like that is going to be the way to go then.

_DW_

2nd March 2009, 19:42

Yeah mashing them together into a single file and then attempting to encode them using FFMPEG rather than just producing the individual parts (using AVISynth) and then muxing them at the end is a bad thing and is more than likely dropping the quality from what it could be.

Where did ffmpeg come into this at? Anyway you must have missed the post where I agree'ed with all this and abandoned that part of the process. Until I understand more about Avisynth I'm going to use the cutting feature in staxrip. Unless I'm dead wrong on this I think it uses avisynth for the cutting part.

But on the other hand this process was "invented" for subtitle processing and not anime encoding. Instead of muxing the video and audio in with them just cut them out. That way if you have a vob set of 4 shows you will have 4 mkv with nothing but subtitles in them.

Once your done with the encoding you just mux the subs in the with the video and audio and everything should line up. Or at least that is the theory.

We could probably give you additional hints if you could give us a useable source file.

Very well. How about the original section where I first noticed the original jerking problem? How do I post that? Just a url to file link somewhere?

_DW_

2nd March 2009, 19:53

I am an idiot.

I just noticed that I can do all the cutting that I need to do from dvddecrypter right on the same ifo page where I pull the show off in one big vob. I can pull them off by chapters and totally skip the cutting and hacking and mashing it all up.

I've been using this tool for years and never even though of that. It's been sitting right in front of me all the time. I even believe that was pointed out to me a few posts back.

neuron2

2nd March 2009, 22:06

How about the original section where I first noticed the original jerking problem? Yes, perfect.

How do I post that? Just a url to file link somewhere? Try this:

http://www.mediafire.com/

ChronoCross

3rd March 2009, 01:30

Where did ffmpeg come into this at? Anyway you must have missed the post where I agree'ed with all this and abandoned that part of the process. Until I understand more about Avisynth I'm going to use the cutting feature in staxrip. Unless I'm dead wrong on this I think it uses avisynth for the cutting part.

okay mencoder, they all use the same libraries.

But on the other hand this process was "invented" for subtitle processing and not anime encoding. Instead of muxing the video and audio in with them just cut them out. That way if you have a vob set of 4 shows you will have 4 mkv with nothing but subtitles in them.

Once your done with the encoding you just mux the subs in the with the video and audio and everything should line up. Or at least that is the theory.

I am an idiot.

I just noticed that I can do all the cutting that I need to do from dvddecrypter right on the same ifo page where I pull the show off in one big vob. I can pull them off by chapters and totally skip the cutting and hacking and mashing it all up.

I've been using this tool for years and never even though of that. It's been sitting right in front of me all the time. I even believe that was pointed out to me a few posts back.

Congrats........pretty much everyone in this thread was wondering why you weren't using this feature.

Comatose

3rd March 2009, 12:32

Actually I doubt it would have because the "silliness" has nothing to do with the problem. It wasn't a filter problem, it was a problem with the process I was using. Once I removed the Dss and avisynth level the problem went away. Applying ether the ivtc or the yadif, which I did; neither fixed the problem. Only by changing from staxrip to mencode and removing the dss layer did the problem go away.
You were causing the problem, not Avisynth or DSS. You told DSS to convert the framerate while the video was still interlaced, which is a very very bad idea...

If you had done it properly (which probably means doing IVTC, in this case) then it would be smooth.
It was only because of your actions, not the tools you were using.

I was shocked to see nobody mentioned IVTC until deep into the first page...

neuron2

9th March 2009, 04:13

Why are you giving us an MKV when we asked for a sample of the original source, which you claimed was a DVD?

Use DGSPlit or equivalent to cut a fragment of the VOB and upload that.

_DW_

9th March 2009, 05:19

No, that was a 18 mb file itself. It took 45 mins to upload that. I'm calling a halt to this. The mkv file contains the original streams, it will have to do. If not, then oh well.

I'm happy with the results I got weeks ago. I'm currently doing all my encoding using mencoder and piping it to x264. Once I figure out more about avisynth then I might revisit this problem. But for now I'm moving on.

http://www.mediafire.com/download.php?tfmznmtdmkm

JEEB

9th March 2009, 05:30

neuron2: As _DW_ said that .mkv was the way he was ripping data off DVDs it seems... it contained telecined MPEG-2 and AC3 from a (probable) R1 release it seems. So only the format can feel weird :)

_DW_: This is, as so many said, a telecined stream that has to be decimated, too (checked by fields, also it has that dupe there in cycles of four frames+dupe). So it is 24000/1001fps. And somewhat noisy, so filtering that out could be a good idea.

To IVTC:
MPEG2Source("girls bravo_Track1.d2v", cpu=0)
tfm(mode=1).tdecimate(mode=1)
crop(2,2,-2,0)
spline36resize(720,480)

As for filtering, that thing's noisiness is pretty bad at places, dfttest didn't really work alone, neither did FFT3d (well seen around frame 342 or so when the window is on-screen). Pretty much only the motion compensated dfttest -> MVDegrain2 -filter chain I originally got from Avisynth.org wiki and then edited it did something to it :/ (oh jolly gosh how good framerates I get from that). Of course extra grain can be added at such places, but IMHO that still isn't the best solution.

edit: actually raising the cpu=x had a pretty good effect on parts of it, but it would probably create "fake blurryness"- like effect there, which I don't really like... Also awarpsharp might do something here, but it's a filter that is usually considered to be something that one shouldn't use.