After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 733171 - baseparse: handling of EOS when no output produced
baseparse: handling of EOS when no output produced
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other All
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 746390
 
 
Reported: 2014-07-14 18:25 UTC by Thiago Sousa Santos
Modified: 2015-03-27 01:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
baseparse: only post 'no valid frames' error if buffers were received (3.57 KB, patch)
2015-03-25 14:39 UTC, Thiago Sousa Santos
committed Details | Review

Description Thiago Sousa Santos 2014-07-14 18:25:24 UTC
Currently baseparse considers an error any case where it has received EOS and still hasn't produced any output buffer.

This seems to try to care for the case where a whole stream is dropped because the input is completely random for a parser (linking of wrong parser for a given media format), but this seems to cause errors in the following valid scenarios:

1) fakesrc num-buffers=0 ! h264parse ! fakesink

A valid scenario is of a completely empty stream, this shouldn't lead to an error but just to EOS.

2) In h264parse, for example, it will only output buffers after it has received an SPS, so it might have received valid data before and successfully parse input buffers but drop them waiting for the SPS. This can happen with mpegts as the input can be completely unaligned and doesn't need to start from a SPS. If you have a very short attempt at playing an h264 out of mpegts it can make baseparse error out and cause your whole pipeline fail. This happens when quickly switching mpegts programs.

I'm willing to fix this, but I'd like to reach a sane decision on how to handle this.
Comment 1 Thiago Sousa Santos 2014-07-14 18:28:26 UTC
A few ideas I had:

1) Demote this error to a warning

2) Add an input_framecount to baseparse to handle the case of EOS without input data

3) Only error out on EOS if no buffers were produced in case the sinkpad has no caps set into it (trying to parse an unknown input type), otherwise just post a warning.

4) Instead of dropping the h264 data before the SPS store it in a pending buffer list an push it when an SPS is obtained. In case the SPS never arrives and it gets an EOS we can check if there are pending buffers and verify that valid data was parsed.

Those aren't exclusive, can be applied together if needed.
Comment 2 Thiago Sousa Santos 2015-03-25 14:39:31 UTC
Created attachment 300284 [details] [review]
baseparse: only post 'no valid frames' error if buffers were received

Otherwise baseparse will consider empty streams to be an error while
an empty stream is a valid scenario. With this patch, errors would
only be emitted if the parser received data but wasn't able to
produce any output from it.

This change is only for push-mode operation as in pull mode an
empty file can be considered an error for the one driving the
pipeline

Includes a unit test for it
Comment 3 Tim-Philipp Müller 2015-03-26 00:07:05 UTC
Comment on attachment 300284 [details] [review]
baseparse: only post 'no valid frames' error if buffers were received

Seems reasonable.
Comment 4 Thiago Sousa Santos 2015-03-27 01:35:54 UTC
Thanks for the review.

commit a041d8862d90a86b7745f99a0db547be7d9baa75
Author: Thiago Santos <thiagoss@osg.samsung.com>
Date:   Wed Mar 25 10:49:08 2015 -0300

    baseparse: only post 'no valid frames' error if buffers were received
    
    Otherwise baseparse will consider empty streams to be an error while
    an empty stream is a valid scenario. With this patch, errors would
    only be emitted if the parser received data but wasn't able to
    produce any output from it.
    
    This change is only for push-mode operation as in pull mode an
    empty file can be considered an error for the one driving the
    pipeline
    
    Includes a unit test for it
    
    https://bugzilla.gnome.org/show_bug.cgi?id=733171