ux

The median cut quantization with a few tweaks (using the the variance typically - see the post for more) actually gives very good results. According to your post, it seems it will not provide much better results with Octree, if any. That calls for testing though (I won't but feel free to, the infrastructure is ready for you to hack in), as improvements are very welcome.

Concerning the dithering, you can disable it (dither=none). And indeed, it kills the compression, mainly when using animation, that's why I added the diff_mode option typically (see at the end of the post).

Yes, that's what I presented. Sometimes though you need a function because you have a function pointer tab for each feature (foo, bar, baz), that's why I wrapped them to show the mechanism of inlining.

It's mentioned quickly, look for "func_lut" in the post. These functions can not be inlined if the LUT must be declared dynamically, and it's a problem when they have different parameters typically.

These solutions are what is presented at the beginning of the article, basically. They suffer from a maintenance and readability issue (most editors will disable syntax in the macro scope, you have to mess with the '\', ...).

In this particular case it's not exactly a problem, but when you reach a 100+ lines macro, it becomes one.

It's a bit like maintaining pixel shaders in strings, it pretty quickly becomes a huge PITA.

Now if you read carefully the post, you will notice that I'm not encouraging the latest multiple files method, it is just presented because it's a common pattern and has its use cases.

I think what is described in "Mixing full functions mechanism and macros" would be more appropriate for the example you picked. Again, you have to assume that the function is going to grow, and it needs to be editable.

I was simply not aware of it as I never really looked deeply at the features of anything posterior to C99 (I only vaguely remember the thread features that look appealing). That's interesting, I might end up mentioning it in the conclusion later.

Thank you.

That's why you have -filter_script and -filter_complex_script options.

Haters gonna hate. You can put that filtergraph in a file with line returns or whatever clarity you fancy.

Note that FFmpeg doesn't require wine to work on Linux (or any other system), and it also handles here the audio, the encode, and the remuxing.

(Ah, and it doesn't need to download dll on random dubious sites or lost forum threads to make it usable)

Thanks for the frame ranges. So...

ffmpeg -i zelda.mp4 -vf "perspective=60:90:589:147:50:415:582:418:enable='not(between(n,0,149)+between(n,1488,2063))'" -c:a copy -c:v libx264 zelda.mkv

Well... you can do that with only ffmpeg.

ffmpeg -i zelda_720p.mp4 -vf perspective=60:90:589:147:50:415:582:418 output.mp4

Edit: BTW on your picture it's not (50,145) but (50,415) for the bottom left corner.

Edit: if quvi supports still works, you can ffplay "https://www.youtube.com/watch?v=rMXD5DxbXog" -vf perspective=60:90:589:147:50:415:582:418 (otherwise something similar should be doable with youtube-dl)

Edit: you can also do better and enable the perspective only in the part where it matters. Typically with something like -vf "perspective=60:90:589:147:50:415:582:418:enable='not(between(t,0,5))'"

What actually happened to quvi? Is it really still active? (https://github.com/legatvs?tab=repositories). No more commit since last year.

Same question for clive/cclive...

By the way, FFmpeg has support for the 0.4 branch of libquvi, so if you built it with --enable-libquvi you can ffmpeg -i http://youtube... (assuming libquvi and its scripts still work)

Forking is not that much a problem when it's limited to a program. Typically in the case of MPlayer, you had mplayer2, and nowadays mpv, and this is fine really. It's just a program that could live with the others without much trouble.

On the other hand, with a project like FFmpeg which actually provides libraries, it can really hurts the users community. Especially when the forking is made without changing the library names... which is exactly what happened here (thanks to the confusing name of the fork, chosen on purpose).

Basically, the fork was made such that only one can survive (example: only one "libavcodec" can exists), because they were actually confident about the outcome. But it seems they didn't anticipate such fundamental changes in the way FFmpeg continued to live.

s/paper/code/g and you get a nice read about code review

Well, I just assumed it was symmetrical because I couldn't imagine it to be unrolled manually (I just quickly watched the visual representations of each side)... But now that you pointed out this I guess I'm going to check for differences, in all the filters. Do you remember on which side the typo was present?

And yeah, we still haven't really cracked the algorithm. I initially wanted to write the article as "understanding hqx", but I actually realized I still don't really get the rules.

Could you share the board post where you discuss your implementation?

Oh that's awesome. May I ask what method you used to figure out the algorithm?

> I asked the author, he apparently made the entire unrolled table by hand.

what the hell...

It would help understanding why that happened and thus maybe how to prevent it.

Most of the old options have been mapped to the new interface (see opt_old2new() for instance). So most of the old commands are still compatible. Libav also has dropped ffmpeg forked copy since a long while, so FFmpeg is actually more retro compatible.

Interesting, so you have a way of making the relationship at the end. Now I could start nitpicking about how you decide to make the link to Aphex Twin and not his name (or another nick), and how would you make that decision for any similar cases.

Note that I don't consider this issue the main problem, it's just one I hit a few times, and I wasn't able to select a correct solution.

You mean by having a guy to ask where to find something because you're lost in the store and can't find shit?

I was actually talking about browsing. The musical content analysis has the goal to provide new ways of representing your music, and browse it.

Well, it's the same person behind. Even if the artist tried to give a different "personality" to his music over the time, following all his creations is actually a good listening experience. The "hey I just want to listen to the musical evolution of this guy" isn't a rare feeling IMO. Grabbing all his nicknames is kind of a problem.

Of course, you have a point, I'm making the problem harder than it needs, and you can just don't care about most of these issues. Hey, that's actually to the conclusion I reached. But still, I believe the current solutions are not optimal if you want to match N songs, store all the related "context" information, or just keep a consistent way of storing them.

Nice, I'm sure a lot of people would be interested in trying this.

But talking to myself, I'm disgusted with all of this, so I'm just maintaining my mess in its current state for now.

Still, I like to see such solution, and I'd be really interested in a counter article to what I wrote dealing with each issue. Even if at the end, I will likely not use the given solution.

About the regex search, I'm not sure that's really the solution to the "textual problem". As mentioned in the article, the music content retrieval system is in my opinion the future. Echonest and similar services are trying to achieve something like this. Looking for one artist isn't really what you actually want most of the time. It's likely you are looking for good music, and just want to listen to things who sound "like this".

It would be interesting to make an analysis on how MusicBrainz deals with all these problems, I admit I didn't look much into this. But AFAICT it wouldn't really solve the file system problem, except if you decide to name your files with a hash. Also, you might still want at some point to keep extra information MusicBrainz wouldn't handle, even if you have a MusicBrainz ID stored in the file to identify the music.

About the ASCII, my point was just all about the fact that you can't actually keep only the international name and you need to store the name in different language version. Obviously, I don't have any problem with using UTF-8.

PS: note that UTF-8 won't be able to represent properly mathematical formula... :)

I wonder how often a bit exact copy of one song appears... Sure the songs might have the same title and duration, but some very trivial edits might be done. You need to be extra careful when identifying these songs as identical if you don't want to lose any information.

Of course, from a listener point of view it might not mean much, but how would you decide at which level of non-similarity a track is the same as another one?

It's a bit like choosing a lossy codec quality, it's very subjective, and for indexation this might not be the best way.

Feel free to use plugins like Stylish :)

Do you have any suggestion for the CSS?

This really changed a lot, see http://fate.ffmpeg.org/

We now test all the code through valgrind; a single memory leak will complain. There are also static analysis, and various other checks.

And BTW, you can't treat warnings as errors. Just try to fix the warnings we have and you might understand why it's not possible easily (might require API changes, compiler false-positive, deprecated warnings that can just be silenced, etc). Of course, you might be able to fix some easily, and the patches will likely be accepted (assuming they are correct).

We did some work to improve this a little, see for example: http://git.videolan.org/?p=ffmpeg.git;a=tree;f=doc/examples;...

This should be deployed with any new fresh ffmpeg install.

The filtering code is still unstable due to what's explained in the blog post...

I just fixed that paragraph. It will hopefully avoid some confusion.

By the way, x264 isn't really a codec, it is just an encoder. I'm also not sure calling H.264 a video format is really correct, it's more like a codec standard to me. But I guess all of this is just wording bikeshed :)

Thanks for spotting anyway.