Dne 9.2.2017 v 07:49 wm4 napsal(a):
On Wed, 8 Feb 2017 23:31:54 +0100
Miroslav Slugeň wrote:
It is much more robust solution to always calculate second field (when
deinterlacing) PTS from frame rate, then relating on previous PTS,
because if there are B frames in input and some video frames ar
Dne 8.2.2017 v 23:59 Carl Eugen Hoyos napsal(a):
2017-02-08 23:31 GMT+01:00 Miroslav Slugeň :
It is much more robust solution to always calculate second field
(when deinterlacing) PTS from frame rate
Without looking at your patch, I would have guessed that not
every stream has a useful frame ra
On Wed, 8 Feb 2017 23:31:54 +0100
Miroslav Slugeň wrote:
> It is much more robust solution to always calculate second field (when
> deinterlacing) PTS from frame rate, then relating on previous PTS,
> because if there are B frames in input and some video frames are
> corrupted (dropped) it wil
2017-02-08 23:31 GMT+01:00 Miroslav Slugeň :
> It is much more robust solution to always calculate second field
> (when deinterlacing) PTS from frame rate
Without looking at your patch, I would have guessed that not
every stream has a useful frame rate.
(It's 1000fps for asf input)
Carl Eugen
___
It is much more robust solution to always calculate second field (when
deinterlacing) PTS from frame rate, then relating on previous PTS,
because if there are B frames in input and some video frames are
corrupted (dropped) it will calculate wrong PTS for second field and
could hang on encoding
