OSSC Pro

[Kez]

Is it possible to upscale and downscale simultaneously? For example a 480p HDMI input, I would like to output 240p to a 15hz broadcast monitor and also upscale to lets say 1080p for video capture purposes

I doubt this would be feasible with a single device.

[shroom2k]

Is it possible to upscale and downscale simultaneously? For example a 480p HDMI input, I would like to output 240p to a 15hz broadcast monitor and also upscale to lets say 1080p for video capture purposes

I doubt this would be feasible with a single device.

Yeah, that might be asking too much. Best you can hope for is dual output where one is a pass-through. Or use multiple devices with splitters.

[Downcry]

I was doing some calculations, and found that for 256 mode games (NES, SNES, Genesis 256 mode, etc.), it's possible to reach perfect signal aspect ratio correction at a size of 8 by 7 (2048x1680). Is this within the realm of something the OSSC Pro can do? Thankfully it's within the 4K range for 4K TVs if doable.

Even with reduced blanking, 2048x1680_60 needs pixel clock of almost 230MHz. That significantly exceeds max. input video clock spec of ADV7513 (165MHz) so I'm afraid it wouldn't work reliably, at least with all samples. The only dedicated TX chip with higher spec I'm aware of is SiI1136 (300MHz), but its programming guide is under NDA.

With the prevalence of 4K, I’m surprised there aren’t more widely available components which can support it.

[6t8k]

- Are power requirements such that one could potentially reuse a PSU that was initially shipped for use with the original OSSC? My observation is that max. current flow rating of PSUs included by sellers is usually quite spot-on, so I'd assume that's a no (in most cases)
- Will the type/dimensions of the PSU barrel connector be unchanged? If yes, people that power their OSSC with a PSU that has more reserves could potentially reuse it without needing an adaptor.
- Will it be possible to power expansion modules via GPIO pins?
- Will we be able to reuse the common remote? I see no reason why this shouldn't be possible, so I'm inclined to take this for granted – but maybe it's not, so I'm just asking explicitly for good measure (overlay stickers will benefit from an update, though)

I'd also love to see expansion modules use the main unit's display and SD card slot – e.g. for firmware updates, but not necessarily limited to that – instead of bringing their own (unless the device's function requires certain dedicated components of that kind).

[BuckoA51]

- Are power requirements such that one could potentially reuse a PSU that was initially shipped for use with the original OSSC? My observation is that max. current flow rating of PSUs included by sellers is usually quite spot-on, so I'd assume that's a no (in most cases)

Yeah it doesn't have enough amps (although I'm running my proto with the OSSC Classic PSU and it's been OK so far). Since there's only a few cents difference I'll eventually phase out the OSSC Classic PSU and sell only the PSU that works with both.

- Will the type/dimensions of the PSU barrel connector be unchanged? If yes, people that power their OSSC with a PSU that has more reserves could potentially reuse it without needing an adaptor.

Yeah same connector.

- Will it be possible to power expansion modules via GPIO pins?

You'd have to ask Markus on that one.

- Will we be able to reuse the common remote? I see no reason why this shouldn't be possible, so I'm inclined to take this for granted – but maybe it's not, so I'm just asking explicitly for good measure (overlay stickers will benefit from an update, though)

There's more functions on Pro than will fit on the existing remote, though it should at least partially work. However the plan is for a new custom designed remote to be fully backwards compatible with OSSC classic and indeed replace the generic remote.

[marqs]

- Are power requirements such that one could potentially reuse a PSU that was initially shipped for use with the original OSSC? My observation is that max. current flow rating of PSUs included by sellers is usually quite spot-on, so I'd assume that's a no (in most cases)
- Will the type/dimensions of the PSU barrel connector be unchanged? If yes, people that power their OSSC with a PSU that has more reserves could potentially reuse it without needing an adaptor.

The connector is the same and estimated max. current is ~1.5A.

- Will it be possible to power expansion modules via GPIO pins?

Yes, there are pins for 5V and 3.3V.

- Will we be able to reuse the common remote? I see no reason why this shouldn't be possible, so I'm inclined to take this for granted – but maybe it's not, so I'm just asking explicitly for good measure (overlay stickers will benefit from an update, though)

NEC IR protocol is still used so the old remote works fine.

I'd also love to see expansion modules use the main unit's display and SD card slot – e.g. for firmware updates, but not necessarily limited to that – instead of bringing their own (unless the device's function requires certain dedicated components of that kind).

I2C and 2 outputs from clock generator are also routed to the expansion connector to provide some basic building blocks for expansion modules.

[6t8k]

Thank you both for the clarifications!

[XtraSmiley]

That being said, Marqs, it's now August. Can we have a sliver of an update on where the project is currently?

A second prototype board should be finished soon. Estimates on release date etc. will have to wait until that's on my hands and verified. It's also worth remembering that even if the prototype HW works flawlessly and is ready for production, firmware is still far from the point which I feel comfortable releasing it with.

Awesome news and perfectly great update as far as I'm concerned! Thank you!

One of the most interesting features I'm curious about is the screen rotation ability. Can you talk at all about how the development is going for this feature? I assume it's able to rotate both directions, and potentially able to save per setting/PCB? Any feedback on added lag for this feature?

Thanks again Marqs, I know you and the team are super busy working on this, we are very excited!

[kardus]

Will this be able to go beyond the 1080/1200p of the previous ossc?

[marqs]

One of the most interesting features I'm curious about is the screen rotation ability. Can you talk at all about how the development is going for this feature? I assume it's able to rotate both directions, and potentially able to save per setting/PCB? Any feedback on added lag for this feature?

Thanks again Marqs, I know you and the team are super busy working on this, we are very excited!

The thing is that there's no team working on HW/SW (at least not yet) - it's just me trying to put some effort on my spare time. Therefore it's way too early to talk about any scaler mode related developments when there's still so much to do before that. It's not that rotation is particulary hard but there are many higher priority items right now. For its latency, you should expect 1 frame at minimum since you're essentially seeing part of last source line on the first line of rotated picture.

Will this be able to go beyond the 1080/1200p of the previous ossc?

This one has been asked too many times. Pixel clock of 200MHz should be possible whereas original ossc can reliably run at 165MHz.

[XtraSmiley]

One of the most interesting features I'm curious about is the screen rotation ability. Can you talk at all about how the development is going for this feature? I assume it's able to rotate both directions, and potentially able to save per setting/PCB? Any feedback on added lag for this feature?

Thanks again Marqs, I know you and the team are super busy working on this, we are very excited!

The thing is that there's no team working on HW/SW (at least not yet) - it's just me trying to put some effort on my spare time. Therefore it's way too early to talk about any scaler mode related developments when there's still so much to do before that. It's not that rotation is particulary hard but there are many higher priority items right now. For its latency, you should expect 1 frame at minimum since you're essentially seeing part of last source line on the first line of rotated picture.

Will this be able to go beyond the 1080/1200p of the previous ossc?

This one has been asked too many times. Pixel clock of 200MHz should be possible whereas original ossc can reliably run at 165MHz.

No team!!!! Wow, I thought you had help working on this right now, but I see that it is for later!

Amazing work then, all on your own!

Thanks for the reply as well!

[dc_coder_84]

What about a screenshot function for the OSSC Pro? Maybe copy the framebuffer content to SD card and with an external but yet to be written software convert the data to a PNG file. Is that a stupid idea? Not sure... At least I would like that functionality

[H6rdc0re]

Would it be possible to double refreshrates? With new TV's we're getting 1080p 120Hz support and this cuts input lag in half.

[marqs]

What about a screenshot function for the OSSC Pro? Maybe copy the framebuffer content to SD card and with an external but yet to be written software convert the data to a PNG file. Is that a stupid idea? Not sure... At least I would like that functionality

It is possible. One might as well put a FT602Q on an expansion PCB and turn it into a video capture device.

Would it be possible to double refreshrates? With new TV's we're getting 1080p 120Hz support and this cuts input lag in half.

1080p@120Hz pixel clock of 300MHz exceeds current HW capabilities but 720p@120Hz is still doable. Duplicating refresh rate will cause you min. half-frame latency on input side, though.

[juji82]

One might as well put a FT602Q on an expansion PCB and turn it into a video capture device.

somebody make it happen!

[yoshiyukiblade]

That would be the holy grail of retro capture. I hate having to throw dice to test multiple HDMI capture devices, and few testers give good/detailed information on specifics. Full RGB capture is quite uncommon and only appears in the pricier devices. I often see YUY2, which is acceptable in some cases, but you'll still be throwing dice between the color matrix (601/709) and range (limited/full). Furthermore, the YUY2 chroma subsampling has to be compensated with 2x horizontal pixel multiplication or better, which is only available in the optimal sampling modes. Getting perfect capture straight off the unit would be a godsend. In the meantime, I'm stuck with the first gen Cam Link.

[BuckoA51]

No team!!!! Wow, I thought you had help working on this right now, but I see that it is for later!

Amazing work then, all on your own!

Thanks for the reply as well!

Right now all our efforts are focused on getting the hardware ready. Of course it will be much easier for the community to develop software when they can actually buy some hardware to run it on

[6t8k]

One might as well put a FT602Q on an expansion PCB and turn it into a video capture device.

With its 100MHz * 32bit parallel bus / 400MB/s burst rate, when the "245" bus protocol is utilized, it should be capable of sustaining 1920x1080p60 8bpc RGB, provided the USB host is able to keep up. 1920x1200p60 and 1920x1440p60 timings would be possible by using YUY2 (4:2:2 chroma subsampling). The FT602Q would on paper allow for a very tidy solution: it implements the USB 3.0 PHY, the device controller, as well as the UVC protocol (no need to install a driver on any of the three major desktop operating systems), all in silicon.

But its UVC configuration is static and can only be reprogrammed via an FTDI tool, and it seems like it's not possible to have different pixel formats depending on resolution/framerate, for one UVC channel.
This means that when opting for RGB, one will not be able to use 1200p and 1440p – if, on the other hand, one chooses YUY2, these will be available, but in return every video timing will (need to) have YUY2 pixels.
Switching between both tradeoffs would require manually falling back on the configuration tool every time. Perhaps it's possible to work around this somehow...

The other thing is, I'd expect such an expansion module to pass through the OSSC-generated LPCM audio (after optional processing) to the host through the same cable, which is unfortunately not possible with this chip.

[marqs]

One might as well put a FT602Q on an expansion PCB and turn it into a video capture device.

With its 100MHz * 32bit parallel bus / 400MB/s burst rate, when the "245" bus protocol is utilized, it should be capable of sustaining 1920x1080p60 8bpc RGB, provided the USB host is able to keep up. 1920x1200p60 and 1920x1440p60 timings would be possible by using YUY2 (4:2:2 chroma subsampling). The FT602Q would on paper allow for a very tidy solution: it implements the USB 3.0 PHY, the device controller, as well as the UVC protocol (no need to install a driver on any of the three major desktop operating systems), all in silicon.

But its UVC configuration is static and can only be reprogrammed via an FTDI tool, and it seems like it's not possible to have different pixel formats depending on resolution/framerate, for one UVC channel.
This means that when opting for RGB, one will not be able to use 1200p and 1440p – if, on the other hand, one chooses YUY2, these will be available, but in return every video timing will (need to) have YUY2 pixels.
Switching between both tradeoffs would require manually falling back on the configuration tool every time. Perhaps it's possible to work around this somehow...

The other thing is, I'd expect such an expansion module to pass through the OSSC-generated LPCM audio (after optional processing) to the host through the same cable, which is unfortunately not possible with this chip.

The bandwidth is still too low for 4:4:4 1920x1080p60 unless blanking can be omitted. I think it would be mainly useful for capturing lower-res signals in raw form, assuming support for RGB/YUV444 can be hacked since they are not part of UVC spec. Another issue is that currently there are 32 GPIOs whereas the chip needs a couple control/status signals on top of the 32bit parallel bus.

[energizerfellow‌]

The bandwidth is still too low for 4:4:4 1920x1080p60 unless blanking can be omitted. I think it would be mainly useful for capturing lower-res signals in raw form, assuming support for RGB/YUV444 can be hacked since they are not part of UVC spec. Another issue is that currently there are 32 GPIOs whereas the chip needs a couple control/status signals on top of the 32bit parallel bus.

For the UVC side at least, I thought UVC kind of supported whatever the device claimed it does. Magewell even has a tool for their USB capture cards to change what the capture card reports over USB for UVC supported modes with adjustment in like 2 pixel increments. Off the top of my head, the Avermedia Live Gamer Ultra and all of Magewell's current cards will do 1920x1080p60 @ 4:4:4/RGB over USB 3.0 and are UVC.

[6t8k]

Yeah, UVC is agnostic to the video format being transported. The receiving application on the host has to have access to an applicable decoder. Only active pixels need to be transmitted.

Another issue is that currently there are 32 GPIOs whereas the chip needs a couple control/status signals on top of the 32bit parallel bus.

I believe this could be solved with a shift register: PCLK * 2 / 3 in exchange for bus width * 4 / 3 in the RGB/4:4:4 case (24 pixel-GPIOs from the Pro), and PCLK / 2 in exchange for bus width * 2 in the YUY2/4:2:2 case (16 pixel-GPIOs from the Pro).
Edit: oh, actually the FT602 prescribes the clock. A dual-clock/asynchronous FIFO then. Again on the expansion module's side, but this time it crosses clock domains, and there could be a performance penalty depending on how it's driven. Edit²: the example project uses this as well.

[marqs]

Yeah, UVC is agnostic to the video format being transported. The receiving application on the host has to have access to an applicable decoder. Only active pixels need to be transmitted.

Does that mean you could also inject audio in there if you had a custom decoder? If only active video is transmitted, 1080p60 4:4:4 is possible in theory (373MB/s), but requires the USB host to keep up so that the 16kB FIFO doesn't remain full for too long at a time.

Another issue is that currently there are 32 GPIOs whereas the chip needs a couple control/status signals on top of the 32bit parallel bus.

I believe this could be solved with a shift register: PCLK * 2 / 3 in exchange for bus width * 4 / 3 in the RGB/4:4:4 case (24 pixel-GPIOs from the Pro), and PCLK / 2 in exchange for bus width * 2 in the YUY2/4:2:2 case (16 pixel-GPIOs from the Pro).
Edit: oh, actually the FT602 prescribes the clock. A dual-clock/asynchronous FIFO then. Again on the expansion module's side, but this time it crosses clock domains, and there could be a performance penalty depending on how it's driven. Edit²: the example project uses this as well.

There's still possibility to increase the number of GPIOs although that would mean I have to free up some FPGA pins.

[6t8k]

Does that mean you could also inject audio in there if you had a custom decoder?

UVC allows this, but I don't think it's guaranteed that the FT602 does as well, in particular when the host comes into play. Rather than making allowances for the UVC standard as a whole, the chip was designed with an explicit subset of primitives in mind, and wraps UVC's framework around that to achieve its purpose.

I think one would just have to try it out. Not only would the custom decoder need to be installed, there also remains the aspect that existing host software would possibly have to be convinced to use a different decoder for a given standard format than it normally would, if it's not possible to teach the FT602 to report the custom codec correctly. This could be avoided with a custom device driver that separates audio and video beforehand, but at the latest by now, we are sidestepping UVC and wouldn't need a chip specializing in it in the first place. Maybe it could work with some steganography-style in-band signalling :p

I think it's actually relatively simple, it just seems caveat-laden due to a few limitations of the FT602.

Here's an I/O graph I created with the Magewell USB Capture HDMI Plus (released mid-2017) via usbmon and Wireshark on a ~6 years old Intel Haswell USB 3.0 laptop while capturing 1920x1080p60 RGB24 and 48kHz 16bit LPCM audio. For audio, it exposes a separate USB endpoint (and associated pipe) over the same physical socket, behaving like a sound card with an output stream that can be fed into an application for capture/playback:

Spoiler

Here's a different measurement, zoomed in, you can even see the individual frames.
Please ignore the denoted throughput, it was about the same as in the first screenshot, it's just not calculated correctly due to the interval setting:

~376.4MB/s: just a little bit of overhead beyond the theoretical 1920*1080*24*60+48000*16*2. There are no dropped frames at all and there's a perceived latency of ~200ms or so. I'm curious as to how the Magewell achieves its performance and features. With that optional scaling there's no doubt it's fitted with an FPGA (not implying a OSSC Pro extension module would need an FPGA too). I wouldn't mind taking a peek at the PCB, but I don't have a Torx bit that's small enough (it's on its way).

There's still possibility to increase the number of GPIOs although that would mean I have to free up some FPGA pins.

That's good to know, I hope doing that wouldn't create other inconveniences. Depending on whether operating multiple expansion modules simultaneously is an intended feature, it could still be favorable for a single module to consume as few GPIOs as possible.

[FBX]

@Marqs,

Any chance on updating the microSD port to a spring-loaded version? I noticed on your OP you're using the one from the original OSSC (and strangely rotated inward). That port sucks ass because you don't get any feedback on whether you have the card securely installed. Once person already messaged me about fixing his as he bent it to hell.

[marqs]

@Marqs,

Any chance on updating the microSD port to a spring-loaded version? I noticed on your OP you're using the one from the original OSSC (and strangely rotated inward). That port sucks ass because you don't get any feedback on whether you have the card securely installed. Once person already messaged me about fixing his as he bent it to hell.

Yes, the design has a spring-loaded version (503182-1852) - the pictures in OP are more concept than actual design CAD. In a month the second prototype round should be finally manufactured so you can expect actual photos then.

[SuperSpongo]

I am so PUMPED for this

[DatMonkey]

I just read that the Pro would be able to convert 1080p -> 1080i (awesome!). Would it be possible to do 1440p -> 1440i or would that exceed the limitations?

[vol.2]

I just read that the Pro would be able to convert 1080p -> 1080i (awesome!). Would it be possible to do 1440p -> 1440i or would that exceed the limitations?

That is very cool. I am most interested in XXX-> 540p.

1080i scaling for modern titles is a great feature, but a quick and dirty 480p->540p, & 240p->540p would open up every Sony HISCAN tv out there to an easy digital processing fix. That's thousands of 850 line 32" CRTs.

[strayan]

I just read that the Pro would be able to convert 1080p -> 1080i (awesome!). Would it be possible to do 1440p -> 1440i or would that exceed the limitations?

That is very cool. I am most interested in XXX-> 540p.

1080i scaling for modern titles is a great feature, but a quick and dirty 480p->540p, & 240p->540p would open up every Sony HISCAN tv out there to an easy digital processing fix. That's thousands of 850 line 32" CRTs.

I thought you could already do this with a DVDO.

[Fudoh]

of course you can. And with a myriad of other processors as well. 480p to 540p just usually isn't very nice to look at. It makes more sense to pad the area to 540p instead and try to compensate by maxing out th overscan on the TV instead.