[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