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

[Peter B.]

Hi! :D

Sorry for "cross-posting"?, but I thought I'd take this up one level and 
bring it before "the real devs".
Original thread = 2 msg monologue: 
https://ffmpeg.org/pipermail/ffmpeg-user/2025-August/059734.html

@cehoyos:
Are you still reading me?
I'd like to talk. I am seriously believing it's possible to move beyond 
file-formats and even container formats. Already. Existing 
filesystem-features.
For preservation and science and gaming data, this is /very useful/ and 
in demand.

And I may be able to hire someone to write a patch to ffmpeg supporting 
container-less media handling and metadata by using xattrs.


I am working actively with xattrs for more than 1 year now, and they are 
stable.
It would be amazing if FFmpeg were one of the first to charter that 
territory of new usability of modern filesystems.


Thank you for your time, and I'd be happy to hear your opinions on this!

Peter 🌟️❤️


On 02.08.25 21:58, Peter B. wrote:
> 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".
>
>
> _______________________________________________
> 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-devel/attachments/20250822/1f387a7e/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-devel/attachments/20250822/1f387a7e/attachment.sig>