I looked into JWPlayer and doesn't seem like it's possible. We could take JWPlayer sources, add the code and then compile a custom version to do it though.
So reviving this old thread, I finally got around to testing a bit and found out that these tags should really be used instead of manually scaling when a video needs a DAR of 4:3 (or 16:9).
Start AVI dumping process in an emu that uses VFW. Get to the codec selection screen. Select Lagarith, Camstudio, or MLC. Hit the "Configure", button, change some settings, and hit "OK". Then hit "Configure" again. Do you see exactly what you just saw before, or have settings reverted?
I just went to Snes9x and did that. The settings saved.
I've encountered a bug that impacts these tests: Some emulators (not vba23.5 in my tests though), seem to be unable to correctly remember a codec's settings. I suspect it's improper handling of ICM_GETSTATE and ICM_SETSTATE, but I haven't investigated it thoroughly. From what I've seen, this means snes9x, gens, pcejin, and possibly others always compress with default codec settings. This hurts some of the codecs quite a bit (MLC defaults are much faster but much lower compression; Lagarith defaults are singlethreaded and no null-frames).
That's a big find! That's not good if some defaults to colorspace other than RGB, which lucky none do (I think?). Still something isn't right as I know I get NULL frames from Snes9x (or at least I thought I did...).
I should mention Lagarith has the option of adding null frames, saving a ton of space when capturing with .kkapture and emulators like PCSX and Mupen where there are a ton of duplicate frames (50%-75% are dups).
I sure don't remember seeing each sharp pixel on my NES when playing. It was all blur to me =p. It is true that any other resize besides point creates more palettes though, but then again when it is that blurry on the TV, your human mind makes it up anyway.
The link replacement can only happen if it meets certain standards as set by here:
http://tasvideos.org/EncoderGuidelines.html
As such, you can post the link in the submission thread and have a publisher check to make sure it does meet those standards. If needed it meets it, the link may be replaced by a publisher.
It's due to YouTube being picky and me forgetting to fix it for YouTube, so the video needed to be uploaded again. Sorry people. As for the run, that was dang fast! Great job Mukki.
great research natt! Though I don't know how to apply to our current method.
creaothceann, we are doing a lot of YUV444 recently, so the color loss is less now.
There seems to be a bug in version 0.02 related to using Crop in Avisynth. If you use Crop in your script, I would say wait until this is sorted out before using this.
Edit: The bug is due to the fact the plugin does not take into account that a pitch may be bigger than a row, thus comparing values in areas that may not be used. I am trying to get it fix.
I usually set it to 1 to allow x264 decide if it really needs consecutive I-frames, to allow it to place it. I don't think it happens very often or at all, so I don't think there will be much of an increase of filesize.
I think sgrunt meant, more like a place to download the clip. As for your problem, it looks like what I would see when I use DXVA to playback lossless H.264.