[FFmpeg-trac] #6971(undetermined:new): ffmpeg drops frames after deinterlacing
FFmpeg
trac at avcodec.org
Wed Nov 14 17:36:35 EET 2018
#6971: ffmpeg drops frames after deinterlacing
-------------------------------------+-------------------------------------
Reporter: CaryKnoop | Owner:
Type: defect | Status: new
Priority: normal | Component:
Version: git-master | undetermined
Keywords: cuvid | Resolution:
Blocking: | Blocked By:
Analyzed by developer: 0 | Reproduced by developer: 0
-------------------------------------+-------------------------------------
Comment (by malakudi):
Replying to [comment:16 cehoyos]:
> Replying to [comment:14 malakudi]:
> > After further testing, -r 50 on input works fine if input is a correct
encoded file, starting from keyframe etc etc.
>
> > If input is a live stream (http or udp multicast), even if it starts
at keyframe, with -r 50 as input any input error will immediately result
in audio/video sync error.
>
> This is expected.
Well, if it is expected, using -r XX as input flag is not an option for
many workloads. -r XX as output should be "fixed" to work as it used to
work before the above mentioned commit. Before the above mentioned commit,
both kind of interlaced h264 input (MBAFF and PAFF) were working with -r
XX on output. After that commit, as I found out, ffmpeg drops frames if
input is MBAFF. It would be nice to fix this, although there is now an
alternative, yadif_cuda filter. But since it used to work, it would be
nice to make it work again.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/6971#comment:19>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list