MediaInfo(Lib) 0.7 - Reading information about media files - Page 27

ipanema · 18th September 2009, 15:24

The B frame must be based only on the I frame that is presentationally AFTER it (i.e. the I frame appears BEFORE it in the file/encoding order). The B frame is not based on any earlier frames (there are none) - that's what a closed GOP means. If they were based on earlier frames which were not present then the GOP is open. Note that this applies to MPEG-2 also so you may need to look at how the video delay for MPEG-2 is calculated aswell.

Of course there may be 1 or 2 B frames (or more?) presentaionally before the I frame. I suggest something like .... look forward from the start of file for the first I frame, then continue searching forward for the next video frame whose PTS is greater than the I-frame's PTS - during the search count the number of frames you find whose PTS is less than the I-frame's PTS.

That will give you the number of B frames that are presentationally before the I frame, but it won't tell you whether the decoder WILL output the preceeding B frames. For that you need to look for the closed-gop flag in MPEG-2. Unfortunately for H.264 (MTS) I don't know where the corresponding flag is (I would love to know).

ipanema · 18th September 2009, 15:51

I've PM-ed you but my Sent folder is still empty so I don't know if you have received the message - let me know if not.

Shark007 · 5th October 2009, 20:52

For your consideration; This 7.1 TrueHD audio sample is detected as only having 6 channels. Current FFDshow (rev3094) releases detect all 8 channels.

SeeMoreDigital · 5th October 2009, 21:46

Quote:

Originally Posted by Shark007

For your consideration; This 7.1 TrueHD audio sample is detected as only having 6 channels. Current FFDshow (rev3094) releases detect all 8 channels.

If MediaInfo could identify the properties of the "core" and "HD" parts separately, yes this would be very useful.

Cheers

Brazil2 · 13th October 2009, 16:44

I'm getting strange results with a MTS file recorded with a Panasonic TZ7:

Code:

General
ID                               : 0
Complete name                    : F:\Test\TZ7.MTS
Format                           : BDAV
Format/Info                      : Blu-ray Video
File size                        : 8.46 MiB
Duration                         : 4s 672ms
Overall bit rate                 : 15.2 Mbps
Maximum Overall bit rate         : 18.0 Mbps

Video
ID                               : 4113 (0x1011)
Menu ID                          : 1 (0x1)
Format                           : AVC
Format/Info                      : Advanced Video Codec
Format profile                   : High@L4.0
Format settings, CABAC           : No
Format settings, ReFrames        : 1 frame
Duration                         : 4s 640ms
Bit rate                         : 14.4 Mbps
Width                            : 1 280 pixels
Height                           : 720 pixels
Display aspect ratio             : 16:9
Frame rate                       : 25.000 fps
Standard                         : NTSC
Resolution                       : 24 bits
Colorimetry                      : 4:2:0
Scan type                        : Progressive
Bits/(Pixel*Frame)               : 0.624
Stream size                      : 7.95 MiB (94%)

Audio
ID                               : 4352 (0x1100)
Menu ID                          : 1 (0x1)
Format                           : AC-3
Format/Info                      : Audio Coding 3
Duration                         : 4s 672ms
Bit rate mode                    : Constant
Bit rate                         : 192 Kbps
Channel(s)                       : 2 channels
Channel positions                : L R
Sampling rate                    : 48.0 KHz
Stream size                      : 110 KiB (1%)

How can it be NTSC with 25 FPS ?

And also MPC-HC, TsMuxer and MP4Box are all saying that the file is 50 FPS.
Example from MPC-HC:

Code:

Video: MPEG4 Video (H264) 1280x720 50.00fps [Video]
Audio: Dolby AC3 48000Hz stereo 192Kbps [Audio]

Sample:
http://www.megaupload.com/?d=4PFDDYK4

LoRd_MuldeR · 13th October 2009, 17:27

Quote:

How can it be NTSC with 25 FPS ?

It can't. The definition of NTSC in the "digital world" is 720x480@29.97fps. The video size of 1280x720 also isn't NTSC.

SeeMoreDigital · 13th October 2009, 17:34

Hi Brazil2,

In order for these Panasonic 1280x720 video streams to comply with the Blu-ray specification they contain an implementation called "frame repeats". This raises the frame speed from 25fps to 50fps but not the number of "actual" progressive frames.

I guess it can be further described as a form of pull-down.

EDIT: After re-muxing the elementary stream into the .MP4 container, here's what AVInaptic reports. Is there any data listed here that could explain why MediaInfo thinks it's an NTSC stream: -

Code:

[ Relevant data ]

Resolution: 1280 x 720
Width: multiple of 32
Height: multiple of 16
Average DRF: 21.931623
Standard deviation: 1.875284
Std. dev. weighted mean: 1.746235

[ Video track ]

Codec: avc1
Resolution: 1280 x 720
Frame aspect ratio: 16:9 = 1.777777
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 16:9 = 1.777777
Framerate: 50 fps
Number of frames: 117
Bitrate: 28402.984615 kbps

[ About H.264 encoding ]

SPS id: 0
  Profile: High@L4
  Num ref frames: 1
  Aspect ratio: Square pixels
  Chroma format idc: YUV 4:2:0
PPS id: 0 (SPS: 0)
  Entropy coding type: CAVLC
  Weighted prediction: No
  Weighted bipred idc: No
  8x8dct: No
  Custom intra4X4 luma: 
      5   7  10  12
      7  10  12  16
     10  12  16  20
     12  16  20  20
  Custom intra4X4 chromau: 
      5   8  12  16
      8  12  16  16
     12  16  20  24
     16  20  24  24
  Custom intra4x4 chromav: 
      5   8  12  16
      8  12  16  16
     12  16  20  24
     16  20  24  24
  Custom inter4X4 luma: 
     10  15  24  30
     15  24  30  36
     24  30  36  36
     30  36  36  36
  Custom inter4X4 chromau: 
      9  13  20  25
     13  20  25  30
     20  25  30  30
     25  30  30  30
  Custom inter4x4 chromav: 
      9  13  20  25  13  20  25  30
     20  25  30  30  25  30  30  30
    135 110 211 247 129   0   0   0
      0   0   0   0   0   0   0   0
      0   0   0   0   0   0   0   0
      0   0   0   0   0   0   0   0
      0   0   0   0   0   0   0   0
      0   0   0   0   0   0   0   0
Number of frames: 117
Drop/delay frames: 0
Corrupted frames: 0

P-slices: 108 ( 92.308 %) #######################  
B-slices:   0 (  0.000 %)                          
I-slices:   9 (  7.692 %) ##                       
SP-slices:   0 (  0.000 %)                          
SI-slices:   0 (  0.000 %)                          

[ DRF analysis ]

Average DRF: 21.931623
Standard deviation: 1.875284
Max DRF: 33

DRF<18:  0 (  0.000 %)                          
DRF=18:  1 (  0.855 %)                          
DRF=19:  0 (  0.000 %)                          
DRF=20: 27 ( 23.077 %) ######                   
DRF=21: 18 ( 15.385 %) ####                     
DRF=22: 42 ( 35.897 %) #########                
DRF=23: 12 ( 10.256 %) ###                      
DRF=24:  7 (  5.983 %) #                        
DRF=25:  5 (  4.274 %) #                        
DRF=26:  4 (  3.419 %) #                        
DRF=27:  0 (  0.000 %)                          
DRF=28:  0 (  0.000 %)                          
DRF=29:  0 (  0.000 %)                          
DRF=30:  0 (  0.000 %)                          
DRF=31:  0 (  0.000 %)                          
DRF=32:  0 (  0.000 %)                          
DRF=33:  1 (  0.855 %)                          
DRF>33:  0 (  0.000 %)                          

P-slices average DRF: 21.888888
P-slices std. deviation: 1.553570
P-slices max DRF: 26

I-slices average DRF: 22.444444
I-slices std. deviation: 4.058218
I-slices max DRF: 33

Cheers

smok3 · 14th October 2009, 12:57

unexpected behaviour/bug: unable to drop media file to icon in stack (osx snow leopard), with gui version of course.

Zenitram · 15th October 2009, 12:28

Quote:

Originally Posted by Shark007

For your consideration; This 7.1 TrueHD audio sample is detected as only having 6 channels. Current FFDshow (rev3094) releases detect all 8 channels.

Thanks for the file.
I currently don't parse the "HD" part, because I don't have any specifcations, so only the "Core" part is analyzed.
I look at ffmpeg code in order to see how they parse this HD part, and I hope to be able to display the "HD" part.

Quote:

Originally Posted by SeeMoreDigital

If MediaInfo could identify the properties of the "core" and "HD" parts separately, yes this would be very useful.

Good idea.
MediaInfo was not designed to handle multiple Channel count or sampling rate values for 1 stream, I try to see how I can handle this (for both AC-3 and DTS)

Zenitram · 15th October 2009, 12:52

Quote:

Originally Posted by Brazil2

I'm getting strange results with a MTS file recorded with a Panasonic TZ7.
How can it be NTSC with 25 FPS ?

I only report data from the stream.
After demuxing:

Code:

00000001 access_unit_delimiter (5 bytes)
(...)
00000007 seq_parameter_set (46 bytes)
00000007  Header (4 bytes)
00000007   sync:                                    1 (1)
0000000A   nal_ref_idc:                             3 (3)
0000000A   nal_unit_type:                           7 (7)
0000000B  profile_idc:                              64 (100)
(...)
00000013  vui_parameters_present_flag (34 bytes)
00000013   vui_parameters_present_flag:             Yes
(...)
00000015   video_signal_type_present_flag (2 bytes)
00000015    video_signal_type_present_flag:         Yes
00000015    video_format:                           2 (2) - NTSC
00000015    video_full_range_flag:                  No
00000016    colour_description_present_flag:        No
(...)

--> video_format should be:
* not present
* or egal to 5 (no format)
But Panasonic decided to put this item in the stream, and to set it as NTSC. I report this.

Quote:

Originally Posted by LoRd_MuldeR

It can't. The definition of NTSC in the "digital world" is 720x480@29.97fps. The video size of 1280x720 also isn't NTSC.

Panasonic has maybe decided to change the definition ;-)

Quote:

Originally Posted by Brazil2

And also MPC-HC, TsMuxer and MP4Box are all saying that the file is 50 FPS.
Example from MPC-HC:

Code:

Video: MPEG4 Video (H264) 1280x720 50.00fps [Video]
Audio: Dolby AC3 48000Hz stereo 192Kbps [Audio]

Yes, wrong detection from me, this is a 50 fps stream.

Quote:

Originally Posted by SeeMoreDigital

Hi Brazil2,

In order for these Panasonic 1280x720 video streams to comply with the Blu-ray specification they contain an implementation called "frame repeats". This raises the frame speed from 25fps to 50fps but not the number of "actual" progressive frames.

I guess it can be further described as a form of pull-down

You are nearly right:
* There is "frame doubling", I indicate it in the "Easy view": "(Frame doubling / 1 Ref Frames)", but I noticed this is not in the other views, I will modify other views.
* Time clock is set to 100 fps. So with Frame doubling AND progressive sequence, this is 50 fps (25 fps if frame doubling AND interlaced sequence)

Zenitram · 15th October 2009, 12:53

Quote:

Originally Posted by smok3

unexpected behaviour/bug: unable to drop media file to icon in stack (osx snow leopard), with gui version of course.

I am limitated by drag n drop capacities of WxWidgets toolkit.
I am moving to Qt, which is a lot better for this kind of stuff, but it is unfortunatly not yet ready.

Brazil2 · 17th October 2009, 15:45

Sample: http://rapidshare.com/files/29345782...n-mpc.mp2.html

MediaInfo reports the DAR as 2.35:1 :

Code:

General
Complete name                    : F:\Test\no-audio-in-mpc.mp2
Format                           : MPEG-PS
File size                        : 2.63 MiB
Duration                         : 3s 168ms
Overall bit rate                 : 6 966 Kbps

Video
ID                               : 224 (0xE0)
Format                           : MPEG Video
Format version                   : Version 2
Format profile                   : Main@Main
Format settings, Matrix          : Default
Duration                         : 3s 120ms
Bit rate mode                    : Constant
Bit rate                         : 6 500 Kbps
Width                            : 720 pixels
Height                           : 576 pixels
Display aspect ratio             : 2.35:1
Frame rate                       : 25.000 fps
Standard                         : PAL
Colorimetry                      : 4:2:0
Scan type                        : Interlaced
Scan order                       : Top Field First
Bits/(Pixel*Frame)               : 0.627
Stream size                      : 2.42 MiB (92%)

Audio
ID                               : 128 (0x80)
Format                           : AC-3
Format/Info                      : Audio Coding 3
Duration                         : 3s 168ms
Bit rate mode                    : Constant
Bit rate                         : 448 Kbps
Channel(s)                       : 6 channels
Channel positions                : Front: L C R, Surround: L R, LFE
Sampling rate                    : 48.0 KHz
Video delay                      : -48ms
Stream size                      : 173 KiB (6%)

But every other tool (e.g. Gspot, DGindex, ProjectX) and player (e.g. MPC-HC) reports the DAR as being 16:9. And players are playing it at 16:9.

Code:

Video: MPEG2 Video 720x576 (16:9) 25.00fps 6500Kbps [Video]
Audio: Dolby AC3 48000Hz 6ch 448Kbps [Audio]

So I wonder where this info comes from, the container or the video stream ? If the DAR information is different between the container and the video stream then why not showing both informations like this:

Code:

Format                           : MPEG-PS
File size                        : 2.63 MiB
Container DAR                    : 2.35:1
Duration                         : 3s 168ms
Overall bit rate                 : 6 966 Kbps

Video
ID                               : 224 (0xE0)
Format                           : MPEG Video
Format version                   : Version 2
Format profile                   : Main@Main
Format settings, Matrix          : Default
Duration                         : 3s 120ms
Bit rate mode                    : Constant
Bit rate                         : 6 500 Kbps
Width                            : 720 pixels
Height                           : 576 pixels
Display aspect ratio             : 16:9

Zenitram · 17th October 2009, 16:18

Quote:

Originally Posted by Brazil2

Sample: http://rapidshare.com/files/29345782...n-mpc.mp2.html
(...)
But every other tool (e.g. Gspot, DGindex, ProjectX) and player (e.g. MPC-HC) reports the DAR as being 16:9. And players are playing it at 16:9.

So I wonder where this info comes from, the container or the video stream ?

For your file:
00000821 sequence_header (12 bytes)
00000828 aspect_ratio_information: 3 (3) - 1.778
0000082D extension_start - Sequence (10 bytes)
00000832 horizontal_size_extension: 0 (0)
00000833 vertical_size_extension: 0 (0)
00000837 extension_start - Sequence Display (12 bytes)
0000083F display_horizontal_size: 21C (540)
00000840 display_vertical_size: 240 (576)

"Sequence Display" description in specifications is not very precise, my formula is (if there is a "Sequence Display" extension):
(0x1000*horizontal_size_extension+horizontal_size_value)/(0x1000*vertical_size_extension+vertical_size_value)*Mpegv_aspect_ratio2[aspect_ratio_information]/(display_horizontal_size/display_vertical_size)

FYI, specifications say "display_horizontal_size and display_vertical_size do not affect the decoding process but may be used by the display process that is not standardised in this specification." (funny, isn't it?)

I think this formula is right or at least the more common (I trust a lot VLC), because both VLC and MPC (not HC) display it as 2.35 (picture is streched, because picture is actually recorded in 16:9 in your case). If I don't handle "Sequence Display" extension, some other files are not well detected.

If "Sequence Display" extension is not handled, DAR is "16:9", but there is a "Sequence Display" extension...

If I remember well, there already was here a discussion about "Sequence Display" extension and the problems with it.

Quote:

Originally Posted by Brazil2

If the DAR information is different between the container and the video stream then why not showing both informations

It already does.
* "Display Aspect Ratio" is the displayed DAR.
* "Original Display Aspect Ratio" is the DAR from the stream if different.

But this file has only one DAR value (the raw video DAR).

Edit:

Quote:

Originally Posted by Brazil2

If the DAR information is different between the container and the video stream then why not showing both informations like this

Your solution is not possible: how do you display data for multiple video stream in one container? "General" container can't have video information, because there are only 1 general item (data about the container) even if there are 30 video streams (this is possible, e.g. MPEG-TS from satellites)

Shark007 · 17th October 2009, 18:20

Quote:

Originally Posted by Brazil2

Sample: http://rapidshare.com/files/29345782...n-mpc.mp2.html

But every other tool (e.g. Gspot, DGindex, ProjectX) and player (e.g. MPC-HC) reports the DAR as being 16:9. And players are playing it at 16:9.

PowerDVD 9's mpeg2 decoder will play this sample at the correct aspect ratio.

Brazil2 · 17th October 2009, 18:26

Quote:

Originally Posted by Shark007

PowerDVD 9's mpeg2 decoder will play this sample at the correct aspect ratio.

Yes, every player I've tried is playing it at 16:9, even the 'old' MPC (not HC) with internal splitters and decoders and even with external ones despite of what Zenitram said. Only VLC is playing it at 2.35:1.

Zenitram · 18th October 2009, 00:40

Quote:

Originally Posted by Brazil2

Yes, every player I've tried is playing it at 16:9, even the 'old' MPC (not HC) with internal splitters and decoders and even with external ones despite of what Zenitram said. Only VLC is playing it at 2.35:1.

yes, for MPC, this was due of my configuration of MPC, it was using external ffmpeg (ffdshow), as VLC does.

VLC is not a tiny software in a garage, they are not newbees... This is VLC/ffmpeg team vs Cyberlink/MPC!
Anyway, I am interested in your vision about how to interpret "Sequence Display" bytes. Theses bytes exist, I handle them, I need a formula or the signification of theses bytes. For what reason your encoder put theses bytes in the stream?

Ignoring completely "Sequence Display" is not so easy, some other files have wrong DAR if I do this, decision creates a winner and a looser.

So I propose something: I am not as expert as the VLC/ffmpeg team, send this bug report to VLC/ffmpeg team, if you succeed VLC/ffmpeg team to accept that VLC has a bug with your file, I change directly my code and ignore "Sequence Display" without discussion. Another possibility is to have a reply from your encoder creator about the signification of theses bytes in the stream and have an argument about how the creator of the stream imagine theses bytes. Else I don't see what is the purpose of theses bytes if I don't handle them as I currently do, so I prefer to handle them, as VLC/ffmpeg does: if theses bytes are in the stream, there is a reason, ignoring them is not a good solution.

Brazil2 · 18th October 2009, 13:52

I haven't encoded the file myself, it's only a sample that I've found on some forums. Here is another one showing the same issue:
http://rapidshare.com/files/28936871...itle2.vob.html

I'm not sure it's a ffmpeg issue since the files are playing with the correct aspect ratio in Mplayer so it looks more like a splitter issue.
But is it an issue or a feature ? I don't know.
I'm not saying MediaInfo is wrong, in fact without MediaInfo I wouldn't be able to see this 2.35:1 DAR but since other tools and players are ignoring this Sequence Display it might be a good idea to show both aspect ratios in MediaInfo, the Sequence Display and the Aspect Ratio Information. So it will be easier to spot such conflicts.

Zenitram · 18th October 2009, 14:02

Quote:

Originally Posted by Brazil2

but since other tools and players are ignoring this Sequence Display it might be a good idea to show both aspect ratios in MediaInfo, the Sequence Display and the Aspect Ratio Information. So it will be easier to spot such conflicts.

Yes, there is actually an issue for players, displaying both values may be a good reply because my goal is to propose the best tool for debugging players problems, I didn't reacted this is useful to have both values.
I will try to add this feature when I implement "multiple values" support with AC-3 / TrueHD (Core / HD values) proposed by SeeMoreDigital.

LoRd_MuldeR · 18th October 2009, 14:12

Zenitram, a quick question: What exactly do the following pre-processor defines do?

Code:

NDEBUG; MEDIAINFO_MINIMIZESIZE; MEDIAINFO_LIBCURL_NO; MEDIAINFO_LIBMMS_NO

Zenitram · 18th October 2009, 14:20

Quote:

Originally Posted by LoRd_MuldeR

Zenitram, a quick question: What exactly do the following pre-processor defines do?

NDEBUG: identic for all software (No debug --> Release mode)
MEDIAINFO_MINIMIZESIZE: reduce binary size because it removes the trace feature (this feature is not yet completely ready, work in progress, this is the trace I display sometimes here in order to display what is the bytestream of files, no public GUI)
MEDIAINFO_LIBCURL_NO: don't use libcurl (for read from HTTP/FTP instead of HDD files) (works well on Linux but is not currently the default, "all in one" package is not yet ready on Windows, work in progress, but if you compile yourself libcurl you can remove this define)
MEDIAINFO_LIBMMS_NO: don't use libmms (for read from MMS/MMSH instead of HDD files) (this feature will not be available on Windows because libmms is not Windows-compatible, works well on Linux but is not currently the default)

14th October 2009, 12:57	#528 \| Link
smok3 brontosaurusrex Join Date: Oct 2001 Posts: 2,392	unexpected behaviour/bug: unable to drop media file to icon in stack (osx snow leopard), with gui version of course. __________________ certain other member

18th October 2009, 14:12	#539 \| Link
LoRd_MuldeR Software Developer Join Date: Jun 2005 Location: Last House on Slunk Street Posts: 13,248	Zenitram, a quick question: What exactly do the following pre-processor defines do? Code: NDEBUG; MEDIAINFO_MINIMIZESIZE; MEDIAINFO_LIBCURL_NO; MEDIAINFO_LIBMMS_NO __________________ Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

18th September 2009, 15:24	#521 \| Link
ipanema Registered User Join Date: Apr 2009 Posts: 93	The B frame must be based only on the I frame that is presentationally AFTER it (i.e. the I frame appears BEFORE it in the file/encoding order). The B frame is not based on any earlier frames (there are none) - that's what a closed GOP means. If they were based on earlier frames which were not present then the GOP is open. Note that this applies to MPEG-2 also so you may need to look at how the video delay for MPEG-2 is calculated aswell. Of course there may be 1 or 2 B frames (or more?) presentaionally before the I frame. I suggest something like .... look forward from the start of file for the first I frame, then continue searching forward for the next video frame whose PTS is greater than the I-frame's PTS - during the search count the number of frames you find whose PTS is less than the I-frame's PTS. That will give you the number of B frames that are presentationally before the I frame, but it won't tell you whether the decoder WILL output the preceeding B frames. For that you need to look for the closed-gop flag in MPEG-2. Unfortunately for H.264 (MTS) I don't know where the corresponding flag is (I would love to know).

18th September 2009, 15:51	#522 \| Link
ipanema Registered User Join Date: Apr 2009 Posts: 93	I've PM-ed you but my Sent folder is still empty so I don't know if you have received the message - let me know if not.

5th October 2009, 20:52	#523 \| Link
Shark007 Registered User Join Date: Apr 2009 Posts: 88	For your consideration; This 7.1 TrueHD audio sample is detected as only having 6 channels. Current FFDshow (rev3094) releases detect all 8 channels.

18th October 2009, 13:52	#537 \| Link
Brazil2 Registered User Join Date: Jul 2008 Posts: 532	I haven't encoded the file myself, it's only a sample that I've found on some forums. Here is another one showing the same issue: http://rapidshare.com/files/28936871...itle2.vob.html I'm not sure it's a ffmpeg issue since the files are playing with the correct aspect ratio in Mplayer so it looks more like a splitter issue. But is it an issue or a feature ? I don't know. I'm not saying MediaInfo is wrong, in fact without MediaInfo I wouldn't be able to see this 2.35:1 DAR but since other tools and players are ignoring this Sequence Display it might be a good idea to show both aspect ratios in MediaInfo, the Sequence Display and the Aspect Ratio Information. So it will be easier to spot such conflicts.