The future of AMV distro? [followup: open source amv]

[NicholasDWolfwood]

I can play huffyuv at 720x480 at full speed, and thats how I watch most of my vids to check for errors before I do a distro encode. But full uncompressed gives me some shit(I drop 1 out of every 8 or so frames), as does trying to directly play IVTC scripts in VDub(I drop one out of every 6 or so). I know where the problems are, they're A) not RAIDing my 180gb of drives(both 7200rpm, 1 60gb, and one 120gb), B) not having registered/ECC RAM(I have 2 512 sticks of DDR), and C) not defragging/wiping my drives nearly enough. My procs are a dual 1.8 ghz MP's, with a MSI motherboard.

You do know that if you had RAID'd the two HD's together, they'd be a total of 120GB, right? Most likely 111GB of physical space.

[Dannywilson]

Yes. I understand the concept of RAID nick. I'm not stupid. Much to the contrary in fact.

[kthulhu]

That's open for debate .

[danielwang]

Though there's still four big problems:
...
The idea is simply not feasible.

Ok, so it's not feasible without a fairly powerful computer. But there are still the two possibilites I mentiones:

Write a script to detect the client's DVD-ROM drive and program path, and mirror *every single action* the AMV author has taken to create his or her AMV.
You can distributo under a few KB, but the client needs the compiler script, a copy of AE, or whatever app, and the original DVDs. You might have to send the music too though.

Script:
Detect client programs and filesystem
Tell user to insert the original anime DVD
Rip the DVD to a folder on the client's HD
Render all 3d effects and other necessary footage transforms
Compile and build the AMV through command line AE toolkit
Export directly to HuffYUV or just have the user scrub the timeline.

Ripping, rrerendering the 3d effects, blurs, etc, and then compiling should take less than 15-30 min. In the case of some videos such as Euphoria, it might take 45 minutes to render the nice color effects on a really slow CPU. But then, if they want real quality they better get an SGI.

Code: Select all

// Sample conceptual scripting system to build AMV
// Find the FS system
// Unix systems
source = grep(*dvd*,"ls -la /dev/") ;
// Find the mount point (simple)
mount = grep(*dvd*,"mount") ;
// Windows. .NET Gundam puts the Volume ID in fstab
mount = grep("RahXephon_1","cat /etc/fstab/");
// Windows XP, use Mountvol lookups
source = chomp("{???????2*}","mountvol");
// Get ripper location (defaults are /usr/bin or progfiles/smartripper)
ripperlocation = trim(":","which smartripper") // Or any ripping app
// Our only app needed is After Effects
aelocation = "/usr/bin/ae/ae55","%PROGRAMFILES/Adobe/After _
Effects/5.5/ae55.exe";

// Rip the DVDs
ripperlocation "-r" mount "-d /tmp/amv/";

// Start the After Effects script
aelocation "--export -f" makefile sourcecode options_
"-d $HOME$/%PROFILE%/Desktop/" amvname  _

// Play the video
"$HOME$/%PROFILE%/Desktop/" amvname

It's a ridiculous idea, I know, but theoretically it should be possible to pack a AMV that's dependent on other files. Just run a script to find user's DVD, rip it into the right location, then render all the effects in the background to a file on the Desktop.

Hypothetical, but possible (TM).

[EarthCurrent]

Is there even a need for this?

[danielwang]

Is there even a need for this?

True, true. But not for me?

After production b0x Temjin got zapped by a powerbus issue, we had to fallback on 14.4 modem on mr. DNS router Zaku.
That was a good Inter PRO/DSL card too!
Well DSL NIC + Lightning + crummy Belkin powerbus = 150,00$ trash.

So once everyone had broadband, there shouln't be much need. But for those who want to efficiently have 100% pristine quality (defined by "DVD quality"), you too can send a half hour compiling Ermac's latest lens flare radial blur white flash wipe transition and 3d effect filled video.
Try watching that on your PocketPC. With 8MB ram.

*is currently playing PristonTale over TightVNC*

[Tab.]

holy shit,

I'm gonna go hack ragnarok, then some other shitty korean RPG.
Then I'm gonna make a thread about obsessing over operating systems used in Anime.
Then I'll go watch TV on my 1337 hacked-card satellite system.
Then I'll take a trip to the bathroom to make another topic.

Plz use this day planner wang:

Monday: Buy gun, bullets

Wednesday: BLOW BRAINS OUT

What does this look like everquest?

[koronoru]

Every video I create involves at least dozens if not hundreds of files. There are scripts to rip the DVDs (usually applying some processing along the way), other scripts to generate the index files needed by my editing software, still images I screen-cap (often without recording the exact coordinates from which I captured them, even if my playback program were frame-accurate which it often isn't), usually two or three EDLs (the main one and a couple of backups or checkpoints), sometimes scripts to edit the EDLs to correct for idiocies in the editing software, more scripts for processing the output into a distributable form, "profile" files setting options for the encoder, and so on and so on. To make matters worse, everything depends on the current versions of the software I'm using - if I upgrade, often features change and files have to be changed to suit.

The end result is that when I finish a project and burn a final version to CD, if I come back to it a few months later, it's a triumph if I can reproduce ithe video again exactly myself. I'd love to be able to share my created files (scripts, EDLs, etc.) and have someone else be able to reproduce my work exactly; but it's hard to imagine how that would be possible. They would have to first reproduce my entire system configuration. The couldn't just have the same DVDs; they would have to rip them in the same way I did, with the same version of the same software, to directories with the same names, and so on.

Now, the same kind of problem also affects the people who make open-source software, and they have a solution for it (actually, two). One solution is to just dumb everybody down to the lowest common denominator, and then pray. That's why most Windows software works on most Windows systems without needing to be recompiled. It doesn't always work, of course, and you do pay a price for that partial compatibility. The other solution is autoconf (or equivalent); before you build the package, you run some software that is written for absolute maximum portability and that probes your system to figure out what to have. Then it edits the software you're building, to make it compatible with your particular configuration. In the case of an AMV, I imagine the configure equivalent would for instance touch up the EDL to point at the directories in which you've ripped your DVDs. autoconf only works because the tools that it's feeding into (compilers, linkers, and so on) are designed to take their marching orders from text files in well-documented formats. You can write a configure script that will generate text config files and the tools for building the software package will look at those files and it'll all work.

Applying the same logic to AMVs doesn't work because important steps in "compiling" AMVs are done with manual intervention and not defined in terms of text files that can be processed by automated tools. If I open up an image with an image editor and use an eraser to remove a character, there isn't anywhere recorded "Oh, koronoru captured frame 398003 of the DVD with identification code 83970DEADBEEF4973097, then removed pixels in such and such coordinates". All that's recorded is the final image. So either I have to graft some kind of human-readable note into the package saying "You will need this image file, generate it by the following procedure", or I have to treat the edited image as a fait accompli, something that just has to be included as-is in the distribution, or I have to rewrite the entire fucking image editor to record my editing activities in a version-controllable form. And that last is tricky if it's something like Adobe Photoshop where I don't have the source and will get sued if I try to reverse-engineer it, even assuming I have the skill and inclination to do so. Even when the instructions for compiling the AMV are in a file (e.g. a Premiere EDL) it's often an undocumented non-text format; even when the format is text and at least sort of documented (e.g. a Cinelerra EDL - no docs, but at least source code is available), the actual action of compiling/rendering the AMV often involves GUI commands that are not easily scriptable.

AMVs have huge amounts of tricky dependencies (unlike software, which only has a lot of dependencies), AMVs require human participation to compile, often at least to press the button and usually also to do human-intelligent things like image editing, and so it's very difficult to compile an AMV without the participation of its original creator, or on any system other than the one where it was first created. Even the same system operated by the same human after a few months of upgrades, is often a big problem.

[Tab.]

koronoru pwns me

[trythil]

koronoru pwns me

Yes.

Beautifully done, koronoru.

Write a script to detect the client's DVD-ROM drive and program path, and mirror *every single action* the AMV author has taken to create his or her AMV.

Still not feasible. Do you know the kind of insanity it would take to record the kinds of actions that occur in a usual AMV session? Even a centralized scripting engine like Windows' VBScript or OS X AppleScript couldn't handle it, because the applications I use either don't have scripting hooks or have their own scripting languages that are incompatible with everything else (by necessity or by design).

Examples of the above (all programs I use): Cinelerra (no scripting hooks yet) and Blender (it has a Python scripting engine, but it works with nothing else). More examples of category #2: Photoshop, CinePaint.

Recording something at a higher level -- i.e. mouse clicks -- wouldn't work either. Absolute coordinates are obviously out of the question, and there's really no other way to do it. In Windows' GUI and just about every other GUI, objects are assigned handles, and they are rarely ever assigned the same handle twice. Objects also have names, but frequently they're given the same name, and assigned a position in an array that is internal to the program being used.

Hell, that all assumes that Windows can even isolate the objects in question. Blender, for example, uses OpenGL to render its UI and handles all the other stuff internally; Windows doesn't have a hope of interacting with it in the manner I described above. And no, I didn't bring up Blender just for an example; I've used it extensively in two AMV projects.

But now I'm tired of entertaining this proposal. It's clear to me, from a look at your profile and your writing, that you've insufficient experience with the AMV creation process.

When you have created a few AMVs, hopefully you'll see why we all say that your idea smacks of impossibility. That, or you'll put forward an idea for automation that actually makes sense.