<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
hverkuil: <u>mripard</u>: paulk-leonov: posted v2 of the 'cookie' series (now renamed to 'tag', which is a much better name)
<br> is it possible to get this tested with the cedrus driver this or next week?
<br> It should go to 4.20, and once I have test results I can write the documentation and post the final version of this.
mripard: <u>hverkuil</u>: paulk-leonov has some time allocated this week, with this on top of his todo list :)
hverkuil: <u>mripard</u>: excellent! Assuming that nothing unexpected happens then I can finish it next week, adding the missing documentation.
<br> <u>gnurou</u>: I love the new name 'tag'. Great suggestion!
gnurou: <u>hverkuil</u>: I suggested it at random (like most things I do), so glad you like it :)
<br> <u>hverkuil</u>: and I also like your RFC, simple and should cover all our needs
sailus: <u>hverkuil</u>: Did you or do you happen to know if someone else take notes on the stateless codec discussion on Tuesday during ELc-E?
<br> I remember the rough outcome, so I could write a few words on that topic if no-one else has plans to do that.
hverkuil: <u>sailus</u>: I don't think we made any notes. pinchartl: can you remember if someone started an etherpad?
<br> It boiled down to: leave bitstream parsing to the applications and add libva support for each stateless codec since all apps support libva.
sailus: I suppose libVA support would be a single library on top of V4L2, is that right, or do you think there would be per-driver things to handle?
<br> (To the extent that a single implementation would be troublesome.)
hverkuil: Yes, that's the expectation. But to be honest, we're not 100% certain. We only have one datapoint (cedrus) at the moment, so it is a bit hard to predict whether it can stay completely driver independent.
<br> If there are driver-specifics, then hopefully that can be hidden inside the library.
sailus: The notes mention a libVA backend for the stateless cedrus decoder. This makes it sound like a frontend instead. Am I right?
hverkuil: to be honest, I am not sure of the terminology. 'backend' is probably right.
sailus: Well, this is a wrapper so I guess it depends on whether you're looking it from above or below. :-)
<br> I'd perhaps call it "libVA frontend for V4L2 stateless codec drivers".
<br> I mainly wanted to make sure we're talking about the same thing.
<br> What do you think?
hverkuil: <u>sailus</u>: looks OK to me
sailus: <u>hverkuil</u>: You proposed __u64 timestamps for v4l2_buffers.
<br> Are there other kernel APIs using __u64 timestamps, and would you use the same clock as now? Or would everyone be moved to clock_monotonic as a result?
hverkuil: u64 timestamps (ns since 1/1/1970) are y2038 safe and it should be used for new APIs to avoid y2038 problems.
sailus: Should I read the clock will be the same?
hverkuil: Yes, clock remains the same. No need to change that.
sailus: For CLOCK_MONOTONIC starts counting from system boot time.
hverkuil: Sorry, I think I got confused here.
sailus: I guess a few drivers still support the realtime clock optionally.
<br> At least UVC does, for others it could be a bug.
hverkuil: You are right, we will keep using CLOCK_MONOTONIC.
sailus: Good.
hverkuil: So it's ns since boot time.
sailus: I think we'd actually only run into problems with systems that would stay up for more than 78 years currently. Unless someone opts to use the realtime clock with UVC.
<br> So the problem is lesser than originally thought.
<br> Albeit I don't think that still changes the conclusions.
hverkuil: Older drivers can still use realtime clocks, so they will definitely need u64.
sailus: There are 64 users of V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC whilst the number of users of V4L2_BUF_FLAG_TIMESTAMP_REALTIME stands at zero.
<br> In principle a driver could miss setting the type, but there are also no calls to do_gettimeofday().
hverkuil: older drivers do not fill this in at all, so it is using TIMESTAMP_UNKNOWN (i.e. can be either realtime or monotonic).
sailus: I still need to figure out what the UVC driver does, is the realtime timestamp support gone with bits left here and there.
hverkuil: It's hard to grep for that, actually.
sailus: I know.
<br> But how do they get the actual timestamp?
<br> The common function does not support the realtime timestamp.
<br> I'd expect them to call do_gettimeofday().
hverkuil: perhaps everything is converted to monotonic by now?
<br> To be honest, I can't remember.
sailus: There are actually a few callers of ktime_get_real() and friends.
<br> I guess that's what is being used currently.
<br> But there are only a handful of drivers doing that.
<br> Including UVC.
<br> So there are drivers using CLOCK_REALTIME. I guess it'd be good to convert them going forward.
hverkuil: It would be good to do that, but (just for the record) I have no plans to work on it :-)
<br> REALTIME make no sense and should be killed.
sailus: :-)
<br> I can submit patches *if* I remember and have time.
<br> :-}
<br> I wonder how probable that actually is...
***: benjiG has left
hverkuil: <u>tfiga</u>: gnurou: I did a full review of the stateful/stateless codec specs and replied to the "[RFP] Which V4L2 ioctls could be replaced by better versions?" thread.
<br> I think I'm now completely up to date.
<br> Most of my comments are minor (typos, clarifications), but I did have a few questions about corner cases. Nothing big AFAICS.
<br> So hopefully the next version of the stateful codec and probably the stateless codec as well is ready to be merged.
ezequielg: <u>sailus</u>: I have some notes for the meeting. let me see if I can send them today.
<br> <u>sailus</u>: also, it's a "libva backend", in this sense: user -> libva -> plugins/backends -> libva v4l2 -> kernel
<br> <u>sailus</u>: i've reviewed my notes, but they don't add much to what is here http://muistio.tieke.fi/p/osseu18-codecs
<br> fwiw, http://muistio.tieke.fi/p/osseu18-codecs-eze
***: menace has left
sailus: I'd think a backend is the bit that actually does the work, which certainly is not the case here.
<br> I'd wish to get some support from a dictionary, but mine tells "backend" is German and all it means is "baking".
<br> Would you say a "wrapper" would be the right term to describe this?