Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
|
Thread Tools | Search this Thread | Display Modes |
20th July 2012, 20:47 | #1161 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ |
|
20th July 2012, 21:49 | #1162 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
MediaInfo reports audio delays on mp4 files (muxed with L-Smash):
https://rapidshare.com/files/2377518...lay_sample.mp4 "Delay relative to video : -3s 337ms" Where does that come from? There shouldn't be any delay in that file. |
22nd July 2012, 09:29 | #1163 | Link | |
Registered User
Join Date: Aug 2002
Location: France, Paris
Posts: 672
|
Quote:
Code:
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 Code:
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
__________________
Want to know all about your media files? http://mediaarea.net/MediaInfo |
|
22nd July 2012, 09:54 | #1164 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
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. Last edited by sneaker_ger; 22nd July 2012 at 10:35. |
23rd July 2012, 04:32 | #1165 | Link | |
Spinner of yarns
Join Date: May 2009
Posts: 164
|
Quote:
http://mediainfo.svn.sourceforge.net...1=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.)
__________________
僕と契約して、L-SMASH developerになってよ! L-SMASH | L-SMASH Works | Opus-in-ISOBMFF specification and reference software Last edited by VFR maniac; 23rd July 2012 at 04:34. |
|
23rd July 2012, 10:08 | #1166 | Link | ||
Registered User
Join Date: Aug 2002
Location: France, Paris
Posts: 672
|
Quote:
2002 is 83 milliseconds if I well understood now. Quote:
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.
__________________
Want to know all about your media files? http://mediaarea.net/MediaInfo |
||
23rd July 2012, 12:52 | #1167 | Link | |
Spinner of yarns
Join Date: May 2009
Posts: 164
|
Quote:
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.
__________________
僕と契約して、L-SMASH developerになってよ! L-SMASH | L-SMASH Works | Opus-in-ISOBMFF specification and reference software Last edited by VFR maniac; 23rd July 2012 at 12:58. |
|
23rd July 2012, 13:47 | #1169 | Link | |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
Quote:
|
|
23rd July 2012, 14:24 | #1170 | Link |
Spinner of yarns
Join Date: May 2009
Posts: 164
|
Yes, zero if the demuxer can handle edit list correctly.
__________________
僕と契約して、L-SMASH developerになってよ! L-SMASH | L-SMASH Works | Opus-in-ISOBMFF specification and reference software |
6th August 2012, 21:28 | #1171 | Link |
Life's clearer in 4K UHD
Join Date: Jun 2003
Location: Notts, UK
Posts: 12,219
|
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
__________________
| I've been testing hardware media playback devices and software A/V encoders and decoders since 2001 | My Network Layout & A/V Gear |
Last edited by SeeMoreDigital; 6th August 2012 at 21:30. |
8th August 2012, 17:19 | #1172 | Link |
Life's clearer in 4K UHD
Join Date: Jun 2003
Location: Notts, UK
Posts: 12,219
|
Cool...
Support for reading Opus audio files has been added to MediaInfo 0.7.59 Thanks Zen
__________________
| I've been testing hardware media playback devices and software A/V encoders and decoders since 2001 | My Network Layout & A/V Gear |
|
8th August 2012, 17:22 | #1173 | Link | |
Registered User
Join Date: Aug 2002
Location: France, Paris
Posts: 672
|
Quote:
__________________
Want to know all about your media files? http://mediaarea.net/MediaInfo |
|
8th August 2012, 18:03 | #1174 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
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 |
8th August 2012, 19:18 | #1175 | Link | |
Registered User
Join Date: Aug 2002
Location: France, Paris
Posts: 672
|
Quote:
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.
__________________
Want to know all about your media files? http://mediaarea.net/MediaInfo |
|
8th August 2012, 21:45 | #1176 | Link |
Registered User
Join Date: Aug 2006
Posts: 2,229
|
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.
|
8th August 2012, 22:03 | #1177 | Link |
Registered User
Join Date: Aug 2002
Location: France, Paris
Posts: 672
|
Which format? Any? I need a sample file.
__________________
Want to know all about your media files? http://mediaarea.net/MediaInfo |
8th August 2012, 22:50 | #1178 | Link |
Registered User
Join Date: Aug 2006
Posts: 2,229
|
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. Last edited by burfadel; 8th August 2012 at 23:00. |
9th August 2012, 09:04 | #1179 | Link |
Registered User
Join Date: Aug 2002
Location: France, Paris
Posts: 672
|
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) 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.
__________________
Want to know all about your media files? http://mediaarea.net/MediaInfo |
Thread Tools | Search this Thread |
Display Modes | |
|
|