mp4: parse udta stream names

[JoelLinn]

• Increases accessibility to the visually impaired by allowing multiple
  (audio) channels per language.
• Stream names are usually (i.e. FFmpeg) saved in udta node as
  name atom
• Configurable via vod_parse_udta_name, defaults to Off
• Existing hdlr name parsing often just contains generic names, see
  is it possible to get audio label attribute from mp4 file in local mode? #695 for previous
  discussion

I am assuming null terminated strings inside udta->name atom. I know that some formats (.mov ?) use pascal strings. At least FFmpeg uses null termination for mp4, please comment if you think pascal strings might be encountered and need to be addressed (similar to hdlr name is parsed)

If both vod_parse_hdlr_name and vod_parse_udta_name are On, hdlr will take precedence. I consider this an implementation detail and therefore did not specify this order in the documentation/Readme.md

[kaltura-hooks]

Hi @JoelLinn,
Thank you for contributing this pull request!
Please sign the Kaltura CLA so we can review and merge your contribution.
Learn more at http://bit.ly/KalturaContrib

[JoelLinn]

Changed as requested

[erankor]

I checked ffmpeg source -
https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/movenc.c#L3279

Unlike hdlr, there is no case of pascal string here, and also, it seems ffmpeg won't write any null characters on this string.
So, unless you have a sample file created with some other software that has these properties, I prefer to remove this code. Meaning - just use name & name_len as they are.

[JoelLinn]

special string handling removed

[erankor]

One last comment, for consistency with the hdlr code, let's replace const char* name & uint64_t name_len with a single var vod_str_t name

[JoelLinn]

👍

[erankor]

Merged, thanks!