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 747505 - vp8 decoding deadline should be specified in us instead of ms
vp8 decoding deadline should be specified in us instead of ms
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Mac OS
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-04-08 12:18 UTC by Cecill Etheredge (ijsf)
Modified: 2015-04-08 13:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Passes vp8 decode deadline in us instead of ms (812 bytes, patch)
2015-04-08 12:19 UTC, Cecill Etheredge (ijsf)
none Details | Review

Description Cecill Etheredge (ijsf) 2015-04-08 12:18:35 UTC
Just noticed something in gstvp8dec.c:

  deadline = gst_video_decoder_get_max_decode_time (decoder, frame);
  if (deadline < 0) {
    decoder_deadline = 1;
  } else if (deadline == G_MAXINT64) {
    decoder_deadline = 0;
  } else {
    decoder_deadline = MAX (1, deadline / GST_MSECOND);
  }
  status = vpx_codec_decode (&dec->decoder,
      minfo.data, minfo.size, NULL, decoder_deadline);

I am assuming the decoder_deadline is in milliseconds here, given the division. The libvpx docs mention the following:

deadline: Soft deadline the decoder should attempt to meet, in us. Set to zero for unlimited.

Also see http://www.webmproject.org/docs/vp8-sdk/group__decoder.html

This basically implies that the deadline is a factor of 1000 off. Could anyone verify this?
Comment 1 Cecill Etheredge (ijsf) 2015-04-08 12:19:49 UTC
Created attachment 301126 [details] [review]
Passes vp8 decode deadline in us instead of ms

Attaching a patch for good measure.
Comment 2 Robert Swain 2015-04-08 13:34:55 UTC
gst_video_decoder_get_max_decode_time returns a GstClockTimeDiff which is a gint64 of nanoseconds. If you want that in milliseconds you need to divide by 10^6 which is what GST_MSECOND is. Alternatively you can think of these GST time constants as the amount of nanoseconds for that unit, then it becomes nanoseconds / (nanoseconds / millisecond) = milliseconds. So I think the code is correct as it is.
Comment 3 Cecill Etheredge (ijsf) 2015-04-08 13:38:15 UTC
Alright. It isn't exactly clear from the documentation. Guess this one can be closed then.