On Sat, Mar 25, 2023 at 10:43:49PM +0100, Michael Niedermayer wrote:
> On Sat, Mar 25, 2023 at 08:15:14PM +0100, Anton Khirnov wrote:
> > The code currently uses lavfi for this, which creates a sort of
> > configuration dependency loop - the encoder should be ideally
> > initialized with information from the first audio frame, but to get this
> > frame one needs to first open the encoder to know the frame size. This
> > necessitates an awkward workaround, which causes audio handling to be
> > different from video.
> > 
> > With this change, audio encoder initialization is congruent with video.
> > ---
> >  fftools/ffmpeg.c          | 58 ++++++++-------------------------------
> >  fftools/ffmpeg_filter.c   |  8 ------
> >  fftools/ffmpeg_mux_init.c | 19 +++++++++----
> >  3 files changed, 25 insertions(+), 60 deletions(-)
> 
> this results in the following to be apparently stuck
> 
> ffmpeg -y -i https://samples.ffmpeg.org/V-codecs/geov.avi -t 1 file.avi

This patch causes more issues it seems
the following:

./ffmpeg -i AnivisionLogo.bik -t 1 -y test.avi
see https://samples.ffmpeg.org/game-formats/bink/

produces:

==9868== Process terminating with default action of signal 11 (SIGSEGV)
==9868==  General Protection Fault
==9868==    at 0x11D3CAD: ??? (in ffmpeg/ffmpeg_g)
==9868==    by 0x9ACA31: mp3lame_encode_frame (in ffmpeg/ffmpeg_g)
==9868==    by 0x882EC4: ff_encode_encode_cb (in ffmpeg/ffmpeg_g)
==9868==    by 0x8832DD: encode_receive_packet_internal (in ffmpeg/ffmpeg_g)
==9868==    by 0x8834BF: avcodec_send_frame (in ffmpeg/ffmpeg_g)
==9868==    by 0x31A281: encode_frame (in ffmpeg/ffmpeg_g)
==9868==    by 0x31F901: transcode (in ffmpeg/ffmpeg_g)
==9868==    by 0x2F0843: main (in ffmpeg/ffmpeg_g)



[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is a danger to trust the dream we wish for rather than
the science we have, -- Dr. Kenneth Brown