Clément Péron: > Hi Andreas, > > On Fri, 22 Sept 2023 at 12:01, Andreas Rheinhardt > <andreas.rheinha...@outlook.com> wrote: >> >> Clément Péron: >>> Hi Andreas, >>> >>> On Fri, 22 Sept 2023 at 09:58, Andreas Rheinhardt >>> <andreas.rheinha...@outlook.com> wrote: >>>> >>>> Clément Péron: >>>>> Hi Michael, Andreas, >>>>> >>>>> On Thu, 21 Sept 2023 at 22:50, Andreas Rheinhardt >>>>> <andreas.rheinha...@outlook.com> wrote: >>>>>> >>>>>> Michael Niedermayer: >>>>>>> On Thu, Sep 21, 2023 at 02:17:00PM +0200, Clément Péron wrote: >>>>>>>> Output the producer reference time to a dirty raw output. >>>>>>>> >>>>>>>> Signed-off-by: Clément Péron <peron.c...@gmail.com> >>>>>>>> --- >>>>>>>> libavformat/rawenc.c | 122 +++++++++++++++++++++++++++++++++++++++++++ >>>>>>>> 1 file changed, 122 insertions(+) >>>>>>> >>>>>>> this breaks fate-filter-volume and others >>>>>>> (Segmentation fault) >>>>>>> >>>>>>> I can rerun it with debug symbols and provide peoper gdb output >>>>>>> but i suspect given this has "HACK" in the title you are aware of this >>>>> >>>>> The "HACK" tag meaning was not supposed to be: "it's ok if it >>>>> segfaults", but more to trigger a discussion is it possible to >>>>> properly support an output timestamp in the raw video demux, and if >>>>> yes how to do it :) >>>> >>>> If you need a timestamp for raw video, then use a proper container and >>>> not raw video. In fact, this patch basically creates new formats >>>> different from all the raw formats. >>> >>> Yes I agree, but I do not want to add too much overhead nor >>> computation processing or memory copy to my pipeline just to mux and >>> demux between ffmpeg and my python script. >>> >>> The idea is to have a very light structure to easily pipe it. >>> >> >> Our libraries are meant to be used by API users and are designed for >> that. The ffmpeg command line tool is just one user among many and >> adding code to a library to circumvent a limitation of ffmpeg (or >> another user of the libraries) is not appropriate. We would end up with >> a ton of hacks. > > Yes I agree and maybe the final solution for this is "keep a fork of > FFMpeg with your patch on your side", >
Yes, that is the likely outcome. > But my idea is could introducing a "raw-format user-defined" would be > acceptable or will it be considered a hack? > > like we pass the pix_fmt why not passing a raw_fmt to specify the raw > output format? It will default to only "packet" but a user could add > other metadata if wanted. This would require us to add hacks and introduce new container formats instead of you simply using one of the already existing containers. - Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
