On 02-05-2019 04:12 PM, Moritz Barsnick wrote:
On Wed, May 01, 2019 at 12:03:41 -0300, James Almer wrote:
+ if (pkt->pts != AV_NOPTS_VALUE) {
+ int64_t pts = av_rescale_q(pkt->pts, bsf->time_base_in, AV_TIME_BASE_Q) /
ctx->speed;
+ int64_t now = av_gettime_relative();
+ int64_t sleep = pts - now + ctx->delta;
+ if (!ctx->inited) {
+ ctx->inited = 1;
+ sleep = 0;
+ ctx->delta = now - pts;
If this is meant to be used for input, where seeking can take place,
wouldn't a flush() callback to set ctx->inited and ctx->delta back to 0
be needed?
Interesting point. I suppose you mean backward seeking. Is that a valid
use case for a bitstream filter? Would it also apply to the standard
filter, where I took this code from?
I don't know, but I can try to add that, if required. Can you tell me
how to emulate or test seeking from the command line? Would I create a
file with backward jumps in PTS (and how)?
Also, you may want to add support for -copyts which -re lacks as well.
Another complication is timestamp rollover, independent of copyts.
How does the filter behave with non-monotonic timestamps?
Gyan
P.S. you can craft files to test all of this by generating individual TS
files with custom timestamps and then 'cat'ting them together, whether
via the concat protocol or shell utility.
_______________________________________________
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".
