Fix #992.

@kieranjol, I "merge" MXF files duration when I detect the same count of files per reel and the same kind of file in the same order for each reel (if reel 1 has Video then Audio, other reels must have Video then Audio too), in order to simplify the algorithm. If count of files per reel or file kind order is different, I keep displaying each file in its each part, as I don't know yet how I would like to display that in MediaInfo in a readable way (how should it be actually displayed?), if I decide to support such kind of content one day.

I also display only the first file in the "Source" line, I am reluctant to display 10 file names in this MediaInfo field when there are 10 reels. The issue is not really technical and is not new (already implemented for IMF packages having several resources for a track), just that the MediaInfo output in text may be huge if I list all file names in 1 shot (some IMF packages have hundreds of files for a single track)

So result is e.g. for a multi-reel package with 1mn20s + 40s content:

General
Complete name                            : Jerome_FTR-1-25_F-133_2K_20180912_SMPTE_OV\cpl_baf3403d-c7cf-490f-8b47-3a09521bdc5a.xml
Format                                   : DCP CPL
File size                                : 1.05 GiB
Duration                                 : 2 min 0 s
Overall bit rate                         : 74.9 Mb/s

Video
ID                                       : 1-2
Format                                   : JPEG 2000
Format profile                           : D-Cinema 2k
Format settings, wrapping mode           : Frame
Muxing mode                              : MXF
Codec ID                                 : 0D010301020C0100-0401020203010103
Duration                                 : 2 min 0 s
Bit rate                                 : 68.0 Mb/s
Width                                    : 1 998 pixels
Height                                   :  pixel0
Original height                          : 1 080 pixels
Display aspect ratio                     : 1.85:1
Frame rate                               : 25.000 FPS
Color space                              : XYZ
Chroma subsampling                       : 4:4:4
Bit depth                                : 12 bits
Scan type                                : Progressive
Stream size                              : 973 MiB (91%)
Title                                    : Picture Track
Color range                              : Full
Source                                   : j2c_304cc461-bb25-4976-8117-c33d0ccbe3eb.mxf

Audio
ID                                       : 2-2
Format                                   : PCM
Format settings                          : Little
Format settings, wrapping mode           : Frame (BWF)
Muxing mode                              : MXF
Codec ID                                 : 0D01030102060100-0000000000000000
Duration                                 : 2 min 0 s
Bit rate mode                            : Constant
Bit rate                                 : 6 912 kb/s
Channel(s)                               : 6 channels
Sampling rate                            : 48.0 kHz
Frame rate                               : 25.000 FPS (1920 SPF)
Bit depth                                : 24 bits
Stream size                              : 98.9 MiB (9%)
Title                                    : Sound Track
Source                                   : pcm_ed08d089-6f26-4d12-aef6-3d060dad53a7.mxf
Locked                                   : No

This one I don't actually know how to fix.

C:/builds/ab/build/libmediainfo-git/Source/MediaInfo/Text/File_AribStdB24B37.cpp: In member function 'void MediaInfoLib::File_AribStdB24B37::aption_statement()':
C:/builds/ab/build/libmediainfo-git/Source/MediaInfo/Text/File_AribStdB24B37.cpp:744:72: error: cannot convert 'const char*' to 'const wchar_*' in assignment
             Event.Content=Streams[(size_t)(Element_Code-1)].Line.c_str();
                                                                        ^
[178/223] Building CXX object CMakeFiles/mediainfo.dir/C_/builds/ab/build/libmediainfo-git/Source/MediaInfo/Text/File_Eia608.cpp.o
In file included from C:/builds/ab/build/libmediainfo-git/Source/ThirdParty/aes-gladman/aescpp.h:26:0,
                 from C:/builds/ab/build/libmediainfo-git/Source/MediaInfo/File__Analyze.h:23,
                 from C:/builds/ab/build/libmediainfo-git/Source/MediaInfo/Text/File_Eia608.h:19,
                 from C:/builds/ab/build/libmediainfo-git/Source/MediaInfo/Text/File_Eia608.cpp:24:
C:/builds/ab/build/libmediainfo-git/Source/ThirdParty/aes-gladman/aes.h:85:3: warning: 'align' attribute directive ignored [-Wattributes]
 } aes_encrypt_ctx;
   ^~~~~~~~~~~~~~~
C:/builds/ab/build/libmediainfo-git/Source/ThirdParty/aes-gladman/aes.h:93:3: warning: 'align' attribute directive ignored [-Wattributes]
 } aes_decrypt_ctx;
   ^~~~~~~~~~~~~~~

This was previously reported via email as was the following suggestion for a change in File_Mpeg4_Elements.cpp: Changing this: if (moov_trak_tkhd_DisplayAspectRatio && Height && moov_trak_tkhd_DisplayAspectRatio != ((float32)Width) / Height) to this: if (moov_trak_tkhd_DisplayAspectRatio && Height && fabs((moov_trak_tkhd_DisplayAspectRatio-((float32)Width)/Height)>0.000001f)) testFiles.zip

Also, I found that building release32 exhibited the problem, but building debug32, release64, or debug64 didn’t. So, I downloaded the standalone release64 and, just like not expected, it exhibited the problem.

I wasn't able to find a parameter related to CUE for extracting such data from FLAC files. Is that possible by now? what is the name of the "general" parameter?

cuesheet : REM GENRE Kammermusik / REM DATE 2005 / PERFORMER "Maria Kliegel+Nina Tichman" / TITLE "Cellosonaten Nr. 1 & 2" / REM REPLAYGAIN_ALBUM_GAIN +2.51 dB / REM REPLAYGAIN_ALBUM_PEAK 0.999969 / FILE "Maria Kliegel und Nina Tichman - Faure - Cellosonaten Nr. 1&2.flac" WAVE / TRACK 01 AUDIO / TITLE "Elegie, Op. 24" / PERFORMER "Maria Kliegel+Nina Tichman" / REM REPLAYGAIN_TRACK_GAIN +3.56 dB / REM REPLAYGAIN_TRACK_PEAK 0.872437 / INDEX 01 00:00:00 / TRACK 02 AUDIO / TITLE "Papillon, Op. 77" / PERFORMER "Maria Kliegel+Nina Tichman" / REM REPLAYGAIN_TRACK_GAIN +6.27 dB / REM REPLAYGAIN_TRACK_PEAK 0.557831 / INDEX 00 06:43:61 / INDEX 01 06:48:23 / TRACK 03 AUDIO / TITLE "Sonate Nr. 1 fur Cello und Klavier, Op. 109, I. Allegro" / PERFORMER "Maria Kliegel+Nina Tichman" / REM REPLAYGAIN_TRACK_GAIN +0.22 dB / REM REPLAYGAIN_TRACK_PEAK 0.965851 / INDEX 00 09:58:43 / INDEX 01 10:05:24 / TRACK 04 AUDIO / TITLE "Sonate Nr. 1 fur Cello und Klavier, Op. 109, II. Andante" / PERFORMER "Maria Kliegel+Nina Tichman" / REM REPLAYGAIN_TRACK_GAIN +4.98 dB / REM REPLAYGAIN_TRACK_PEAK 0.577148 / INDEX 00 15:06:13 / INDEX 01 15:07:50 / TRACK 05 AUDIO / TITLE "Sonate Nr. 1 fur Cello und Klavier, Op. 109, III. Finale: Allegro commodo" / PERFORMER "Maria Kliegel+Nina Tichman" / REM REPLAYGAIN_TRACK_GAIN +2.31 dB / REM REPLAYGAIN_TRACK_PEAK 0.741760 / INDEX 00 21:52:48 / INDEX 01 21:53:35 / TRACK 06 AUDIO / TITLE "Berceuse, Op. 16" / PERFORMER "Maria Kliegel+Nina Tichman" / REM REPLAYGAIN_TRACK_GAIN +5.68 dB / REM REPLAYGAIN_TRACK_PEAK 0.497345 / INDEX 00 27:35:33 / INDEX 01 27:38:39 / TRACK 07 AUDIO / TITLE "Romance, Op. 69" / PERFORMER "Maria Kliegel+Nina Tichman" / REM REPLAYGAIN_TRACK_GAIN +3.82 dB / REM REPLAYGAIN_TRACK_PEAK 0.600098 / INDEX 00 31:13:38 / INDEX 01 31:17:39 / TRACK 08 AUDIO / TITLE "Sicilienne, Op. 78" / PERFORMER "Maria Kliegel+Nina Tichman" / REM REPLAYGAIN_TRACK_GAIN +7.69 dB / REM REPLAYGAIN_TRACK_PEAK 0.448090 / INDEX 00 35:27:40 / INDEX 01 35:31:11 / TRACK 09 AUDIO / TITLE "Sonate Nr. 2 fur Cello und Klavier, Op. 117, I. Allegro" / PERFORMER "Maria Kliegel+Nina Tichman" / REM REPLAYGAIN_TRACK_GAIN +0.70 dB / REM REPLAYGAIN_TRACK_PEAK 0.999969 / INDEX 00 39:19:30 / INDEX 01 39:23:74 / TRACK 10 AUDIO / TITLE "Sonate Nr. 2 fur Cello und Klavier, Op. 117, II. Andante" / PERFORMER "Maria Kliegel+Nina Tichman" / REM REPLAYGAIN_TRACK_GAIN +3.08 dB / REM REPLAYGAIN_TRACK_PEAK 0.747131 / INDEX 00 45:16:02 / INDEX 01 45:16:49 / TRACK 11 AUDIO / TITLE "Sonate Nr. 2 fur Cello und Klavier, Op. 117, III. Allegro vivo" / PERFORMER "Maria Kliegel+Nina Tichman" / REM REPLAYGAIN_TRACK_GAIN +0.09 dB / REM REPLAYGAIN_TRACK_PEAK 0.945648 / INDEX 00 52:19:42 / INDEX 01 52:20:63 / TRACK 12 AUDIO / TITLE "Apres un reve, Op. 7/1" / PERFORMER "Maria Kliegel+Nina Tichman" / REM REPLAYGAIN_TRACK_GAIN +6.01 dB / REM REPLAYGAIN_TRACK_PEAK 0.596161 / INDEX 00 56:44:06 / INDEX 01 56:47:38 / TRACK 13 AUDIO / TITLE "Serenade, Op. 98" / PERFORMER "Maria Kliegel+Nina Tichman" / REM REPLAYGAIN_TRACK_GAIN +1.56 dB / REM REPLAYGAIN_TRACK_PEAK 0.948059 / INDEX 00 60:03:13 / INDEX 01 60:05:28

https://pastebin.com/r7iMhefj

I'm not sure how you want to handle these kind of things.

You'll have to add the Matroska Enabled flag too at some point and there's already a "default" and "forced" field, it's useful to know, but I'm worried about cluttering the output.

MPC-HC obeys the Matroska enabled flag, I don't know how many others do.

For MP4 MP4Box only shows the enabled flag if it's set to disabled, and as far as the MP4 specs are concerned, having an alternate group of zero means the track doesn't have an alternate group.

I don't know if there's a way of specifying to only show a field in output if it contains or doesn't contain a certain value. To be honest, I don't see the point in showing the Matroska forced flag for audio and video, unless it happens to be set to yes. I'm not even sure what that would mean in the real world.

Shouldn't it be 15 dynamic ojects and 1 Bed channel?

Audio
Format                                   : MLP FBA 16-ch
Format/Info                              : Meridian Lossless Packing FBA with 16-channel presentation
Commercial name                          : Dolby TrueHD with Dolby Atmos
Bit rate mode                            : Variable
Maximum bit rate                         : 7 662 kb/s
Channel(s)                               : 8 channels
Channel layout                           : L R C LFE Ls Rs Lb Rb
Sampling rate                            : 48.0 kHz
Frame rate                               : 1 200.000 FPS (40 SPF)
Number of dynamic objects                : 11
Bed channel count                        : 1 channel
Bed channel configuration                : LFE

I'm not sure what this code is trying to do? Was there meant to be a mode where lots of filenames could be provided as a string which was ':' separated? ':'s can occur in filenames (on macOS at least).

:.png will go through the top code path and a.png will go through the other one

https://github.com/MediaArea/MediaInfoLib/blob/master/Source/MediaInfo/MediaInfoList_Internal.cpp#L89

    if (Pos!=string::npos && Pos!=1)
        List.push_back(File_Name);
    #if defined(MEDIAINFO_FILE_YES)
    else if (File::Exists(File_Name))
        List.push_back(File_Name);
    #endif //defined(MEDIAINFO_FILE_YES)
    #if defined(MEDIAINFO_DIRECTORY_YES)
    else
    {
        ....
    }

At some point we should add messages when there is an error in the bitstream, but for the moment I didn't figure the best approach (with generic code for handling errors as much as possible, and not poluting the default output)

From vote https://mediaarea.net/Vote/Support-Buggy-Hevc-H-265-Sei-171 Issue from encoder, see https://github.com/rigaya/NVEnc/issues/51#issuecomment-393130636

Dears, We have a mp4 file, which contain a HEVC raw stream and right hvc1 and hvcC atom. But MediaInfo cannot show "Format Profile" in Video Properties, when using Basic View or Tree View. Please help to check the attached file and tell us what the problem is. test.zip

It seem that for now it show the codecID as format: aprh Shouldn't "ProRes RAW" be more meaningful?

Samples: https://filmplusgear.com/prores-raw-testfiles-for-download-nab-2018/

Running on Alpine Linux which uses musl libc instead of glibc. This crash is pretty repeatable, with pretty much any video file.

Thread 8 "Threadpool work" received signal SIGSEGV, Segmentation fault.
decfloat (f=f@entry=0x7ffff1f1aeb8, c=50, bits=24, emin=-149, sign=1, pok=pok@entry=1) at src/internal/floatscan.c:67
67	{
(gdb) bt
#0  decfloat (f=f@entry=0x7ffff1f1aeb8, c=50, bits=24, emin=-149, sign=1, pok=pok@entry=1) at src/internal/floatscan.c:67
#1  0x00007ffff7d8c76e in __floatscan (f=f@entry=0x7ffff1f1aeb8, prec=prec@entry=0, pok=pok@entry=1) at src/internal/floatscan.c:509
#2  0x00007ffff7dbbfd5 in strtox (s=0x555558fb4578 "23.976", p=0x7ffff1f1aff0, prec=prec@entry=0) at src/stdlib/strtod.c:14
#3  0x00007ffff7dbc00c in strtof (s=<optimized out>, p=<optimized out>) at src/stdlib/strtod.c:22
#4  0x00007fffeeb124c0 in void std::__convert_to_v<float>(char const*, float&, std::_Ios_Iostate&, int* const&) () from /usr/lib/libstdc++.so.6
#5  0x00007fffeeb5dadf in std::num_get<wchar_t, std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> > >::do_get(std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> >, std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> >, std::ios_base&, std::_Ios_Iostate&, float&) const () from /usr/lib/libstdc++.so.6
#6  0x00007fffeeb584aa in std::num_get<wchar_t, std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> > >::get(std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> >, std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> >, std::ios_base&, std::_Ios_Iostate&, float&) const () from /usr/lib/libstdc++.so.6
#7  0x00007fffeeb42aba in std::basic_istream<wchar_t, std::char_traits<wchar_t> >& std::basic_istream<wchar_t, std::char_traits<wchar_t> >::_M_extract<float>(float&) () from /usr/lib/libstdc++.so.6
#8  0x00007fffeedd6212 in ZenLib::Ztring::To_float32(ZenLib::ztring_t) const () from /usr/lib/libzen.so.0
#9  0x00007fffef8ddc88 in MediaInfoLib::File__Analyze::Fill(MediaInfoLib::stream_t, unsigned long, unsigned long, ZenLib::Ztring const&, bool) () from /usr/lib/libmediainfo.so.0
#10 0x00007fffef8df7be in MediaInfoLib::File__Analyze::Fill(MediaInfoLib::stream_t, unsigned long, unsigned long, float, unsigned char, bool) () from /usr/lib/libmediainfo.so.0
#11 0x00007fffef8f1e61 in MediaInfoLib::File__Analyze::Fill(MediaInfoLib::stream_t, unsigned long, unsigned long, double, unsigned char, bool) () from /usr/lib/libmediainfo.so.0
#12 0x00007fffef8e617f in MediaInfoLib::File__Analyze::Video_FrameRate_Rounding(unsigned long, MediaInfoLib::video) () from /usr/lib/libmediainfo.so.0
#13 0x00007fffef8ddeb5 in MediaInfoLib::File__Analyze::Fill(MediaInfoLib::stream_t, unsigned long, unsigned long, ZenLib::Ztring const&, bool) () from /usr/lib/libmediainfo.so.0
#14 0x00007fffef8df7be in MediaInfoLib::File__Analyze::Fill(MediaInfoLib::stream_t, unsigned long, unsigned long, float, unsigned char, bool) () from /usr/lib/libmediainfo.so.0
#15 0x00007fffef8f1e61 in MediaInfoLib::File__Analyze::Fill(MediaInfoLib::stream_t, unsigned long, unsigned long, double, unsigned char, bool) () from /usr/lib/libmediainfo.so.0
#16 0x00007fffef8e617f in MediaInfoLib::File__Analyze::Video_FrameRate_Rounding(unsigned long, MediaInfoLib::video) () from /usr/lib/libmediainfo.so.0

<recurse for ~1500 frames>

#1540 0x00007fffefb028c7 in MediaInfoLib::File_Mk::Streams_Finish() () from /usr/lib/libmediainfo.so.0
#1541 0x00007fffef8a8e5e in MediaInfoLib::File__Analyze::ForceFinish(char const*) () from /usr/lib/libmediainfo.so.0
#1542 0x00007fffef8a0f72 in MediaInfoLib::File__Analyze::Open_Buffer_Finalize(bool) () from /usr/lib/libmediainfo.so.0
#1543 0x00007fffef95e408 in MediaInfoLib::MediaInfo_Internal::Open_Buffer_Finalize() () from /usr/lib/libmediainfo.so.0
#1544 0x00007fffef911569 in MediaInfoLib::MediaInfo::Open_Buffer_Finalize() () from /usr/lib/libmediainfo.so.0
#1545 0x00007fffefdc882f in MediaInfo_Open_Buffer_Finalize () from /usr/lib/libmediainfo.so.0
#1546 0x00000000403cf5a3 in ?? ()
#1547 0x0000555558185840 in ?? ()
#1548 0x00007ffff2118940 in ?? ()
#1549 0x00007ffff2118900 in ?? ()
#1550 0x00000000317c1241 in ?? ()
#1551 0x00007ffff2813a38 in ?? ()
#1552 0x0000000000000001 in ?? ()
#1553 0x00007ffff75661f0 in ?? ()
#1554 0x00007ffff75697c8 in ?? ()
#1555 0x00007ffff21189c0 in ?? ()
#1556 0x00000000403ceec4 in ?? ()
#1557 0x0000000000000001 in ?? ()
#1558 0x0000000000000003 in ?? ()
#1559 0x0000000000004000 in ?? ()
#1560 0x00000000317caff7 in ?? ()
#1561 0x00007ffff0cf7970 in ?? ()
#1562 0xffffffffffffffff in ?? ()
#1563 0x00007fff00000007 in ?? ()
#1564 0x0000000000000000 in ?? ()

I'm honestly not sure whether this crash is the fault of Sonarr, libmediainfo, zenlib or musl. Can you provide any insight? I'll keep gdb running in this state in case I can provide any extra information that may be useful for debugging this.

I initially thought that this was caused by a stack overflow due to the large amount of recursion; musl is renowned for it's small stack size. From what I can see that total stack is a hair under 2MiB, so it still could be that.

Summary

When set to use CBR rate control, QSV's HEVC encoder can generate slice_segment_layer() NALs that have trailing zeroes, which can cause MediaInfoLib to miscalculate its position when it moves to the next block of NALs. And if PPS repeating is enabled, causes it to have cascading parsing errors, which in turn corrupts the reporting output.

Data and Affected Files

MediaInfoLib version: ca37f16b7f6a2e210722e10d5a78084dbc10584b (master as of this writing) MediaInfo version: 9c1a6e8fbd2f206805054ffcaa1c761d5f09b0ac (master as of this writing) ZenLib version: 94ea0fd07edb43237e8e219fe2b2624a4287bd3e (master as of this writing)

Example file (post-mux) causing parsing errors: https://obsproject.com/temp/cbr_packets.mkv Example raw HEVC packet (pre-mux) which causes parsing errors: https://obsproject.com/temp/cbr_packet.bin HEX view of HEVC packet showing trailing zeroes: https://gist.github.com/jp9000/98fea8dfe6a045d70aa022c8ff745101

The offset to that packet (the first packet with trailing zeroes) within the MKV file is 624388 (0x98704), or frame 168(?) I believe.

This was tested with the in-progress pull request for obs-studio: https://github.com/obsproject/obs-studio/pull/6522

It was also tested with FFmpeg, with parameters: ffmpeg -i [input file] -c:v hevc_qsv -preset:v medium -profile:v main -g:v 180 -b:v 2500k -maxrate 2500k -c:a copy [output file].mkv -- if you want to test FFmpeg yourself, don't use blank video, use a video that has details but is moving only marginally, such as my example video. But my video file should be sufficient to show the parsing issue.

Note about MKV

MKV container is required, because for some reason MediaInfoLib will only parse all frames in a file if MKV container is used; other file containers will only parse the first dozen or so frames, which stops before the frame where it occurs (usually around 150 frames in or so).

Details of parsing issue

I'll speak relative to that first example packet. The first packet with trailing zeroes, the example packet, has 3 NAL units:

1. pic_parameter_set() (because repeating headers is on; note that it doesn't matter if they're on or off, the parsing errors still occur)
2. sei()
3. slice_segment_layer() with the aforementioned trailing zeroes

When MediaInfoLib encounters the third NAL of the example packet, the slice_segment_layer() NAL with trailing zeroes, the first thing that happens is that it'll misinterpret the first three bytes of the trailing zeroes as a delimiter to for a new NAL, via this code: https://github.com/MediaArea/MediaInfoLib/blob/master/Source/MediaInfo/Video/File_Hevc.cpp#L1063-L1082

Then, after it parses that NAL, it'll mistakenly parse the trailing zeroes as a fourth NAL here: https://github.com/MediaArea/MediaInfoLib/blob/master/Source/MediaInfo/File__Analyze.cpp#L1115-L1118

It silently fails parsing the zeroes and erroneously treats it as a slice_segment_layer(). When it finishes parsing that NAL, the Buffer_Offset will be equal to Buffer_Size-1, so one byte will be remaining. It'll then try to treat that last byte as a fifth NAL in the block. But Buffer_Parse() fails, and it leaves Buffer_Offset equal to Buffer_Size-1.

Then, because Buffer_Offset is left with the value of Buffer_Size-1, when Open_Buffer_Continue_Loop() returns to its calling function, Open_Buffer_Continue(), it'll calculate Buffer_Size which will now equal just 1, here: https://github.com/MediaArea/MediaInfoLib/blob/master/Source/MediaInfo/File__Analyze.cpp#L861

Because of that, when the next block of NALs is parsed, it will erroneously subtract 1 from the file position of that File_Offset, here: https://github.com/MediaArea/MediaInfoLib/blob/master/Source/MediaInfo/File__Analyze.cpp#L976-L978

Because of that, when it starts parsing NALs, the File_Offset will be incorrect, one byte less than what it's supposed to be, causing the reading of the Size value for the next NAL to be read as 0 instead of its correct size, here: https://github.com/MediaArea/MediaInfoLib/blob/master/Source/MediaInfo/Video/File_Hevc.cpp#L1052

This then causes it to try to calculate the size when it tries to parse the next header here: https://github.com/MediaArea/MediaInfoLib/blob/master/Source/MediaInfo/Video/File_Hevc.cpp#L1060-L1061

Which makes it use a much larger value than it was supposed to be (5578 versus the intended value of 8). This causes cascading corrupt parsing, especially in this case when the encoder is set to use repeating PPS. You'll get bad SEI values, and on this file in particular, you'll see this:

SEI_rbsp_stop_one_bit                    : Missing

Which is part of its erroneous analysis of the file due to the parsing issue.

Other thoughts

That's basically the situation. I am not very familiar with the HEVC spec, I had to wing it and look through the spec as I investigated this issue as thoroughly as I could. The trailing zeroes I was told are related to CBR's HRD compliance, or something like that (paraphrasing, can't remember exactly). I think it's CBR bitrate padding or something.

This file appears to decode properly with normal decoders.

The intent is that I'm just trying to confirm whether it's a bug in this parser, or whether it's a bug with Intel's QSV encoder. I doubt it's a bug in the QSV encoder, but I could be wrong. MediaInfoLib appears to use a custom parser, so I feel like I'd be more likely to assume it's just some bug in the parser, especially considering this is a very niche rate control, and usually parsing cuts off at a dozen or so frames on other container formats.

If you can verify whether this is a bug with the MediaInfoLib parser or not, I'd be most grateful. If it's a bug in the code, hopefully my investigation will help you pinpoint this niche bug and improve the parser. I'll relay this issue report so that you can talk with the relevant people around QSV if necessary.

MP4 edit list atoms('moov'/'trak'/'edts'/'elst') contain a table of edits, each with three entries. The entries are, loosely, duration, start, speed.

• duration is given in movie timescale units(listed in 'moov'/'mvhd')
• start is given in media timescale units(listed in 'moov'/'trak'/'mdia'/'mdhd')
• speed is a unitless fixed-point number

I think that mediainfo's --details=1 human-readable output presents start using the same units as duration, as opposed to the timescale given in the track's media header. The fix for this may require some inconvenient, out-of-order precessing. An alternate solution would be to present this value using some unit like "ticks" instead of converting to seconds.

Thank you for this incredible library.

When using C# interop class to read multiple remote files in parallel, there are high chances that open() will fail randomly, which looks like resource contention issue.

e.g. opening three video files a,b,c together async will likely see:
a-> fail to open
b-> success
c-> fail to open

Example code

    public static void Main(string[] args)
        {
            var videoDuration1 = ReadVideoDuration("http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/SubaruOutbackOnStreetAndDirt.mp4");
            var videoDuration2 = ReadVideoDuration("http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/ForBiggerMeltdowns.mp4");
            // expect intermittent file open failures
            Console.WriteLine($" [async] #1 Video Duration {videoDuration1.Result}");
            Console.WriteLine($" [async] #2 Video Duration {videoDuration2.Result}");
        }


        private static async Task<string> ReadVideoDuration(string videoUri)
        {
            return await Task.Run(
                () =>
                {
                    MediaInfo mediaInfo = new MediaInfo();
                    try
                    {
                        if (mediaInfo.Open(videoUri) == 0)
                        {
                            throw new Exception($"Cannot read media file {videoUri}");
                        }
                        return mediaInfo.Get(StreamKind.Video, 0, "Duration");
                    }
                    finally
                    {
                        mediaInfo.Close();
                    }
                });
        }

Local files or synchronous read don't have this problem. Please help to check if this is a wrong usage or a thread safety issue, thanks.

I'm using .net471 on windows 10 x64, mediaInfo 21.9 (same issue latest release), libcurl 7.80

Attached project (with binaries), MediaInfoExample.zip and dlls dll.zip

I'm trying to update our code to use the latest MediaInfoLib from v0.7.88. Yes, it's been quite a while. Our unit tests load some data from files and some data from memory output from ffmpeg after processing the file data. The unit tests loading data directly from files seem to be working. The unit tests loading from memory are failing because many values are unavailable.

I've tracked down that it breaks with release v0.7.95, specifically the change: "Rely less on file size (for growing file support)" https://github.com/MediaArea/MediaInfoLib/commit/ef6968bab7691dbe1c67bc9fae99e63979220356

I've included test code and a couple small ts files that illustrate the problem.

I'm not sure if this is a bug or working as designed, but I'd appreciate knowing how to get more fields available from using memory buffers.

Thx, Katherine

main.cpp.pdf 187812.log.pdf 187812.ts.zip 1290996.log.pdf 1290996.ts.zip