Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds .NET Core 3.1 Console App project #1197

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

NickDrouin
Copy link

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

Nick Drouin and others added 2 commits December 5, 2019 22:14
…and .Open_Buffer_Init, as well as a .Open_Buffer_Init example for Azure Storage Blobs
Removed MemoryStream.  Increased localByteBufferSize to 1MB after doing performance testing against azure for both single and mult-block blobs, with moov boxes at the begining and end of an mp4 file.
@JeromeMartinez
Copy link
Member

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.

return;
}

if (ToDisplay == "Unable to load MediaInfo library")
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Author

  • 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
Copy link
Author

  • 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.

MI.Open_Buffer_Init(contentLength, 0);

// The parsing loop using a fixed memory buffer for reading and marshaling
const int localByteBufferSize = 1 * 1024 * 1024;
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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 ?

Copy link
Author

@NickDrouin NickDrouin Jan 23, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link

DvdKhl commented Feb 14, 2020

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
Copy link
Contributor

@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
Copy link

DvdKhl commented Feb 14, 2020

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
Copy link

DvdKhl commented Feb 14, 2020

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
Copy link

DvdKhl commented Feb 14, 2020

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
Copy link
Author

NickDrouin commented Feb 16, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants