GNOME Bugzilla – Bug 740804
BYTES format duration query fail on demux
Last modified: 2016-02-21 23:52:49 UTC
Created attachment 291629 [details] [review] qtdemux: ask to upstream for duration query I used BYTES format query when get the size of the contents on http streaming case. Demuxers usually respond TIME format duration query, but it does not handle BYTES format. I'm curious about why demux does not ask to upstream at least. At now, BYTES format duration query is failed at demux, then baseparse calculated bytes duration based on time duration, but it was inaccurate. So, I modify to get accurate duration from source element (e.g. souphttpsrc).
Comment on attachment 291629 [details] [review] qtdemux: ask to upstream for duration query Thanks for the patch but this is not correct. The query results should be for the specific stream of the srcpad, thus give the size in bytes of that specific stream and not of the complete container.
What is the use case here? Usually it's not useful to know the byte duration of some demuxed stream.
Thanks for your comments, I use bytes duration for buffering. At first we want to use current-level-time property on queue2 for buffering, but it is not work. we get the size of contents by using bytes duration query, then divide it by time duration for getting average bitrate. So, we can measure the current time in queue2 approximately. (Get remaining time at queue2 = currenty-level-bytes / average bitrate)
What exactly is it that you want to achieve by this?
I just want to get accurate bytes duration by sending query to pipeline, not send to source element directly. I was curious about why demux does not forward bytes duration query.
The question was really what do you want to achieve with all these values that you query? What's the big picture? Then we can either make alternative suggestions how to achieve that, or determine that perhaps we need to implement additional functionality somewhere. But without more information it's hard to figure out what you're trying to do exactly.
At first, I did not perfectly understand what sebastian mentioned about but now I understand it. Anyway, there was not a quite a big picture. What I really want to do is get the total contents bytes size at application by sending bytes duration query to pipeline. I agreed that this is not correct, from application side, is there any other way to get bytes size of contents without sending duration query to source element directly?
Currently nothing else than sending the duration query to the source. But why do you need the byte duration of the complete stream in the application? What can the application do with it? :)
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!