Deinterlacing on Cartoons

[nightstrm]

I'm looking for a single reference to you doing a MP4 encode with bframes enabled... I have yet to find one. All of your examples clearly show mkv.

AAC does not mean DRM! The DRM-free AAC in iTunes may have some personal information in them, but I have to ask the obvious: who cares if you aren't going to share the music with people who don't have any rights to the music in the first place? Please save the "fair use" argument that I can only imagine is coming. Fair use has never given anyone the right to give copies of copywritten content to other people.

You seem to be confusing the general public with the "highly vocal minority of nerds on the Internet". If you look at the true general public, it would appear AAC is clearly the superior format in terms of legal online audio distribution. Even with Amazon offering a wider selection of DRM-free MP3s, consumers are sticking with iTunes and AAC, simply because they do not care.

Finally, I await your thesis on how a bit can vary between an AAC and a Vorbis file when it comes down to file size. If you can scientifically prove that bits can have different sizes based on what they are, you just might win a Nobel Prize. I know how these various audio compression technologies work, so I do not need a lesson on the differences. My whole point of contention was that you still claim that a 160kbps vorbis file is going to be smaller than a 160kbps AAC file.

As this little side conversation has completely taken this thread off topic, I'm going to suggest we just stop here. If you want to post your theory on how bits change size depending on their format, please do so in another thread.

[Hello]

We'll I don't think arguing is going to do much of anything now is it. He has his opinion which he has provided some links to back up and thats perfectly fine. I didn't mean to start a fight, I guess the main reason I use AAC is compatibility, and because it sounds fine/better than mp3 to me. I don't really have much experience with ogg, and the only reason I don't use it is because it is not supported with any general media player I have ever used without secondary add-ons that I see no reason to look in to.

Anyway, I agree with night. This has become a very side-tracked discussion. From what I have found out, because I was the one who asked the question that started this discussion in the first place. Family Guy was not interlaced, but was telecined, which when I first asked the question, I did not know the difference between them. So using VFR with Family Guy cleared up nearly all the problems with telecining in the file, and it looks perfect now. So hopefully if anyone is wondering about the weird lines in many cartoons, they should try using VFR before they deinterlace, because I have found that deinterlacing often just caused the file to look worse in the end.

[echohead]

it was never my intention to start an irrational off-topic argument. i felt that being able to isolate the source of the animation telecining issue to the inclusion of b-frames was significant enough to mention. when my preference for matroska and vorbis were called into question, i felt that since they were the settings that i found produced optimum quality while still eliminating the original problem, it might be worth it to defend them. that being said...

no, he (jbrjake) 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.

with a little more research, you'll find that A) the average consumer doesn't know what a file extension is and B) that the most successful music retailer is Wal-Mart, not iTunes. therefore, i think it's a safe bet that if you explicitly asked an "average consumer" whether they prefer higher audio quality or a format that has the ability to include DRM, they just might opt for quality.

Fair use has never given anyone the right to give copies of copywritten content to other people.

i see. next time my roommate asks to borrow my Jimi Hendrix t-shirt, ill be sure to turn him in to the feds for attempted copyright infringement.

I await your thesis on how a bit can vary between an AAC and a Vorbis file when it comes down to file size.

bitrate has less to do with final file size, and more to do with what ranges of audio are left in the finished encode and what ranges are cut out. at the same bitrate (assuming its above 160 in this case), vorbis will produce smaller and higher quality encodes than AAC because it has superior compression: what is left in the final encode is more similar to the lossless original than what AAC leaves in. this is not a radical idea, merely the ; simply a matter of performing two test encodes at the same bitrate and comparing file size. proof of this can be seen in foobar2000 (one of the better windows-based audio players, which happens to have native ogg support). take the same audio track @256kbps, one vorbis and one aac and the lossless original, open the spectrum analyzer and you can literally see the inferiority of aac at moderate-to-high bitrates.


if you use handbrake exclusively to make files for an ipod or other portable media player, mp4/aac are obviously the better choice because mkv/vorbis is not supported. but i only play my encodes on a home theater PC and am after quality, efficiency, and open standards - something vorbis audio and matroska capitalize on. regardless, i gave a definitive solution to the animated telecining problem several posts ago and see no reason to further defend a container and audio format that work and work well.

[s55]

Code: Select all

B) that the most successful music retailer is Wal-Mart, not iTunes.

http://uk.news.yahoo.com/techdigest/200 ... 70a33.html

Code: Select all

[b]bitrate has less to do with final file size[/b], and more to do with what ranges of audio are left in the finished encode and what ranges are cut out. at the same bitrate (assuming its above 160 in this case), vorbis will produce smaller and higher quality encodes than AAC

Rubbish.

Filesize will be the same, if the bit-rate is infact the same.
Quality of the audio however, Will NOT be the same. (as you said)

Filesize (in kB) = (bitrate *seconds) / 8. You simply can't dispute this.

Now, If i can't make this any clearly, Here's an example.

120 Second audio file. Encoded with AAC and Vorbis at 160Kbit.
Vorbis Filesize: 2.34MB
AAC Filesize: 2.34MB

[jbrjake]

no, he said the problem was with b-frames OR with libmkv.

No, I said the clearest solutions were not using b-frames in MKV or using MP4. I know exactly what the problem is. It's b-frames in MKV. That's why I told you "It has nothing to do with VFR. It's an issue with b-frames and 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.

There is no telecining problem. You came to this thread with an audio-sync issue when using VFR. It's actually an audio sync issue with b-frames in MKV, as I already told you. Your theory that the audio drops are when VFR dropped frames is entirely specious. I think I know what I'm talking about when it comes to b-frames in HandBrake, and the same with VFR, so maybe pay attention to the information you're being given.

mp4 only supports AAC.

Um, no.

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.

This is simply not true. I do all my testing with MP4. VFR works with MP4. No telecining shows up. And the issue you were requesting help with at the time I told you it was a container issue was not "telecining still shows up" it was "the audio is out of sync."

at the same bitrate (assuming its above 160 in this case), vorbis will produce smaller and higher quality encodes than AAC

This has to be one of the stupidest things anyone has ever tried to argue on this forum.

i gave a definitive solution to the animated telecining problem several posts ago

Online support forums are based around public goods. The only incentives someone has to help is the reputation garnered from helping and a sense of altruism. You reduce both incentives -- and in turn reduce the efficacy and utility of the forum -- when you take credit for things someone else told you.

[dynaflash]

wow, just read this thread and all I can say is ... "WOW"!

[echohead]

regrettably, i managed to confuse telecining with audio syncing...and managed to roll off a few paragraphs about audio encoding that made very little (if any) sense. call it lack of sleep, lack of proofreading, whatever. regardless, i managed to sound like a dumbass. i think i would have saved a lot of time if i had instead typed the sentence: "different format audio encoders, encoding at the same bitrate, will yield files of identical size but different quality." and let me clarify that: based on my testing, VFR works fine in both MP4 and MKV


i have 5 handbrake encodes of my family guy movie:
-Vorbis audio and MKV as the container, with VFR and b-frames on. there is no telecining, but the audio is out of sync.
-MP3 audio and MP4 as the container, with VFR on and b-frames on. there is no telecining, but while playing the file reports the audio stream as AAC and is completely mute (if MP4 supports audio other than AAC, then why is there no sound?)
-AAC audio and MP4 as the container, with VFR on and b-frames on. there is no telecining, but the audio is out of sync.
-AAC audio and MP4 as the container, with VFR on and all b-frame related arguments removed. there is no telecining and the audio has been fixed.
-Vorbis audio and MKV as the container, with VFR on and all b-frame related arguments removed. there is no telecining and the audio has been fixed.

@jbrjake: according to you my 3rd encode should have solved the audio sync problem, but it didnt. neither container had audio synced properly when b-frames were used, but both worked perfectly with b-frames removed. now if the mp4 container should be able to handle b-frames in this situation, then i have data that proves something is wrong here.

i was probably asking for trouble when i came to a primarily mac/apple forum and said i preferred mkv and vorbis, but getting information on audio and video encoding confused clearly didnt help. regardless, ill go ahead and assume that 3 admins in a row replying to me is a sign that its time to shut up.




...if someone could explain why b-frames under MP4 failed for me, i would appreciate it.

Code: Select all

 -i "D:\VIDEO_TS" -o "C:\famguy.mp4" -e x264 -E faac --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 160 -R 48 -D 1 -6 stereo -v

if i can get b-frames to work for telecined animation under MP4 without audio being out of sync, then obviously MP4 would be the superior container for this situation.

[realityking]

-MP3 audio and MP4 as the container, with VFR on and b-frames on. there is no telecining, but while playing the file reports the audio stream as AAC and is completely mute (if MP4 supports audio other than AAC, then why is there no sound?)

I'm not entirely sure but if I remember correctly HandBrake doesn't support MP3 audio in the MP4 container. However that doesn't mean that the MP4 standard doesn't support MP3 audio.

BTW, what do you consider an "open standard"? MPEG-4 (The MP4 container, AAC and H.264 are all parts of MPEG-4) is an official ISO standard: ISO/IEC 14496.
If you want to use stuff that isn't patented you shouldn't use H.264.

[jbrjake]

(if MP4 supports audio other than AAC, then why is there no sound?)

Because the only other audio codec that HandBrake supports in MP4 is AC3? MP3 and MP2 are perfectly valid in the standard, though, as are ALS and a few other things. AC3 is available because the spec includes the idea of private track IDs to allow further extensions of what the container supports, and that's why you can also put Vorbis or Apple Lossless in there too. All sorts of audio codecs can be muxed into an MP4 besides AAC.

@jbrjake: according to you my 3rd encode should have solved the audio sync problem, but it didnt. neither container had audio synced properly when b-frames were used, but both worked perfectly with b-frames removed. now if the mp4 container should be able to handle b-frames in this situation, then i have data that proves something is wrong here.

What video player? Were you using reference b-frames (b-pyramid)? That adds a whole 'nother layer of frame reordering on top of regular b-frames, making playback more complex. Also, does your player fully support the MP4 spec? We use a feature of the MP4 format called edit lists to make sure our audio and video are always aligned when using b-frames in that container.

I just did a test encode using the options you provided (-e x264 -E faac --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 160 -R 48 -D 1 -6 stereo -v) and it has no noticeable audio desynch when played back in QuickTime with Perian on my Mac.

[TedJ]

Woo, feel the heat in here...

While on the (off)topic of audio formats let me take the opportunity to announce the impending release of Q-Ogg (pronounced Quag), which uses quantum superposition to encode an entire track into ONE 16bit frame. Thus, my 160kbit encode is smaller than yours... giggety!

[dynaflash]

Personally I have seen the light. From now on its avi all the way baby, my atv and iPod's be damned.

[Hello]

Wow this ogg-aac fight really escalated fast. My apologies for starting such an off-topic conversation.

[echohead]

What video player? Were you using reference b-frames (b-pyramid)? That adds a whole 'nother layer of frame reordering on top of regular b-frames, making playback more complex. Also, does your player fully support the MP4 spec? We use a feature of the MP4 format called edit lists to make sure our audio and video are always aligned when using b-frames in that container.

I just did a test encode using the options you provided (-e x264 -E faac --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 160 -R 48 -D 1 -6 stereo -v) and it has no noticeable audio desynch when played back in QuickTime with Perian on my Mac.

i use The KMPlayer, but also tested the video with several different video players. AFAIK KMPlayer fully supports MP4, and if its any indication of its robustness, i have a few Bedlam encodes that it can playback just fine. the audio syncing problem was still there, regardless of the player i used...the only real difference being the quality of the decoded video. if it helps, audio desync with b-frames under mkv is about 0.5 seconds, whereas with mp4 its only about 0.25 seconds. and the h.264 options i used are the same as those i listed a few posts ago...so if theyre enabled there then thats what i used. is there a windows-based media player you can recommend that might fix this problem? or maybe re-encoding with b-frames and mp4 but without reference b-frames?

[jbrjake]

AFAIK KMPlayer fully supports MP4

Well, clearly it doesn't...

Have you tried VLC?

[neocui]

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

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

Question about that... I did a:
HandBrake -t0
on Futurama Season 1 Disc 1, and it shows:

+ title 1:
+ vts 4, ttn 1, cells 0->9 (600727 blocks)
+ duration: 00:23:18
+ size: 720x480, aspect: 1.33, 23.976 fps
+ autocrop: 0/0/6/4
+ chapters:

Interlaced/Telecined at 24 frames? What's up with that? I thought telecine/3-2 pulldown happens when you go from 24 to 30. So what does it mean when a video at 24 FPS is telecined? What is the original frame rate then?

[jbrjake]

Um, it's mixed content. Didn't you try to encode it? Don't you see all the Film->Video messages and vice versa flying by?

[neocui]

Ahh.. Now I do, after passing in --verbose flag to HandBrakeCLI

Thanks...

So why is it switching between Film and Video every 2 seconds? Is there any advantage in doing that? Or did they just do a terrible job of transferring it to DVD?

[jbrjake]

So why is it switching between Film and Video every 2 seconds? Is there any advantage in doing that? Or did they just do a terrible job of transferring it to DVD?

It might not have been a terrible of transferring it to DVD -- it might have happened when the episode was originally produced. And that could have been an issue of budget/time constraints, or something.

There's no real advantage to it, it's just something that has to be done when content is mixed -- when sequences done at different frame rates and presented different ways (interlaced, hard telecined, soft telecined/progressive) are all edited together into one stream.

[djcraze]

haha, I has a question regarding the show Futurama. I see where everyone was saying that Futurama was Telecine (if thats it??) and not interlaced, does this follow true for every episode on a single disk, or does it vary from episode to episode? Should I rip one-episode-at-a-time??

Is it safe to say, that I can rip an entire disk using the same setting through-out, getting great quality?

Thanks,
DJCraze

[rhester]

If you use VFR, you really can't go wrong.

Rodney

[Filmriss]

... Family Guy was not interlaced, but was telecined, which when I first asked the question, I did not know the difference between them. So using VFR with Family Guy cleared up nearly all the problems with telecining in the file, and it looks perfect now. So hopefully if anyone is wondering about the weird lines in many cartoons, they should try using VFR before they deinterlace, because I have found that deinterlacing often just caused the file to look worse in the end.

If you use VFR, you really can't go wrong.

Rodney

From the follow up posts I get, that de-telecining might have to be applied, too.

When using VFR, there is a field/option above that, where you have to choose something. Should one choose "same as source" or (if you want to watch it on PAL-TV) choose "25fps PAL"?


PS: does the "deinterlace/decomb: slower/default" setting under the hood still use a two times yadif or does it utilise another algorythm in the newer versions of Handbrake? (-> "deinterlace slower" = "decomb default" = "yadiff, two times" I derive from what is written here https://web.archive.org/web/20160609142 ... nterlacing )