Revision 2015 - 3rd to 6th April - Saarbrücken, Germany
category: parties [glöplog]
Quote:
the stuttering video on the bigscreen
You mean the unstable image of C64 prods? Looked to me like an issue with the de-interlacer.
Not just C64; nearly every non-PC entry suffered very badly from this. Could be an issue with the scaler, in which case a Framemeister is probably the best solution unless it's simply a case of a misconfiguration.
I heard theories about it being an error in video playback rather than in capturing though.
I heard theories about it being an error in video playback rather than in capturing though.
Not that serious an error, considering all motion is raped by the time it gets shown anyway. Waiting for proper end-to-end 50 Hz video streaming.
Zavie: Not the Burgerking in Saarbrücken. ;)
radiantx: Not an official answer as I'm not an organizer but I heard that the new Apple codec that is used for the new recording setup doesn't have hardware acceleration and consumes a great bunch of CPU time. This is now a known issue.
The stuttering video on the bigscreen was our fault, sorry. We went to a new, fancy Full-HD capturing solution this year and there just were a lot of small problems to solve that we didn't anticipate :/
In case you're interested, here's how stuff works and where the stuttering came from, and how I fixed the stuttering for the last compo block on Sunday evening (you might have noticed that the Oldschool 4K and Amiga Demo compos didn't stutter anymore):
The outputs of whatever computer or other electronic contraption we want to capture goes into a Barco ImagePro2 (scan converter, scaler, switcher, basically "takes any video signal and converts it to any other"). If the ImagePro2 has problems detecting the image (the almost-PAL aka "288p@50.02" of a C64 springs to mind) we optionally put an old Sony DSC-1024 in front of it to stabilize the signal first.
We can then adjust colors and scaling a bit in the ImagePro2, and de-/reinterlace the video. The slight interlace flicker in the C64 captures shouldn't have happened, this is something we need to improve on for next year.
The ImagePro2 is set to output 720p/1080i at 50/60Hz or 1080p at 25/30, depending on what we're recording and what fits best. The converted signal goes over a SDI or HDMI wire into a decicated BlackMagic HD recorder which encodes the video as Apple ProRes 4:2:2 and stores it on an SSD.
Last but not least that SSD is plugged into a PC where we apply final edits to the video and batch-convert a bit of the weirdness out of it. The files are then stored (still as ProRes 4:2:2 with uncompressed sound) on our central file server where the beam team downloads them before the compo and plays them with Media Player Classic HC using the Sync Renderer and a few other custom settings.
This is indeed a perfect end-to-end 50Hz (or whatever other refresh rate) chain but it has so many devices with so many options in it that it's really hard to get this right. I/We underestimated how complicated it can get and what weird errors happen in the middle (somehow the original video has 16 audio tracks of which 14 are naturally empty, we need to filter that out before playback) so yes, it wasn't perfect - but still IMO the oldschool stuff looked way better than before. Just compare Amiga demos with starfields to old recordings, will you? :)
There are some occasional frame drops/repeats because especially old computers just don't run at perfect 50Hz. Eg. 8bit machines or noninterlaced low-res Amiga modes run at exactly 50*(625/624) Hz, and even if it's supposed to be a perfect 50 sometimes the old stuff just misses. Converting that to a steady 50 means that shit like this happens. The only way to filter out those micro glitches would be manually going through the file and deleting/inserting frames. Alternatively now that we got comfortable with the stuff we'll try fiddling with the genlock settings in the ImagePro2 because perhaps it just lets its input deviate from the output too much.
Now, the stuttering. This is one of the most fucked up bugs we had, and I could only "fix" it because I had a weird hunch on Sunday. So. What happened was that during playback, MPC-HC just stopped for a few 100 milliseconds, often three times in a row, and then it worked again for half a minute or so. We killed almost every process on that machines, updated drivers, nothing helped...
... until I got into the network settings and disabled the 2nd ethernat adapter that was unused.
Yes, this is what happened. The network driver was very busy (as in kernel-space busy) determining REALLY THOROUGHLY that there was indeed ABSOLUTELY NO CABLE PLUGGED IN. Every 30 seconds. And when I turned it off the stuttering was gone completely. MPC-HC reported zero frame drops and glitches (try pressing Ctrl-J and Ctrl-T, it shows a lot of info) and, yay.
Sorry that this didn't work from the get go. But for next year we know how to fix everything. Sometimes new equipment/software just has to "sink in", and given how expensive parts of the equipment are, we weren't able to completely test it before we arrived at the partyplace.
I hope that explains it, and thanks everyone for bearing with us. At least the people I talked to at the party place were very understanding. :)
In case you're interested, here's how stuff works and where the stuttering came from, and how I fixed the stuttering for the last compo block on Sunday evening (you might have noticed that the Oldschool 4K and Amiga Demo compos didn't stutter anymore):
The outputs of whatever computer or other electronic contraption we want to capture goes into a Barco ImagePro2 (scan converter, scaler, switcher, basically "takes any video signal and converts it to any other"). If the ImagePro2 has problems detecting the image (the almost-PAL aka "288p@50.02" of a C64 springs to mind) we optionally put an old Sony DSC-1024 in front of it to stabilize the signal first.
We can then adjust colors and scaling a bit in the ImagePro2, and de-/reinterlace the video. The slight interlace flicker in the C64 captures shouldn't have happened, this is something we need to improve on for next year.
The ImagePro2 is set to output 720p/1080i at 50/60Hz or 1080p at 25/30, depending on what we're recording and what fits best. The converted signal goes over a SDI or HDMI wire into a decicated BlackMagic HD recorder which encodes the video as Apple ProRes 4:2:2 and stores it on an SSD.
Last but not least that SSD is plugged into a PC where we apply final edits to the video and batch-convert a bit of the weirdness out of it. The files are then stored (still as ProRes 4:2:2 with uncompressed sound) on our central file server where the beam team downloads them before the compo and plays them with Media Player Classic HC using the Sync Renderer and a few other custom settings.
This is indeed a perfect end-to-end 50Hz (or whatever other refresh rate) chain but it has so many devices with so many options in it that it's really hard to get this right. I/We underestimated how complicated it can get and what weird errors happen in the middle (somehow the original video has 16 audio tracks of which 14 are naturally empty, we need to filter that out before playback) so yes, it wasn't perfect - but still IMO the oldschool stuff looked way better than before. Just compare Amiga demos with starfields to old recordings, will you? :)
There are some occasional frame drops/repeats because especially old computers just don't run at perfect 50Hz. Eg. 8bit machines or noninterlaced low-res Amiga modes run at exactly 50*(625/624) Hz, and even if it's supposed to be a perfect 50 sometimes the old stuff just misses. Converting that to a steady 50 means that shit like this happens. The only way to filter out those micro glitches would be manually going through the file and deleting/inserting frames. Alternatively now that we got comfortable with the stuff we'll try fiddling with the genlock settings in the ImagePro2 because perhaps it just lets its input deviate from the output too much.
Now, the stuttering. This is one of the most fucked up bugs we had, and I could only "fix" it because I had a weird hunch on Sunday. So. What happened was that during playback, MPC-HC just stopped for a few 100 milliseconds, often three times in a row, and then it worked again for half a minute or so. We killed almost every process on that machines, updated drivers, nothing helped...
... until I got into the network settings and disabled the 2nd ethernat adapter that was unused.
Yes, this is what happened. The network driver was very busy (as in kernel-space busy) determining REALLY THOROUGHLY that there was indeed ABSOLUTELY NO CABLE PLUGGED IN. Every 30 seconds. And when I turned it off the stuttering was gone completely. MPC-HC reported zero frame drops and glitches (try pressing Ctrl-J and Ctrl-T, it shows a lot of info) and, yay.
Sorry that this didn't work from the get go. But for next year we know how to fix everything. Sometimes new equipment/software just has to "sink in", and given how expensive parts of the equipment are, we weren't able to completely test it before we arrived at the partyplace.
I hope that explains it, and thanks everyone for bearing with us. At least the people I talked to at the party place were very understanding. :)
Oh yes, I forgot. I hope the info desk enjoyed the random snacks I dropped off.
Quote:
288p@50.02
Grid fluctuations? :) Or where is the excess .02 coming from?
And yeah, thanks for the stream. Pretty stable and decent quality too.
So you need to buy equipment worth about 20000-30000 eur, and then it almost works? ;)
I wish there was a way to stream the actual signal from the C64 and Amiga as-is, with whatever variable not-exactly-50 Hz or any other refresh rate they produce, and get that signal onto sofa screens. Or at least, somehow deliver 100.0000% of frames produced by the source machine, and show all of them at the viewer screen. A few dozen frames worth of buffering should be enough to stabilize it to keep a frame-by-frame sync throughout the duration of even the longest demos, and nowadays audio can be stretched as needed without anyone noticing anything.
I wish there was a way to stream the actual signal from the C64 and Amiga as-is, with whatever variable not-exactly-50 Hz or any other refresh rate they produce, and get that signal onto sofa screens. Or at least, somehow deliver 100.0000% of frames produced by the source machine, and show all of them at the viewer screen. A few dozen frames worth of buffering should be enough to stabilize it to keep a frame-by-frame sync throughout the duration of even the longest demos, and nowadays audio can be stretched as needed without anyone noticing anything.
tomaes: Normal PAL is 50 fields with 312.5 raster lines each (the .5 results in the next frame beginning a little lower -> boom, interlacing). C64 et al keep the horizontal frequency of 15625Hz but output only 312 lines, omitting the last half one. This way the image ends up stable on analog TVs but the refresh rate is a teensy bit higher because of that. This is also the reason a lot of capture hardware just crashes when confronted with an old 8bit machine. Analog equipment goes like "yeah, whatever" but digital stuff where coders anticipated how the signal would look like just barfs.
@kb: Shit happens! It wasn't killer-annoying IMHO and you finally were able to fix it, so who cares! You and the whole team did an excellent job! THANKS! :)
BTW: Will there be a mp3 of "Threesome with Ronny" available for download?
If you really need it right now, you can grab the SceneSat recording and use the CUE sheet to cut it from the whole file! Of course proper recording with proper cue for the set itself would be killer! :D
I'd like to thank everybody who was involved in "Revision 2015". I think it was a blast - and i wasn't even there! But the whole setup: so many streams, excellent moderation, seminars, the shader compo, live acts and the unbelievable shitload of uberdope productions (!!) as well as IRCing gave me a pretty immersive feeling of really being there. Today in the morning i even had something like a hangover - i wasnt drinking anything though :D - and felt a bit like the boy in the end of that strange animation showed earlier at the party that nobody seemed to understand ;)
Thank you ♥
Thank you ♥
here is a Quite Big gif: (not embedded because like I said, it is Quite Big) :)
http://skjoldbroder.dk/void/big_Capture02353.gif
http://skjoldbroder.dk/void/big_Capture02353.gif
Here are some photos from ted and me:
http://keyj.emphy.de/photos/revision2015/
http://keyj.emphy.de/photos/revision2015/
@kb_ thanks for all the technical details, nice read and a good to know for the future.
Also, thanks everyone - it was a great party and now i'm sad it was only 4 days :(
Also, thanks everyone - it was a great party and now i'm sad it was only 4 days :(
Perhaps this has been discussed earlier, but I don't want to go through 27 pages to find it:
What is up with the Amiga OCS demos being split between Amiga Demo and Oldschool demo?
Was it up to the submitters to choose which compo they wanted to be in?
I think it would be better to have clear guidelines - "Amiga OCS demos goes into XXX" and that's it.
If you ask me, they should all go into the Amiga compo. That opinion may or may not be influenced by the fact that I was involved in a prod in the oldschool compo that ended up having two OCS demos in front of it in the results... ;)
What is up with the Amiga OCS demos being split between Amiga Demo and Oldschool demo?
Was it up to the submitters to choose which compo they wanted to be in?
I think it would be better to have clear guidelines - "Amiga OCS demos goes into XXX" and that's it.
If you ask me, they should all go into the Amiga compo. That opinion may or may not be influenced by the fact that I was involved in a prod in the oldschool compo that ended up having two OCS demos in front of it in the results... ;)
kaputt, aber glücklich!
Thanks to everyone <3
Thanks to everyone <3
I also want to thank everyone for making this years Revision a pleasure for herbaculum and me, lots of great prods!
And a big thanks to our infodesk co-workers, it was fun to work with you all! Hope to see you on the next round! :-)
And a big thanks to our infodesk co-workers, it was fun to work with you all! Hope to see you on the next round! :-)
Oh, by the way, were the 2nd stage DJ sets recorded by the stream team or anyone else? :)
@kb: thanks for the exhaustive explanation. Though, I'm still a bit ticked off that you didn't even bother to re-show the Media Facade entries that stuttered, it's not like there were that many of them. Or, if you did re-show them, I managed to miss it. In any case, I hope the youtube compilation of them works, I cannot check because the hotel net is shit.
I doubt re-showing them would have helped in any way until they found the solution. And re-showing basically most of the Saturaday compos on Sunday would, like, not fit into the party schedule at all?
The eternal problem of tight party schedules is the worst limiting factor of course... as is the risk of entering into the first compos ;)
kb: Nice explaination, thanks! I wish i could thumb forum posts up.
A note: The C64 video signal is actually even more fucked up than 50.02 Hz; it's rather ~50.124 Hz. This is determined by the clock speed of the machine (985248 Hz for a PAL C64) and the fact that there are 312*63 clock cycles per frame. So if you display a captured C64 signal on a 50 Hz digital display you will get a frameskip every tenth second, and this is non-fixable (and why analogue displays are superior).
If you fix the interlace flickering please post about it somewhere; we had that issue with C64 signals in the Edison capturing setup as well. :-)
A note: The C64 video signal is actually even more fucked up than 50.02 Hz; it's rather ~50.124 Hz. This is determined by the clock speed of the machine (985248 Hz for a PAL C64) and the fact that there are 312*63 clock cycles per frame. So if you display a captured C64 signal on a 50 Hz digital display you will get a frameskip every tenth second, and this is non-fixable (and why analogue displays are superior).
If you fix the interlace flickering please post about it somewhere; we had that issue with C64 signals in the Edison capturing setup as well. :-)