Restructure rocPyDecode into independent video and JPEG binding projects

Objective

Restructure rocPyDecode into a lightweight umbrella repository containing two independently configurable, buildable, installable, and testable Python-binding projects:

• videoDecode: Python bindings for rocDecode.
• jpegDecode: Python bindings for rocJPEG.

Each component owns its source code, Python package, samples, tests, build configuration, and documentation. Neither component requires files from the other component, allowing either directory to move into a separate repository later.

Implemented in PR #281.

Repository Structure

rocPyDecode/
├── CMakeLists.txt
├── README.md
├── CHANGELOG.md
├── LICENSE.txt
├── docs/
├── videoDecode/
│   ├── CMakeLists.txt
│   ├── LICENSE.txt
│   ├── README.md
│   ├── cmake/
│   ├── docs/
│   ├── pyRocVideoDecode/
│   ├── samples/rocdecode/
│   ├── src/
│   │   ├── roc_pybuffer.cpp
│   │   ├── roc_pybuffer.h
│   │   ├── roc_pydlpack.cpp
│   │   ├── roc_pydlpack.h
│   │   └── rocdecode/
│   └── tests/
└── jpegDecode/
    ├── CMakeLists.txt
    ├── LICENSE.txt
    ├── README.md
    ├── cmake/
    ├── docs/
    ├── pyRocJpegDecode/
    ├── samples/rocjpeg/
    ├── src/
    │   ├── roc_pybuffer.cpp
    │   ├── roc_pybuffer.h
    │   ├── roc_pydlpack.cpp
    │   ├── roc_pydlpack.h
    │   └── rocjpeg/
    └── tests/

Component Ownership

Each component contains its own:

• Python package and native binding sources.
• Buffer and DLPack implementation.
• Dependency discovery modules and CMake configuration.
• Installation rules.
• Samples and component-specific tests.
• Documentation and license.

The former common implementation is duplicated directly under each component’s src/ directory. A src/common/ directory is unnecessary because each copy belongs to its respective component.

This duplication removes cross-component source dependencies. Changes affecting both implementations must be applied to both copies when appropriate.

Build and Installation

The root CMake project orchestrates the components through:

option(BUILD_VIDEO_DECODE "Build the rocDecode Python bindings" ON)
option(BUILD_JPEG_DECODE "Build the rocJPEG Python bindings" ON)

It supports combined builds and selecting either component individually. Each component also supports direct standalone configuration from its own directory.

Component-specific target names, output directories, and test names allow both projects to build and install together.

The installation delivers:

Component | Python package | Native extension -- | -- | -- Video | pyRocVideoDecode | rocpydecode JPEG | pyRocJpegDecode | rocpyjpegdecode

The original proposal for separate wheel-generation workflows was dropped. This restructuring uses CMake to build and install the native shared libraries and Python packages; it does not introduce component wheel packaging.

Bindings for overlapping types use module-local registration where needed so both native modules can coexist in one Python process.

Optional Video Features

FFmpeg-dependent demuxing and the rocDecode CPU backend remain optional.

The build enables these features when the corresponding libraries and utility sources are available. The default video tests avoid requiring FFmpeg, the host decoder library, PyTorch, or hip-python.

Optional samples and API tests remain available with their additional dependencies.

Tests

Video tests and JPEG test registration belong to their respective components.

The restructuring provides:

• Standalone component CTest execution.
• Combined CTest execution from the root.
• Component-specific Python import paths.
• SDK test-media discovery.
• Clear configuration messages when required test media is unavailable.
• Installation of component test scripts for subsequent testing.

Validation covers standalone and combined configuration, compilation, installation, Python imports, and CTest execution. Both native modules must also import successfully in the same Python process.

Repository Cleanup

Removed obsolete root content:

• data/
• conda-recipe/
• build_rocpydecode_wheel.py
• pyproject.toml
• setup.py
• Root __init__.py
• rocPyDecode-requirements.py
• rocPyDecode-docker-install.py
• Obsolete wheel documentation.
• Unused Azure DevOps pipeline and Codecov configuration.

The ResNet50 sample no longer depends on data/labels.txt. It accepts an optional --labels argument and can run without a labels file.

Documentation

Video- and JPEG-specific documentation is located under the owning component’s docs/ directory.

Each component has its own README and documentation entry point. Component documentation uses local paths and does not require the sibling component.

Root documentation provides unified navigation and explains how to select and build the components.

Completion Criteria

• Separate video and JPEG source ownership.
• Independent component CMake projects.
• Component-local buffer and DLPack implementations.
• Standalone and combined build/install support.
• Separate Python packages and native extensions.
• Coexistence of both native modules in one Python process.
• Component-owned samples and tests.
• Optional video dependency handling.
• Component-owned documentation.
• Removal of obsolete packaging scripts and root directories.
• Removal of the ResNet50 sample’s dependency on the former root labels file.

**Title:** Restructure rocPyDecode into independent video and JPEG binding projects

Objective

Restructure rocPyDecode into a lightweight umbrella repository containing two independently configurable, buildable, installable, and testable Python-binding projects:

• videoDecode: Python bindings for rocDecode.
• jpegDecode: Python bindings for rocJPEG.

Each component owns its source code, Python package, samples, tests, build configuration, and documentation. Neither component requires files from the other component, allowing either directory to move into a separate repository later.

Implemented in [PR #281](https://github.com/ROCm/rocPyDecode/pull/281).

Repository Structure

rocPyDecode/
├── CMakeLists.txt
├── README.md
├── CHANGELOG.md
├── LICENSE.txt
├── docs/
├── videoDecode/
│   ├── CMakeLists.txt
│   ├── LICENSE.txt
│   ├── README.md
│   ├── cmake/
│   ├── docs/
│   ├── pyRocVideoDecode/
│   ├── samples/rocdecode/
│   ├── src/
│   │   ├── roc_pybuffer.cpp
│   │   ├── roc_pybuffer.h
│   │   ├── roc_pydlpack.cpp
│   │   ├── roc_pydlpack.h
│   │   └── rocdecode/
│   └── tests/
└── jpegDecode/
    ├── CMakeLists.txt
    ├── LICENSE.txt
    ├── README.md
    ├── cmake/
    ├── docs/
    ├── pyRocJpegDecode/
    ├── samples/rocjpeg/
    ├── src/
    │   ├── roc_pybuffer.cpp
    │   ├── roc_pybuffer.h
    │   ├── roc_pydlpack.cpp
    │   ├── roc_pydlpack.h
    │   └── rocjpeg/
    └── tests/

Component Ownership

Each component contains its own:

• Python package and native binding sources.
• Buffer and DLPack implementation.
• Dependency discovery modules and CMake configuration.
• Installation rules.
• Samples and component-specific tests.
• Documentation and license.

The former common implementation is duplicated directly under each component’s src/ directory. A src/common/ directory is unnecessary because each copy belongs to its respective component.

This duplication removes cross-component source dependencies. Changes affecting both implementations must be applied to both copies when appropriate.

Build and Installation

The root CMake project orchestrates the components through:

option(BUILD_VIDEO_DECODE "Build the rocDecode Python bindings" ON)
option(BUILD_JPEG_DECODE "Build the rocJPEG Python bindings" ON)

It supports combined builds and selecting either component individually. Each component also supports direct standalone configuration from its own directory.

Component-specific target names, output directories, and test names allow both projects to build and install together.

The installation delivers:

Component	Python package	Native extension
Video	pyRocVideoDecode	rocpydecode
JPEG	pyRocJpegDecode	rocpyjpegdecode

The original proposal for separate wheel-generation workflows was dropped. This restructuring uses CMake to build and install the native shared libraries and Python packages; it does not introduce component wheel packaging.

Bindings for overlapping types use module-local registration where needed so both native modules can coexist in one Python process.

Optional Video Features

FFmpeg-dependent demuxing and the rocDecode CPU backend remain optional.

The build enables these features when the corresponding libraries and utility sources are available. The default video tests avoid requiring FFmpeg, the host decoder library, PyTorch, or hip-python.

Optional samples and API tests remain available with their additional dependencies.

Tests

Video tests and JPEG test registration belong to their respective components.

The restructuring provides:

• Standalone component CTest execution.
• Combined CTest execution from the root.
• Component-specific Python import paths.
• SDK test-media discovery.
• Clear configuration messages when required test media is unavailable.
• Installation of component test scripts for subsequent testing.

Validation covers standalone and combined configuration, compilation, installation, Python imports, and CTest execution. Both native modules must also import successfully in the same Python process.

Repository Cleanup

Removed obsolete root content:

• data/
• conda-recipe/
• build_rocpydecode_wheel.py
• pyproject.toml
• setup.py
• Root __init__.py
• rocPyDecode-requirements.py
• rocPyDecode-docker-install.py
• Obsolete wheel documentation.
• Unused Azure DevOps pipeline and Codecov configuration.

The ResNet50 sample no longer depends on data/labels.txt. It accepts an optional --labels argument and can run without a labels file.

Documentation

Video- and JPEG-specific documentation is located under the owning component’s docs/ directory.

Each component has its own README and documentation entry point. Component documentation uses local paths and does not require the sibling component.

Root documentation provides unified navigation and explains how to select and build the components.

Completion Criteria

• Separate video and JPEG source ownership.
• Independent component CMake projects.
• Component-local buffer and DLPack implementations.
• Standalone and combined build/install support.
• Separate Python packages and native extensions.
• Coexistence of both native modules in one Python process.
• Component-owned samples and tests.
• Optional video dependency handling.
• Component-owned documentation.
• Removal of obsolete packaging scripts and root directories.
• Removal of the ResNet50 sample’s dependency on the former root labels file.