GNOME Bugzilla – Bug 606287
Add an 'is-vbr' boolean tag
Last modified: 2013-08-14 09:57:20 UTC
Created attachment 150959 [details] [review] taglist: Add an 'is-vbr' boolean tag It would be good to have decoders/demuxers add a boolean flag on streams which have a variable bitrate. Specifically, this would be useful for GstDiscoverer and its users. Attaching a patch to do this. I'll post some patches to actually post this tag for some of the codecs in a while.
Review of attachment 150959 [details] [review]: ::: gst/gsttaglist.h @@ +655,3 @@ + * GST_TAG_VARIABLE_BITRATE: + * + * whether the stream has a variable bitrate (boolean) A more extensive description/usage would be nice imho. If True, the stream is *guaranteed* to have a variable bitrate. If False, the stream is *guaranteed* to have a constant bitrate.
Created attachment 150968 [details] [review] Updated patch incorporating feedback from review
Comment on attachment 150968 [details] [review] Updated patch incorporating feedback from review Looks good. Please push.
Wouldn't IS_VBR be a better name for this? And what exactly does VBR or CBR mean in general? You always have to talk about a constant size for a specific time unit, e.g. all 384 sample frames have the same size for mp3. Also, to *guarantee* that an mp3 stream is CBR you have to look at every single frame and the same is probably true for most other formats.
(In reply to comment #4) > Wouldn't IS_VBR be a better name for this? I think a stream "has a variable bitrate". > > And what exactly does VBR or CBR mean in general? You always have to talk about > a constant size for a specific time unit, e.g. all 384 sample frames have the > same size for mp3. > > Also, to *guarantee* that an mp3 stream is CBR you have to look at every single > frame and the same is probably true for most other formats. I was wondering earlier if we would need a probability or a string like "cbr, maybe-cbr, unknown, maybe-vbr, vbr". But that's ugly :/
(In reply to comment #5) > (In reply to comment #4) > > Wouldn't IS_VBR be a better name for this? > > I think a stream "has a variable bitrate". Or "is a variable bitrate stream". Both are identical as far as I am concerned, though. :) [...] > I was wondering earlier if we would need a probability or a string like "cbr, > maybe-cbr, unknown, maybe-vbr, vbr". But that's ugly :/ Which is why this patch hasn't been pushed so far. We could retain the current tag name and replace the "guaranteed" to "most probably" with a big caveat in the documentation about the accuracy of this tag. I think this is an uncertainty that we will have to live with since the only definitive way to determine this (parse the whole stream) is not likely to be practical in most cases.
Comment on attachment 150968 [details] [review] Updated patch incorporating feedback from review Ok, so what's the plan now?
I still think that having is_vbr as a best-effort "this is probably a vbr stream" is good enough. Might as well design for the normal case and account for pathological cases rather than try to include all possibilities and clutter the design.
We could also have "is-vbr" and "is-cbr" for the cases we are (quite) sure and don't do anything where we are not. The docuementation would make clear that the absence of e.g. "is-vbr"=TRUE does not mean "is-cbr"=TRUE / "is-vbr"=FALSE, bur rather "sorry, we don't know".
We now have BITRATE and NOMINAL_BITRATE tags, shouldn't detecting vbr or cbr be using those ?
I'm still not sure if this would be useful at all, and if so, what it would be useful for. Who cares if something is VBR or CBR (for some definition of CBR), why does it matter? If you have special bitrate constraints you have to do more than looking at such a best-effort, undefined tag anyway. And users should not care at all, that's an implementation detail of the codec and users will only do weird conclusions based on misunderstanding the codec concepts if they see such a thing.
It would be for information reporting for discoverer users.
Yes, what would they do with this useless information? :)
I believe it was meant for DLNA stuff/profiles. One reason why it might be useful to have is that if you know a file is VBR and you want to figure out e.g. the duration or so, then one might want to try a little harder instead of just doing preroll + query (though I believe this should ultimately be solved differently).
How is CBR defined for DLNA? Sorry if I'm blocking this but to me it seems like just useless API bloat that is confusing people later. Also it's not really simple to detect e.g. if an MP3 is VBR, you would need to check all frames.
I'm aware of all that. I don't mind WONTFIXing this for the time being until someone finds a better solution, just stating what the original context was.
I'd originally opened this to deal with DLNA specifying different requirements for some VBR/CBR streams. We managed to pretty much get by without this flag, iirc, so will mark this WONTFIX until a better reason comes up.