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.

Sign up for GitHub

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

Jump to bottom

Rollover gets confused by multiple streams #132

Closed
slifty opened this issue Jul 2, 2021 · 0 comments · Fixed by #134
Closed

Rollover gets confused by multiple streams #132

slifty opened this issue Jul 2, 2021 · 0 comments · Fixed by #134
Labels
bug Something isn't working

Comments

@slifty
Copy link
Member

slifty commented Jul 2, 2021

Bug

Current Behavior

The demuxer actually spits out more than one stream's worth of packets (e.g. there might be both an audio and a video stream).

This means that rollovers are being triggered almost constantly because different stream timestamps are being compared.

(Interestingly, this might be a more existential challenge we have to face down the line when we start dealing with audio processing -- if the audio PTS is different from the video PTS do we want to track those separately?)

Expected Behavior

We should have the rollover only compare PTS from a single stream type.

Possible Solutions

Some options:

  1. Track the PTS values of each stream number, only compare those values. Actually this probably won't work since we only care about the rollover of an individual stream.
  2. Track the PTS value of a single stream. It could just be the first stream that emits a payload; or the first video stream.

Related Issues

Issue #130
@slifty slifty added the bug Something isn't working label Jul 2, 2021
slifty added a commit that referenced this issue Jul 2, 2021
@slifty
Only track video streams
69d390d 
The AbstractVideoIngestionAppliance keeps track of the position associated
with the stream; however, in MPEG-TS there is more than one stream (e.g.
audio and video) which means there is actually more than one stream
position.

This was causing issues where position was jumping around back and forth
because all positions were treated as being from a single stream.  We
now only care about the video stream.

It may be that an MPEG-TS stream can contain multiple video streams,
which will break this code; that said, TV Kitchen is fairly built around
an assumption that a given video stream has a single video in it.

In the long run we may want to also track audio stream position, but
honestly at that stage we would probably want the ingestor to output
multiple demuxed and remuxed streams instead of simply forwarding the
stream.

Issue #132
slifty added a commit that referenced this issue Jul 2, 2021
@slifty
Only track video streams
2d2fc33 
The AbstractVideoIngestionAppliance keeps track of the position associated
with the stream; however, in MPEG-TS there is more than one stream (e.g.
audio and video) which means there is actually more than one stream
position.

This was causing issues where position was jumping around back and forth
because all positions were treated as being from a single stream.  We
now only care about the video stream.

It may be that an MPEG-TS stream can contain multiple video streams,
which will break this code; that said, TV Kitchen is fairly built around
an assumption that a given video stream has a single video in it.

In the long run we may want to also track audio stream position, but
honestly at that stage we would probably want the ingestor to output
multiple demuxed and remuxed streams instead of simply forwarding the
stream.

Issue #132
@slifty slifty mentioned this issue Jul 2, 2021
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Only track video streams tvkitchen/appliances
1 participant
@slifty