Hi Andreas, On Fri, 22 Sept 2023 at 13:33, Andreas Rheinhardt <andreas.rheinha...@outlook.com> wrote: > > 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.
I could propose it, if it's an acceptable solution and could also help other users. Regards, > > - 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". _______________________________________________ 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".
