starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-05-30 23:40:40 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[Enhancement]: Video Podcast Support #2547

New Issue
Closed
opened 2026-04-25 00:08:15 +02:00 by adam · 5 comments
adam commented 2026-04-25 00:08:15 +02:00
Owner
Copy Link
Copy Source

Originally created by @AdrianEdelen on GitHub (Feb 5, 2025).

Type of Enhancement

Server Backend

Describe the Feature/Enhancement

Add video podcast support for podcasts, as a stretch goal, add video podcast playback in the web UI.

Currently, when adding a video podcast, it is converted to an audio only. A minimum implementation would be to keep the video metadata and include it with the RSS feeds created by ABS ('Open RSS feed') to serve the videos. This way podcast clients that support video can play them.

Why would this be helpful?

Video podcasts are common and are often served through RSS feeds.

Future Implementation (Screenshot)

I propose a backend implementation only to begin with, to avoid the extra challenge of UI implementation.

Audiobookshelf Server Version

v2.19.0

Current Implementation (Screenshot)

This is generally a backend change.

Originally created by @AdrianEdelen on GitHub (Feb 5, 2025). ### Type of Enhancement Server Backend ### Describe the Feature/Enhancement Add video podcast support for podcasts, as a stretch goal, add video podcast playback in the web UI. Currently, when adding a video podcast, it is converted to an audio only. A minimum implementation would be to keep the video metadata and include it with the RSS feeds created by ABS ('Open RSS feed') to serve the videos. This way podcast clients that support video can play them. ### Why would this be helpful? Video podcasts are common and are often served through RSS feeds. ### Future Implementation (Screenshot) I propose a backend implementation only to begin with, to avoid the extra challenge of UI implementation. ### Audiobookshelf Server Version v2.19.0 ### Current Implementation (Screenshot) This is generally a backend change.
adam added the enhancement label 2026-04-25 00:08:15 +02:00
adam closed this issue 2026-04-25 00:08:15 +02:00
adam commented 2026-04-25 00:08:15 +02:00
Author
Owner
Copy Link
Copy Source

@nichwall commented on GitHub (Feb 5, 2025):

Duplicate of https://github.com/advplyr/audiobookshelf/issues/2196

Video support within the clients is not likely to be implemented.

@nichwall commented on GitHub (Feb 5, 2025): Duplicate of https://github.com/advplyr/audiobookshelf/issues/2196 Video support within the clients is not likely to be implemented.
adam commented 2026-04-25 00:08:15 +02:00
Author
Owner
Copy Link
Copy Source

@AdrianEdelen commented on GitHub (Feb 5, 2025):

I don't think this would require a change in the client, at least not initially.

as it stands, video files can be uploaded, so I think https://github.com/advplyr/audiobookshelf/blob/0cf7a6abec66803380753906a52e89efb71468cd/server/utils/podcastUtils.js#L146-L153 could be replaced with something like:

if (item.enclosure?.[0]?.['$']?.url) {
    enclosure = item.enclosure[0]['$']
  } else if(item['media:content']?.find(c => c?.['$']?.url && /(audio|video)\//.test(c?.['$']?.type ?? ""))) {
    enclosure = item['media:content'].find(c => /(audio|video)\//.test(c['$']?.type ?? ""))['$']
  } else {
    Logger.error(`[podcastUtils] Invalid podcast episode data`)
    return null
  }

though I haven't tested this yet, and am working on that. that should just result with the type in the feed data being set correctly, and would allow clients that support video to use it.

@AdrianEdelen commented on GitHub (Feb 5, 2025): I don't think this would require a change in the client, at least not initially. as it stands, video files can be uploaded, so I think https://github.com/advplyr/audiobookshelf/blob/0cf7a6abec66803380753906a52e89efb71468cd/server/utils/podcastUtils.js#L146-L153 could be replaced with something like: ``` js if (item.enclosure?.[0]?.['$']?.url) { enclosure = item.enclosure[0]['$'] } else if(item['media:content']?.find(c => c?.['$']?.url && /(audio|video)\//.test(c?.['$']?.type ?? ""))) { enclosure = item['media:content'].find(c => /(audio|video)\//.test(c['$']?.type ?? ""))['$'] } else { Logger.error(`[podcastUtils] Invalid podcast episode data`) return null } ```` though I haven't tested this yet, and am working on that. that should just result with the type in the feed data being set correctly, and would allow clients that support video to use it.
adam commented 2026-04-25 00:08:15 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Feb 5, 2025):

That change would be for downloading MRSS feed episodes (recently added https://github.com/advplyr/audiobookshelf/pull/3732)

I don't think that is what you are looking for. Is this not a duplicate of #2196?

@advplyr commented on GitHub (Feb 5, 2025): That change would be for downloading MRSS feed episodes (recently added https://github.com/advplyr/audiobookshelf/pull/3732) I don't think that is what you are looking for. Is this not a duplicate of #2196?
adam commented 2026-04-25 00:08:15 +02:00
Author
Owner
Copy Link
Copy Source

@AdrianEdelen commented on GitHub (Feb 5, 2025):

I don't think that is what you are looking for. Is this not a duplicate of https://github.com/advplyr/audiobookshelf/issues/2196?

yes it seems so, though I wouldn't call it a bug, rather, its just not something ABS supports currently. Would you prefer I close this issue and add comments to that issue?

It may be in the wrong spot, I am still learning the codebase, I just started looking at it today / getting environment up so I can step through. What I was looking for is when a podcast is downloaded from its source feed to ABS, and then later rebroadcast with the feed generated by ABS.

I believe that keeping the https://github.com/advplyr/audiobookshelf/blob/24d6e390f0fbf9b0f6c26df6a33e5da2475cc815/server/models/PodcastEpisode.js#L38 of PodcastEpisode.js (as well as probably modifying the feed generator as "video/mp4" it would allow 3rd party clients to use the video while just playing the audio from the video on the ABS client or apps (which is the current behavior if you upload a video).

You are right that that what i showed is specific to mrss, though I think it would need to be updated as well, since a video can be in a <media:content> tag.

here is the scenario I am looking at:

<item>
    <title>Podcast</title>
    <description>description</description>
    <pubDate>Wed, 05 Feb 2025 12:00:00 GMT</pubDate>
    <enclosure url="https://example.com/video.mp4" type="video/mp4" length="123456789" />
</item>

here is a more concrete example:

Image

This is a podcast that I created via ABS, by moving the file directly into a podcast folder and scanning. the file gets imported correctly, however ABS treats it as audio.

we can see when we probe the file with ffmpeg via ABS that it is a video:

Image

so my updated proposal is that when creating the ABS RSS feed for the item, since we can detect that it is video we set the type correctly. For this example it wouldn't change functionality for the client at all, as the video will just play as an audio podcast.

then possibly later, the second part would be detecting the video type enclosures on podcasts that get downloaded to ABS from a feed, which I think would potentially have more side effects.

@AdrianEdelen commented on GitHub (Feb 5, 2025): >I don't think that is what you are looking for. Is this not a duplicate of https://github.com/advplyr/audiobookshelf/issues/2196? yes it seems so, though I wouldn't call it a bug, rather, its just not something ABS supports currently. Would you prefer I close this issue and add comments to that issue? It may be in the wrong spot, I am still learning the codebase, I just started looking at it today / getting environment up so I can step through. What I was looking for is when a podcast is downloaded from its source feed to ABS, and then later rebroadcast with the feed generated by ABS. I believe that keeping the https://github.com/advplyr/audiobookshelf/blob/24d6e390f0fbf9b0f6c26df6a33e5da2475cc815/server/models/PodcastEpisode.js#L38 of PodcastEpisode.js (as well as probably modifying the feed generator as `"video/mp4"` it would allow 3rd party clients to use the video while just playing the audio from the video on the ABS client or apps (which is the current behavior if you upload a video). You are right that that what i showed is specific to mrss, though I think it would need to be updated as well, since a video can be in a `<media:content>` tag. here is the scenario I am looking at: ``` xml <item> <title>Podcast</title> <description>description</description> <pubDate>Wed, 05 Feb 2025 12:00:00 GMT</pubDate> <enclosure url="https://example.com/video.mp4" type="video/mp4" length="123456789" /> </item> ``` here is a more concrete example: ![Image](https://github.com/user-attachments/assets/5758bfa8-031d-4406-8749-306f53b36bb2) This is a podcast that I created via ABS, by moving the file directly into a podcast folder and scanning. the file gets imported correctly, however ABS treats it as audio. we can see when we probe the file with ffmpeg via ABS that it is a video: ![Image](https://github.com/user-attachments/assets/be9874fb-ac23-48a8-bf9d-18def2d65d28) so my updated proposal is that when creating the ABS RSS feed for the item, since we can detect that it is video we set the type correctly. For this example it wouldn't change functionality for the client at all, as the video will just play as an audio podcast. then possibly later, the second part would be detecting the video type enclosures on podcasts that get downloaded to ABS from a feed, which I think would potentially have more side effects.
adam commented 2026-04-25 00:08:16 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Feb 5, 2025):

This is a bit more complicated to change since the mime type is coming from the file extension only. We aren't storing anywhere on the audio file whether it has a video stream or not so we would have to save that with the audio file on the initial scan.
The reason is because we don't want to run an ffprobe for every audio file when a feed is created/updated.

@advplyr commented on GitHub (Feb 5, 2025): This is a bit more complicated to change since the mime type is coming from the file extension only. We aren't storing anywhere on the audio file whether it has a video stream or not so we would have to save that with the audio file on the initial scan. The reason is because we don't want to run an ffprobe for every audio file when a feed is created/updated.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
authentication
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
pull-request
Mirrored from GitHub Pull Request
 sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#2547
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?