MediaInfo(Lib) 0.7 - Reading information about media files [Archive] - Page 24

Kurtnoise

6th July 2012, 08:24

I dont mean the tooltip i mean a direct column view integration into Explorer (with selectable data source from mediainfo like codec, container, bitrate,video format,audio format bitrate, framerate, maybe some more codec specific stuff like reference frames, b-frames, gop status, gop time. interlace status ect) without needing to always open the mediainfo gui when working with several files, i wonder that no one needs that it could save time :)
I'm working on it...should be available next week for testing.

ikuban

12th July 2012, 05:03

MediaInfo doesn’t show the exact bitrate of DTS Tracks. It seems that MediaInfo rounds to the nearest value like 755 kbps or 1510 kbps.
There are some DTS tracks out there that have real 768 kbps, but MediaInfo shows them as 755 kbps. I found this bug, when I was testing eac3to.
eac3to shows always the correct bitrate. Also it has a nice feature, which shows DTS header infomation (-logdts). Here are two header infos of a 754.5 kbps and a 768 kbps DTS track.

- frameSize 1024
- DTS-ES -
- channelNo 5
- lfe 1
- channelDescr 5.1
- samplingRate 48000
- bitDepth 24
- bitrate 768000
- samplesPerFrame 512
- copyHistory 1

- frameSize 1006
- DTS-ES -
- channelNo 5
- lfe 1
- channelDescr 5.1
- samplingRate 48000
- bitDepth 24
- bitrate 754500
- samplesPerFrame 512
- copyHistory 1

The difference is in the framesize (and of cource in the bitrate). I also did a simple crosscheck, I divided the filesize (in bit) by the duration (in sec) and the bitrate results were the same as the eac3to it shows.
I don’t know how MediaInfo calculates the DTS bitrate, but with an existing header data the calculation is very simple:

samplingRate / samplesPerFrame * frameSize * 8 / 1000 = bitrate
48000 / 512 * 1024(byte) * 8(bit) / 1000 = 768 kbps
48000 / 512 * 1006(byte) * 8(bit) / 1000 = 754.5 kbps

Also a rate of 1510 kbps is not actual, because most BluRay Movies with »full« DTS bitrate have exact 1509.0 kbps (framesize 2012 byte). Bitrates of 1509.75 kbps (framesize 2013 byte) are very rare.

Zenitram

12th July 2012, 07:51

MediaInfo doesn’t show the exact bitrate of DTS Tracks. It seems that MediaInfo rounds to the nearest value like 755 kbps or 1510 kbps.

I currently use the Tables 5.7 and 5.8 of ETSI TS 102 114 v1.2.1.
"RATE specifies the targeted transmission data rate for the current frame of audio"
"Due to the limitations of the transmission medium the actual bit rate may be slightly different from the targeted bit rate,
as listed in table 5.8 for the two types of applications. The bit-rates that are not shown in the table 5.8 are not applicable
on either of these two applications."

-> I use "Transmission Bit Rate" field instead of computing from "Primary Frame Byte Size" field as you do.

If it is wrong (if there may be several real bit rates for a specific "Transmission Bit Rate" code), I can change the algorithm and use "Number of PCM Sample Blocks", "Primary Frame Byte Size", "Core Audio Sampling Frequency" instead. Please provide sample files for DTS 768 kbps / 754.5 kbps / 1509.0 kbps / 1509.75 kbps.

ikuban

13th July 2012, 00:47

I use "Transmission Bit Rate" field instead of computing from "Primary Frame Byte Size" field as you do.
But your "Transmission Bit Rate" values are also wrong. They have to be 768 or 1536 kbps. Page 20 → ETSI TS 102 114 v1.3.1 (2011-08) (http://www.etsi.org/deliver/etsi_ts/102100_102199/102114/01.03.01_60/ts_102114v010301p.pdf)

If it is wrong (if there may be several real bit rates for a specific "Transmission Bit Rate" code), I can change the algorithm and use "Number of PCM Sample Blocks", "Primary Frame Byte Size", "Core Audio Sampling Frequency" instead.
Yes, there are several bitrates. And again Page 20: "The targeted transmission rate may be greater than or equal to the actual bit rate."

Please provide sample files for DTS 768 kbps / 754.5 kbps / 1509.0 kbps / 1509.75 kbps.
Here you are. Download (http://www38.zippyshare.com/v/97323045/file.html)
I have trimmed all tracks exact to 10s 5.333ms (938 frames). And here is an another bug: MediaInfo shows wrong durations, because of the not exact bitrate values.

754.5 – 10s 5ms
768 – 10s 184ms
1509 – 10s 0ms
1509.75 – 10s 5ms

Zenitram

13th July 2012, 00:53

But your "Transmission Bit Rate" values are also wrong. They have to be 768 or 1536 kbps. Page 20 → ETSI TS 102 114 v1.3.1 (2011-08) (http://www.etsi.org/deliver/etsi_ts/102100_102199/102114/01.03.01_60/ts_102114v010301p.pdf)

OK, the updated version of the spec is more explicit than the one I used, I was wrong about how to compute the bit rate, I'll change it soon. Thank you for the explaination ans samples.

LoRd_MuldeR

20th July 2012, 19:48

Hi, Zenitram. Is there any change Opus (http://www.opus-codec.org/downloads/) detection can be added to MediaInfo? Would be greatly appreciated! :)

Atak_Snajpera

20th July 2012, 20:24

is opus finalized yet?

LoRd_MuldeR

20th July 2012, 20:34

The IETF has accepted it as a standard recently. The final specification is to be released as an RFC anytime soon:
http://www.heise.de/newsticker/meldung/Universal-Audiocodec-Opus-auf-dem-Weg-zum-Internet-Standard-1632291.html

Also there are listening tests that claim Oups already is superior to HE-AAC, which makes it an interesting option, at least ;)

Zenitram

20th July 2012, 20:38

Hi, Zenitram. Is there any change Opus (http://www.opus-codec.org/downloads/) detection can be added to MediaInfo? Would be greatly appreciated! :)

Already added in SVN (http://mediainfo.svn.sourceforge.net/viewvc/mediainfo?view=revision&revision=4912) (in both OGG and Matroska), it will be in next official version.

LoRd_MuldeR

20th July 2012, 20:47

Already added in SVN (http://mediainfo.svn.sourceforge.net/viewvc/mediainfo?view=revision&revision=4912) (in both OGG and Matroska), it will be in next official version.

:thanks: a lot!

sneaker_ger

20th July 2012, 21:49

Zenitram

22nd July 2012, 09:29

MediaInfo reports audio delays on mp4 files (muxed with L-Smash):
https://rapidshare.com/files/2377518186/delay_sample.mp4

"Delay relative to video : -3s 337ms"
Where does that come from? There shouldn't be any delay in that file.

Video edit list:
00812FC9 Edit List (28 bytes)
00812FC9 Header (8 bytes)
00812FC9 Size: 28 (0x0000001C)
00812FCD Name: elst
00812FD1 Version: 0 (0x00)
00812FD2 Flags: 0 (0x000000)
00812FD5 Number of entries: 1 (0x00000001)
00812FD9 Entry (12 bytes)
00812FD9 Track duration: 27352 (0x00006AD8) - 45586 ms
00812FDD Media time: 2002 (0x000007D2) - 3337 ms
00812FE1 Media rate: 65536 (0x00010000) - 1.000

Audio edit list:
008166B1 Edit List (28 bytes)
008166B1 Header (8 bytes)
008166B1 Size: 28 (0x0000001C)
008166B5 Name: elst
008166B9 Version: 0 (0x00)
008166BA Flags: 0 (0x000000)
008166BD Number of entries: 1 (0x00000001)
008166C1 Entry (12 bytes)
008166C1 Track duration: 27404 (0x00006B0C) - 45673 ms
008166C5 Media time: 0 (0x00000000) - 0 ms
008166C9 Media rate: 65536 (0x00010000) - 1.000

--> there is an indication that video starts 3337 ms after audio. Else what is the meaning of this edit list?

sneaker_ger

22nd July 2012, 09:54

Hmm. But how does 2002 translate to 3337ms? Shouldn't it be something like 1000*2002/24000 ~= 83.417ms?
Sorry if my questions sound stupid, just trying to understand.

VFR maniac

23rd July 2012, 04:32

Hmm. But how does 2002 translate to 3337ms? Shouldn't it be something like 1000*2002/24000 ~= 83.417ms?
Sorry if my questions sound stupid, just trying to understand.

http://forum.doom9.org/showthread.php?p=1577792#post1577792
http://mediainfo.svn.sourceforge.net/viewvc/mediainfo/MediaInfoLib/trunk/Source/MediaInfo/Multiple/File_Mpeg4.cpp?r1=4836&r2=4882

It seems the bug (that misunderstands timescale of media_time) was fixed at rev4882.

MP4/MOV has two timescale.
One is for all tracks.
Another is for each media.

In this case, media timescale = 24000, movie timescale = 600.
So, 24000/600 * 83.417 = 3336.68ms = 3s 337ms.

Anyway this is still wrong at point of 'Delay relative to video' since media_time specifies the start time of composition.
Therefore, should take account of CTS of the sample composited at the first.
(Be careful. The first sample is not always the sample composited at the first.)

Zenitram

23rd July 2012, 10:08

It seems the bug (that misunderstands timescale of media_time) was fixed at rev4882.

Actually, yes, I forgot this issue in my quick response. The specs say it is in media time scale units, so I was wrong (I was using the movie timescale unit) and it is corrected.
2002 is 83 milliseconds if I well understood now.

Anyway this is still wrong at point of 'Delay relative to video' since media_time specifies the start time of composition.
Therefore, should take account of CTS of the sample composited at the first.
(Be careful. The first sample is not always the sample composited at the first.)

So what would be exactly the meaning of this delta?
I see that track and media duration of :
- video: 45s 587ms (1093 frames)
- audio: 45s 673ms

so a delay of 83 milliseconds is maybe logical (the end of delay+video would be the end of audio)

I don't know what is the expected synchro when there is such "edit list" :(, any help is welcome.

VFR maniac

23rd July 2012, 12:52

So what would be exactly the meaning of this delta?
I see that track and media duration of :
- video: 45s 587ms (1093 frames)
- audio: 45s 673ms

so a delay of 83 milliseconds is maybe logical (the end of delay+video would be the end of audio)

I don't know what is the expected synchro when there is such "edit list" :(, any help is welcome.

Each edit in edit list maps a portion of media timeline to presentation timeline.
Concatenation of all edits makes overall presentation of a track in the movie.
media_time of an edit specifies start time of arbitrary portion of media.
Let's say, CTS of the first composited sample is 2002 because of B-frames reordering, and the first edit has media_time = 2002, then presentation starts from CTS=2002 so the first composited sample is displayed without composition delay derived from B-frames.

Here, the difference of duration between video and audio is accidental and trivial.
Audio is encoded with AAC, so there shall be priming samples at the start and might be remainder samples at the end.
I guess the sum of priming and remainder samples makes 83 milliseconds.

sneaker_ger

23rd July 2012, 13:02

83ms != 45s 673ms - 45s 587ms = 86ms anyways. But yes, I did not remove the AAC encoder delay (and of course not padding at the end) during the sample creation.

sneaker_ger

23rd July 2012, 13:47

Each edit in edit list maps a portion of media timeline to presentation timeline.
Concatenation of all edits makes overall presentation of a track in the movie.
media_time of an edit specifies start time of arbitrary portion of media.
Let's say, CTS of the first composited sample is 2002 because of B-frames reordering, and the first edit has media_time = 2002, then presentation starts from CTS=2002 so the first composited sample is displayed without composition delay derived from B-frames.

So the delay is indeed zero?

VFR maniac

23rd July 2012, 14:24

Yes, zero if the demuxer can handle edit list correctly.

SeeMoreDigital

6th August 2012, 21:28

Hi Zenitram,

Is there any chance you could add support for reading Opus audio files?

If you have not got one already, here's a sample: http://www.sendspace.com/file/ezi6q3

Cheers

EDIT: I've just spotted that LoRd_MuldeR has beaten me to the request :o

SeeMoreDigital

8th August 2012, 17:19

Cool...

Support for reading Opus audio files has been added to MediaInfo 0.7.59

Thanks Zen :D

Zenitram

8th August 2012, 17:22

Support for reading Opus audio files has been added to MediaInfo 0.7.59. Thanks Zen :D

I only accepted a patch from Kurtnoise (http://forum.doom9.org/member.php?u=19312).:D

sneaker_ger

8th August 2012, 18:03

Don't know if it's already supposed to be fixed or still on the to-do list, but the delay of the mp4 sample shows as 83ms now with 0.7.59. Shouldn't this show as 0ms according to VFR maniac's explanation?

Here is an additional sample, this time with a negative delay of 2585 samples to compensate for the aac encoder delay:
http://www.mediafire.com/?57cha6d4yzp7h10

Zenitram

8th August 2012, 19:18

Don't know if it's already supposed to be fixed or still on the to-do list, but the delay of the mp4 sample shows as 83ms now with 0.7.59. Shouldn't this show as 0ms according to VFR maniac's explanation?

I did not have the time to dig a lot in the issue. The tests I have made have a problem: some files I have, with B-frames, have an edit list starting at 0. So I must first understand how all is "compatible" because with the explanation from maniac, there should be a delay in the edit list.
Is there a precise place in specs saying that it is the mandatory behavior? I saw the same kind of explanation in CFF specs, so I don't doubt it is a good explanation, but I have difficulties to understand how I can have the right delay for all the files I have.

burfadel

8th August 2012, 21:45

The Mediainfo 0.7.59 32-bit mediainfo.dll doesn't work properly, at least with Staxrip. Version 0.7.58 and before works fine! The issue is that the framerate info isn't being delieved properly for the AssumeFPS() function, meaning instead of say, AssumeFPS(23.976) it comes up AssumeFPS() instead, which is invalid. This is an issue only with 0.7.59.

Zenitram

8th August 2012, 22:03

The issue is that the framerate info isn't being delieved properly

Which format? Any? I need a sample file.

burfadel

8th August 2012, 22:50

Here is a sample of a file that is affected:
http://www.mediafire.com/?t62da6y8fz8gyl7

Some files work fine, other's don't. Might be something to do with multiple audio and subtitle streams?

As I said, this works fine with previous Mediainfo versions.

Zenitram

9th August 2012, 09:04

Here is a sample of a file that is affected

Time stamps:
Frame 0 : 0
Frame 6 : 134
Frame 2 : 50
Frame 4 : 84
Frame 10: 217
Frame 8 : 167

Reordered:
Frame 0 : 0
Frame 2 : 50 (difference = 50)
Frame 4 : 84 (difference = 34)
Frame 6 : 134 (difference = 50)
Frame 8 : 167 (difference = 34)
Frame 10: 217 (difference = 50)

Average is right (42 ms) but in this case I detect VFR and I can not be sure it will be stable during the whole file.
so now I display:

Frame rate mode : Variable --> Meaning that the container has VFR
Original frame rate : 23.976 fps --> Frame rate indicated in the H264 stream

Is there any good reason to have such time stamps in the Matroska container? Is it wanted? Any kind of 3:2 Pulldown at the Container level? (in this case, I can try to detect it)
As I said, this works fine with previous Mediainfo versions.

Previous versions were buggy, because I was testing DefaultDuration field but the developper of mkvmerge said it was wrong. I can try to open a ticket for mkvmerge developper because in your case DefaultDuration is 42 ms and it is not logical compared to time stamps.

Brazil2

10th August 2012, 11:27

Kurtnoise

10th August 2012, 12:18

A sample would be good...

@Burfadel : what did you say exactly ? Forum had a bug yesterday...

burfadel

10th August 2012, 13:14

I was saying the sample was remuxed using the latest MkvToolNix MMG etc, and that I split the file into 5MB chunks and randomly chose one from the middle for the sample. So the timestamp etc stuff was reset with the sample?

I wasn't sure why it was doing it with that file and not others, I thought it might have been to with the multiple audio and subtitle streams.

Selur

10th August 2012, 17:49

Bug in MediaInfo or ffmpeg?

ffmpeg:
Stream #0:0[0x1e0]: Video: mpeg2video (Main), yuv420p, 720x576 [SAR 64:45 DAR 16:9], 4610 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc

Stream #0:1[0x80]: Audio: ac3, 48000 Hz, 5.1(side), s16, 384 kb/s

Stream #0:2[0x1c1]: Audio: mp2, 48000 Hz, stereo, s16, 128 kb/s

mediainfo:
Kind of stream : Video
Stream identifier : 0
ID : 224 (0xE0)

Kind of stream : Audio
Stream identifier : 0
Stream identifier : 1
ID : 193
ID : 193 (0xC1)

Kind of stream : Audio
Stream identifier : 1
Stream identifier : 2
ID : 189-128
ID : 189 (0xBD)-128 (0x80)

mplayer:
==> Found video stream: 0
ID_VIDEO_ID=0
==> Found audio stream: 128
ID_AUDIO_ID=128
==> Found audio stream: 1
ID_AUDIO_ID=1

ffmpeg reports for the video 0x1E0 -> 480, mediaInfo reports 0xE0,.....
-> anyone know which one is right ?

Zenitram

10th August 2012, 20:01

ffmpeg reports for the video 0x1E0 -> 480, mediaInfo reports 0xE0,.....
-> anyone know which one is right ?

MediaInfo is right.

MPEG-PS specs:
PES_packet() {
packet_start_code_prefix 24 bslbf
stream_id 8 uimsbf
(...)

The packet_start_code_prefix is the bit string '0000 0000 0000 0000 0000 0001' (0x000001).
stream_id specifies the type and number of the elementary stream
Stream_id assignments
Stream_id Note stream coding
1011 1100 1 program_stream_map
1011 1101 2 private_stream_1
1011 1110 padding_stream
1011 1111 3 private_stream_2
110x xxxx ISO/IEC 13818-3 or ISO/IEC 11172-3 or ISO/IEC 13818-7 or ISO/IEC 14496-3 audio stream number x xxxx
(...)

***

ffmpeg includes the start code. It is absolutely not necessary (start code is always same, start code is not part of stream identifier)

Kurtnoise

13th August 2012, 18:23

With MediaInfo 0.7.59 the METADATA_BLOCK_PICTURE information is not reported anymore for some OGG files, in both Tree and Text views, which is the way to know if there is at least one embedded cover inside the file.
The current MI OGG parser doesn't have this field yet...Only COVERART. However, reading official specs, this is now deprecated. We need to add it.

@Zen : after reading the code and specs (http://wiki.xiph.org/VorbisComment#METADATA_BLOCK_PICTURE), it looks like METADATA_BLOCK_PICTURE uses Big Endian format instead Little Indian like in the FLAC block. Can we reuse it ?

A sample can be found here (http://kurtnoise.free.fr/samples/)...

Kurtnoise

13th August 2012, 18:34

burfadel

14th August 2012, 10:17

After reading Zen post, Staxip must be updated on this part to use MI 0.7.59+...i.e reading "Original frame rate" instead of "Frame rate mode".

Ah ok! Staxrip is kind of stalled in development, so I'll just have to stick with Mediainfo 0.7.58

Brazil2

14th August 2012, 12:05

The current MI OGG parser doesn't have this field yet
It works with most files, and always did before, only few files are showing the issue.

Atak_Snajpera

14th August 2012, 18:36

@Zenitram
MediaInfoA_Get(Handle_, 2, 0, 'BitRate', 1, 0) does not return audio bitrate for .opus files
Obviously it works fine for older audio formats.

Zenitram

15th August 2012, 09:48

The issue is that the framerate info isn't being delieved properly for the AssumeFPS() function, meaning instead of say, AssumeFPS(23.976) it comes up AssumeFPS() instead, which is invalid. This is an issue only with 0.7.59.

Is it possible to have the original file (the one used to mux) too? mkvmerge and me don't know yet where is the issue.
mkvmerge ticket: https://trac.bunkus.org/ticket/781

PS: for other issues, I don't have the time to take care of them this month, please be patient.

burfadel

15th August 2012, 17:06

Is it possible to have the original file (the one used to mux) too? mkvmerge and me don't know yet where is the issue.
mkvmerge ticket: https://trac.bunkus.org/ticket/781

PS: for other issues, I don't have the time to take care of them this month, please be patient.

Uploading it to a site now, will PM you the link when done.

Zenitram

16th August 2012, 09:34

The issue is that the framerate info isn't being delieved properly for the AssumeFPS() function, meaning instead of say, AssumeFPS(23.976) it comes up AssumeFPS() instead, which is invalid. This is an issue only with 0.7.59.

I got your source file.
It has the same kind of issue with time stamps / duration, something is buggy with the orignal file.
It was made with HandBrake 0.9.4 (+libmkv 0.6.4), I don't plan to dig more about this issue, it seems it is more a problem with Handbrake or how Handbrake was used, and I don't know how Handbrake was used, so it is difficult for me to open a ticket on the Handbrake tracker (I need the original file for Handbrake + how Handbrake was used)

MediaInfo only displays that there is a problem with the file if the expected frame rate is 23.976 fps, and it is the expected behavior of MediaInfo.

burfadel

16th August 2012, 09:58

Ah ok :) Just thought it was strange that 0.7.58 seemed to handle it fine and 0.7.59 doesn't. At least it is something of 'little concern' :)

Thanks!

Zenitram

16th August 2012, 10:01

Just thought it was strange that 0.7.58 seemed to handle it fine and 0.7.59 doesn't.

My point of view is a bit different ;-):
- 0.7.58 was missing to catch the issue with that file and was reporting wrong information compared to the real content (even if you expect that this information is the right one)
- 0.7.59 catchs now the issue and display it.

MediaInfo is also used to catch wrongly muxed files, so it is one on its goals to find such issue.

Kurtnoise

17th August 2012, 08:00

It works with most files, and always did before, only few files are showing the issue.
could you upload a file which works please ?

MediaInfoA_Get(Handle_, 2, 0, 'BitRate', 1, 0) does not return audio bitrate for .opus files
Obviously it works fine for older audio formats.
Stream Duration calculation is not implemented yet for this format...

stax76

19th August 2012, 18:00

@burfadel

I've committed a fix to SVN but don't have a release schedule, sometime this year I guess.

burfadel

19th August 2012, 19:11

@burfadel

I've committed a fix to SVN but don't have a release schedule, sometime this year I guess.

Thanks, much appreciated!

Keiyakusha

21st August 2012, 19:42

I broke my head trying to figure this out... can someone please look into this?
So here is mkv file (http://www.mediafire.com/?lz17pnhotgh7hpv). I encoded it with constant fps 24000/1001 but mediainfo for some reason reports it to be variable framerate. The whole file is truly constant. Something that confuses mediainfo is in the beginning of the file.
Even after I remux this file with timecodes like below, or even by patching h264 stream to be lets say 30000/1001 fps instead and then muxing it with mkvmerge - mediainfo still reports it have variable fps... or maybe this is mkvmerge problem or something?
Some files have this "issue", some not, even though I encode them in the same way...

# timecode format v1
Assume 23.976024
0,36755,23.976024

Zenitram

21st August 2012, 20:39

I broke my head trying to figure this out...(...) mediainfo still reports it have variable fps...

I think it is a bug from MediaInfo. Nothing else. I'll correct it soon.

Zenitram

21st August 2012, 22:43

mediainfo still reports it have variable fps...

Corrected in developments snapshots:
http://sourceforge.net/projects/mediainfo/files/development_snapshots/0.7.59%2B/MediaInfo_GUI_20120821_Windows_i386_WithoutInstaller.7z/download

the headache you had is due to a value roundig issue (sometimes the delta is 41 ms, sometimes 42 ms) and MediaInfo was sometimes catching the CFR, sometimes not.