[FFmpeg-user] Would it be possible to load xattr-related media-files like a container?

[Peter B.]

Me again :)

I was surprised to find this idea not sparking more interest here.
Hm.

Let me try again:
**I would like to hire someone to implement and design with me such a 
patch!**

~~Imagine:

**Dissolving container file formats into related annotated-objects on 
the filesystem.**

And it already works! Currently I have to hack a loooong ffmpeg to load 
"a clip object tree" like that, but it works!

Anyone got time and curiosity on their hands? :D
I've already de-embedded everything exiftool could read, copied into 
xattrs (on ZFS over Samba: works!), and written 2 tools for that:
https://github.com/pjotrek-b/mercs/tree/main/helpers

I truly question a transition to related object structures and xattrs 
for regular "file" handling in the future: Aren't video providers 
already doing it like that? providing separate "related objects" - and 
then pulling the "selected ones" on the fly per ObjectID (URI)?

If ffmpeg could load and handle such an "object tree", that would be 
amazing!
And I imagine it could be implemented as demuxer/muxer: So it wouldn't 
even be hack, but a "proper format variation".

Audio/Video/Subtitle/Data could be in the same folder - or spread around 
the globe: it wouldn't matter anymore... media streams would be 
annotated (and related) as plain filesystem attributes.

Sounds interesting now?
Opinions?
Coding interests?


Would be happy to hear from you!
Peter


On 21.11.24 00:29, Peter B. wrote:
> Hi everyone :)
>
> I'm working a lot with extended attributes on filesystems, and I'm 
> amazed!
>
> I was wondering if it would be possible for ffmpeg to load "related 
> media-streams" as related objects:
> Having a 0-Byte "videofile.aha":
>
>   * video = /path/to/my_movie.h264
>   * audio = ./my_movie-DE_AT.flac
>   * audio.1 = my_movie-EN_GB.mp3
>   * video.default = video
>   * audio.default = audio.1
>   * dc.title = "My Movie"
>   * dc.creator = "..."
>   * ...
>
> Like an input demuxer which resolves the related objects and treats 
> this like loading a container?
>
> I imagine this to be quite fun (and useful actually).
> One could then drag-and-drop to remux tracks, and right-click-edit 
> metadata, I imagine.
>
> Feedback greatly appreciated :)
>
> Have a great day!
> Peter
>
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xE429ADDBF0F47726.asc
Type: application/pgp-keys
Size: 3134 bytes
Desc: OpenPGP public key
URL: <https://ffmpeg.org/pipermail/ffmpeg-user/attachments/20250802/319a2163/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-user/attachments/20250802/319a2163/attachment.sig>