Deinterlacing on Cartoons

[Hello]

I have been ripping several Aqua Teen Hunger Force and Family Guy episodes to m4vs and I am using fast deinterlacing, but it does not seem to get rid of much of the interlacing in the videos, but using anything higher than fast deinterlacing creates a small band of colors a few pixels wide at the bottom of the video. Does anyone know a way around this or a reason that this keeps happening?

[cxb456]

For some odd reason, Family Guy appears to be a telecined DVD. The two big projects that I've used Handbrake for have been archiving all of my Family Guy and Futurama DVDs. For Futurama I needed neither deinterlacing nor detelecining. Whereas with Family Guy, I noticed an immediate difference when I activated detelecining.

Hope that helps.

[jbrjake]

Futurama certainly needs detelecining, it's one of the reasons for VFR.

ATHF uses different methods on different episodes, especially in season 1.

[echohead]

i have had nothing but problems trying to encode cartoons with handbrake...for me the telecining effects are most apparent during periods of fast motion (chase scenes, "cameras" panning over, characters walking around, and even talking). enabling VFR always puts audio out of sync, and im not enough of a videophile to know how to fix this. i dont think ive had a single animated show/movie NOT show telecining, regardless of the settings i use.

[nightstrm]

i have had nothing but problems trying to encode cartoons with handbrake...for me the telecining effects are most apparent during periods of fast motion (chase scenes, "cameras" panning over, characters walking around, and even talking). enabling VFR always puts audio out of sync, and im not enough of a videophile to know how to fix this. i dont think ive had a single animated show/movie NOT show telecining, regardless of the settings i use.

Really? I haven't had this issue with VFR since testing the pre-.9.2 code. Are you still using .9.1?

[echohead]

i grabbed 0.9.2 the day it was released to the public. as far as VFR goes, it does nothing in terms of fixing telecining...encoding w/o VFR results in the cartoon/animation exhibiting telecining. encoding with VFR results in a telecined cartoon with audio out of sync from the video.

ill do a re-encode of "Family Guy: Blue Harvest" tonight, just to be sure: animation preset, audio changed to 192kbps vorbis stereo, chapter markers removed, loose anamorphic, VFR enabled, mkv container. will reply to this thread with results.

[jbrjake]

ill do a re-encode of "Family Guy: Blue Harvest" tonight, just to be sure: animation preset, audio changed to 192kbps vorbis stereo, chapter markers removed, loose anamorphic, VFR enabled, mkv container. will reply to this thread with results.

The animation preset uses deinterlacing. This is because I wasn't ready to make VFR part of presets. When you run VFR on top of the animation preset, it runs VFR *after* deinterlacing the picture. This is not what you want to happen. Run VFR on its own. Not with the animation preset.

[echohead]

The animation preset uses deinterlacing. This is because I wasn't ready to make VFR part of presets. When you run VFR on top of the animation preset, it runs VFR *after* deinterlacing the picture. This is not what you want to happen. Run VFR on its own. Not with the animation preset.

would it be better to use the film preset with VFR, and just lower the video bitrate to 1000, as in the animation preset?

[jbrjake]

would it be better to use the film preset with VFR, and just lower the video bitrate to 1000, as in the animation preset?

Should be fine. Hell, for testing this you could use Normal or Classic. Just don't use a preset that has deinterlacing on, or grab the animation preset's CLI equivalent and just cut out the deinterlacing bit.

The animation preset just uses more b-frames and ref frames and stronger in-loop deblocking.

[Hello]

Wait so let me get this straight. So variable frame rate helps with cartoons and you need detelecining and not deinterlacing for Family Guy?

[Hello]

You guys were right, Family Guy was not interlaced, it needed detelecining. The deinterlacing was just making the video look worse, and when I used VFR, the video came out perfectly. I haven't tried any ATHF episodes yet, but I usually used Videora for those as they are short and don't even have chapters. I didn't seem to have any problems with the sound being unsynchronized with VFR, but I'll test a few more episodes to check.

[echohead]

okay so heres what i did for my encode:

Code: Select all

 -i "D:\VIDEO_TS" -o "C:\famguy.mkv" -e x264 -E vorbis --detelecine -V  -P  -b 1000 -2  -T  -x ref=5:mixed-refs:bframes=6:bime:weightb:b-rdo:direct=auto:b-pyramid:me=umh:subme=5:analyse=all:8x8dct:trellis=1:no-fast-pskip -B 192 -R 48 -D 1 -6 stereo -v 

basically i used a mash-up of the film and animation presets, along with a few settings i prefer: changed the audio to 192kbps sch vorbis, disabled chapter markers, lowered the video bitrate to 1000, enabled VFR (obviously), ref=5, subme=5, and output the file as a mkv. when handbrake was done, i re-muxed the mkv in mkvtoolnix and added the commandline parameter

Code: Select all

--engage keep_bitstream_ar_info

to keep the aspect ratio...




results: the picture quality is amazing, and the interlacing/telecining is finally gone! BUT the audio is out of sync. its the most apparent where VFR deleted frames(?), and its never by more than .5 seconds, but its enough that its noticeable. is the audio syncing problem just inherent with handbrake and what im trying to do, or is there a way around this?

[nightstrm]

I haven't had any audio sync issues with my Family Guy and Futurama encodes, but they were MP4/AAC. I haven't done much with either MKV or vorbis...

I think the devs are aware of some issues with VFR and PAL sources...

[jbrjake]

results: the picture quality is amazing, and the interlacing/telecining is finally gone! BUT the audio is out of sync. its the most apparent where VFR deleted frames(?), and its never by more than .5 seconds, but its enough that its noticeable. is the audio syncing problem just inherent with handbrake and what im trying to do, or is there a way around this?

It has nothing to do with VFR. It's an issue with b-frames and libmkv.

[echohead]

okay last question...if i re-encode under the same settings, except use ogm as the container, is there a different bframe value i can specify in the CLI that will fix/minimize the audio syncing problem?

[jbrjake]

okay last question...if i re-encode under the same settings, except use ogm as the container, is there a different bframe value i can specify in the CLI that will fix/minimize the audio syncing problem?

I don't use ogm and have never tested with it and I don't think it supports frame reordering for h.264 (nor do I think it's even a possible codec choice for the container in HB) so b-frames would still fail.

The clearest choices are using MP4 or turning off b-frames.

[echohead]

SOLVED!

the telecining/deinterlacing issue is NOT related to libmkv; it is caused by b-frames. By removing all b-frame related arguments from the advanced h.264 options, telecining is completely gone. heres what i had under advanced h.264 options:

Code: Select all

ref=5:mixed-refs:bime:direct=auto:me=umh:subme=5:analyse=all:8x8dct:trellis=1:no-fast-pskip

and heres the complete command line query:

Code: Select all

 -i "D:\VIDEO_TS" -o "C:\famguy.mkv" -e x264 -E vorbis --detelecine -V  -P  -b 1200 -2  -T  -x ref=5:mixed-refs:bime:direct=auto:me=umh:subme=5:analyse=all:8x8dct:trellis=1:no-fast-pskip -B 192 -R 48 -D 1 -6 stereo -v 

i increased the bitrate from 1000 (the animation default) to 1200, to compensate for the lack of b-frames. this increased the final filesize from 347MB to 436MB. when the encode was done, i just had to re-mux it in mkvtoolnix with the additional argument:

Code: Select all

--engage keep_bitstream_ar_info

alternatively, the mp4 container can be used instead of mkv. i just happen to prefer the superior quality and smaller file size of vorbis audio, which mp4 does not support.

[nightstrm]

Isn't that exactly what jbrjake said three posts above yours? If you are using mkv, don't use b-frames. Also, how does using vorbis give you smaller file sizes than using AAC?

[Hello]

alternatively, the mp4 container can be used instead of mkv. i just happen to prefer the superior quality and smaller file size of vorbis audio, which mp4 does not support.

Yeah i don't know much about vorbis/ogg but i'm pretty sure aac audio comes fairly close or even surpasses vorbis audio in bitrate to quality comparison. IMO, aac is a much, much better audio codec than ogg, not only because it is supported by far more programs (and especially iTunes), and even though it's licensing is not technically free, there are numerous ways to encode to aac without cost. Furthermore, aac is intended to be the successor to the highly popular mp3 format, so it inevitably is the future, so it would be better to start now, i say. Sorry, i didn't mean to attack you or anything, i was just offering my opinion, and trying to defend one of my good friends: aac.

[nightstrm]

alternatively, the mp4 container can be used instead of mkv. i just happen to prefer the superior quality and smaller file size of vorbis audio, which mp4 does not support.

Yeah i don't know much about vorbis/ogg but i'm pretty sure aac audio comes fairly close or even surpasses vorbis audio in bitrate to quality comparison. IMO, acc is a much, much better audio codec than ogg, not only because it is supported by far more programs (and especially iTunes), and even though it's licensing is not technically free, there are numerous ways to encode to acc without cost. Furthermore, acc is intended to be the successor to the highly popular mp3 format, so it inevitably is the future, so it would be better to start now, i say. Sorry, i didn't mean to attack you or anything, i was just offering my opinion, and trying to defend on of my good friends: acc.

AAC = Advanced Audio Codec
ACC = Atlantic Coast Conference

Someone still have NCAA basketball on the brain?

[Hello]

Oops! I was watching a bit of the final four i must say. I wrote aac at the beginning but then for some reason i kept writing acc. basketball will do that to you

[echohead]

Isn't that exactly what jbrjake said three posts above yours? If you are using mkv, don't use b-frames.

no, he said the problem was with b-frames OR with libmkv. but since i also did a test encode with b-frames under the mp4 container, i can prove that libmkv has nothing to do with the telecining problem.

i'm pretty sure aac audio comes fairly close or even surpasses vorbis audio in bitrate to quality comparison...aac is intended to be the successor to the highly popular mp3 format, so it inevitably is the future, so it would be better to start now

-MP3 beats AAC for audio quality, at bitrates above 160
-Vorbis beats AAC and MP3 in terms if audio quality AND filesize, at bitrates above 160
-the only "real" difference between MP3 and AAC, other than the DRM, is that AAC is only the better codec at bitrates of 160 and BELOW
-AAC is the only audio format that handbrake doesnt support at bitrates above 160. so if audio quality is important to you, AAC is actually the worst audio format to use
-MP3 may not be "superior" in to AAC in terms of filesize, but Apple's about-face from an AAC-only DRM audio store to providing DRM-free MP3's at 256 kbps seems to indicate that the market wants AAC audio to die.

[realityking]

-MP3 beats AAC for audio quality, at bitrates above 160
-Vorbis beats AAC and MP3 in terms if audio quality AND filesize, at bitrates above 160
-the only "real" difference between MP3 and AAC, other than the DRM, is that AAC is only the better codec at bitrates of 160 and BELOW
-AAC is the only audio format that handbrake doesnt support at bitrates above 160. so if audio quality is important to you, AAC is actually the worst audio format to use
-MP3 may not be "superior" in to AAC in terms of filesize, but Apple's about-face from an AAC-only DRM audio store to providing DRM-free MP3's at 256 kbps seems to indicate that the market wants AAC audio to die.

Filesize is determined by the codec, only by bitrate, you second sentence is non sense.
Also the iTunes Store doesn't provide any MP3s, they only provide DRMed 128 kbps AACs and DRM free 256 kbps AACs.

[nightstrm]

Isn't that exactly what jbrjake said three posts above yours? If you are using mkv, don't use b-frames.

no, he said the problem was with b-frames OR with libmkv. but since i also did a test encode with b-frames under the mp4 container, i can prove that libmkv has nothing to do with the telecining problem.

i'm pretty sure aac audio comes fairly close or even surpasses vorbis audio in bitrate to quality comparison...aac is intended to be the successor to the highly popular mp3 format, so it inevitably is the future, so it would be better to start now

-MP3 beats AAC for audio quality, at bitrates above 160
-Vorbis beats AAC and MP3 in terms if audio quality AND filesize, at bitrates above 160
-the only "real" difference between MP3 and AAC, other than the DRM, is that AAC is only the better codec at bitrates of 160 and BELOW
-AAC is the only audio format that handbrake doesnt support at bitrates above 160. so if audio quality is important to you, AAC is actually the worst audio format to use
-MP3 may not be "superior" in to AAC in terms of filesize, but Apple's about-face from an AAC-only DRM audio store to providing DRM-free MP3's at 256 kbps seems to indicate that the market wants AAC audio to die.

Based on your posts above, you encoded a mkv file without b-frames and it worked... that is exactly what jbrjake said. He said to use the MP4 container if you wanted to use b-frames.

As for your other points:

1. Apple's DRM-free tracks are AAC @ 256kbps. The only people who want AAC to die are people who are too cheap to buy a AAC-compatible player, and company's who are too cheap to build AAC playback into their devices.
2. The size of a 160kbps AAC, 160kbps MP3, and 160kbps vorbis file will be roughly the same. Size = bitrate * length (in seconds). Vorbis cannot defy how a bit is defined.
3. Your MP3 is better than AAC at higher quality is highly subjective, and I have never seen a single study to suggest that. Maybe a badly-encoded AAC file vs. a properly encoded LAME MP3 or something.
4. You seem to think that Apple has some controlling interest in the AAC codec. The do not; they have only adopted it for their iTunes platform. AAC has pretty much universal support as the "next-generation" digital audio format.
5. Handbrake only supports AAC to 160kbps (~80kbps per channel) because that is all the FAAC allows. Higher bitrates are not always necessary; for example, a stereo AC3 file is typically encoded at 192kbps (~96kbps/channel). As you have said, AAC really shines at lower bitrates.

[echohead]

Based on your posts above, you encoded a mkv file without b-frames and it worked... that is exactly what jbrjake said. He said to use the MP4 container if you wanted to use b-frames.

you missed the part where i said i did a test encode using b-frames with mp4 as the container. with these settings, telecining still shows up. this is why i said b-frames are the source of the telecining problem and that the container format chosen had nothing to do with the problem in the first place.

i will repeat this one more time: as long as you re-mux the finished handbrake encode in mkvtoolnix, THERE IS NOTHING WRONG WITH USING MKV AS THE CONTAINER FORMAT

The only people who want AAC to die are people who are too cheap to buy a AAC-compatible player, and company's who are too cheap to build AAC playback into their devices.

i guess thats true...as long as you dont count public opinion, the vast majority of the consumer market, and almost the entire recording industry:

http://www.betanews.com/article/Apple_C ... 1180986419
http://www.betanews.com/article/DRMFree ... 1185300009
http://www.betanews.com/article/DRMfree ... 1180539752
http://www.betanews.com/article/iTunes_ ... 1192551506
http://www.betanews.com/article/The_era ... 1199466050
http://www.betanews.com/article/Record_ ... 1196699760
http://www.betanews.com/article/Warner_ ... 1198780555
http://www.betanews.com/article/Amazon_ ... 1190735662
http://www.betanews.com/article/Univers ... 1186753795

as of right now, there are only 8 portable media players that even support AAC and all of them have prices comparable to MP3-only players. so it seems to me that people "holding out" on buying AAC-supported media players are taking issue with DRM.

The size of a 160kbps AAC, 160kbps MP3, and 160kbps vorbis file will be roughly the same. Size = bitrate * length (in seconds). Vorbis cannot defy how a bit is defined. Your MP3 is better than AAC at higher quality is highly subjective, and I have never seen a single study to suggest that. Maybe a badly-encoded AAC file vs. a properly encoded LAME MP3 or something.

please, go over to the hydrogenaudio forums and post these two sentences...i guarantee youll start a holy war. AAC produces smaller and higher quality files than MP3 at lower bitrates because its internal code was written to compress better here (in response to studies showing that the "average" consumer can't discern 160kbps audio from the lossless source, and the need to store the same quality music in smaller file sizes). the fact that different audio formats compress differently is what makes them different in the first place. AAC is more aggressive in how it removes very high and low audio frequencies, and its encoding time is also much more efficient than LAME and Vorbis. Vorbis takes a completely different approach to handling these frequencies, which just happens to make it the best lossy audio encoder in terms of compression rate and quality preservation.

here's a basic Ogg vs MP3 vs AAC test:
http://www.xciv.org/~meta/audio-shootout/

and here's an extremely in-depth one that goes great lengths to quantify audio quality:
http://www.hydrogenaudio.org/forums/ind ... opic=36465

in both tests, Vorbis comes out on top for quality and size, at higher bitrates.

You seem to think that Apple has some controlling interest in the AAC codec. The do not; they have only adopted it for their iTunes platform. AAC has pretty much universal support as the "next-generation" digital audio format.

well, they do have some interest in AAC...meaning they need it so they can keep their pseudo-DRM in the itunes store. take a look at any "DRM-free" AAC music you've purchased from the itunes store. examine the metadata/tagging information and youll find personal information that ties these tracks back to you. and as far as AAC being the "future" of digital audio, i would think that the near-universally accepted return to DRM-free MP3's as well as an emerging FLAC market tend to suggest that the public is beginning to reject the low bitrate distortion offered up by AAC.




but i feel like ive gone on a tangent here. if low-bitrate compression and overall file size is important, then AAC audio is the most logical choice. if quality is the most important factor, go with Vorbis. the case is basically the same for mkv vs mp4 as the container: mkv supports all audio formats whereas mp4 only supports AAC. and while portable video players dont support mkv (unless you happen to use rockbox), mkv has much less overhead and is therefore more efficient.