But some programs can somehow find proper one - f.e. Windows Media Player of ffplay (from ffmpeg package).
I've posted sample file here: http://dl.dropbox.com/u/17364065/160brmp2.avi
00000064 Stream header (64 bytes)
00000064 Header (8 bytes)
00000064 Name: strh
00000068 Size: 56 (0x38)
0000006C fccType: auds
00000070 fccHandler: 1 (0x1)
00000074 Flags: 0 (0x00000000)
00000078 Priority: 0 (0x0000)
0000007A Language: 0 (0x0000)
0000007C InitialFrames: 0 (0x00000000)
00000080 Scale: 32 (0x20)
00000084 Rate: 1225 (0x4C9)
00000088 Start: 0 (0x0)
0000008C Length: 1039 (0x40F)
00000090 SuggestedBufferSize: 12288 (0x00003000)
00000094 Quality: 4294967295
00000098 SampleSize: 1152 (0x00000480)
0000009C Frame_Left: 0 (0x0000)
0000009E Frame_Top: 0 (0x0000)
000000A0 Frame_Right: 0 (0x0000)
000000A2 Frame_Bottom: 0 (0x0000)
Duration is Length*Scale/Rate = 1039*32/1225= 27 seconds.
Windows Media Player finds the right duration (based on the count of frames
in the index = 2293 frames), but VLC reads the duration from the header.
There is an inconstency in your file.
Moved to feature request, in order to have both durations
There are 2 durations:
- The one from the header
- The one from the index
The file is buggy, and should be corrected.
Some players use the first one, some others the second one.
So MediaInfo continues to report the duration from header, but it provides now a second duration, as it already does with QuickTime (same kind of issue, behavior depends of the player)
Example result for such file:
Duration : 27s 141ms
Source duration : 59s 899ms
Feature request done.
Available in the latest development snapshot:
or next official release.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.