Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inaccurate StartTime(typ) and Duration(typ) for the demuxer #4

Open
tinne26 opened this issue Nov 9, 2022 · 0 comments
Open

Inaccurate StartTime(typ) and Duration(typ) for the demuxer #4

tinne26 opened this issue Nov 9, 2022 · 0 comments

Comments

@tinne26
Copy link
Contributor

tinne26 commented Nov 9, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant