rbutcher

This maybe seems complicated because Node has 1 obvious way to run (single threaded with asynchronous functions) but Python has a few ways (single threaded, multithreaded, ioloops kind of like Node, greenlets).

Python is excellent for toy implementations, and real ones too in many cases.

Nobody has said that the quality would be bad, just that some amount of generation loss [1] will occur when you use a lossily compressed [2] video (the netflix stream) as input for the creation of another lossily compressed video (the "recompressed" video file). The "recompressed" video would be slightly worse than the streamed video, which would be slightly worse than the original video.

An approximation of an approximation of a video is going to be worse than an approximation of a video.

1: https://en.wikipedia.org/wiki/Generation_loss

2: https://en.wikipedia.org/wiki/Lossy_compression

Netflix sends you a video that has been lossy compressed once. If you lossy compress that lossy compressed video, then you will have a video of worse quality than the video that was only lossy compressed once.

Original source video > Netflix video stream (1 level of lossy encoding) > Recompressed video stream (2 levels of lossy encoding)

Have you seen Bleve? https://github.com/blevesearch/bleve

I have only tried it for an hour or two, and can't speak for its search result quality, but it seems promising.

On my laptop, with an index of 10,000 documents each containing 200 random words, it takes about 110ms to perform a fuzzy search. Half of that is the actual search, the other half is the process/initialization overhead.