July 2, 2018 at 8:45 PM #22304
I’m starting this thread to get an idea of how large a task it would be to add some variety of mode for fixed-rate output, for example constant 59.94 regardless of the input rate or presence of an input signal.
Main reasons I’m looking into this:
-For our purposes, resolution swaps are killer. Even with as fast as the OSSC typically re-establishes connection, it causes significant problems further down our chain which adds longer time before the full feed is available on end devices. Having some way to ensure that it will never have to re-initiate a handshake would stop this.
-Somewhat related to the above, we need to deal with a large number of different consoles, many of which may not be in the best shape or provide the cleanest sync signals. Image quality concerns aside, some consoles are very susceptible to dropping sync spontaneously, forcing a resync. This varies from console to console, even within the same revision, so it can be difficult to predict and account for. It would be great if the output from the OSSC were stable even with momentary sync loss, either providing duplicate frames or blank frames until sync is re-established.
-End device compatibility is also a concern. Some varieties of capture cards and displays tend to be fickle with some combinations of resolutions and framerates, which limits our equipment selection. Having a fixed-rate output for some ubiquitous resolution should alleviate a lot of the pain in troubleshooting why this device or that decided not to play nice with the OSSC output.
-I understand there are drawbacks to this, including loss or duplication of frames due to the input/output frequency discrepancy. It may also require some form of framebuffer, eating up more memory and adding latency. Memory usage is already very high, though I haven’t spent enough time looking over the source code to identify what it’s being used for.
-No, finding and using VP50s in our video chain is not an adequate solution.
As I said at the beginning, I’m looking for ideas and feedback on major roadblocks to implementing something like this. I understand it’s not currently part of the roadmap, and may not be compatible with the current architecture at all. It just seems prudent to ask the folks who are already familiar with the inner workings before diving in and trying to muck with it myself.
~OmniJuly 2, 2018 at 11:03 PM #22305
You’re looking for a device that is able to generate unlocked “standard” refresh rate AND buffer 1-3 input frames. OSSC as is can do the former (e.g. test pattern) but in no way the latter as it doesn’t have external RAM. The FPGA only has ~500 kilobits of internal block RAM while such framebuffer would require a 100-200 megabits if all supported input resolutions (up to 1920×1200) were considered.
It’s unfortunate that VP50 and Framemeister cannot handle transitions without resync even though they should be technically equipped to do so. Along with support for 4k and HDMI sources, frame buffer would certainly be high on the wishlist for a next-generation (gaming-focused) scaler. Scope of such project would be much larger than OSSC, though, so the bar is high for hobbyists. With right people and resources it might still happen someday, but don’t hold your breath.July 3, 2018 at 7:06 PM #22306
The framebuffer is definitely not happening using only the resources on the FPGA, but what is the communication performance with the microSD slot? For sufficiently small sources and a reasonable encoding scheme, it may be possible to send source copies there and process them during output frame generation. Bandwidth limits are a lot rougher for inputs greater than 240p, but most of those sources don’t exhibit many of the same issues, so we could possibly leave them as-is.July 3, 2018 at 11:21 PM #22307
All 4 SD card data pins are wired to FPGA so one could get good read/write performance with a suitable controller, but bandwidth probably isn’t the biggest worry. I think erase speed is the bottleneck since it would block other SD card accesses – even if you managed to time erases to vblank, I doubt it’d be sufficient length even for the smallest sector erase. Another issue is SD card retention as such flash is typically specced to last only ~100k erase cycles.
You might be able to sitestep both issues with a massive SD card, though. With a good lossless compression scheme and low-res content you could maybe run the system for good 5 hours before a 256GB microSD would get full :). That’s assuming changes between read and write modes wouldn’t incur notable latency penalties which might also break the scheme.July 3, 2018 at 11:57 PM #22308paulb_nlParticipant
What about a custom SD card with a RAM chip on it instead of flash? I don’t know how much that would cost to create but a 256GB SD card is around 80 euro 🙂July 4, 2018 at 4:32 AM #22309
It’s annoyingly difficult to find published timing characteristics for microSD flash, but best possible block erase times seem to be in the range of 2 ms, with 5 ms being more typical. Block erases can cover multiple planes in a single erase, but that’s up to the sophistication of the controller or layout scheme. Endurance can also vary pretty widely, but you’re right that 100k is typical rating, with some claiming as much as 2M. Even with a modest sized card at 10k p/e cycles, that’s quite a long period of performance before it needs replaced.
Either way, the point stands that it would very much be dependent on the combination of card quality, encoder performance, and access timing to make it work for that scheme. It’s an interesting idea to theorize about, but from an ease perspective it may just be easier to refactor the code for either a different part or external ram blocks. It would mean manufacturing units ourselves, but that very well might be the better option over embarking on a path that has no guarantee of working.July 5, 2018 at 9:55 PM #22319
You could take a look into the original project that was an add-on card for a FPGA development board (that also has SDRAM). There is also OSSC Wolf project ongoing that consists of several daugthercards directly or indirectly (thru an adapter) compatible with the same DE2-115 dev board (and possibly newer DE10 boards, e.g. DE10-Nano).
- You must be logged in to reply to this topic.