-
Notifications
You must be signed in to change notification settings - Fork 767
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
Simply metadata propagation API. #1407
base: master
Are you sure you want to change the base?
Changes from all commits
3e54f66
556a7cb
dd4d749
1246b72
a696d7c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -46,6 +46,8 @@ typedef struct { | |
|
||
typedef struct VmafPredictModel { | ||
VmafModel *model; | ||
unsigned last_highest_seen_index; | ||
unsigned last_lowest_seen_index; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you explain why these index tracking fields are needed? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Of course, as you know if application is multithreaded model scores might be calculated in out of order. Those indexes basically helping them to make in order. I am using those indexes for the current calculated index is in order. For example; Let's say we have frame order like this: 3, 0, 1, 2 Frame 3 arrives -> Calculate but not propagate, Update Frame 0 arrives -> Calculate and propagate since frame index (0) == last_lowest_seen_index. Increase Frame 1 arrives -> Calculate and propagate since frame index (1) == last_lowest_seen_index. Increase Frame 2 arrives -> Calculate and propagate since frame index (2) == last_lowest_seen_index. Increase There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is it a problem if the callbacks come out of order? Using your method, callbacks could be withheld for an unlimited number of frames (1 - N) until frame 0 is ready? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I don't think it's a problem for us. But for the sake of usability of API I think we need something like this. Otherwise users might need to reorder the frames. For example I am thinking FFmpeg, in that implementation we need to send frames in order to filtergraph (If we want to write features to original frame's metadata otherwise we don't need).
Unfortunately, yes. Is there a possibility that frame 0 somehow not calculated? I thought this situation while implementing this and I concluded if somehow one of the frames doesn't calculate then we can't calculate any other future frames due to metrics like |
||
struct VmafPredictModel *next; | ||
} VmafPredictModel; | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do these callbacks only work for model predicted metrics now? What about something like
psnr
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes they are working only for predicted metrics currently. We can make it work for all metrics with such a change like below. However for make it work with those metrics also needs a registered vmaf model. So user can't only get
psnr
. Is this a thing that we need to rethink about?https://github.com/yigithanyigit/vmaf/blob/a696d7cb22a54568c97c9f0562b6c34142a89acf/libvmaf/src/feature/feature_collector.c#L395-L406
to