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

[Andreas Rheinhardt <andreas.rheinhardt@outlook.com>]

Clément Péron:
> 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",
> 

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