Re: [FFmpeg-devel] [RFC PATCH 3/3] HACK: avformat: rawenc: allow to output a raw PRFT

["Clément Péron" <peron.clem@gmail.com>]

Hi Andreas,

On Fri, 22 Sept 2023 at 12:01, Andreas Rheinhardt
<andreas.rheinhardt@outlook.com> wrote:
>
> Clément Péron:
> > Hi Andreas,
> >
> > On Fri, 22 Sept 2023 at 09:58, Andreas Rheinhardt
> > <andreas.rheinhardt@outlook.com> wrote:
> >>
> >> Clément Péron:
> >>> Hi Michael, Andreas,
> >>>
> >>> On Thu, 21 Sept 2023 at 22:50, Andreas Rheinhardt
> >>> <andreas.rheinhardt@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.clem@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",

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.


>
> > I'm not familiar with audio/video container but it seems to me that
> > parsing containers are not very light no?
>
> For certain formats the overhead of parsing containers can be negative
> when compared to the raw format, because the containers provide a length
> field for the packet whereas one has to search for the packet boundaries
> in case of a truely raw stream. But this is not true for raw video which
> is fixed size.

Yes, good point, in my case I have a fixed size raw video.

Thanks for your comments,
Regards,
Clement

>
> - 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-request@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-request@ffmpeg.org with subject "unsubscribe".