Adds .NET Core 3.1 Console App project

[NickDrouin]

Adds .NET Core 3.1 Console App project with examples for local .Open and .Open_Buffer_Init, as well as a .Open_Buffer_Init example for Azure Storage Blobs.

Uses the MediaInfoDll.cs from #1192

[JeromeMartinez]

Thank you for your PR!
Some initial thoughts before I review the PR by testing it:

• Wondering the reason you create a new project instead of expanding the current MSCS one. Something blocking the usage of the same project?
• I was stupidly not aware about .gitignore from GitHub, I think I would like to have it in /Project so I handle all VisualStudio subdir, maybe I'll request to remove this file from the PR.

I'll test the PR when I finish urgent tasks I have for the moment.

[NickDrouin]

I would have like to use more explicit .LoadLibrary() / .IsLoaded() here, but wanted to limit my changes to only demonstrating the Azure byte-range pattern.

[NickDrouin]

• Wondering the reason you create a new project instead of expanding the current MSCS one.

I like the idea of supporting a number of examples using 'dotnet new '.

In fact, I'd much prefer refactoring for a class library, and including the lib in any number of .net project types. A lib would also solve the problem of many instances of MediaInfoDll.cs copied in all the project folders (which do not match each other).

[NickDrouin]

• I was stupidly not aware about .gitignore from GitHub, I think I would like to have it in /Project so I handle all VisualStudio subdir, maybe I'll request to remove this file from the PR.

No problem. Use 'dotnet new gitignore' to get the latest.

[NickDrouin]

@JeromeMartinez , this buffer seems too large for calls into LibMediaInfo. The .Inform call will return less data if the buffer size is too large. First it drops the audio tracks, then in the extreme of a 16MB buffer, it also drops the video track information (all that is left is the container info).
Do you know of some sort of max_size for the buffer passed to Open_Buffer_Continue ?

[NickDrouin]

Using and MP4 with an ftyp, free, mdat, moof top-level box layout:

A 4KB buffer will provide the same JSON results as the compiled / released app, whereas a 5KB buffer will have inaccurate video StreamSize and inaccurate audio StreamSize and BitRate (versus the app or 4KB buffer).
The 5KB and 4KB have similar but different seek request patterns, with many matching byte offset requests. They both read their initial buffers, seek to the moof, (which is 6715 bytes) read it in two sequential reads, then seek back into the mdat and perform lots of reads.
A 6KB (and above) buffer will read the initial buffer, seek to the moof, read it and then we hit EOF. None of these larger buffer sizes will report the audio stream at all.
I also tried a 6715b (the moof size) and 6714b buffer, to test edge cases around the moof boxe size. These had the same behavior as 6KB and above.

[DvdKhl]

Hi, I'm trying to interface with MIL also using .NET Core 3.1 in Linux (Debian) and I stumbled on this PR.
Sadly the official example nor the one in this PR is working for me when I try to pass a file path with non-ASCII characters to MediaInfo_Open. A path with only ASCII characters works fine.

I've attached an example with which this issue is reproducible:
MediaInfoLib.zip

[g-maxime]

@DvdKhl What is the output of your program?

Here (Fedora 31) It's work after changing all DllImport("MediaInfo") to DllImport("mediainfo")

Handle=37284112 UseUTF32Encoding=True
Opening file '/home/maxime/MediaArea/Temp/CS/😢.txt'
File Open Result was 1

[DvdKhl]

I'm getting (even after changing it to "mediainfo"):
Handle=19751616 UseUTF32Encoding=True
Opening file '/data/Media/AVDump3/Newfolder/😢.txt'
File Open Result was 0

[DvdKhl]

Not sure if it is important but I build MediaInfo from https://mediaarea.net/download/binary/libmediainfo0/19.09/MediaInfo_DLL_19.09_GNU_FromSource.tar.xz then took the File at "...\MediaInfo_DLL_GNU_FromSource\MediaInfoLib\Project\GNU\Library.libs\libmediainfo.so" and placed it next to the C# dll.
This works fine as long as there are only ASCII chars in the filepath argument.

[DvdKhl]

I got it to work with some help.
After I issued "export LANG=C.UTF-8; export LC_ALL=C.UTF-8" it works.

[NickDrouin]

Hey, quick update on this. So the partial parsing is at least two problems. First and easiest, some (new storage SDK) behavior has changed and I needed to pump the stream with a stream-reader -- easy fix, I'll get that up soon.
Second, however, seems to be a genuine bug with the lib implementation: If I use a buffer that is as large as the file (or larger), it will only read some of the meta. That is, unless I loop through at least a second time, I will not get the same results analyzing the same file as with the mediainfo.exe / json.