Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Some interesting analysis here, but I think you are analysing a video far too heavily in the spatial space i.e at frame level, this doesn't particularly give reliable results as compression and hence artifacts can vary according to frame in time.

Video needs to be analysed ideally in the temporal space (i.e as a sequence). I see no mention of the GOP structure or length of the encoding chosen, which would need to be considered.

For example the one frame you have chosen to compare could be an I frame in some of the video compression or could be a P or B frame which would result in slight variance in quality and artifacts.



Also, reading back, this is a huge huge red flag:

> "I dumped all the images into separate PNG files, and then used sips to convert the PNGs to somewhat-more-reasonably sized JPGs"

You are adding further compression to the PNGs (the frame grabs) by using JPEG (I assume you are using it in lossy mode), which is basically adding another form of compression to your results.

The fact you used JPEGs (further compression) for comparison basically null and voids all the results I am afraid.


That was a huge "WTF" moment, and the point I basically gave up on the article. I was hoping for an interesting deep dive, not a layman fiddling with stuff.

There are much better ways and tools for comparing encoded videos.


Yes, it's too bad that the author lacks basic understanding of signal processing. I respect his effort though, it's not an easy topic - you have to start somewhere.


Not only that, if the color space is different between the original video, the PNG files (RGB), and the final output video, there can be lossy effects from that as well.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: