You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are quite a few reasons why I have doubts about the precision of both Demuxer.StartTime() and Demuxer.Duration():
StartTime() caches the startTime value and reuses it on subsequent calls regardless the packet type. But for example, test.mpg (from this repository) has different audio and video pts times on their first packets. Calling demux.StartTime(mpeg.PacketAudio1) and then demux.StartTime(mpeg.PacketVideo1) will return 0.81 for both, but doing it in the inverse order will return 0.87 for both.
The behavior from the previous point may actually be correct, but only if the whole pack was read instead of taking just the first packet.Pts value. I don't have the spec so I can't tell, but packets within a pack may be unordered. In fact, test.mpg has a video packet with pts = 0.81 too, the same starting point as the audio, but it's the second video packet, not the first, so it's missed.
Duration(), since it depends on StartTime(), is also incorrect. It also does the same caching, which again, unless start and end times of all streams have to match (and then I wouldn't understand why do we bother passing any packet type into the functions), does not seem correct for successive calls. It also takes the pts of last packet of the given type right away instead of actually checking if it's the biggest one found yet, which also seems incorrect to me, given unordered packets.
Besides the previous point, there's still another issue: as I understand, the delta between first and last pts's is not the same as the duration, as the length of the data should also be added to the final value. For example, for audio one should calculate the actual duration as lastPts - firstPts + 1152*(1/sampleRate).
Instead, when it comes to Video.Decode(), the code seems to take this into account (backward, current and forward frames being explicitly handled), so I had my doubts if I was missing something. I know these issues come from pl_mpeg, but I wanted to share them here in case you had more idea than me.
The text was updated successfully, but these errors were encountered:
There are quite a few reasons why I have doubts about the precision of both
Demuxer.StartTime()
andDemuxer.Duration()
:StartTime()
caches thestartTime
value and reuses it on subsequent calls regardless the packet type. But for example, test.mpg (from this repository) has different audio and video pts times on their first packets. Callingdemux.StartTime(mpeg.PacketAudio1)
and thendemux.StartTime(mpeg.PacketVideo1)
will return 0.81 for both, but doing it in the inverse order will return 0.87 for both.packet.Pts
value. I don't have the spec so I can't tell, but packets within a pack may be unordered. In fact, test.mpg has a video packet with pts = 0.81 too, the same starting point as the audio, but it's the second video packet, not the first, so it's missed.Duration()
, since it depends onStartTime()
, is also incorrect. It also does the same caching, which again, unless start and end times of all streams have to match (and then I wouldn't understand why do we bother passing any packet type into the functions), does not seem correct for successive calls. It also takes the pts of last packet of the given type right away instead of actually checking if it's the biggest one found yet, which also seems incorrect to me, given unordered packets.lastPts - firstPts + 1152*(1/sampleRate)
.Instead, when it comes to
Video.Decode()
, the code seems to take this into account (backward, current and forward frames being explicitly handled), so I had my doubts if I was missing something. I know these issues come from pl_mpeg, but I wanted to share them here in case you had more idea than me.The text was updated successfully, but these errors were encountered: