Event queue fix #97
Open
Event queue fix #97
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mmontero
reviewed
Sep 29, 2021
gst/interpipe/gstinterpipesrc.c
Outdated
| @@ -671,6 +673,7 @@ gst_inter_pipe_src_push_buffer (GstInterPipeIListener * iface, | |||
| GST_TIME_ARGS (GST_BUFFER_PTS (buffer))); | |||
| } else if (GST_INTER_PIPE_SRC_RESTART_TIMESTAMP == src->stream_sync) { | |||
| /* Remove the incoming timestamp to be generated according this basetime */ | |||
| buffer = gst_buffer_make_writable (buffer); | |||
There was a problem hiding this comment.
please remove this change from this pull request, this correspond to a different fix
There was a problem hiding this comment.
Done
And have also rebased to develop
Send all queued events with "timestamp < buffer timestamp" instead of just the 1st one before sending the buffer. Only the 1st event of the event queue with "timestamp < buffer timestamp" was being send before the buffer. But there could be several events in the queue that should sent before the buffer. Fixes RidgeRun#96 The segment event was not being handled properly when using x264enc + mpegtsmux together with interpipesrc/sink. Which was causing 2 segment to be delivered to the mpegtsmux: 1st one generated by the interpipesrc (starting from zero) because no segment existed. 2nd coming from the x264 encoder (correcting the 1000 hours offset added by the encoder). The 1st segment resulted in all subsequent DTS being seen as invalid (backwards) by the muxer. This happened because the event queue contained the following: stream-start, segment, tag, tag, tag. All with timestamp 0. But only the stream-start was sent, then the 1st buffer, then the segment. Which caused the DTS issues.
mariannasb
force-pushed
the
event-queue-fix
branch
from
4d78cba
to
ac06ae2
Compare
|
Any updates on the progress? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Send all queued events with "timestamp < buffer timestamp" instead of just the 1st one before sending the buffer.
Only the 1st event of the event queue with "timestamp < buffer timestamp" was being send before the buffer.
But there could be several events in the queue that should sent before the buffer.
Related to #96
The segment event was not being handled properly when using x264enc + mpegtsmux together with interpipesrc/sink.
Which was causing 2 segment to be delivered to the mpegtsmux:
1st one generated by the interpipesrc (starting from zero) because no segment existed.
2nd coming from the x264 encoder (correcting the 1000 hours offset added by the encoder).
The 1st segment resulted in all subsequent DTS being seen as invalid (backwards) by the muxer.
This happened because the event queue contained the following: stream-start, segment, tag, tag, tag.
All with timestamp 0.
But only the stream-start was sent, then the 1st buffer, then the segment.
Which caused the DTS issues.
This fix makes sure that mpegtsmux will receive the proper segment event from x264enc before receiving the 1st buffer which fixes backwards DTS warnings.
However an extra (wrong) segment is still being generated (by interpipesrc?).
And that is still missing a fix.