didn't have the patchst anymore and already processed comments in later
patches, so 02/35 and 05/35 became out of 33. Noticed that too late. Hope
that doesn't confuse anything. Else we'll get it on -v2 of this series
(which there will certainly be), where i think i'll throttle sending a bit
(someho
Just resend them (without any -v2).
___
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 Tue, Jun 8, 2021 at 2:13 AM Valerii Zapodovnikov
wrote:
> Actually I do not know how well will this work. Did you ever play any
> stream? Even if you play it without forcing seeking you are allowed to
> search forth due to how latency works. That problem with latency was only
> fixed in CMAF.
Actually I do not know how well will this work. Did you ever play any
stream? Even if you play it without forcing seeking you are allowed to
search forth due to how latency works. That problem with latency was only
fixed in CMAF. ONE must to accelerate decoding forward in time to get low
latency.
avdevice/dshow is a realtime device and as such does not support seeking.
Therefore, its demuxer format should define the AVFMT_NOBINSEARCH,
AVFMT_NOGENSEARCH and AVFMT_NO_BYTE_SEEK flags.
With these flags set, attempting to seek (with e.g. avformat_seek_file())
correctly yields -1 (operation no
