GNOME Bugzilla – Bug 757631
progressreport format=bytes will not send msg
Last modified: 2016-11-15 13:16:20 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.
Created attachment 314912 [details] dot file for the pipeline on which I encounter this problem.
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?
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.
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