On 2022-02-13 10:58 pm, James Almer wrote:
On 2/13/2022 2:22 PM, Andreas Rheinhardt wrote:
James Almer:
On 2/13/2022 2:14 PM, Paul B Mahol wrote:
Too soon.
Wait more,
Ok.
does this breaks something?
There are no fate tests, and 0 is used when the duration is unknown, so
it shouldn'
James Almer:
>
>
> On 2/13/2022 2:22 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> On 2/13/2022 2:14 PM, Paul B Mahol wrote:
Too soon.
Wait more,
>>>
>>> Ok.
>>>
does this breaks something?
>>>
>>> There are no fate tests, and 0 is used when the duration is unknown, so
>>>
On 2/13/2022 2:22 PM, Andreas Rheinhardt wrote:
James Almer:
On 2/13/2022 2:14 PM, Paul B Mahol wrote:
Too soon.
Wait more,
Ok.
does this breaks something?
There are no fate tests, and 0 is used when the duration is unknown, so
it shouldn't break anything.
It breaks the simple use-
James Almer:
> On 2/13/2022 2:14 PM, Paul B Mahol wrote:
>> Too soon.
>>
>> Wait more,
>
> Ok.
>
>> does this breaks something?
>
> There are no fate tests, and 0 is used when the duration is unknown, so
> it shouldn't break anything.
>
It breaks the simple use-case where this filter is used t
On 2/13/2022 2:14 PM, Paul B Mahol wrote:
Too soon.
Wait more,
Ok.
does this breaks something?
There are no fate tests, and 0 is used when the duration is unknown, so
it shouldn't break anything.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffm
Too soon.
Wait more,
does this breaks something?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe"
On 2/9/2022 12:28 PM, James Almer wrote:
It's not possible to know the resulting packet's duration after
applying the expression as it depends on the timestamp of the next
packet, which we haven't seen yet.
The old duration, if any, is no longer valid, so just remove it.
Signed-off-by: James Alm
