Skip to content

Fix: PyAV does not support floating point numbers with decimals as FPS when writing and will throw in case this constraint is not satisfied. #2334

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 1 commit into from
Jun 22, 2020

Conversation

QuentinDuval
Copy link
Contributor

…S when writing and will throw in case this constraint is not satisfied.

…S when writing and will throw in case this constraint is not satisfied.
@QuentinDuval QuentinDuval changed the title Refactoring to use context manager, list comprehension when more idioma… Fix: PyAV does not support floating point numbers with decimals as FPS when writing and will throw in case this constraint is not satisfied. Jun 22, 2020
Copy link
Member

@fmassa fmassa left a comment

Choose a reason for hiding this comment

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

Thanks for the PR!

I have a meta-question: is this a bugfix? The behavior of the code now if the user passes a 25.5 is not going to be giving an fps of 25.5, but 26 instead, giving the false impression that we support non-integer fps (which isn't the case)

# PyAV does not support floating point numbers with decimal point
# and will throw OverflowException in case this is not the case
if isinstance(fps, float):
fps = np.round(fps)
Copy link
Member

Choose a reason for hiding this comment

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

nit: we would prefer to use native python functions over numpy functions (in this case round from python).
The reason being that numpy can't be torchscripted, while many python builtins can.
In here this doesn't make a difference because this function can't be torchscripted anyway (due to pyav), but this is something good to keep in mind.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi, thank you for the comment ! This makes totally sense: I can replace this with round.

Regarding the fix itself: the issue is more a problem of symmetry:

  • reading with read_video will return me a floating point number
  • writing with this floating point number will not work (and the error is not clear)

The net effect is that if one tries to read a video to write it afterwards (for instance, to resize it), the error will be very hard to understand. My proposal is not necessarily the best way to fix this though: we could at least add a warning. Or we could decide to try something more ambitious.

Copy link
Member

Choose a reason for hiding this comment

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

That's a valid point.

The original reason why I added write_video was purely for testing purposes (to validate that video reading was working), so I didn't really think much about it (maybe I should have made it private?). But looks like more people are relying on it / using it.

The decision between using ceil / floor / round is not yet very clear to me yet. round seems ok, so let's go for it. But given that videos can have a varying fps, the concept of a single fps is not really well-defined.

@fmassa fmassa merged commit 32f21da into master Jun 22, 2020
@fmassa fmassa deleted the write_video_fps branch June 22, 2020 14:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants