MindCandy Volume 3 - demo playlist feedback
category: general [glöplog]
xTr1m: Actually, the motion blur on the highest setting really looks great, so it's in our capture. I'm curious why you think it looks better without it (other than personal preference :-) Maybe you think it hides the clean lines? (I don't)
ryg/keyj: It's not a decoder supported options issue, but rather a bitstream/packing/format compliance issue that I stopped trying to debug after a frustrating few hours. No matter what I tweaked, the authoring app wouldn't accept my x264 test output as compliant, so I gave up.
If I were making an AVCHD, I'd try harder. But we're making a BD-50 so I can accept the 10% less efficient encoder output for a compliant bitstream :)
ryg/keyj: It's not a decoder supported options issue, but rather a bitstream/packing/format compliance issue that I stopped trying to debug after a frustrating few hours. No matter what I tweaked, the authoring app wouldn't accept my x264 test output as compliant, so I gave up.
If I were making an AVCHD, I'd try harder. But we're making a BD-50 so I can accept the 10% less efficient encoder output for a compliant bitstream :)
trixter: Yes, the HRD stuff I talked about falls exactly into the "bitstream/packing/format compliance issue" category, so it's probably that :)
trixter: you misunderstood me... In my opinion, the motion blur is missing completely in your capture. in the alarm-clock part, there are fast digits flying from the right to the left in the background, they all look blocky in every frame, not blurred. I meant that it's a pity there's NONE of the original motion blur.
xtr1m: Thanks for the explanation... but that wasn't my capture, it was plonk420's capture :-)
Don't worry, mindcandy's looks sufficiently awesome.
Don't worry, mindcandy's looks sufficiently awesome.
trixter: oh ok, my bad. As long as it's in MindCandy, all is well :)
I finally had some time to post a few work-in-progress files. Feel free to critique the video quality (although if I did my job right, you won't be able to ;-)
More captures with motion blur, please.
hey trixter, I have one question. Are you artificially adding motion blur to the demos? I'm too lazy to read the 10 pages of the thread. Hope you are not...
I have no problem about adding motion blur to video captures, as it compensates the lack of properly fast refresh rate. You might wanna ask the makers of the demos though, some might actually prefer the blocky motion :)
I think 50 fps should be enough for most demos... Dunno, I feel a bit like adding external motion blur is changing the content/look more than fixing refresh rate problems. It's also true that MC is not about archiving and historically correctness but about show. But then why wasn't Second Reality recorded with motion blur too in MCV1? Bah, I'm fine with any decision is taken anyway, just wanted to express the feeling.
If you capture 6000 frames and merge every 100 frames to make a 60fps capture I'm sure it will look better in most cases.
Yeah, 50fps doesn't need added motion blur. 24fps would definitely benefit from it.
the videos need more interlacing!!!!11 in fact why not interleave 4 fields instead of 2? or maybe 8? that would be SOO RAD!!!!
No, we're not adding motion blur.. they'll be 60fps progressive anyway.
I'd vote for 18.5Mfps and then showing a point of light scanning the screen for the unique CRT viewing experience \o/
I haven't read the whole thread but good move if you didn't add motion blur to the captures.
The captures should be as close as possible to the original productions imo.
The captures should be as close as possible to the original productions imo.
iq, keops: No, I am not adding artificial motion blur. That's the blur in the demo if you run it with full quality. My goodness, what do you take me for? :-) All demos are running at their best quality settings and AA. The only "enhancements" are that they were captured at the proper rate (59.94fps, not 60) and that they were grabbed at 1920x1080 and then spline64'd down to 720p, which I guess you could call an additional antialiasing step. All processed and saved via avisynth scripts using lagarith. It's 2 terabytes of video data (so far). I thought maybe I should have used spline36 after the fact, but I did a quick visual check with both and didn't notice any massive difference so spline64 it was.
kurli: The demos are 60Hz, the footage is 60Hz, the blu-ray is 60Hz, so there is no reason to add blur.
xernobyl: I used to think adding blur made things look better. Now I think it only looks better in static scenes (less video noise, assuming an analog capture). I don't blend across frames any more unless there is no alternative (ie. mocomp fails).
kurli: The demos are 60Hz, the footage is 60Hz, the blu-ray is 60Hz, so there is no reason to add blur.
xernobyl: I used to think adding blur made things look better. Now I think it only looks better in static scenes (less video noise, assuming an analog capture). I don't blend across frames any more unless there is no alternative (ie. mocomp fails).
I should also mention that we had a few 4:3 demos that I had to get creative with. Some are "pillarboxed" but for those that could be cropped to 16:9 without losing anything, I did something like this (800x600 4:3 demo to 720p):
As you can see I was very careful to use "rational" scaling where possible (the above is a 1.5x scale).
Code:
Spline64Resize(1200,900) # 800x600 -> 1200x900
Crop (0,90,0,-90) # crop to 16:9 1200x720
addborders(40,0,40,0) # add borders to 1280x720
As you can see I was very careful to use "rational" scaling where possible (the above is a 1.5x scale).
...did you try asking the groups for an higher res/different aspect version?
For those who didn't loose their sources.
For those who didn't loose their sources.
Each group that gave permission certainly had to know about it :-) The only one I wish we had a higher-res version of is Iconoclast, simply because the imagery would really benefit from it. I tried hacking the binary and got as far as the title screen showing up in 1600x1200 but none of the 3D was there.
Trixter: I did not ask if you did it, complaining, I said it was a good move if you did it ;)
x264 finally passes blu-ray specifications... (overpriced compliance test sponsored by Critereon)
http://x264dev.multimedia.cx/?p=328
http://x264dev.multimedia.cx/?p=328
yeah, we're happy about that. trixter's been testing it out.
Oh, we still need the permission form back for Heaven 7 (hey d-lee, check your email :) and audio commentary if possible. I'd threaten to use the MFX "commentary" if we didn't get the real one in but I'm sure many of you would say go for it. :)
Oh, we still need the permission form back for Heaven 7 (hey d-lee, check your email :) and audio commentary if possible. I'd threaten to use the MFX "commentary" if we didn't get the real one in but I'm sure many of you would say go for it. :)
Results have been so spectacular that x264 will definitely be the encoder for MC3. crf16 is the minimum acceptable quality (it could be a bit higher) and that results in 32G of video+audio data. If the extras don't take up as much room as I think they might, I can lower the ratefactor even more for ludicrous quality.
...and takes one full day to encode on an overclocked (3.2GHz) Core i7.