starred/audiobookshelf-advplyr

Fork 0

mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-03-02 22:46:55 -05:00

[Enhancement]: Video Podcast Support #2545

New issue

Closed

opened 2026-02-20 10:20:19 -05:00 by deekerman · 5 comments

deekerman commented

2026-02-20 10:20:19 -05:00

Owner

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.

deekerman

2026-02-20 10:20:19 -05:00

closed this issue
added the
enhancement
label

deekerman commented

2026-02-20 10:20:21 -05:00

Author

Owner

@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.

deekerman commented

2026-02-20 10:20:21 -05:00

Author

Owner

@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 github.com/advplyr/audiobookshelf@0cf7a6abec/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.

deekerman commented

2026-02-20 10:20:21 -05:00

Author

Owner

@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?

deekerman commented

2026-02-20 10:20:21 -05:00

Author

Owner

@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 github.com/advplyr/audiobookshelf@24d6e390f0/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:

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:

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.

deekerman commented

2026-02-20 10:20:21 -05:00

Author

Owner

@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.