langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 12:05:30 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

Audio Extraction from Local Video File Using FFmpeg Fails #14204

New Issue
Closed
opened 2026-02-21 19:16:04 -05:00 by yindo · 2 comments
yindo commented 2026-02-21 19:16:04 -05:00
Owner
Copy Link
Copy Source

Originally created by @ZHJ19970917 on GitHub (May 27, 2025).

Self Checks

  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
  • [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.4.0

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

I attempted to extract audio from a local video file using FFmpeg, but encountered an error during the process.

Despite the file being present on the local filesystem, the error message indicates:

"Error extracting audio: Request URL is missing an 'http://' or 'https://' protocol."

This seems misleading, as I'm not using a remote URL but a local file path.
It appears the program is incorrectly interpreting the local file path as a URL or expecting an HTTP(S) protocol prefix.

The error at the FFmpeg processing point shows the following message:

{
  "text": "Error extracting audio: Request URL is missing an 'http://' or 'https://' protocol.",
  "files": [],
  "json": [
    {
      "message": "Error extracting audio: Request URL is missing an 'http://' or 'https://' protocol.",
      "status": "error"
    }
  ]
}

✔️ Expected Behavior

No response

❌ Actual Behavior

No response

Originally created by @ZHJ19970917 on GitHub (May 27, 2025). ### Self Checks - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [x] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:) - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.4.0 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce I attempted to extract audio from a local video file using FFmpeg, but encountered an error during the process. Despite the file being present on the local filesystem, the error message indicates: "Error extracting audio: Request URL is missing an 'http://' or 'https://' protocol." This seems misleading, as I'm not using a remote URL but a local file path. It appears the program is incorrectly interpreting the local file path as a URL or expecting an HTTP(S) protocol prefix. The error at the FFmpeg processing point shows the following message: ``` { "text": "Error extracting audio: Request URL is missing an 'http://' or 'https://' protocol.", "files": [], "json": [ { "message": "Error extracting audio: Request URL is missing an 'http://' or 'https://' protocol.", "status": "error" } ] } ``` ### ✔️ Expected Behavior _No response_ ### ❌ Actual Behavior _No response_
yindo added the 🐞 bug label 2026-02-21 19:16:04 -05:00
yindo closed this issue 2026-02-21 19:16:04 -05:00
yindo commented 2026-02-21 19:16:04 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (May 27, 2025):

Your issue is caused by how Dify handles local file paths: it expects file references to be accessible via HTTP(S) URLs, not direct filesystem paths. When a local file path is provided, Dify tries to treat it as a URL, resulting in the misleading error about a missing 'http://' or 'https://' protocol. This is a known limitation in Dify's file handling logic, especially in self-hosted Docker deployments, and has been observed in other file extraction scenarios as well [1].

How to resolve or work around this:

  1. Check and Configure FILES_URL:

    • In your docker/.env file, set the FILES_URL parameter to the externally accessible address of your Dify instance (e.g., http://192.168.10.14/). If you use a non-standard port, include it (e.g., http://192.168.10.14:8080/). Avoid using localhost; use your actual LAN IP [2].
    • After updating, restart your containers with: 
      docker-compose down && docker-compose up -d

  2. Understand the Limitation:

    • Dify's file management system is designed to generate signed URLs for file access, not to pass raw filesystem paths to tools like FFmpeg. If the file is not accessible via a URL, Dify cannot process it as expected [3].

  3. Workarounds:

    • Convert Local Paths to URLs: If you have files on the local disk, upload them through Dify's interface or API so they are stored and referenced via a proper URL.
    • Use Cloud-Hosted Files: If possible, use files that are already accessible via HTTP(S) URLs.
    • Manual Extraction: As a last resort, extract the audio manually using FFmpeg outside of Dify, then upload the resulting audio file to Dify.

References:

If you need to process local files directly, you will need to ensure they are uploaded and accessible via a URL that Dify can use. This is a current architectural limitation of the platform.

To reply, just mention my name @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Join Discord Share on X

@dosubot[bot] commented on GitHub (May 27, 2025): <!-- Answer --> Your issue is caused by how Dify handles local file paths: it expects file references to be accessible via HTTP(S) URLs, not direct filesystem paths. When a local file path is provided, Dify tries to treat it as a URL, resulting in the misleading error about a missing 'http://' or 'https://' protocol. This is a known limitation in Dify's file handling logic, especially in self-hosted Docker deployments, and has been observed in other file extraction scenarios as well [[1]](https://github.com/langgenius/dify/issues/15099). **How to resolve or work around this:** 1. **Check and Configure `FILES_URL`:** - In your `docker/.env` file, set the `FILES_URL` parameter to the externally accessible address of your Dify instance (e.g., `http://192.168.10.14/`). If you use a non-standard port, include it (e.g., `http://192.168.10.14:8080/`). Avoid using `localhost`; use your actual LAN IP [[2]](https://github.com/langgenius/dify/issues/16309). - After updating, restart your containers with: ``` docker-compose down && docker-compose up -d ``` 2. **Understand the Limitation:** - Dify's file management system is designed to generate signed URLs for file access, not to pass raw filesystem paths to tools like FFmpeg. If the file is not accessible via a URL, Dify cannot process it as expected [[3]](https://github.com/langgenius/dify/issues/16327). 3. **Workarounds:** - **Convert Local Paths to URLs:** If you have files on the local disk, upload them through Dify's interface or API so they are stored and referenced via a proper URL. - **Use Cloud-Hosted Files:** If possible, use files that are already accessible via HTTP(S) URLs. - **Manual Extraction:** As a last resort, extract the audio manually using FFmpeg outside of Dify, then upload the resulting audio file to Dify. **References:** - [Known limitation and workaround](https://github.com/langgenius/dify/issues/15099) - [How to configure FILES_URL](https://github.com/langgenius/dify/issues/16309) - [Deployment-specific FILES_URL advice](https://github.com/langgenius/dify/issues/16327) If you need to process local files directly, you will need to ensure they are uploaded and accessible via a URL that Dify can use. This is a current architectural limitation of the platform. <!-- Dosu Comment Footer --> *To reply, just mention my name [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/caf3510f-1da1-4052-9074-6c1df4a63945?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/caf3510f-1da1-4052-9074-6c1df4a63945?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/caf3510f-1da1-4052-9074-6c1df4a63945?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/caf3510f-1da1-4052-9074-6c1df4a63945?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/caf3510f-1da1-4052-9074-6c1df4a63945?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/caf3510f-1da1-4052-9074-6c1df4a63945?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/caf3510f-1da1-4052-9074-6c1df4a63945?feedback_type=other)</sup>&nbsp;&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/20281)
yindo commented 2026-02-21 19:16:04 -05:00
Author
Owner
Copy Link
Copy Source

@crazywoola commented on GitHub (May 27, 2025):

Please open an issue in this repo https://github.com/stvlynn/ffmpeg-Dify-Plugin/issues

@crazywoola commented on GitHub (May 27, 2025): Please open an issue in this repo https://github.com/stvlynn/ffmpeg-Dify-Plugin/issues
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label 🐞 bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#14204
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?