GNOME Bugzilla – Bug 599301
[matroskademux] Doesn't populate video bitrate field
Last modified: 2009-11-06 15:12:26 UTC
The nominal video bitrate field of the stream should be populated so that front-ends can show it.
This can't be supported in matroskademux, Matroska doesn't contain any information about the bitrate of streams.
Can't matroskademux ask the videobitrate to its video tracks?
It can't be trivially supported in any muxer format afaik - they would all need to measure the bitrate by counting (delta-bytes)/(delta-timestamps) and posting the tag message. It seems to me that that is an operation better undertaken centrally - in the demuxers, rather than individually in every video/audio decoder.
To play the devil's advocate, it might also be a good task for the video decoder base class.
For that it might be a good idea to create some kind of bitrate counter: bitrate = gst_bitrate_counter (counter, buffer) this would only return bitrate!=-1 if it changed a lot (a lot being configurable at initialization) and take the buffer metadata to update its state. Right, I'm aware of the fact that this is a very simple thing but it would prevent to copy the same 10 lines of code into every demuxer ;) What do you think, Jan?
Sounds like a reasonable idea. It should probably also take a duration parameter, as the duration on encoded buffers is not always valid.
(In reply to comment #6) > Sounds like a reasonable idea. It should probably also take a duration > parameter, as the duration on encoded buffers is not always valid. Well, where should this duration come from then? If you can pass it to that bitrate counter, you could as well set it in the buffer metadata ;)
Only if you want to call gst_buffer_make_metadata_writeable on all the input buffers....
(In reply to comment #8) > Only if you want to call gst_buffer_make_metadata_writeable on all the input > buffers.... You mean on all output buffers, right? The bitrate tag should be the bitrate of output buffers... and on those you usually set the timestamp and other things already.
Ooooops. Sorry, I forgot we were talking about doing this in the demuxer. For the demuxers... we might need to aggregate using a segment structure, since demuxers (MPEG, I'm looking at you) don't always know the duration of the data they contain - but they can aggregate the passage of time and calculate delta-bytes/delta-time
MPEG doesn't even know the duration of packets it's pushing downstream? What a weird format ;) What kind of API do you have in mind?
I'm sorry to step into this advanced discussion, since I'm definitely not an expert. But maybe I can make a suggestion: mkvinfo prints all the desidered informations. You could analyze its code and port it to gstreamer
(In reply to comment #12) > I'm sorry to step into this advanced discussion, since I'm definitely not an > expert. > But maybe I can make a suggestion: mkvinfo prints all the desidered > informations. You could analyze its code and port it to gstreamer It doesn't output the bitrate for the files I tested... is there any special parameter necessary? Also all it can do is looking at the complete file and calculating the bitrates.
I'm very sorry, I was completely wrong. Anyway you could see how vlc handles this. I'm sure it prints audio and video bitrate if you choose "codec information"