-
Notifications
You must be signed in to change notification settings - Fork 71
Proper resize tests; remove swscale resize #1013
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
Changes from 6 commits
dd24dfa
3a2df84
1541ab8
25f3002
b4efafb
a7c6d69
5717cb4
f0a6174
f853e3a
0e61aba
2a391b6
7668eea
08fa176
928ae4c
a95dd4c
4245bdd
225b6fb
02f884c
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 |
|---|---|---|
|
|
@@ -42,7 +42,7 @@ int toSwsInterpolation(ResizeTransform::InterpolationMode mode) { | |
| std::string ResizeTransform::getFilterGraphCpu() const { | ||
| return "scale=" + std::to_string(outputDims_.width) + ":" + | ||
| std::to_string(outputDims_.height) + | ||
| ":sws_flags=" + toFilterGraphInterpolation(interpolationMode_); | ||
| ":flags=" + toFilterGraphInterpolation(interpolationMode_); | ||
|
Contributor
Author
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. From the FFmpeg docs:
Whereas |
||
| } | ||
|
|
||
| std::optional<FrameDims> ResizeTransform::getOutputFrameDims() const { | ||
|
|
||
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.
@NicolasHug, do you think I should pull this explanation out into a named section, and then refer to it in a few different places?
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.
I think it's fine here. I'd just suggest to remove (or re-write?) the last paragraph because it seems redundant with the second.
Is there any difference between
"copy"and"format=rgb24"when passingAV_PIX_FMT_RGB24? I think we have made this slight change now.I might suggest to leave the default to
"copy"?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.
I used
"copy"before because the empty string is not a valid filtergraph (I tried). So we needed to provide something, and"copy"is the closest I could find to a no-op. That, however, was back when the transforms were okay to happen in the input colorspace; we were okay with the automatically inserted format conversions.Now that we want the transforms to happen in RGB24, we need to explicitly specify the format conversion. For the no-transformations case, there is no difference between explicitly specifying
"format=rgb24"and not. However, when there are transformations, the explicit"format=rgb24"makes sure that the transforms happen in RGB24 colorspace. Without it, filtergraph will automatically insert a format after our transforms to do the conversion we specified when we said the output node isAV_PIX_FMT_RGB24.With all that said, I don't love the current logic as it does require more knowledge. I'm going to try to make it more clear without introducing
"copy".