[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