Join VideoLan Wiki -- How do I do it?

[markfilipak]

How can I become a registered VideoLan Wiki member? I could not find a way.

Warm Regards,
Mark.

[unidan]

Hi, the wiki will soon be removed in favor of gitlab pages, which you would be able to contribute to by using git and merge requests, or maybe gitlab IDE directly. The previous pages must be migrated to git too.

Do you know these tools ? what would you like to contribute to ?

[markfilipak]

Howdy unidan.

I'd like to generate/contribute high quality documentation of a type that's currently not available anywhere that I've found. It would document video formatting and processing at a system architecture level, for example, by graphically showing/tracking buffer contents & processing operations step-by-step. The documentation is mostly pictures of the type that's undoubtedly in your head as you visualize your code and what it does. Right now the pictures are texie-pix but I could beautify them if there's a market for my documentation. Most existing documentation I've found is vague or contradictory (or just plain wrong). Of interest to me is mainly DVD mastering and playback processing of 24fps movies.

In the course of my research I think I may have stumbled upon a 2-3 pull-down scheme that's like mean/blend but way faster (and perhaps, better).

Short bio: I'm a retired circuit & chip hardware designer/architect with experience in video (Atari, Intel, Viewgraphics), real-time multiprocessor shared memory caching & supercomputers (Altos Computers), peripheral bus architectures (EISA/PCI, Wyse Technology), and network hardware & disk array (RadioLAN, NetApp) among others (a mix of start-ups & US defense contractors). I worked in Silicon Valley for 25 years.

[unidan]

Hi, this looks really promising and interesting

Maybe you can start that in your own repository and merge it later ?

[markfilipak]

I don't know. By "repository" I assume you mean a git account and some sort of place to put documentation. I'm not keen on git. Do you have any other suggestion?

PS: How about a forum for discussion ...sort of like is done in the AVS forum?

[unidan]

I believe you could do that on drive.google, overleaf, etc, but having a version control system compatible with git would help a lot to integrate parts of your work progressively too.

What are you used to work with ?

[markfilipak]

Well, if you and others would want to work on it collaboratively, I can understand why a collaborative tool like git would help, but I didn't anticipate that anyone else would want to work on it.

I have graphically diagrammed, for example, how 480i30-DVDs (mastered interlaced & 2-3 pull-down) appear subtly different at 1080p from how 480p60-DVDs appear depending upon whether the player does the deinterlace or the TV does it. As I come to realizations, for example, that almost all movie DVDs are actaully 480p60, not 480i30 (though 480i30 is what past writers have assumed) ...as I come to such realizations, I have to do wholesale revisions of scores of dense pages of interdependent texie-pix diagrams and explanations... well, you get the idea. It's getting tiresome to have to reverse engineer sequential processes only to discover that some base information is wrong or notional (bogus info from Wikipedia, for example, or from actual authorities who have simply been a little sloppy). Pictures don't lie.

The diagrams I do are space-time diagrams. They're the type of diagrams I make when I architect hardware and by which I figure out how processes should be staged and what the sizes of buffers should be and at what points independently clocked processes must be synchronized, and how to optimize the processes & synchornization and minimize the buffers. My processes are implimented as 10s-nano-second (or today, 100s-pico-second) hardware state machines, but there's much commonality between those state machines and software, especially when SMP & threading are taken into account.

Perhaps my diagrams are nothing special. If that's true, why don't I see other people making them? You know, software can be revised but hardware is forever. Hardware has to be correct and hardware designers employ methods that work. Another citation: If state machines are reliable, why do I see so many IF (...) ELSE IF (...) constructs instead of CASE contructs? State machine state diagrams are 100% CASE, 0% IF (...) ELSE IF (...). I suspect that such diagrams as I do would really help with process visualization, time (buffer) optimization and code coverage.

Is a git repository really the venue to contact people like you? Or would it merely become a cul-de-sac like so many things in git?

[markfilipak]

Here's an example of my questions:
Are 480i30 DVDs mastered with 2-3 pull-down in the samples (prior to MPEG-2 encoding), or does the player always have to perform the 2-3 pull-down on the decoded sample set? Certainly the 2 pull-down fields are redundant information that would make the pre-code sample set larger, but perhaps it makes coding easier and more efficient, so is done for that reason. Or does the .IFO metadata merely point to the fields that are to be pulled down so that they're not really redundant?