Sizif-XXS

[SoftLight]

А какое еще может быть качество по композиту если еще и выдавать через jack? Это же полнейшее безумие. Разницы в сортах этого видесигнала особо не вижу в разных режимах.

[Advertiser]

[sv]

Это же полнейшее безумие. Разницы в сортах этого видесигнала особо не вижу в разных режимах.

Ты наверное не понял... я как бы очень давно в курсе что такое композитный сигнал.
Ты реально не видишь разницы на моём видео? Если да, то действительно - это безумие (ну или к оккулисту).
Просто не отвечай мне тут тогда, пожалуйста. Спасибо.

Вопрос простейший: Это нормально что есть такая разница в качестве, при переключении таймингов, или нет? У этого клона. Что там ещё преключается при этом?
Раз автор не может ответить, нижайше спрашиваю у обладателей. Только без "экспертных" мнений про композит, сорта говна итд, пожалуйста - они мне не нужны.

[SoftLight]

Просто не отвечай мне тут тогда, пожалуйста.

Хорошо, умолкаю. Мне просто лениво писать. На плате стоит генератор 28МГц. Для корректного PAL-видеосигнала требуется точная цветовая поднесущая частота 4.43361875 МГц: 625 строк/кадр, 50 кадров/сек, 312.5 строк в кадре, 15625 Гц частота строк. 4.43361875 / 28000000 ≈ 6315.789. Чтобы получить цветовую поднесущую нужно делить на целое число 6316. В итоге, получаем разницу в 633 Гц с эталонным сигналом. То есть частота поднесущей отклоняется на сотни герц, что при PAL-демодуляции приводит к усилению dot crawl и неустойчивому colour burst. В режиме 48k у нас 224 тактов на 3.5 МГц, следовательно, получаем 64 мкс. Это 448 пиксельных такта при частоте 7Мгц. А в режиме 128k у нас уже 256 тактов и примерно 73.14 мкс. При увеличении длины строки фазовая ошибка накапливается и цветовой синхроимпульс смещается относительно идеала. Как следствие, PAL-декодер теряет фазу и получаем сильный dot crawl и бегущие цвета. Не думаю, что это можно пофиксить чисто прошивкой.

[sv]

На плате стоит генератор 28МГц. Для корректного PAL-видеосигнала требуется точная цветовая поднесущая частота 4.43361875 МГц: 625 строк/кадр, 50 кадров/сек, 312.5 строк в кадре, 15625 Гц частота строк. 4.43361875 / 28000000 ≈ 6315.789. Чтобы получить цветовую поднесущую нужно делить на целое число 6316. В итоге, получаем разницу в 633 Гц с эталонным сигналом. То есть частота поднесущей отклоняется на сотни герц, что при PAL-демодуляции приводит к усилению dot crawl и неустойчивому colour burst. В режиме 48k у нас 224 тактов на 3.5 МГц, следовательно, получаем 64 мкс. Это 448 пиксельных такта при частоте 7Мгц. А в режиме 128k у нас уже 256 тактов и примерно 73.14 мкс. При увеличении длины строки фазовая ошибка накапливается и цветовой синхроимпульс смещается относительно идеала. Как следствие, PAL-декодер теряет фазу и получаем сильный dot crawl и бегущие цвета. Не думаю, что это можно пофиксить чисто прошивкой.

Огромное спасибо). Именно это я и хотел услышать.
Как простому пользователю, мне было интересно узнать почему такая разница, и вот так вот по циферкам разложить я бы сам не смог.
ну или короткий ответ "да, это нормально, в силу определённых причин".

[Serg6845]

На плате стоит генератор 28МГц. Для корректного PAL-видеосигнала требуется точная цветовая поднесущая частота 4.43361875 МГц: 625 строк/кадр, 50 кадров/сек, 312.5 строк в кадре, 15625 Гц частота строк. 4.43361875 / 28000000 ≈ 6315.789. Чтобы получить цветовую поднесущую нужно делить на целое число 6316.

ошибочка на 3 порядка однако. не 6315 а 6.315, ближайшее целое - 6. получится фигня. но в примененной ПЛИС есть PLL - хотя и с довольно крупным шагом. насколько близко можно получить нужную частоту - считать лень, но возможно прошивкой хотя бы частично это пофиксить можно.