fourCcList definition should provide for a wildcard

[zenomt]

in traditional RTMP, clients that are capable of receiving any codec (like recorders or forwarders) can just set the videoCodecs and audioCodecs fields to 0xffff to enable all possible code points. however, the number of possible future fourCCs is way too large to list them all. to accommodate clients that can handle any codec, i propose defining a special value to include in the fourCcList codec list (or its replacement(s)) to indicate "any/all codecs".

i further propose this special value to be the one-character string "*" (ASTERISK). being one character long it can never conflict with any real fourCC, and * is already commonly used to mean "wildcard".

[veovera]

Interesting idea. It might behove to expand the special style even further to help solve #10. Please see my comments there.

[zenomt]

i followed up in #10 as well, but for completeness here: i don't think we should add delimiters and ordering to fourCcList, but i do like the idea of wildcard strings for "any codec", "any audio codec", and "any video codec". my recommendations are:

• *: "any codec"
• audio/*: "any audio codec"
• video/*: "any video codec"

[zenomt]

note though that "any audio codec" and "any video codec" would be solved with * by having separate lists for audio and video, and the separate wildcard strings are only needed for the unified fourCcList case.

[veovera]

Fixed, please see https://veovera.org/docs/enhanced/enhanced-rtmp-v2.