After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 599301 - [matroskademux] Doesn't populate video bitrate field
[matroskademux] Doesn't populate video bitrate field
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 563297
 
 
Reported: 2009-10-22 13:22 UTC by Bastien Nocera
Modified: 2009-11-06 15:12 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Bastien Nocera 2009-10-22 13:22:40 UTC
The nominal video bitrate field of the stream should be populated so that front-ends
can show it.
Comment 1 Sebastian Dröge (slomo) 2009-10-24 14:08:02 UTC
This can't be supported in matroskademux, Matroska doesn't contain any information about the bitrate of streams.
Comment 2 Nicolò Chieffo 2009-10-24 14:09:42 UTC
Can't matroskademux ask the videobitrate to its video tracks?
Comment 3 Jan Schmidt 2009-10-25 20:07:29 UTC
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.
Comment 4 Jan Schmidt 2009-10-25 20:44:13 UTC
To play the devil's advocate, it might also be a good task for the video decoder base class.
Comment 5 Sebastian Dröge (slomo) 2009-11-06 13:46:30 UTC
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?
Comment 6 Jan Schmidt 2009-11-06 13:51:56 UTC
Sounds like a reasonable idea. It should probably also take a duration parameter, as the duration on encoded buffers is not always valid.
Comment 7 Sebastian Dröge (slomo) 2009-11-06 14:00:18 UTC
(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 ;)
Comment 8 Jan Schmidt 2009-11-06 14:05:13 UTC
Only if you want to call gst_buffer_make_metadata_writeable on all the input buffers....
Comment 9 Sebastian Dröge (slomo) 2009-11-06 14:24:26 UTC
(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.
Comment 10 Jan Schmidt 2009-11-06 14:36:36 UTC
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
Comment 11 Sebastian Dröge (slomo) 2009-11-06 14:43:09 UTC
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?
Comment 12 Nicolò Chieffo 2009-11-06 14:44:10 UTC
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
Comment 13 Sebastian Dröge (slomo) 2009-11-06 14:59:39 UTC
(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.
Comment 14 Nicolò Chieffo 2009-11-06 15:12:26 UTC
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"