When the system clock is set to a value which is a recurring number, scanvideo.c will always panic even when the system clock is effectively an integer multiple of 2 times the desired pixel clock.
This is due to the system clock and the pixel clock being truncated to different levels of precision. e.g:
I was experimenting with custom scanvideo timings and wanted an output using a 14.318181Mhz pixel clock (or a close approximation of this NTSC frequency) and vcocalc.py gave the following solution for an 8x system clock:
I set the system clock with the above values and specified the pixel clock frequency as 14333333 in my scanvideo timing struct (timing->clock_freq) and that led to the panic:
System clock (114666666) must be an integer multiple of 2 times the requested pixel clock (14333333).
This is due to the way the comparison is made by multiplying the pixel clock by the scale factor and comparing with the system clock which will fail as 14333333*8 = 114666664 not 114666666.
The fix is to divide the system clock by the scale factor and compare with the pixel clock and this will succeed as both sides have been truncated to the same level of precision. (114666666 / 8 = 14333333)
When the system clock is set to a value which is a recurring number, scanvideo.c will always panic even when the system clock is effectively an integer multiple of 2 times the desired pixel clock.
This is due to the system clock and the pixel clock being truncated to different levels of precision. e.g:
I was experimenting with custom scanvideo timings and wanted an output using a 14.318181Mhz pixel clock (or a close approximation of this NTSC frequency) and vcocalc.py gave the following solution for an 8x system clock:
Requested: 114.545448 MHz Achieved: 114.66666666666667 MHz FBDIV: 86 (VCO = 1032 MHz) PD1: 3 PD2: 3
I set the system clock with the above values and specified the pixel clock frequency as 14333333 in my scanvideo timing struct (timing->clock_freq) and that led to the panic: System clock (114666666) must be an integer multiple of 2 times the requested pixel clock (14333333).
This is due to the way the comparison is made by multiplying the pixel clock by the scale factor and comparing with the system clock which will fail as 14333333*8 = 114666664 not 114666666.
The fix is to divide the system clock by the scale factor and compare with the pixel clock and this will succeed as both sides have been truncated to the same level of precision. (114666666 / 8 = 14333333)