Ffmpeg colour bugs

So.. Pretty nice guide you have here, but I think you slightly misunderstood *the situation*.
It is true that "all unspecified things the same" they stick to bt601, but the problem isn't really that there are assumptions about unknown still image formats (or better yet \*videos\*, because from png to jpg and webp I'm really skeptical any of them wouldn't have pretty rigorously documented default properties).
Everything is kind of a disaster because despite all of this, the program is then completely silent about such decisions (including within the final metadata) - and it is ***then*** the video players that have to try to guess what the color matrix is for yuv-rgb conversion.
And this is only one of the many shortcomings.

Long story short we have:
* files aren't [tagged](https://trac.ffmpeg.org/ticket/9167) with their colorspace information (and I'd like to remember the SD=601 and HD=709 convention otherwise)
* unless using [zscale](https://trac.ffmpeg.org/ticket/9693), forget about extracting videos to jpeg (unsure about the other way around?)
* output pngs have [wrong](https://trac.ffmpeg.org/ticket/10000) gamma (in one of the tags at least? depending on the software you may be good)
* colorspace and scale are also [busted](https://trac.ffmpeg.org/ticket/9772) in their own ways with linear gamma conversions

There are too what you could call "slight rounding errors" (the last three links [here](https://github.com/n00mkrad/flowframes/issues/157#issuecomment-1171774927)), but for once they seem pretty minor.

Comece revisando o guia de codificação e os tickets do FFmpeg vinculados 9167, 9693, 10000 e 9772, além da discussão vinculada do Flowframes. A issue abrange várias questões de marcação de cor, extração, gamma e espaço de cor, mas não nomeia arquivos nem testes do repositório; uma contribuição precisaria de um escopo definido e de uma definição de concluído acordada.

Escrita pelo modelo de indexação a partir do texto da issue.