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 757631 - progressreport format=bytes will not send msg
progressreport format=bytes will not send msg
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: 1.11.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-11-05 12:33 UTC by yash
Modified: 2016-11-15 13:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
dot file for the pipeline on which I encounter this problem. (34.01 KB, text/vnd.graphviz)
2015-11-05 12:54 UTC, yash
Details

Description yash 2015-11-05 12:33:05 UTC
It will print something like this to the console

progressreport0 (00:00:01): -10804955 / 5099673 bytes (-211.9 %)
progressreport0 (00:00:02): -10813031 / 3797435 bytes (-284.7 %)
progressreport0 (00:00:03): -10819279 / 3051024 bytes (-354.6 %)

but will not fire any messages except for "spate change".

When format=auto, messages are received as expected every update-freq interval.
Comment 1 yash 2015-11-05 12:54:12 UTC
Created attachment 314912 [details]
dot file for the pipeline on which I encounter this problem.
Comment 2 Thiago Sousa Santos 2015-11-05 14:52:01 UTC
What version are you using? It seems to be working here with latest master using auto, bytes or time.

I had to use fakesink instead of rtmpsink but otherwise the pipeline should be similar enough.

Can you get a GST_DEBUG=6 log to help tracking down the issue for you?
Comment 3 Tim-Philipp Müller 2016-05-22 21:01:53 UTC
I can reproduce this with e.g.

gst-launch-1.0 flvmux name=mux ! progressreport format=bytes ! fakesink  uridecodebin uri=file:///home/tpm/samples/foo.mov name=d    d. ! videoconvert ! queue ! x264enc tune=zerolatency ! mux.   d. ! audioconvert ! audioresample ! voaacenc ! mux.

h264parse seems to answer the bytes duration query, but not sure where negative position values come from yet.
Comment 4 Jan Schmidt 2016-11-15 13:16:20 UTC
I pushed a few commits that 'fix' things. Noone is / can sensibly answer bytes queries on demuxed elementary streams. The encoders *could* try and answer bytes position / duration by converting TIME to BYTES using the nominal/target bitrate, but it's not accurate. Better to just query in time and refuse other formats. Tim's pipeline now:

progressreport0 ( 0: 0: 5): Could not query position and/or duration

The commits (because actually a bunch of pieces were doing things wrong here):

commit d81c0aec8164f27019b8b768eeebdc62ee5e5c68
Author: Jan Schmidt <jan@centricular.com>
Date:   Tue Nov 15 23:51:06 2016 +1100

    baseparse: Restrict query/convert responses when demuxing
    
    If the parser is not parsing a raw elementary stream, restrict
    the position, duration and conversion query replies to
    things we can sensibly answer about - especially don't do
    random conversions to/from bytes.

commit a6ca8dfb42140e306de79506cf65ecf12e3912a5
Author: Jan Schmidt <jan@centricular.com>
Date:   Tue Nov 15 22:39:43 2016 +1100

    queues: Don't return negative position queries.
    
    When subtracting queued data sizes from upstream queries
    in queue, queue2, downloadbuffer and typefind, clamp the
    result to not go negative, in case upstream returned
    a nonsense value that's too small (as could happen if
    upstream is estimating, or just broken)

commit 2b06e54651956d779123020c51c466397f5161ac
Author: Jan Schmidt <jan@centricular.com>
Date:   Tue Nov 15 23:36:41 2016 +1100

    videodecoder: Don't answer BYTES queries
    
    Refuse to answer BYTES queries ourselves. The only
    time they make sense is on raw elementary streams,
    in which case upstream would already have answered.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=757631

commit 1840b0233a4b4686e7254e568c91c7f078a05f66
Author: Jan Schmidt <jan@centricular.com>
Date:   Tue Nov 15 23:27:17 2016 +1100

    audio: Don't answer BYTES queries
    
    Refuse to answer BYTES queries ourselves. The only
    time they make sense is on raw elementary streams,
    in which case upstream would already have answered.
    
    They especially don't make sense for encoders to answer
    based on upstream values - although perhaps later
    we could make it do TIME->BYTES conversion on the source
    pad based on bitrate.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=757631