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 785222 - mpegtsmux: generate proper timecode for JPEG 2000 stream using GstVideoTimeCode API
mpegtsmux: generate proper timecode for JPEG 2000 stream using GstVideoTimeCo...
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-07-21 10:42 UTC by Aaron Boxer
Modified: 2018-11-03 14:11 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Aaron Boxer 2017-07-21 10:42:08 UTC
Currently we rely on PTS, which is not ideal.

Use GstVideoTimeCode instead to generate a correct timecode if there is no meta with an actual timecode on the stream.

Also, need to forbid variable frame rate 0/1 in caps

See https://bugzilla.gnome.org/show_bug.cgi?id=753323 for (lots!) more details.

Also, should document a few of the j2k fields: Fic, Fio, etc.
Comment 1 Sebastian Dröge (slomo) 2017-07-21 10:45:22 UTC
Alternatively you could also warn only if there are no timecodes / fps==0/1, and just write zero-timecodes. While this is not according to the spec, it should work just fine in most software.
Comment 2 Aaron Boxer 2017-07-21 10:56:28 UTC
(In reply to Sebastian Dröge (slomo) from comment #1)
> Alternatively you could also warn only if there are no timecodes / fps==0/1,
> and just write zero-timecodes. While this is not according to the spec, it
> should work just fine in most software.

Good idea. But, if there are already timecodes present, might these not follow the spec ?  i.e. frame number between 1 and 60 ?
Comment 3 Sebastian Dröge (slomo) 2017-07-24 07:22:12 UTC
Timecodes for > 60 fps seem to be not very well-defined in general. What seems to happen most often is that they are just duplicated then (i.e. two consecutive frames have the same timecode).

The GstVideoTimeCode API is not enforcing anything here (yet), but you should just assume for now that the values in there are valid.
Comment 4 Aaron Boxer 2017-07-24 12:21:29 UTC
(In reply to Sebastian Dröge (slomo) from comment #3)
> Timecodes for > 60 fps seem to be not very well-defined in general. What
> seems to happen most often is that they are just duplicated then (i.e. two
> consecutive frames have the same timecode).
> 
> The GstVideoTimeCode API is not enforcing anything here (yet), but you
> should just assume for now that the values in there are valid.

Thanks. Hope to get to this some time this week.
Comment 5 GStreamer system administrator 2018-11-03 14:11:16 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/587.