[FFmpeg-devel] [PATCH 3/4 v2] ffmpeg: move A/V non-streamcopy initialization to a later point

Jan Ekström jeebjp at gmail.com
Wed Sep 16 13:20:35 EEST 2020


On Wed, Sep 16, 2020 at 12:24 AM Michael Niedermayer
<michael at niedermayer.cc> wrote:
>
> On Mon, Sep 14, 2020 at 12:33:14AM +0300, Jan Ekström wrote:
> > - For video, this means a single initialization point in do_video_out.
> > - For audio we unfortunately need to do it in two places just
> >   before the buffer sink is utilized (if av_buffersink_get_samples
> >   would still work according to its specification after a call to
> >   avfilter_graph_request_oldest was made, we could at least remove
> >   the one in transcode_step).
> >
> > Other adjustments to make things work:
> > - As the AVFrame PTS adjustment to encoder time base needs the encoder
> >   to be initialized, so it is now moved to do_{video,audio}_out,
> >   right after the encoder has been initialized. Due to this,
> >   the additional parameter in do_video_out is removed as it is no
> >   longer necessary.
> > ---
> >  fftools/ffmpeg.c | 112 ++++++++++++++++++++++++++++++++---------------
> >  1 file changed, 77 insertions(+), 35 deletions(-)
>
> breaks this:
> ./ffmpeg -ss 30.0 -i ~/tickets/1745/1745-Sample.mkv -f vob -c:a copy  -bitexact -t 1 -f framecrc -
> (sample file is linked in the ticket https://trac.ffmpeg.org/ticket/1745)
>
> (Too many packets buffered for output stream 0:1. Conversion failed!)
>
> thx

With an initial look with -debug_ts -v verbose -max_muxing_queue_size
10000 , it appears that audio packets start at about -5.5 seconds, and
video is getting skipped until an exact zero point is hit.

So either the offset is incorrect, or we should also be dropping the
audio packets as well until zero point is found.

Jan


More information about the ffmpeg-devel mailing list