MediaInfo(Lib) 0.7 - Reading information about media files

[StainlessS]

MediaInfo v7.88, Access Violation on mp3 (XP32SP3):- EDIT: LINK REMOVED

With Settings, Explorer Tooltip enabled, hover over pretty much any mp3 file and get Access Violation.
I ended up have to delete original faulting mp3 via command line as just kept crashing explorer when approaching with mouse.
Going to any old mp3 folder, hovering over the 2nd of many mp3's, same again, so example mp3 is probably not really necessary.

EDIT: Disable Tooltip and no Access Violations.
@Zenitram, please say when taken sample file, so I can delete.

EDIT:

General
Complete name : C:\TEMP\Test.mp3
Format : MPEG Audio
File size : 1.72 MiB
Duration : 2 min 30 s
Overall bit rate mode : Constant
Overall bit rate : 96.0 kb/s
Album : Something Something Something
Track name : Something
Track name/Position : 48
Performer : Somebody
Genre : Pop
Recorded date : 2002
Cover : Yes
Cover MIME : image/jpg
MusicMatch_Situation : Background
MusicMatch_Mood : Morose

Audio
Format : MPEG Audio
Format version : Version 2
Format profile : Layer 3
Mode : Joint stereo
Mode extension : Intensity Stereo + MS Stereo
Duration : 2 min 30 s
Bit rate mode : Constant
Bit rate : 96.0 kb/s
Channel(s) : 2 channels
Sampling rate : 22.05 kHz
Compression mode : Lossy
Replay gain : -0.06 dB
Replay gain peak : 0.480973
Stream size : 1.72 MiB (100%)
MP3Gain, Min/Max : 135,180


EDIT: I know, its difficult, hard, impossible, to use MusicMatch after(And I think including) IE7. (I tag with W2K OS and MusicMatch, nothing I like better for that)

[manolito]

For me this only happens when the meta data of the MP3 contain cover information. See this post:
http://forum.doom9.org/showthread.php?p=1759773#post1759773

The last MediaInfo version without this issue is 0.7.81.


Cheers
manolito

[StainlessS]

Cheers Mani, love that smile :) [You should be in movies]

[manolito]

He still has a very nice smile, doesn't he?
http://www.henrydarrow.com/

[StainlessS]

He still has a very nice smile, doesn't he?
http://www.henrydarrow.com/

Yep.
Also from your link
He was also the lead guest star on a still-beloved program called "Bonanza", produced by the man who would later give us "The High Chaparral"


Seems that Gavino is right, even when he thinks he is wrong:- http://forum.doom9.org/showthread.php?p=1574331#post1574331

EDIT: Deleting given mp3 link in about 24 hours.

[LoRd_MuldeR]

In latest "All inclusive" package there still is a weird problem with the zlibstat project:

No matter what I do, the individual source code files in that project simply don't apply the settings (e.g. /MT vs. /MD switch) that I have set up in the "main" project properties - even if I explicitly apply "inherit from project defaults" :confused:

Had to remove the zlibstat project from the MediaInfo solution and add the normal zlib project instead, which seemed to fix this weirdness. Not sure why they exist both, anyway...

[manolito]

The latest MediaInfo v 0.7.91 fixes the issue from this post:
http://forum.doom9.org/showthread.php?p=1781741#post1781741

Thanks Zenitram... :thanks:

Cheers
manolito

[stax76]

here is a new MediaInfo cmdlet for PowerShell:

https://forum.doom9.org/showthread.php?t=174267

[LoRd_MuldeR]

MediaInfoXP v2.24 (MediaInfo v0.7.93)
* https://github.com/lordmulder/mediainfo-gui/releases/tag/v2.24
* https://sourceforge.net/projects/muldersoft/files/MediaInfo%20%28CLI%2BGUI%29/
* https://www.mediafire.com/folder/wpsz22gf8k8qv/MediaInfo

[manolito]

Thanks for the new version 0.7.94...

For the 32-bit CLI executable I found a small cosmetic bug (running under WinXP). For every file I throw at it I get this STDERR output:
E: File read error
E: is the drive where Windows is installed, MediaInfo.exe is called from a different drive. So this new version seems to try reading a file on the OS drive which probably does not exist... :confused:

The STDOUT output seems to be be correct, and since the error message does not cause a crash, I consider it cosmetic. The previous version had no problem. Also the 32-bit DLL 0.7.94 works fine.

Cheers
manolito

[Telion]

For the 32-bit CLI executable I found a small cosmetic bug (running under WinXP). For every file I throw at it I get this STDERR output:
E: File read error
Confirming this (also on XP), but I have no drive E: in my system. I've monitored file system activity with Sysinternal's Process Monitor - it shows no attempts to access anything with E: in a path, if that matters. I've also compared file access patterns of 0.7.93 and 0.7.94 versions, filtering out all successful results, and haven't found any differences except one thing. At the very beginning of an execution (unfiltered log entry ~10, before accessing any dependent dll) there are some QueryDirectory operations that enumerate files in several folders (one with MediaInfo.exe, system32, WinSxS), starting from the root and all the way down to them. And in 0.7.94 right after these queries there is one more enumeration of the tree down to a folder with a media file passed as a parameter - something that the previous version didn't do. So maybe that is somehow relevant to this issue?

[Aleksoid1978]

Latest version is hang when open .mpls from some 3D BD.
We have infinity loop here https://github.com/MediaArea/MediaInfoLib/blob/master/Source/MediaInfo/Video/File_Avc.cpp#L2265, TemporalReferences_Reserved = 0.

I made patch(for MPC-BE) - it's here https://sourceforge.net/p/mpcbe/code/2499/#diff-2
and more accurate fix - https://sourceforge.net/p/mpcbe/code/2500/#diff-1

[stax76]

here is a list of the known parameters: https://pastebin.com/e3U5dtpi

programmers might want to bookmark it

[LoRd_MuldeR]

Confirming this (also on XP), but I have no drive E: in my system. I've monitored file system activity with Sysinternal's Process Monitor - it shows no attempts to access anything with E: in a path, if that matters. I've also compared file access patterns of 0.7.93 and 0.7.94 versions, filtering out all successful results, and haven't found any differences except one thing. At the very beginning of an execution (unfiltered log entry ~10, before accessing any dependent dll) there are some QueryDirectory operations that enumerate files in several folders (one with MediaInfo.exe, system32, WinSxS), starting from the root and all the way down to them. And in 0.7.94 right after these queries there is one more enumeration of the tree down to a folder with a media file passed as a parameter - something that the previous version didn't do. So maybe that is somehow relevant to this issue?

I can confirm the "E: File read error" problem on my side as well. This happens for me on Windows 10.

BTW: I'm pretty sure "E:" is simply the prefix MediaInfo prepends to error messages:
void Log_0 (struct MediaInfo_Event_Log_0* Event, struct UserHandle_struct* UserHandler)
{
String MessageString;
if (Event->Type>=0xC0)
MessageString+=__T("E: ");

[Zenitram]

For every file I throw at it I get this STDERR output:

It is corrected, will be OK in next release or snapshots (https://mediaarea.net/download/snapshots/binary/mediainfo/).

[Zenitram]

I can confirm the "E: File read error" problem on my side as well.

It is corrected, will be OK in next release or snapshots (https://mediaarea.net/download/snapshots/binary/mediainfo/).

BTW: I'm pretty sure "E:" is simply the prefix MediaInfo prepends to error messages

Right.

[Zenitram]

here is a list of the known parameters: https://pastebin.com/e3U5dtpi

programmers might want to bookmark it

or help menu in GUI, "mediainfo --info_parameters" CLI, or source code (https://github.com/MediaArea/MediaInfoLib/tree/master/Source/Resource/Text/Stream).
If you want to see parameters for your files, "mediainfo -f -Language=raw FileName".

And yer, We need a better documentation...

[stax76]

Thanks, I didn't know about Language=raw, I've enabled it now in my GUI which I also use for windows file explorer: staxrip.exe -mediainfo sourcefile

[LoRd_MuldeR]

It is corrected, will be OK in next release or snapshots (https://mediaarea.net/download/snapshots/binary/mediainfo/).

Right.

:thanks:

I can confirm that it is fixed in the "snapshot" version.

[stax76]

Zenitram, there is a issue maybe you can take a look at: https://forum.doom9.org/showthread.php?p=1804785#post1804785

[sneaker_ger]

There's an extra byte added by mkvmerge 11 but I don't know what that means. I asked Mosu.
Sample if anyone wants: https://www.sendspace.com/file/2ja1kx

https://github.com/mbunkus/mkvtoolnix/issues/1958

[sneaker_ger]

@Zenitram @stax76
Was fixed in mkvmerge just now.

[stax76]

@Zenitram @stax76
Was fixed in mkvmerge just now.

Thanks for the help.

[stax76]

I thought typo but maybe it's a text encoding problem, any ideas?


Channel(s)/String : 6 channel3
ChannelPositions : Front: L C R, Side: L R, LFE
SamplingRate/String : 48.0 KHz
FrameRate/String : 46.875 fps3 (1024 spf)


I see this problem in staxrip only in the encoded output file but not on the input file and only with following option:

MediaInfo_Option(mi.Handle, "Language", "raw")

[stax76]

I'm getting crazy with this, it's returned from MI but arbitrary, I thought it might be due to language change on the thread but it's always German. When I start my app it's fine but after I re-encode the problem appears, it happens only with Language raw.

edit:


after startup:

Channel(s) : 2 / 1 / 1
Channel(s)/String : 2 channels / 1 channel / 1 channel


after re-encoding:

Channel(s) : 2 / 1 / 1
Channel(s)/String : 2 channel2 / 1 channel1 / 1 channel1

[Zenitram]

I'm getting crazy with this, it's returned from MI but arbitrary, I thought it might be due to language change on the thread but it's always German. When I start my app it's fine but after I re-encode the problem appears, it happens only with Language raw.

the first time you set Language raw after Open(), the second time it was before (from the first file, the option is global).
"channel3" and so on is the raw data (inside MI), before translation (even to English).

Language raw is to be used mostly for debugging (getting field names), what are you trying to do? set language to "raw" or any language before opening a file for more coherency. Or better: do not use it in production, this is not the goal (I actually don't see the reason you use it, I suggested it for having field names for MediaInfo::Get(), nothing else).

[Zenitram]

Thanks, I didn't know about Language=raw, I've enabled it now in my GUI which I also use for windows file explorer: staxrip.exe -mediainfo sourcefile

This is not an option intended for default mediainfo output, please let the default in that case.
what are you trying to do with that option I advised for getting field names but you use it for default output in your tool?

[stax76]

OK, I use default den.

[Selur]

Small question, when does MediaInfo report something other than 'vbr' as overall bitrate mode?
(tried using bit rate stuffing with tsMuxeR but I always get vbr and a max bitrate of 35MBit/s, which seems kind of odd for a ~500kbit/s stream)

Uploaded a small file to my google drive (https://drive.google.com/drive/folders/0B_WxUS1XGCPAUTlILW54VThMTFU?usp=sharing) as strange.7z.

Cu Selur

[Zenitram]

Small question, when does MediaInfo report something other than 'vbr' as overall bitrate mode?

When it is not VBR ;-).
I have tons of files with CBR overall bitrate mode, mostly dump of satellite or from pro customer preparing to send the TS stream to satellite (or cable, both need CBR TS files)

(tried using bit rate stuffing with tsMuxeR but I always get vbr and

I need to add a big tolerance (30% = NOK, 50% = OK) with " --MpegTs_VbrDetection_Delta=0.5" (hidden feature, default is 0 = no tolerance) for flagging it it as CBR.

a max bitrate of 35MBit/s, which seems kind of odd for a ~500kbit/s stream)

Note my choice, ask to the developer of the software you used for the reason "peak_rate" field is filled with a so high value (lazy default?)
"ETSI EN 300 468 v.1.14.1 - Specification for Service Information (http://www.etsi.org/deliver/etsi_en/300400_300499/300468/01.15.01_60/en_300468v011501p.pdf)":
peak_rate:
The maximum momentary transport packet rate (i.e. 188 bytes divided by the time interval between start
times of two succeeding TS packets). At least an upper bound for this peak_rate should be given. This 22-bit field is
coded as a positive integer in units of 400 bit/s.

0178 0x001F - DVB - selection_information_section (188 bytes)
0178 Header (4 bytes)
0178 sync_byte: 71 (0x47)
0179 transport_error_indicator: No
0179 payload_unit_start_indicator: Yes
0179 transport_priority: No
0179 pid: 31 (0x001F) - (13 bits)
017B transport_scrambling_control: 0 (0x0) - (2 bits)
017B adaptation_field_control (adaptation): No
017B adaptation_field_control (payload): Yes
017B continuity_counter: 1 (0x1) - (4 bits)
017C File Header (1 bytes)
017C pointer_field: 0 (0x00)
017D DVB - selection_information_section - Version=0 - Section=0 (28 bytes)
017D Header (3 bytes)
017D table_id: 127 (0x7F)
017E section_syntax_indicator: Yes
017E private_indicator: Yes
017E reserved: 3 (0x3) - (2 bits)
017E section_length: 25 (0x019) - (12 bits)
0180 DVB_reserved_for_future_use: 65535 (0xFFFF)
0182 reserved: 3 (0x3) - (2 bits)
0182 version_number: 0 (0x00) - (5 bits)
0182 current_next_indicator: Yes
0183 section_number: 0 (0x00)
0184 last_section_number: 0 (0x00)
0185 DVB_reserved_for_future_use: 15 (0xF) - (4 bits)
0185 transmission_info_loop_length: 10 (0x00A) - (12 bits)
0187 Descriptors (10 bytes)
0187 DVB - partial_transport_stream_descriptor (10 bytes)
0187 Header (2 bytes)
0187 descriptor_tag: 99 (0x63)
0188 descriptor_length: 8 (0x08)
0189 DVB_reserved_future_use: 3 (0x3) - (2 bits)
0189 peak_rate: 88750 (0x015AAE) - (22 bits)
018C DVB_reserved_future_use: 3 (0x3) - (2 bits)
018C minimum_overall_smoothing_rate: 4194303 (0x3FFFFF) - (22 bits)
018F DVB_reserved_future_use: 3 (0x3) - (2 bits)
018F maximum_overall_smoothing_buffer: 16383 (0x3FFF) - (14 bits)
0191 0001 (4 bytes)
0191 service_id: 1 (0x0001)
0193 DVB_reserved_future_use: Yes
0193 running_status: 0 (0x0) - (3 bits) -
0193 service_loop_length: 0 (0x000) - (12 bits)
0195 CRC32: 874440526 (0x341EE74E)

[stax76]

Can somebody point me to a sample containing:

MaxCLL - Maximum Content Light Level
MaxFALL - Maximum Frame-Average Light Level

[LoRd_MuldeR]

MediaInfoXP v2.27 (MediaInfo v0.7.99):
https://sourceforge.net/projects/muldersoft/files/MediaInfo%20%28CLI%2BGUI%29/MediaInfo-GUI.2017-10-29.zip/download

* MediaInfo updated to v0.7.99 (2017-09-11)
* Build environment upgraded to Visual Studio 2017 (15.4)

[StainlessS]

Praise the Lord
Thanx :)

[Atak_Snajpera]

It looks like that method of numbering versions has been changed to YEAR.MONTH
https://sourceforge.net/projects/mediainfo/files/binary/mediainfo/

[Emulgator]

Hi Zenitram !
Many thanks for your continued work !
While going through my testfiles I found mediainfo recognising multichannel MPEG Audio Layer 2 streams
(I got 4-CH, 5-CH, 6-CH as 5.1, up to 8 shall be possible) as 2 channel streams.
I can supply some testfiles, if needed.

[LoRd_MuldeR]

Hi Zenitram !
Many thanks for your continued work !
While going through my testfiles I found mediainfo recognising multichannel MPEG Audio Layer 2 streams
(I got 4-CH, 5-CH, 6-CH as 5.1, up to 8 shall be possible) as 2 channel streams.
I can supply some testfiles, if needed.

AFAIK, MPEG Audio Layer II only supports channel modes "Stereo" (00), "Joint Stereo" (01), "Dual Channel" (10) and "Single Channel" (11). Same for Layer III, by the way.
https://web.archive.org/web/20150208104604/http://www.mpgedit.org/mpgedit/mpeg_format/mpeghdr.htm

The so-called "MPEG Multichannel" extension uses a “channel matrixing scheme, where the additional channels are mixed into the two backwards compatible channels”, similar (but apparently not compatible to) Dolby Pro Logic.

So, technically, this would still be a Stereo file, just with the signals for the additional "sourround" channels mixed into the actual two (Stereo) channels...

[Emulgator]

Ah, thank you, that clears it up and at the same time explains why these multichannel files can be decoded with a stereo decoder.
I found Center mixed 50/50 into L/R, SL into L, SR into R.

[Atak_Snajpera]

What are string codes for these items?

Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0050 cd/m2, max: 4000.0000 cd/m2
Maximum Content Light Level : 1529 cd/m2
Maximum Frame-Average Light Level : 380 cd/m2

I'm checking list of parameters in documentation (Developers\List_Of_Parameters\Video.csv) and I can't find anything related to above items.

[Zenitram]

What are string codes for these items?

Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0050 cd/m2, max: 4000.0000 cd/m2
Maximum Content Light Level : 1529 cd/m2
Maximum Frame-Average Light Level : 380 cd/m2

I'm checking list of parameters in documentation (Developers\List_Of_Parameters\Video.csv) and I can't find anything related to above items.

they are currently not MediaInfo "standard" (they could in the future, maybe slightly modified). Field names can be seen with command line and " --Language=raw" or XML output in the GUI, e.g.:

<MasteringDisplay_ColorPrimaries>R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000</MasteringDisplay_ColorPrimaries>
<MasteringDisplay_Luminance>min: 0.0050 cd/m2, max: 4000.0000 cd/m2</MasteringDisplay_Luminance>
<MaxCLL>10000 cd/m2</MaxCLL>
<MaxFALL>111 cd/m2</MaxFALL>

[Atak_Snajpera]

What is equivalent of

Transfer characteristics : PQ

in x265 settings

--transfer <string> Specify transfer characteristics from bt709, unknown, reserved, bt470m, bt470bg, smpte170m,
smpte240m, linear, log100, log316, iec61966-2-4, bt1361e, iec61966-2-1,
bt2020-10, bt2020-12, smpte2084, smpte428, arib-std-b67. Default undef

According to this I'm guessing that smpte2084.
http://i.cubeupload.com/cSkXcy.png

[Zenitram]

What is equivalent of

Transfer characteristics : PQ

in x265 settings


smpte2084 (https://en.wikipedia.org/wiki/High-dynamic-range_video#Perceptual_Quantizer)

[Atak_Snajpera]

It would be much easier for user if you used well known values like in x264/x265 documentation. In this case smpte2084 instead of PQ,
bt2020nc, bt2020c instead of BT.2020 non-constant/constant.

--colorprim <string> Specify color primaries from bt709, unknown, reserved, bt470m, bt470bg, smpte170m,
smpte240m, film, bt2020, smpte428, smpte431, smpte432. Default undef
--transfer <string> Specify transfer characteristics from bt709, unknown, reserved, bt470m, bt470bg, smpte170m,
smpte240m, linear, log100, log316, iec61966-2-4, bt1361e, iec61966-2-1,
bt2020-10, bt2020-12, smpte2084, smpte428, arib-std-b67. Default undef
--colormatrix <string> Specify color matrix setting from undef, bt709, fcc, bt470bg, smpte170m,
smpte240m, GBR, YCgCo, bt2020nc, bt2020c, smpte2085, chroma-derived-nc, chroma-derived-c, ictcp. Default undef

[Zenitram]

It would be much easier for user if you used well known values like in x264/x265 documentation. In this case smpte2084 instead of PQ,
bt2020nc, bt2020c instead of BT.2020 non-constant/constant.

I am in good mood, so let's go.

Sure, as soon as you can prove that what x264/x265 do is "well known" for all people involved with colors.
Spoiler: you won't be able to prove that, as I already had the opposite complain ("please use PQ wording, please use well know values, instead of this crazy SMPTE number") during some beta version.

Ho, BTW, please hint x265 people to change their name, because they do HEVC, look at the URL here https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding , "265" is not known by everyone, look it is not in the URL of Wikipedia English (but it is in the French version, funny isn't it?), why do they mislead people with "265" thing? (I use "HEVC" word, sorry "H.265" people)

(A bit) more seriously, please don't do assumption that x265 people have the "real truth", they are not the center of the universe and they don't represent the industry as a whole (because the industry is not a whole), and in the case of "PQ" it is the "well known value" used by one of my sponsor, a lot known in this industry, and actually my policy is to try to avoid SMPTE number (side note: this is "SMPTE ST 2084", not "SMPTE 2084") when I can because they are difficult to memorize (and are less known than the BT ones), beside prioritizing American names (MPEG ones: AVC, HEVC...) other ITU names (H.264, H.265) when it is a joint venture with only different names in their respective standard bodies.
Warning, in the next release there is a change in order to meet this policy, as I was not aware of "well known names" (remark: someone complained about the exact opposite of your remark when he indicated new names, because I was using SMPTE numbers, the ones used by x265, and not "well known names" from his point of view, he wanted me to replace by his "well known values"), I used SMPTE numbers 431-2 and 432-1 (funny isn't it that such numbers are difficult to differentiate? Worse, one is "RP" and the other is "EG" and 431 alone does not exist, it is 431-2) only because I was not aware of "well known names" and I'll replace them by "DCI P3" and "Display P3" (https://www.google.de/search?q="Display+P3") (commit (https://github.com/MediaArea/MediaInfoLib/commit/afd79f679ace1b27be429a4eb186c1cd383ca839#diff-5f9a9b29a1d4637c8efbb1291b6e0db6)).

summary: your "well known values" are not the "well known values" of some other people, and whatever I choose, someone will complain, this is not the first time and it will not be the last time, as MediaInfo is used by a lot of very different people in this industry, each "community" having different "well known value", when I choose a name I am sure another "community" will complain. I may add option "choose your community" in the future if people are crazy enough for paying for seeing their "well known values" instead of the ones I chose.

PS: bt2020nc means exactly "BT.2020 non-constant", I just show something more "readable", why should I limit the display to a limitation of the command line? I may use "codes" (short names without spaces) internally in the future, but nothing says that I would use x264/x265 choices vs other tools choices.

PPS: in an ideal world, everyone would speak the same language and everyone would use the same "well known values", unfortunately we are not in this ideal world so if you don't do any "translation", someone else will do the same remark about his need to have a translation between your values and his values.

[Atak_Snajpera]

Do you have a full list of "your well known codes" so I could translate them to "my well known codes" for x264/x265 use?
I just need to know that I pass correct codes to encoder. That's all.

[Zenitram]

Do you have a full list of "your well known codes" so I could translate them to "my well known codes" for x264/x265 use?
I just need to know that I pass correct codes to encoder. That's all.

Here (https://github.com/MediaArea/MediaInfoLib/blob/c4e2a397b924ed92302788eaf1c9a0b5571fde0e/Source/MediaInfo/Video/File_Mpegv.cpp#L33-L98) for MPEG related value, Here (https://github.com/MediaArea/MediaInfoLib/blob/b108dc5210607cda2232186df08930a5e5883115/Source/MediaInfo/Image/File_Dpx.cpp#L143-L180) for DPX values.

but right, definitely a need of better doc (not in code)

[Kurtnoise]

#MediaInfo users, we need some testers of #MediaInfoOnline technology preview.

MediaInfo in your browser, without installing any software and everything stays on your machine.

mediaarea.net/MediaInfoOnline

[Q-the-STORM]

#MediaInfo users, we need some testers of #MediaInfoOnline technology preview.

MediaInfo in your browser, without installing any software and everything stays on your machine.

mediaarea.net/MediaInfoOnline

what kind of testing do you need? Testing various files and comparing to local mediainfo output, or testing with various browsers, OS, etc...

Text output slightly differs from v17.12 in this line:

v17.12
Format settings, RefFrames

online
Format settings, ReFrames

[Zenitram]

what kind of testing do you need? Testing various files and comparing to local mediainfo output, or testing with various browsers, OS, etc...

testing with various browsers and report if something does not work, ideas for improvement...

Text output slightly differs from v17.12 in this line:

v17.12
Format settings, RefFrames

online
Format settings, ReFrames

Hum... old bug, should not be there anymore, we'll work on that, thanks.

[Q-the-STORM]

I tested a few more files just to see if I could find more differences, only found two:

I got an old folder with 8 calibration mp4s.
Online doesn't show x264 settings and nominal bitrate on 7 of them
https://www.diffchecker.com/oUUJHGmc
the 8th does correctly show x264 settings and nominal bitrate, it's the only one of them that is larger than 1MB, the rest are smaller than 1MB.

This one doesn't show source duration and Source stream size online
https://www.diffchecker.com/cgPO4RsV
though in this case source duration and duration are the same so it doesn't matter much, though it would be nice to have the exact same output online if possible.

I tested old youtube downloads, some old xvids, vobs from DVDs, some more recent x264 mkvs, hevc hdr video, TV recordings, and some more unusual video like vfr cellphone video, unusual framerates, various containers (mp4, mkv, ts, flv, m2ts), also besides video, some flac, mp3, png, gif and some other files, all had the same output as 17.12.

btw I'm using Win 10 + chrome x64

[Zenitram]

I tested a few more files just to see if I could find more differences, only found two

Thank you for the test, it is useful. Is it possible to get the file?

(...) though it would be nice to have the exact same output online if possible.

We agree! It is the goal.