# P-HAR reports 75.64% in the repository and 94% behind a hosted API

> A human action recognition project applied to adult video, built on four OpenMMLab repositories, fusing RGB, skeleton, and audio streams by late fusion. The open code, the checkpoints, and the accuracy claim in the update note are three different things.

**rlleshi/phar** — deep learning sex position classifier

- Repository: https://github.com/rlleshi/phar
- Stars: 316 · Forks: 36
- Language: Python
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/rlleshi-phar

## The repository reports 75.64% and the update note reports 94%

Two accuracy numbers sit in the same README and they are not measuring the same system. The technical sections say the multi-model figure is 75.64%, described as promising given the small training set, and the models section rounds it to a tilde 75%. That number covers 17 actions.

The update note at the top claims models surpassing 94% accuracy on 20 action categories, available through what it calls an easy-to-use API. The supporting links are a hosted page, phar-virid.vercel.app, and a contact address for business inquiries. There is no weights download for the 20 category set, no code, and no paper in the repository. The only downloadable checkpoints are attached to release tag v1.0.0.

So the 94% figure is not something you can reproduce from what is published. The 75.64% figure is. Two annotation files are in the tree, `annotations.txt` for the 17 action set and `current_annotations.txt` for the larger one, which is the clearest sign that two taxonomies are in play.

## Top 2 is the metric because two actions can overlap in the same clip

The accuracy claim needs its metric attached or it is meaningless. The reason top 2 is used is stated directly: more than one action can happen at the same time, and some of the actions and positions are conceptually overlapping even before you consider timing.

That means a top-1 score would penalise the model for a correct answer in second place, so the headline figure is a top-2 number. If you compare it against a paper reporting top-1, you are comparing different quantities.

The other caveat is scale. The training set is described as quite small, and in total only around 50 experiments have been performed. Fifty runs is not a hyperparameter search; it is enough to know the configuration is not broken and nowhere near enough to know whether a different configuration is better.

The stated direction of travel is more data, and the project asks for help with it. Treat the number as a single-run result on a small set rather than a converged one.

There is also a category-overlap problem that no metric fixes. When two labels in the taxonomy describe overlapping concepts rather than distinct visual events, top-2 credit can be earned by guessing the near neighbour, which inflates the score without improving the classifier. Reading per-category results rather than the aggregate is the only way to see whether that is happening.

## Three input streams fused late, which the audio switch makes visible

The architecture is three models over three streams. RGB frames, a human skeleton, and audio each get their own model, and the results are merged by late fusion rather than by concatenating features early. The claimed benefit over an RGB-only model is significant.

The project is explicitly spatio-temporal. It processes video clips rather than single images, and the README points at miles-deep as a project that uses single images, calling the clip-based approach inherently superior for action recognition. That claim is about the task, not about this implementation, but it explains why the checkpoints expect sequences.

You can see the fusion weights from the command line. The demo takes a `--coefficients` argument, and passing `0.5 1.0` with an empty `--audio-checkpoint` disables the audio stream entirely while keeping two. There is no separate flag list for the skeleton stream, so the practical lever is which checkpoint paths you supply.

```bash
python src/demo/multimodial_demo.py video.mp4 demo.json --audio-checkpoint '' --coefficients 0.5 1.0 --verbose
```

## Every demo writes a prediction row every seven seconds

The demo command takes an input video and an output file, and by default it writes the top predictions every 7 seconds. The output file can be a video or a JSON document, chosen purely by the extension you pass.

```bash
python src/demo/multimodial_demo.py video.mp4 demo.mp4
```

Seven seconds is coarse. One of the five advertised benefits is automated timestamp generation, described as letting a viewer jump straight to a section of the video the way YouTube does, and there is a `--timestamps` flag for it. But the demo's own default granularity is a fixed interval, so what you get out of the box is a sampling grid, not the start and finish of an action.

The second stage is separate. A small script takes the JSON and returns the top 3 tags by default, which is where automated tagging happens.

```bash
python src/top_tags.py demo.json
```

So the pipeline is two commands with a JSON file between them, and the tag count is a parameter of the second one rather than of the classifier.

The demo writes whatever the interval produces, so a short action that begins and ends between two ticks appears in no row at all, and one that spans a tick is credited to a single moment rather than a range. Both are reasons to treat the timestamps flag as the feature and the default as a preview.

## Content filtering is a TODO and deployment is conditional

Five benefits are listed near the top: automated tagging, automated timestamp generation, an improved recommendation system, content filtering, and extracting short clips. Two of them have no implementation behind them.

Content filtering has a single line under its own heading: TODO, depending if people need it. Deployment says it depends on whether people find the project useful, and that currently one has to install the relevant libraries to use the models.

That leaves three working capabilities, and only two of them are demonstrated in commands. The recommendation improvement has no script at all, and neither does short clip extraction. Both follow from the JSON output rather than needing their own model, but nobody wrote the glue.

Docker is the exception. The image is built from a Dockerfile in the docker directory and tagged `rlleshi/phar`:

```bash
docker build -f docker/Dockerfile . -t rlleshi/phar
```

Even the container path still expects the checkpoints to be present, because the models are downloaded separately rather than baked in.

## The documented mmcv command is pinned to one CUDA and one torch pair

Manual installation is a numbered list, and step two is the one that will decide whether your afternoon goes well. The correct mmcv build depends on your CUDA and torch versions, and the example given is a single combination:

```bash
pip install mmcv-full==1.3.18 -f https://download.openmmlab.com/mmcv/dist/cu113/torch1.10.0/index.html
```

CUDA 11.3, torch 1.10.0, mmcv-full 1.3.18. Anything else means reading the OpenMMLab wheel index yourself and choosing a different path, since the instructions say the version has to match and offer this only as an example.

The rest of the list is a framework stack. Clone with `--recurse-submodules` and use Python 3.8 or later, install torch, with CUDA and CUDNN recommended, install the mmaction2 submodule in editable mode after cython, then install MMPose and MMDetection by following each project's own documentation, and finish with the extra requirements file. The instructions are written for Ubuntu and say they should also work under Windows WSL.

Step four and step five are links rather than commands, so the reproducibility of this project is bounded by the reproducibility of three OpenMMLab repositories at whatever version you resolve them to.

## Four OpenMMLab repositories arrive as submodules and three checkpoints arrive as downloads

The dependency situation is unusual in shape. The tree contains `mmaction2`, `mmdetection`, and `mmpose` as subdirectories alongside a `.gitmodules` file, alongside this project's own `annotator/`, `checkpoints/`, `configs/`, `docker/`, `requirements/`, `resources/`, and `src/`. The clone command is SSH based and recursive for that reason.

Then there are three sets of weights, all downloaded by hand and all moved into the same `checkpoints/har` folder. The human detector is a Faster R-CNN checkpoint from the MMDetection v2.0 release path. The pose model is an HRNet top-down checkpoint from the MMPose release path. The HAR models themselves come from the v1.0.0 release tag of this repository.

Put together, that is four frameworks at pinned-in-theory versions, two third-party checkpoints that must match them, and one checkpoint set from a release dated 2022-06-01. The default branch was last pushed on 2026-06-12, so work has continued for roughly four years past that tag without producing a new one.

Which means the only weights you can get are the ones that pair with the 17 action set and the roughly 75% figure, not with the 94% claim.

## Conclusion

P-HAR is worth reading and reproducing if you are working on spatio-temporal action recognition and want a three-stream late fusion baseline with published weights, since the open repository does contain the models, the annotation lists, and a working demo. It is not a product you can evaluate as shipped. The 94% number and the 20 category set live behind a hosted API with no weights, no code, and no paper in the tree, and the open weights correspond to 17 actions at roughly 75% top-2. Budget a day for the install alone, because the one documented mmcv command is pinned to a single CUDA and torch pair and everything else is a link to another project's instructions. If you evaluate it, judge top-2 accuracy and per-category results rather than the single headline figure, since the categories overlap by design.

## FAQ

### What does P-HAR do?

It is a human action recognition system applied to adult video. Three models run over RGB frames, a human skeleton, and audio separately, and their outputs are merged through late fusion to classify which action or position is occurring in a clip.

### How accurate is P-HAR?

The repository reports 75.64%, measured as top-2 accuracy over 17 actions, and calls the result promising given the small training set. An update note claims models above 94% on 20 categories through a hosted API, but no weights, code, or paper for that claim are in the repository.

### How do I run the P-HAR demo?

Download the Faster R-CNN human detector, the HRNet pose model, and the HAR checkpoints, then place them in `checkpoints/har`. Run `python src/demo/multimodial_demo.py video.mp4 demo.mp4`, which writes the top predictions every 7 seconds by default. Passing a .json output file stores them instead of rendering a video.

### Can I disable one of the three models in P-HAR?

The demo accepts a `--coefficients` argument and per-stream checkpoint flags. Passing an empty `--audio-checkpoint` with `--coefficients 0.5 1.0` disables the audio stream and keeps the RGB and skeleton models.

### What are the P-HAR installation requirements?

Python 3.8 or later, torch with CUDA and CUDNN recommended, and a matching mmcv build. The documented example pins mmcv-full 1.3.18 for CUDA 11.3 with torch 1.10.0. MMAction2 arrives as a submodule, while MMPose and MMDetection are installed by following their own instructions.

## Sources

- [Issues](https://github.com/rlleshi/phar/issues)
- [License: Apache-2.0](https://github.com/rlleshi/phar/blob/master/LICENSE)
- [README](https://github.com/rlleshi/phar/blob/master/README.md)
- [Releases](https://github.com/rlleshi/phar/releases)
- [rlleshi/phar on GitHub](https://github.com/rlleshi/phar)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rlleshi-phar