GNOME Bugzilla – Bug 753907
asfdemux: skip a frame with an abnormal time stamp.
Last modified: 2018-11-03 15:35:00 UTC
Created attachment 309786 [details] [review] patch to resolve the issue Although a demuxer succeeded to parse a frame, the frame can be defective. So I added some codes for the asf demuxer to skip frames with an normal timestamp. I regarded the timestamp is abnormal in case the timestamp is out of the segment duration. Issue can be observed with the attached test stream and can be resolved with the attached patch. Kindly share your views/concerns on this.
Review of attachment 309786 [details] [review]: Please provide a "git format-patch" style patch :) ::: gst/asfdemux/gstasfdemux.c @@ +1742,3 @@ + GST_TIME_ARGS (GST_BUFFER_PTS (payload->buf)), + GST_TIME_ARGS (demux->segment.duration)); + gst_buffer_unref (payload->buf); It might be a good idea to explicitly set ret = GST_FLOW_OK here. Also there might be cases where the duration is reported wrong, and there are actually valid buffers after the reported duration. This might break such streams. @@ +1744,3 @@ + gst_buffer_unref (payload->buf); + } else + ret = gst_pad_push (stream->pad, payload->buf); Add some {} around here
Dear Sebastian, Thanks for your review comments. I think under no scenario, we should push a payload having PTS more than the segment duration. For normal playback, segment duration is the play time of media file, which we parse from the stream property object. I have a test stream, to test this scenario, and i found that, video freezes, if we are not skipping/dropping the abnormal payload. Kindly share your views/concerns on this
The problem is that the duration information inside the stream might be wrong. It might say 5s duration, while the stream actually has a few minutes duration.
Dear Sebastian, In ASFdemux, we are sending a segment event, specifying the start, stop, rate, duration and flags. if we see the code in function, gst_asf_demux_process_file(): play_time = gst_asf_demux_get_uint64 (&data, &size); and if we are getting a valid play_time and we are updating the duration. (if we get 5sec, we treat it as valid duration) if (demux->play_time > 0) { demux->segment.duration = demux->play_time; } As per my understanding, gstreamer will render the payloads only within this segment duration value. Kindly share your views/concerns on this. Regards: Rajesh Singh
What is the reason for this defect?
video freezes, while audio continues to play.
I meant, why is the timestamp not correct, is it because whatever generated the file messed up, or because it got corrupted during transport (how/where/why?)?
The generated file is messed up, but skipping/dropping the payload with abnormal TS, will resolve this video freezing issue.
Created attachment 310775 [details] [review] This is diff-patch after modification Once we sent the segment event downstream, pushing any payload out of that segment is not justified. If we send, video freeze is observed, although audio is playing.
It is sometimes necessary for compressed data outside the segment to be pushed downstream to be able to decode the data that is inside the segment. Also here, segment.duration is only informational. It is not uncommon to have streams that continue after their duration (if the duration is only an estimate for example, or headers are broken), and streams should just continue until they're done. segment.start and segment.stop are the parts that are not just informational but actually enforced.
i feel, it may not be applicable in case of asfdemux, as we have following lines of statement in asfdemux code. if (demux->play_time > 0) { demux->segment.duration = demux->play_time; }
Why do you think this makes a difference?
To skip a frame or for making decision, whether frame is abnormal, I am taking the reference of "demux->segment.duration" if(demux->segment.duration > 0 && GST_BUFFER_PTS (payload->buf) > demux->segment.duration)){ }
Yes but that's a circular argument :) The point is that segment.duration is mostly informational and not enforced, so if play_time / segment.duration have wrong values this doesn't matter for now. There could be files where those fields are wrong, unless that would make the file generally unplayable for other reasons.
Test Stream Location: http://wikisend.com/download/164788/Test_Stream.wmv Patch was uploaded to fix the playback issue. Play the full video, video freezes, after few seconds.
Any progress on this issue?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/issues/12.