@@ -14,13 +14,25 @@ namespace py = pybind11;
14
14
15
15
namespace facebook ::torchcodec {
16
16
17
- // In principle, this should be able to return a tensor. But when we try that,
18
- // we run into the bug reported here:
17
+ // Note: It's not immediately obvous why we need both custom_ops.cpp and
18
+ // pybind_ops.cpp. We do all other Python to C++ bridging in
19
+ // custom_ops.cpp, and that even depends on pybind11, so why have an
20
+ // explicit pybind-only file?
19
21
//
20
- // https://github.com/pytorch/pytorch/issues/136664
22
+ // The reason is that we want to accept OWNERSHIP of a file-like object
23
+ // from the Python side. In order to do that, we need a proper
24
+ // py::object. For raw bytes, we can launder that through a tensor on the
25
+ // custom_ops.cpp side, but we can't launder a proper Python object
26
+ // through a tensor. Custom ops can't accept a proper Python object
27
+ // through py::object, so we have to do direct pybind11 here.
21
28
//
22
- // So we instead launder the pointer through an int, and then use a conversion
23
- // function on the custom ops side to launder that int into a tensor.
29
+ // TODO: Investigate if we can do something better here. See:
30
+ // https://github.com/pytorch/torchcodec/issues/896
31
+ // Short version is that we're laundering a pointer through an int, the
32
+ // Python side forwards that to decoder creation functions in
33
+ // custom_ops.cpp and we do another cast on that side to get a pointer
34
+ // again. We want to investigate if we can do something cleaner by
35
+ // defining proper pybind objects.
24
36
int64_t create_file_like_context (py::object file_like, bool is_for_writing) {
25
37
AVIOFileLikeContext* context =
26
38
new AVIOFileLikeContext (file_like, is_for_writing);
0 commit comments