TheAX AMV Contest 2009 Finalists are...

[Vlad G Pohnert]

It don't matter what aspect you edit in so logn as it's all consistant and it's corrected in the end... Hell, right now I stil edit in 720x480 DV (non interlaced) as I still use my high end editing card.. However as it is a HD card I plan to start looking at moking to 720p and then just resize and letterbox it to 720x480 for cons to make it easy for them to enclode with out worrying about resizing...

Vlad

[Melichan923]

Or, if not that, then it could be a telltale sign that someone forgot to uncheck "Deinterlace when speed is below 100%" in Premiere 6.5 and earlier...

That used to be the solution to my problem although it created more of a ghosting effect for me in Vegas. Selecting Disable resample helps a lot for slowed down clips.

Actually, after this year I am putting on all my submission forms what the aspect ratio the video file that is being submitted for my contest are in so that I don't have to guess or ask if for any reason it was done in the wrong aspect ratio intentionally.

But indeed, unless the contest rules state HD, I always assume basic NTSC.

That's a very good idea. I might try doing that as well. Thanks.

[Ryvannis]

It don't matter what aspect you edit in so logn as it's all consistant and it's corrected in the end... Hell, right now I stil edit in 720x480 DV (non interlaced) as I still use my high end editing card.. However as it is a HD card I plan to start looking at moking to 720p and then just resize and letterbox it to 720x480 for cons to make it easy for them to enclode with out worrying about resizing...

Vlad

True, but it's torture on the system. I had so many crashes that CS4 just gave up and quit without any notices at times so I had to constantly save, even with scripts (Avisynth), it's probably on my end maybe, but trust me editing content of that quality (and effects..) requires a lot of processing power. Maybe Ben's quad PC with his 4870x2 can handle anything that's thrown at it but there's always a limit to what a computer can handle.

My system handles 720x480 DV just perfectly.

[outlawed]

As for how to prevent it, I think the problem is in how you're preparing your footage.

Keep in mind you are also limited by the source quality on the DVDs themselves. Not all DVD releases are picture perfect video by any means. To what level AMV video quality is judged or nitpicked is AX's call though. I would expect the TVpro thing or whatever it was called would weigh this more heavily.

You said you edited at 848x480 which tells me you resized and transcoded your footage before editing. Why not stay at native 720x480?

It is a given that the footage will be converted before editing. Editing in MPEG-2 that is not 100% I-frames would be very dumb so it will be transcoded in one way or another whether intermediate huffyuv files or avisynth scripts feeding the footage on the fly. We both know most editors source from DVDs and few AMV creators left are even capable of properly editing in an interlaced environment so they will have to make it progressive. 16:9 720x480 anamorphic video is not square pixels. If one were planning to apply any compositing, effects, or added original content it would be a LOT easier working in square pixels. It's also better for preview on a computer to work in square pixels. Converting this source to 848x480 makes good sense.

[outlawed]

For all the contests I do, I run them from either DVDs or Netstream Mpeg decoder cards, I just find it all easier to just make it 720x480 (0.9 aspect ratio)... Hence anything in 16:9 gets letterboxed into 720x480 at least for now
<SNIP>
I assume the same for other contests (NTSC) so I do the same for my submissions.

I have restricted the submission formats and requirements for the ACen contest gradually over the years (2005-2008) and then expanded them this year (2009). One of the advantages is I can process the entries quickly. When I run the initial judging I no longer have to convert files beforehand because the entries are either in square pixels or are MPEG-2 with an aspect ratio flag. Discussions like the ones in this thread don't happen simply because I have prevented the discussion from even occurring by the restrictions. Of course there is always the risk that we may not see a fascinating video because it was an avi in divx but we've proven we're willing to live with that and I don't think the contest overall quality has suffered (either in terms of finalists or cut videos).

The AMVs played in the ACen AMV room itself the last couple years have been run off computer output (VGA) to a 1024x768 LCD projector. The showings in other programming rooms were run off a DVD video.

My opinion has always been that the rules and requirements for a contest are part of the judging. If you don't follow them no matter how slight the error then it means you are not doing quality control or you are showing the contest coordinators a lack of respect. I have made people re-submit for rule infractions but there's always been a gradual period before a rule restriction went into place so for a regular submitter there have never been any confusing changes.

I think my biggest concern though with new videos after ACen's entries this year are the number of people mixing 720x480 4:3 and 16:9 footage without doing any frame size conversion. Example: Make 720x480 4:3 video and put some 16:9 720x480 anamorphic source into it without re-sizing and cropping it. This looks BAD and is directly noticeable. Based on Xstylus comments earlier I wonder if he saw any vids like this during AX judging. This is probably a point that needs to be hit on an evangelical level for newer AMV creators. Most of them are going to fall into a space experienced editors did not. That is to say having lots of mixed sources because of the new wave of widescreen shows we are now in. Yet many fan favorite shows are still 4:3 and even some new ones are.

[Vlad G Pohnert]

Well, Once everything is running on HD standards (480 p, 720p, 1080 p) things will be eaiser, but lets be honest, 4:3 /NTSC is slowly beign phased out but it will not happen overnight so we as contest coordinators are gong to have to keep dealing with it for a while..

Vlad

[outlawed]

Well, Once everything is running on HD standards (480 p, 720p, 1080 p) things will be eaiser, but lets be honest, 4:3 /NTSC is slowly beign phased out but it will not happen overnight so we as contest coordinators are gong to have to keep dealing with it for a while..

4:3 and NTSC isn't going anywhere for a long time especially when a lot of AMV creators work from DVDs!

I hope no one thought I was saying otherwise. I was trying to point out was that by restricting and controlling formatting requirements you can eliminate a lot of issues such as these aspect ratio questions. Too many contests have broad rules that effectively say "send me MPEG-2 file; send me avi file." Yes I'm exaggerating but there is some truth there.

For example Meli's discussion these last couple pages about her Huffyuv and wondering how do they play it back since it has no aspect ratio set? One method to prevent that entrant worry/consideration/question is to require Huffyuv at 848x480 for 16:9 AMVs. With ACen's reqs I geared MPEG-4 for square pixel submitters ("digital file generation") and MPEG-2 for NTSC submitters ("I likes to send DVDs to muh friends").

*Checks clock on wall proceeds to GTFO soapbox*

Obviously we are now way outside the thread topic and I'm on the verge of hi-jacking so that will be my last post about contest submission formats in general.

[DigitalPanther]

well just to clear up for those wondering.
I was using Adobe Premiere Pro CS3, I am now using CS4. Most of the big problems went away. A couple of little new ones showed up. but they are easily dealt with.(for some reason if the mpeg2 doesn't have the sound in just such a way, Premiere ignores it. Simple fix. Use XviD4PSP to extract the audio as a wav and slap it in the time line (Thanks for pointing me to that program its proving very useful). Aside from that CS4 has been working like a champ. Though the fact that their encoder is external to the editor is taking a little getting used to.

I have no problem with interlaced footage. I started editing on dual S-VHS Panasonic A-570s (I think that was the model) in college so I am familiar with the whole field thing. Thats how I was able to identify the problem and explain it to the audience the year the AMVs went crunchy in 2002 (ahhh memories of things I never want to have to do again). The only time I have field problems anymore is if they are in the source to begin with. If they are throughout the whole vid I just flip the field order or deinterlace it in premiere and that sometimes fixes it. However if it is in just a small segment (like was in one of the finalists for pro last year (which still ended up winning the Pro category last year) I don't bother because at that point I am editing the editors creation and there are ethical and propriety issues.

If its a small enough segment 95% or more of the viewers won't catch it. But for those of us who know what to look for its pretty obvious. Either way I am rambling. my point is that I agree that entrants should check their video on multiple sources before sending. This won't catch it 100% of the time as was illustrated by Kaze's issues, but 99% of the time it will.

On the whole aspect ratio front, I make a habit of telling premiere to maintain aspect ratio of source (they now call it "Zoom to frame size" as of CS4.) this makes it so that letter boxing is automatically done if needed. However if someone submits an anamorphic without the flags set it won't help. I can usually spot it and tell the player to play it 16:9 but I start to walk that "am I crossing the propriety" line. My personal preference is square pixels at the appropriate aspect ratio resolution. That way you don't have to worry about if flags are set right. It is the right size pixel for pixel. However, that is only my opinion.

I have considered flat out banning certain codecs and there are one or two that will likely go off the list next year, but with very few exceptions, it wasn't that big an issue this year. If I hadn't switched to CS4 .mp4 would have been sooooooo gone.

Lets seee am I forgetting anything?... OH the program I was using to view the files at the judging. For the most part it was GOMPlayer. I have found it generally works better and handles more formats cleanly than VLC. For WMVs I used Windows media player because for some reason GOM was having issues with them and for the various Quicktime formats the Quicktime player.

OH backtracking a bit, on the HD front. I render everything for 4:3 because of the fact that renting HD video setups is expensive. VERY expensive. I did the discs widescreen last year because the built in equipment at Nokia was all set for it. But since we aren't using Nokia this year its back to 4:3. Eventually I would like to go HD with it. Once I get a blu-ray burner and teach myself how to engineer it (and build my new edit rig).

Hope that wasn't too random.
-Michael

[milkmandan]

Since the contest demanded "NTSC Standard of 720 by 480 pixels resolution", etc., I kind of assumed that any video files submitted at that resolution but in a format that didn't support aspect ratio flags, e.g. a HuffYUV AVI, would simply be recompressed to MPEG-2 for either playback from a decoder card or burning to a playable DVD, without bothering to resize.
If such was the case, then you'd want to use the same script no matter what format you were submitting in (resize to 720x352 and letterbox it up).

Of course, only the contest coordinator would know whether this is the case or not.

@milkmandan: changing the amount of borders added with AddBorders() would not help; the video itself would still be stretched. If you needed letterboxed video at square pixels for some reason, you'd want to resize to 640x352 first and then letterbox to 640x480.

I was actually referring to the "or" part of the rules that did not include "NTSC Standard". This was on the FanimeCon's FMV rules as well. No one ever states what the PAR should be for formats that don't support flags. I remember one year at AX, they were playing AMVs off a laptop or something :\ Don't know if they even bothered to reconvert to mpeg2 and just left as it was. :\

Going with meli's example in picture 3, i assumed it was in square pixel.
If meli did want 720x480 square pixel (for whatever reason), and for it to look non-stretched, then changing the addBorder() values would work.
The images that we see in picture 2 is basically what you suggested. (resize to 640x352 and then letterbox to 640x480)

The AMV was down-converted from a 720P HD source, editing enough was bitch let alone wait 8-10 hours to get it encoded. Adobe couldn't fixate on doing a proper aspect ratio, and add scripting on top. It was a mess.

even with scripts (Avisynth)

I am not sure if you have a new computer Dean, but I used to be in your situation. My old machine was terribad i had issues editing 480p as it was.
I thought your AMV was kept in 720p? The one you gave me to preview was 720p, if i recall correctly.

Well in any event, you mentioned "adobe fixating proper aspect ratio" and "scripting on top". This suggests to me that you are importing .avs files straight into APP? If you are doing this, while it does save LOADS of HDD space, it's extremely CPU intensive to work with. :\
I would move away from this style (seriously, $/GB is dirt cheap). you will experience crashes.
Your sources in APP, 720p or not, should already be 'script' free, and resize/transcoded/cleaned up, all before hand.
Vlad is right, if you did this, the only real struggle working with 720p would be uber long encodes/preview times

My process of DVD to finished product goes something like this:

-Rip DVD with DVD Decrypter
-Index File with DGIndex
-Create an Avisynth Script and apply filters
-Import script into VirtualDubMod and create Lossless clips (I prefer lagarith for the clips because the files are smaller)
-Edit video and finish video
-Select "Disable resample" on every clip that is slowed down or sped up to prevent any ghosting
-Export the complete file, either HuffYUV or Lagarith
-Compress with TMPGEnc for MPEG, VirtualDubMod for XviD, or Zarx264GUI for MP4

Very nice.
Hmm "disable resample". Never knew there was an option for this :\
Anyone know if this is present in Premiere? I'd like to try it on a current project of mine, it might help with ghosting.
Other than that, this is perfect way to do it, me thinks.

The editing program I use is Sony Vegas 6. As for the resizing before editing part, I think I am going to begin editing at 720x480 instead of re-sizing first since the end result seems to be a slightly better quality file and the lossless clips will be smaller. When I was starting out I liked to resize to square pixels because I was afraid that I'd forget to resize any effects or text I would add in and it would result in those said effects or text looking off when I resized after exporting. I've never changed that habit, maybe it's time I did.

I personally wouldn't recommend doing 0.9 PAR (720x480) for editing. Stick with Square Pixel Aspect Ratio. You really shouldn't be hitting quality loss. What You See Is What You Get. :\ WIZYWIG!

Having to have to resize all your imported text or images, just to compensate for 0.9 PAR is just annoying :\
i rather have my actual editing process be as painless as possible.

If you know what you're doing, you'll never have a problem with Aspect Ratio.

And reposting what outlawed said, since i totally agree...

It is a given that the footage will be converted before editing. Editing in MPEG-2 that is not 100% I-frames would be very dumb so it will be transcoded in one way or another whether intermediate huffyuv files or avisynth scripts feeding the footage on the fly. We both know most editors source from DVDs and few AMV creators left are even capable of properly editing in an interlaced environment so they will have to make it progressive. 16:9 720x480 anamorphic video is not square pixels. If one were planning to apply any compositing, effects, or added original content it would be a LOT easier working in square pixels. It's also better for preview on a computer to work in square pixels. Converting this source to 848x480 makes good sense.

Keep in mind you are also limited by the source quality on the DVDs themselves. Not all DVD releases are picture perfect video by any means. To what level AMV video quality is judged or nitpicked is AX's call though. I would expect the TVpro thing or whatever it was called would weigh this more heavily.

Woot for R2

On the whole aspect ratio front, I make a habit of telling premiere to maintain aspect ratio of source (they now call it "Zoom to frame size" as of CS4.) this makes it so that letter boxing is automatically done if needed. However if someone submits an anamorphic without the flags set it won't help. I can usually spot it and tell the player to play it 16:9 but I start to walk that "am I crossing the propriety" line. My personal preference is square pixels at the appropriate aspect ratio resolution. That way you don't have to worry about if flags are set right. It is the right size pixel for pixel. However, that is only my opinion.

Going off on this, should I have not letterboxed my videos then? >_< mine was in anamorphic glory.
@Michael: btw still experiencing any problems ?

Once I get a blu-ray burner and teach myself how to engineer it (and build my new edit rig).

dual quad i7 xeon
i can provide suggestions and tips

Lets seee am I forgetting anything?... OH the program I was using to view the files at the judging. For the most part it was GOMPlayer. I have found it generally works better and handles more formats cleanly than VLC. For WMVs I used Windows media player because for some reason GOM was having issues with them and for the various Quicktime formats the Quicktime player.
-Michael

CCCP!

[Scintilla]

Since the contest demanded "NTSC Standard of 720 by 480 pixels resolution", etc., I kind of assumed that any video files submitted at that resolution but in a format that didn't support aspect ratio flags, e.g. a HuffYUV AVI, would simply be recompressed to MPEG-2 for either playback from a decoder card or burning to a playable DVD, without bothering to resize.
If such was the case, then you'd want to use the same script no matter what format you were submitting in (resize to 720x352 and letterbox it up).

Of course, only the contest coordinator would know whether this is the case or not.

I was actually referring to the "or" part of the rules that did not include "NTSC Standard". This was on the FanimeCon's FMV rules as well. No one ever states what the PAR should be for formats that don't support flags.

What do you mean, "'or' part of the rules"? This is all the original post says about submission resolution, etc.:

Note: All digital video formats submitted to the contest are required to follow NTSC Standard of
720 by 480 pixels resolution at 29.97 frames per second interlaced or 720x480 pixels resolution
at 24 frames per second progressive. Videos submitted in 24fps will be converted to 29.97fps.
The 3/2 pull down conversion (to make 24fps video NTSC compliant for presentation) may cause
entry video to appear jittery in fast action scenes.

What part of this doesn't fall under NTSC standard resolution/AR?

@milkmandan: changing the amount of borders added with AddBorders() would not help; the video itself would still be stretched. If you needed letterboxed video at square pixels for some reason, you'd want to resize to 640x352 first and then letterbox to 640x480.

Going with meli's example in picture 3, i assumed it was in square pixel.
If meli did want 720x480 square pixel (for whatever reason), and for it to look non-stretched, then changing the addBorder() values would work.
The images that we see in picture 2 is basically what you suggested. (resize to 640x352 and then letterbox to 640x480)

Again: no, merely changing the AddBorder() values would NOT work, because the LanczosResize(720,352) part is what makes it stretched when viewed as square pixels. If Meli did want 720x480 square pixel, then she'd need something like this:

LanczosResize(720,400)
AddBorders(0,40,0,40)