Instrumental Anime Project

[jasper-isis]

Ooshna: an FTP is what we're hoping for. Although I can't say what the total bandwidth requirement would be, as some of us have yet to encode our DVD copies.

Bakadeshi: I have uploaded my files to a friend's server. Check your inbox for a PM. Please let me know when you're done downloading so I can delete them from the server.

[rose4emily]

Nope, I've uploaded a 64mb file in hardly more than 20 minutes. So my DVD submissions, which are 236mb total, should come to just under an hour an a half. Can't say that for some of your behemoth videos though.

I don't know about anybody else, but my Huffyuv-to-MPEG2 conversion compressed by about a factor of 10.

Anyway, I'm asking my friend (who owns the server that I use) if I can temporarily upload these files and let Bakadeshi download them directly off the server.

I'm still a little confused, I guess.

64 megabytes is a bit (well, a maybe few bits) over 480,000 kilobits.

20 min = 1200 seconds

480,000/1200 = 4800/12 = 400 kilobits per second (Kbps).

If you mean kilobytes per second (KBps), its 50 KBps (400Kbps / 8 bits per byte), which would fall within a 60KBps maximum upload speed (which is actually a blazingly fast upload cap by home internet standards).

Maybe that's where I'm getting stuck.

Also, 236MiB is actually less than a 5-fold compression increase from 1.13GiB. It's probably about a 10-fold compression ratio compared to raw video data, but the HuffYUV codec usually offers a 2-3 fold compression ratio for animated sources - hence the ratio of about 5 between the size of the two encodings, rather than 10.

---

Actually because of the many diferent settings in the many different implementations of the mpeg4 codec, and the method used to encode and decode mpeg4 implementations, you are bound to find incompatibility issues in mpeg4 codecs much more so than in mpeg2 codecs. WHile you have many diferent mpeg4 implementations, all of wich arn't even totally compatible with each other, (divx, xvid, 3vix, various freeware options, Miscorosft mpeg4) theres, to my knowledge, only 1 Mpeg2 standard that everyone follows.

This is something of a "Four-Term Fallicy" ("Quaternio Terminorum" if you're in a pedantic state of mind - which, for some odd reason, I am at the moment). There are many different MPEG4 implementations, and also only one MPEG2 standard, but neither is an implementation a standard, nor a standard an implementation. There are, in fact, several MPEG2 implementations in both hardware and software forms. There is also a single MPEG4 standard (it contains multiple "profiles" of varying complexity - but most codecs only purport to support the "simple" profile anyhow). The true source of MPEG4 incompatibilities, as compared to some similar technologies (like the original MPEG) is most likely the fact that MPEG4 is a newer (read "less mature") technology, combined with the sketchy history of several of the popular implementations as forks from hacked Microsoft code that wasn't fully complient in the first place. MPEG2, on the other hand, is used primarily by industry professionals in the production of DVDs (really only a subset of MPEG2's potential uses, but the only one that ever amounted to much), and most MPEG2 implementations were developed through a legitimate process, working off of the MPEG consortium's reference implementation and within the MPEG2 patent scheme to produce encodings that would, as a top priority, offer reliable playback on a wide range of hardware decoder implementations in a hetorogenious distribution environment. Some prominent MPEG4 (and MPEG4-ish) implementation developers, especially Microsoft and the people who hacked MSMPEGv3 to produce the original DIvX codec, were only concerned about playback using their own bastardized implementations - hence the need for several different codecs to playback a variety of encodings that are all, in theory, supposed to be the same.

Still, I do think it's best to stick to one software implementation of MPEG2 for the DVDs, as even mature and carefully tested code tends to have subtle inconsistencies between different implementations - some of which may or may not come into play with the sort of video source and settings we'd be feeding them.

---

Anyhow, I'm back in NH right now, and will be re-encoding the Fullscreen section tomorrow, after I've decided on a good place to set up my workspace for the week.

[jasper-isis]

Also, 236MiB is actually less than a 5-fold compression increase from 1.13GiB.

That should be 2.12GiB. I encoded from my original 720x480 Huffyuvs, not the 512 horizontal resolution ones that I'd sent you. I've never exported in raw AVI data before and don't ever plan to. x__x

___

I've recently started working on my Third Impact segment and realized how drastic the effects of 24fps to 29.97fps framerate conversion can be. The footage speeds up by a LOT. Does anybody know how to do upwards conversion of framerate without speeding up footage? (By way of dupicating frames, I suppose.)

[rose4emily]

I've recently started working on my Third Impact segment and realized how drastic the effects of 24fps to 29.97fps framerate conversion can be. The footage speeds up by a LOT. Does anybody know how to do upwards conversion of framerate without speeding up footage? (By way of dupicating frames, I suppose.)

Yup, that's pretty much how it's done. Cinemetographers will actually use a process called "3-2 Pulldown", also known as "Telecine" to accomplish this framerate conversion from Film (which is usually shot at 24 Progrssive FPS), and NTSC Video (which is shown at 29.97 Interlaced FPS). There are a lot of special considerations in this process which using Film as source material - given the much greater spatial resolution, color resolution, and dynamic range of film as compared to video, which requires a lot of downsampling and compression to get an attractive picture out of the process. Working off of most digital sources, however, the framerate conversion is the only part you have to worry about.

For more information, here's a pretty well-writen overview of the process:

http://www.zerocut.com/tech/pulldown.html

There are other methods of framerate conversion that better suit certain forms of progressive footage, using resampling techniques that weight and average values over frames to generate the output frames (this is also how most high-quality audio sample rate conversions, speed-independent pitch conversions, and pitch-independent speed conversions are done). There are also methods that simply copy whole frames (as opposed to fields, which don't really exist in Progressive footage). Finally, smaller adjustments are often done by just changing the playback speed (this is how the 24 FPS to 25 FPS conversion is done for PAL video - so a PAL film will actually play slightly faster than the same film in a theatre or on a NTSC-formatted disk). For most footage, however, the more common 3-2 Pulldown process works just fine, and should offered as a simple export option in most video editing suites.

---

Last night, I re-encoded all of the segments from the fullscreen segment. I've been working on my Software Engineering project for most of today, but I'll merge the segments tonight and test them for proper playback on my folks' Windows machine. If everything works as it's supposed to, I'll move on to the Widescreen segment.

I'll do the testing in WMP9 and WMP10. I don't have a non NT-based version of Windows (95, 98, ME), much less the 16-bit dinosaur Win3.1, so I can only test the WinXP/Win2000 media players. I do have to imagine that an AVI file (I'll try to get the AVI file to work first, before resorting to the superior but less familiar MKV) that works in two of the Windows Media Players should work well enough in most others.

I do have to re-encode the video narrative for Helen's spot, to add the parts of the narrative that were missing in the first version. Just mentioning to say I haven't forgotten about it.

---

Song, I just saw your "Veggie-tales" rap video. Wow...I think that might be even stranger than most of George's videos. And that says a lot.

[Bakadeshi [AuN Studios]]

rose, if you need help testing, I can setup to test on just about all of those operating systems aside from 3.1. My dad has a few comps in the house still running win 98 and win me on virtual PC stations.

I could also grab virtual PC from him and do the testing on my own system, since I do have all those OSs on cds from way back in the day.


anyway just letting you know I can be a tester if needed ;p

[jasper-isis]

Yup, that's pretty much how it's done. Cinemetographers will actually use a process called "3-2 Pulldown", also known as "Telecine" to accomplish this framerate conversion from Film (which is usually shot at 24 Progrssive FPS), and NTSC Video (which is shown at 29.97 Interlaced FPS).

Oh, duh! *smacks herself on the forehead* I've used IVTC in every one of my amvs so far but for some reason didn't think of the logical opposite. Well, it can't be helped now, since I'm already halfway through, and changing the framerate conversion method would screw up a whole lot of cuts.

Although... wouldn't IVTC make the video interlaced? Ah well I guess there are always ways to make video progressive without altering framerate.

[rose4emily]

Yup, that's pretty much how it's done. Cinemetographers will actually use a process called "3-2 Pulldown", also known as "Telecine" to accomplish this framerate conversion from Film (which is usually shot at 24 Progrssive FPS), and NTSC Video (which is shown at 29.97 Interlaced FPS).

Oh, duh! *smacks herself on the forehead* I've used IVTC in every one of my amvs so far but for some reason didn't think of the logical opposite. Well, it can't be helped now, since I'm already halfway through, and changing the framerate conversion method would screw up a whole lot of cuts.

Although... wouldn't IVTC make the video interlaced? Ah well I guess there are always ways to make video progressive without altering framerate.

IVTC (Inverse Telecine) will convert interlaced footage at 29.97 FPS to progressive footage at 24 FPS. Telecine (not Inverse Telecine, but the process IVTC is inverting) always, so far as I am aware, is used to produce interlaced footage. Otherwise, it wouldn't be much of a "telecine" - which quite literally referrs to the fact that it tranlates a "cine"ma-friendly format (24 FPS Progressive) to a "tele"vision friendly format (29.97 FPS Interlaced). As to why interlaced footage is "television friendly", that lies in the nature of their construction - the electron beam is run down the screen in "scan lines", each of which is composed of several "fields" (which would, in computer terms, be a short strip of pixels). These scan lines aren't displayed all at once, however, but rather in two passes. I'm not sure whether this was done to produce a smoother picture in old TVs (which probably didn't have terribly wonderful phosphers - and would probably look horribly "flickery" with a progressive picture), or due to some technical limitation in the aparatus controlling the focus and location of the electron beam, but this is how analog televisions invariably display a picture.

Digital TVs are different. Most are purely progressive displays (all of the LCDs are, as LCDs are, by the nature of their design, incapable of interlaced display). They do usually accept interlaced input, however, and simply run the picture through an inverse telecine before displaying this.

The rediculous part of all this is that HDTV will probably (judging by current industry practice) often be broadcast in interlaced form, even when the source material is inherently progressive (cinematic film and cel animation being the two most common examples), and the display is also inherently progressive. The same thing is done on a lot of DVDs right now (hence having to use the IVTC for making your AMVs). Why this is done, I do not know, especially as virtually all DVD players and HD reception boxes are capable of performing the telecine process on the fly.

If your source footage is progressive, and you want your output footage to be progressive as well, my best suggestion for a simple way to do this (if your editor can't do this automatically upon export) would be to export to an image stream, delete frames every nth frame where needed to compensate for temporal scaling, and re-encode off of the images.

If you'd like to, you can send me the Huffmans, and I'll do that for you, using a few handy Linux shell scripts I have laying around. I can then re-encode to Huffman, or to obscene quality (constant Q of 1, all Intra frames, less lossy than most DVDs) XviD (no luck with MPEG2 yet), and send the videos back to you, or directly to Kareef if you are trying to do this for the DVD.

I should note, however, that the only way you're going to be able to transfer large files to me while I'm on vacation is via CD or DVD in the mail. I'm afraid Comcast is blocking all server activity (at least in the area of my hometown), so I can't run the FTP here without potentially getting my parents kicked off of the internet (which would be bad).

---

I've concatenated the audio files for the "Forbidden Memories" narrative, and generated the compile script from the new narrative audio using my (sort-of new and slightly improved, due to new parameters and a better "in-between" mouth) lipsynching program. I'll compile that video overnight, and encode it along with the rest of the narratives and titles tomorrow morning.

---

I know I'm sort of dragging this out at the moment. This is because I'm actually working full-time on two different projects at once - and the other has to be completed within a fixed deadline of 10 weeks (which is a lot like the deadline originally set for this one, so I'm trying not to repeat history with my time-estimation skills - or lack thereof). I have looked at the encodings I did last night, though, and they look quite nice. They are also a bit smaller than the ones done with libAVCodec's MPEG4 implementation. I attribute this to the global motion estimation, but XviD might also be more efficient in the post-quantization entrophy encoding stage thanks to its trellis encoding system. I will try watching it on a television tomorrow to see how it looks on a projective display, however, since most LCDs introduce some of their own visual artifacts in dark regions and areas of highly saturated color (thanks to their as compared to most new CRTs, lesser color gamut, inability to display a true black, and the strange things they do to gamma and brightness curves to compensate). The television will be lower resolution, but should help me see whether the darker regions translated well in the new encoding. As to the color saturation, I'm going to have to trust it's still there, as consumer TVs aren't really known for having the best color richness, either.

---

Having gone through much of the process for compiling the Fullscreen section by hand, I can also say that I've automated as much of it as is possible for the Widescreen section - so that one will fly together more or less on its own once I'm sure the Fullscreen section is done and can be properly viewed on as many displays and platforms as is possible.

---

As to testing on older Windows platforms, I think it'd be best to just do that with the Widescreen section, when I submit it to Kalium's FTP for you all to review. I'm using an unmodified compilation of XviD (no special or platform-specific features or optimizations), and a very mature and commonly used MP3 codec (LAME), so codec issues really shouldn't be a problem this time around. AVI indeces or the use of the MKV format (if the AVI tests are unsuccessful) may be an issue with older versions of DirectX (and DirectEverythingElseThatComesWithIt) or older versions of the Windows Media Player.

As to testing on Macs, I'm not too worried about it. There are about as few Mac users as Linux users, they have access to some of the most sophisticated media software available to the common (albiet affluent) consumer, and they can install the Unix/Linux version of MPlayer (the media player I have that plays every format under the sun, and even some corrupted files from bad external media or error-prone downloading programs) if nothing else they have can deal with whatever format they encounter. In essence, they should be able to play whatever we submit to The Donut without problems.

[NeoQuixotic]

Just posting to ask for clarification of what I and other members need to be doing or submitting. I know that getting a copy of our video for the DVD is one project right now, but anything else I am not sure of. I'm still in the middle of bringing my computer back to life. I got my new drive and decided to re-install XP onto a faster harddrive I used in my external enclosure. All the little updates, programs, tweaks, codecs, UGH! I think I should should just mail a data CD or DVD of the my huffyuv file since my computer is still in limbo.

[jasper-isis]

Although... wouldn't IVTC make the video interlaced? Ah well I guess there are always ways to make video progressive without altering framerate.

My bad, I meant Telecine. x__x
___

anubisx00: you're on the right track. I think the only other thing that you'd want to do is download the project beta when it comes out. And force everybody you know to download the bugger when we finally release it.

___

One more major test and I'll be on vacation. I'd better stay off the web for tonight.

[rose4emily]

One more major test and I'll be on vacation. I'd better stay off the web for tonight.

Good luck with your test, and I imagine vacation is a welcome thing for us all.

I meant to ask, what's your major? You seem really sharp with design, and I was wondering if you were somehow in the arts.


---

I've put together the new encoding of the Fullscreen version. I also helped paint my sister's new apartment and set up the first few XML Schema for my SoftEng project. All in all a productive day. I'll test the AVI and MKV versions tomorrow, then move on to the End Credits.