GNOME Bugzilla – Bug 769392
flacparse: add maximum bitrate tag
Last modified: 2016-08-18 11:04:06 UTC
The maximum possible bitrate with a FLAC file is the bitrate of the uncompressed audio stream. Add this as the maximum bitrate tag to inform downstream what the worst case is. This is useful for network buffer size computations.
Created attachment 332489 [details] [review] Additional PCM-like maximum bitrate tag
Review of attachment 332489 [details] [review]: ::: gst/audioparsers/gstflacparse.c @@ +1711,3 @@ + gst_tag_list_add (flacparse->tags, GST_TAG_MERGE_KEEP, + GST_TAG_MAXIMUM_BITRATE, flacparse->samplerate * flacparse->bps * + flacparse->channels, NULL); Is that so? The worst case should be even higher than that. But I guess this is a valid guesstimate
commit c703ab69f526092bb26cce41ca691a896c8383d8 Author: Carlos Rafael Giani <dv@pseudoterminal.org> Date: Mon Aug 1 18:52:26 2016 +0200 flacparse: Add maximum bitrate tag https://bugzilla.gnome.org/show_bug.cgi?id=769392
I think this is a bit bogus tbh, are we going to add max bitrate tags for everything like that? video streams then width*height*4*framerate etc?
In our software here we actually had a special case for lossless audio like FLAC that uses a PCM-like bitrate for buffer size estimations. It is the safest bet with lossless audio, since average bitrates have a variance that is far too large. Extreme cases can happen, like a FLAC that has silence in the beginning, leading to a network buffer that is way too small.
I'm sure it's useful to you, but I am not sure it's really in line with the semantics of the bitrate tags to make up things like this, even just limited to lossless audio.
It is useful for proper buffering without interruptions during playback. But, I am inclined to agree that perhaps we should revert this, for one simple reason: If we apply this rule (= add PCM-like maximum bitrate tag to any lossless audio format because of the high avg bitrate variance over time), then we'd have to do the same for any lossy format that can operate in a VBR manner. Which are most popular formats (MP3, AAC, Vorbis ..). And there's the equivalent in video. So, as an alternative, it would make more sense to make the bitrate-based size estimation in uridecodebin (and urisourcebin) more robust I guess.
So let's revert this one?
Ping? :)
Done: commit 0f41d0e75dab024d6d79864361e37b5d9199c4c0 Author: Tim-Philipp Müller <tim@centricular.com> Date: Thu Aug 18 12:02:01 2016 +0100 Revert "flacparse: Add maximum bitrate tag" This reverts commit c703ab69f526092bb26cce41ca691a896c8383d8. https://bugzilla.gnome.org/show_bug.cgi?id=769392 Let's try to fix whatever the problem is here in some other way then :)