Skip to content

Timecode meta #205

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 14 commits into from Sep 23, 2020
Merged

Timecode meta #205

merged 14 commits into from Sep 23, 2020

Conversation

ghost
Copy link

@ghost ghost commented Aug 19, 2020

I implemented the possibility to get additional metadata from each buffer. Currently, there is only metadata for time codes. In our company, we use these values for navigation in the video (for obtaining exactly the position of showed frame). But there really depends on how the video was created, container type, and codec type. Not all buffers/frames come with attached this kind of metadata.
This is the first time when I wrote some binding over C library, so I hope that I understood correctly how to do it and this extension will be useful also for someone else.

@neilcsmith-net
Copy link
Member

Thanks for this, and for adding tests!

I'll try and find some free time to review soon. At a glance seems to be in right direction, but can you add links to upstream docs (or code in the case of lowlevel) to the Javadocs as other classes have. This keeps our requirement to document a little lower, and makes for easier review.

Travis tests seem to be failing. Bear in mind that all tests should pass with GStreamer 1.8, currently our baseline. Or are we missing availability of GStreamer elements? Features from higher versions need to be guarded and tests not run. See eg. https://github.com/gstreamer-java/gst1-java-core/blob/master/src/org/freedesktop/gstreamer/Buffer.java#L249 and https://github.com/gstreamer-java/gst1-java-core/blob/master/test/org/freedesktop/gstreamer/PropertyTypeTest.java#L188

@@ -5,3 +5,4 @@ addons:
apt:
packages:
- gstreamer1.0-plugins-good
- gstreamer1.0-plugins-bad
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any feasible way to test this that doesn't require adding gstreamer1.0-plugins-bad? We've generally tried to keep that out of test requirements.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just need these plugins not for production but just for tests. There is timecodestamper which can be used for testing timecode metadata. But true is that timecodestamper is available since 1.10.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, just wondering if there's any way to do test differently without this element? If we can keep the test requirements to plugins-good, I'd be happier.

@@ -142,7 +141,7 @@ public long getDecodeTimestamp() {
* Set the decode timestamp of the Buffer
*
* @param val a long representing the timestamp or
* {@link ClockTime#NONE} when the timestamp is not known or relevant.
* {@link ClockTime#NONE} when the timestamp is not known or relevant.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please keep whitespace changes out of this where you can, thanks.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry about that, I forgot to uncheck the checkbox for formatting code before commit.

*
* @return return time code (SMPTE) for current buffer
*/
public GstVideoTimeCodeMeta getVideoTimeCodeMeta() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm unsure about the API here. Maybe we need a getMeta() method that takes a type, which should probably be specified by Java class. Will check upstream docs.

The type here should be VideoTimeCodeMeta - the Gst prefix should only be used in lowlevel package. Helps to make sure we're not exposing things we shouldn't be!

import org.freedesktop.gstreamer.timecode.GstVideoTimeCodeFlags;

/**
* @author Jokertwo
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove the author annotation. Add license headers and add your real name in copyright lines. Also feel free to add your name in a copyright line on modified files if you wish.

* Gst meta data GTypes
* @author Jokertwo
*/
public enum GstMetaData {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure enum seems right here - would expect probably Java types like messages, events and queries. Thoughts?

* @author Jokertwo
* @see <a href="https://gstreamer.freedesktop.org/documentation/gstreamer/gstmeta.html?gi-language=c#GstMetaInfo">GstMetaInfo</a>
*/
public class GstMetaInfo extends MiniObject {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be called MetaInfo.

/**
* @author Jokertwo
*/
public class GstMeta implements NativeObject.TypeProvider {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be called Meta. Should specific Meta extend from this? What is the Meta hierarchy? Java class hierarchy should generally match with GType hierarchy.

The Type.Provider implementation should probably be nested, like Message.Types

* @author Jokertwo
* @see <a href="https://docs.gstreamer.com/documentation/video/gstvideometa.html?gi-language=c#GstVideoTimeCodeMeta">GstVideoTimeCodeMeta</a>
*/
public class GstVideoTimeCodeMeta extends MiniObject {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

VideoTimeCodeMeta. Is this really a MiniObject?

Copy link
Author

@ghost ghost Aug 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not know, how to resolve if is it MiniObject or not?

* @author Jokertwo
* @see <a href="https://docs.gstreamer.com/documentation/video/gstvideotimecode.html?gi-language=c#GstVideoTimeCode">GstVideoTimeCode</a>
*/
public class GstVideoTimeCode extends MiniObject {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

VideoTimeCode. Really a MiniObject? Do we really need a separate package for this?

Copy link
Author

@ghost ghost Aug 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not know, how to resolve if is it MiniObject or not?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should see a GstMiniObject as first element of the struct - eg. https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/master/gst/gstbuffer.h#L265 Or you could try calling various bits of the MiniObject API on them, which will likely crash! 😄 Hence need to be careful here. Likely that you'll want to extend NativeObject directly if anything - check out other classes that directly extend that.

* @author Jokertwo
* @see <a href="https://docs.gstreamer.com/documentation/video/gstvideotimecode.html?gi-language=c#GstVideoTimeCodeConfig">GstVideoTimeCodeConfig</a>
*/
public class GstVideoTimeCodeConfig extends MiniObject {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

VideoTimeCodeConfig. Really a MiniObject?

@ghost
Copy link
Author

ghost commented Aug 26, 2020

I hope that I fixed all your comments

@neilcsmith-net
Copy link
Member

Thanks. I'll take a look as soon as I can - probably won't be able to for at least a week.

@neilcsmith-net neilcsmith-net added this to the 1.3 milestone Aug 26, 2020
@neilcsmith-net
Copy link
Member

Sorry this is taking so long - few other projects going through releases and hitting some teething problems. Have scheduled some time for next week to fully review. Thanks for your patience!

@neilcsmith-net
Copy link
Member

Thanks for looking at this. I still have some issues with it as is. I'm still not sure about the package structure, a few of the method names, the license headers are in the wrong place and mixed up with what should be Javadocs, and I'd still like to get tests working without plugins bad if at all possible.

I'm going to change the base branch for this and merge into a specific branch here to work on together before it hits master.

@neilcsmith-net neilcsmith-net changed the base branch from master to meta September 23, 2020 09:05
@neilcsmith-net neilcsmith-net merged commit fae0b5e into gstreamer-java:meta Sep 23, 2020
@neilcsmith-net
Copy link
Member

@aveco-devel I've started reviewing through, and working out a task list for merging this code. Unfortunately, I hadn't realised quite how much this was exposing lowlevel package types (eg. GType) and JNA types (eg. Pointer). Neither are allowed in our public API as a rule. Feel free to join in the discussion on the linked thread if you wish, and thanks for your work to date.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant