GNOME Bugzilla – Bug 723646
mpeg4videoparse: push caps before segment when first data is a GAP
Last modified: 2018-11-03 13:20:37 UTC
While the attached patch fixes it, I'd rather fix this in the baseclass if possible because it would not require fixing it in all parsers. Unfortunately I found no sane way of doing it with the current baseclass methods. And if we have to add a new method, better just use the event handler just like this patch? Any ideas other than doing a check for a src pad caps before pushing a segment? Another option is to store the GAP as a pending event while caps aren't decided, but then a GAP can be very long and disrupt playback/preroll if not pushed. So not a good one.
Created attachment 268117 [details] [review] mpeg4videoparse: push caps before segment when first data is a GAP mpeg4videoparse waits for the first buffer to be parsed before pushing the caps downstream, but if the first data is a GAP it will cause a flush on the pending events to push before the GAP and it will likely push a segment before pushing the caps leading to an assertion. This patch fixes it by forcefully pushing a caps when a GAP is received and a caps is needed.
Review of attachment 268117 [details] [review]: I'm not sure if this is a good idea... we might only know the real caps after parsing the first buffer and if the first thing is a GAP event we might have different caps first. And that can easily confuse decoders unfortunately :(
(In reply to comment #2) > Review of attachment 268117 [details] [review]: > > I'm not sure if this is a good idea... we might only know the real caps after > parsing the first buffer and if the first thing is a GAP event we might have > different caps first. And that can easily confuse decoders unfortunately :( Do we have any other option? We need caps before segment and before data, and a GAP is data (of some sort). Elements could accept a 'partial' caps and only error out if they actually receive a buffer before a 'complete' caps is received, but then this makes everything even more complex.
-- 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-bad/issues/130.