I doubt this would be feasible with a single device.kardus wrote: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
OSSC Pro
Re: OSSC Pro
Re: OSSC Pro
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.Kez wrote:I doubt this would be feasible with a single device.kardus wrote: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
Re: OSSC Pro
With the prevalence of 4K, I’m surprised there aren’t more widely available components which can support it.marqs wrote: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.FBX wrote: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.
Re: OSSC Pro
- 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).
- 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).
Re: OSSC Pro
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.- 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 same connector.- 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.
You'd have to ask Markus on that one.- Will it be possible to power expansion modules via GPIO pins?
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.- 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)
OSSC Forums - http://www.videogameperfection.com/forums
Please check the Wiki before posting about Morph, OSSC, XRGB Mini or XRGB3 - http://junkerhq.net/xrgb/index.php/Main_Page
Please check the Wiki before posting about Morph, OSSC, XRGB Mini or XRGB3 - http://junkerhq.net/xrgb/index.php/Main_Page
Re: OSSC Pro
The connector is the same and estimated max. current is ~1.5A.6t8k wrote:- 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.
Yes, there are pins for 5V and 3.3V.6t8k wrote:- Will it be possible to power expansion modules via GPIO pins?
NEC IR protocol is still used so the old remote works fine.6t8k wrote:- 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)
I2C and 2 outputs from clock generator are also routed to the expansion connector to provide some basic building blocks for expansion modules.6t8k wrote: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).
Re: OSSC Pro
Thank you both for the clarifications!
-
- Posts: 631
- Joined: Fri Apr 20, 2018 9:22 am
- Location: Washigton DC
Re: OSSC Pro
Awesome news and perfectly great update as far as I'm concerned! Thank you!marqs wrote: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.XtraSmiley wrote:That being said, Marqs, it's now August. Can we have a sliver of an update on where the project is currently?
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!
Re: OSSC Pro
Will this be able to go beyond the 1080/1200p of the previous ossc?
Re: OSSC Pro
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.XtraSmiley wrote: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!
This one has been asked too many times. Pixel clock of 200MHz should be possible whereas original ossc can reliably run at 165MHz.kardus wrote:Will this be able to go beyond the 1080/1200p of the previous ossc?
-
- Posts: 631
- Joined: Fri Apr 20, 2018 9:22 am
- Location: Washigton DC
Re: OSSC Pro
No team!!!! Wow, I thought you had help working on this right now, but I see that it is for later!marqs wrote: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.XtraSmiley wrote: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!This one has been asked too many times. Pixel clock of 200MHz should be possible whereas original ossc can reliably run at 165MHz.kardus wrote:Will this be able to go beyond the 1080/1200p of the previous ossc?
Amazing work then, all on your own!
Thanks for the reply as well!
-
- Posts: 16
- Joined: Sun May 19, 2019 1:05 pm
Re: OSSC Pro
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
Re: OSSC Pro
Would it be possible to double refreshrates? With new TV's we're getting 1080p 120Hz support and this cuts input lag in half.
Re: OSSC Pro
It is possible. One might as well put a FT602Q on an expansion PCB and turn it into a video capture device.dc_coder_84 wrote: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
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.H6rdc0re wrote:Would it be possible to double refreshrates? With new TV's we're getting 1080p 120Hz support and this cuts input lag in half.
Re: OSSC Pro
somebody make it happen!marqs wrote:One might as well put a FT602Q on an expansion PCB and turn it into a video capture device.
-
- Posts: 63
- Joined: Fri Sep 27, 2019 3:47 am
Re: OSSC Pro
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.
Re: OSSC Pro
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 onNo 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!
OSSC Forums - http://www.videogameperfection.com/forums
Please check the Wiki before posting about Morph, OSSC, XRGB Mini or XRGB3 - http://junkerhq.net/xrgb/index.php/Main_Page
Please check the Wiki before posting about Morph, OSSC, XRGB Mini or XRGB3 - http://junkerhq.net/xrgb/index.php/Main_Page
Re: OSSC Pro
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.marqs wrote:One might as well put a FT602Q on an expansion PCB and turn it into a video capture device.
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.
Re: OSSC Pro
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.6t8k wrote: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.marqs wrote:One might as well put a FT602Q on an expansion PCB and turn it into a video capture device.
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.
-
- Posts: 208
- Joined: Thu Sep 27, 2018 1:04 am
Re: OSSC Pro
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.marqs wrote: 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.
Re: OSSC Pro
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.
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.
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).marqs wrote: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.
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.
Re: OSSC Pro
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.6t8k wrote: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.
There's still possibility to increase the number of GPIOs although that would mean I have to free up some FPGA pins.6t8k wrote: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).marqs wrote: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.
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.
Re: OSSC Pro
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.marqs wrote:Does that mean you could also inject audio in there if you had a custom decoder?
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:
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.marqs wrote:There's still possibility to increase the number of GPIOs although that would mean I have to free up some FPGA pins.
Re: OSSC Pro
@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.
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.
Re: OSSC Pro
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.FBX wrote:@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.
-
- Posts: 320
- Joined: Sat Mar 17, 2018 2:49 pm
- Location: Germany
Re: OSSC Pro
I am so PUMPED for this
Re: OSSC Pro
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?
Re: OSSC Pro
DatMonkey wrote: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.
Re: OSSC Pro
I thought you could already do this with a DVDO.vol.2 wrote:DatMonkey wrote: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.
Re: OSSC Pro
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.