Re: [FFmpeg-devel] [PATCH 1/2] avformat/avformat: Introduced `AVInputFormat.read_timestamp2` to fix keyframe seeking for formats that rely on `read_timestamp` for seeking
I think I understand some of what you are saying. You are saying that after the bisection, continuously step backwards + read forward while doubling the step size until the keyframe is found? Some questions: - What is the difference between the lowercase k and the uppercase K in your diagram? And to make sure I didn’t misunderstand, v is the result of the bisection and A/B/C indicate the steps? - Why after finding the keyframe in step C, is there an extra -->? - Re: “there is code somewhere in git to do something similar already”, do you have an idea of what I should search for to find this code? Thanks! > On Sep 3, 2019, at 4:39 AM, Michael Niedermayer > wrote: > > stepwise searching for the keyframe in forward direction while taking steps > backward > ..k.K.v-start > A---> >B---> >C>k-K--> > > there is code somewhere in git to do something similar already > this should be faster than always searching for keyframes during bisection as > long as the initial step is reasonable in relation to the keyframe distance > > also as both approaches are quite similar one could even choose which > way to do it depending on the expected cost of seeks and bandwidth and > if some statistics on the keyframe distance are known and or the > search direction > > thx > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > There will always be a question for which you do not know the correct answer. > ___ > 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". ___ 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".
Re: [FFmpeg-devel] [PATCH 1/2] avformat/avformat: Introduced `AVInputFormat.read_timestamp2` to fix keyframe seeking for formats that rely on `read_timestamp` for seeking
Yup! I just wanted to do the migration in phases rather than all at once so that I can do one demuxer at a time while gathering feedback. At the end of the migration, I’ll rename `read_timestamp2` to `read_timestamp`. > On Sep 2, 2019, at 1:07 PM, James Almer wrote: > > AVInputFormat.read_timestamp() is not a public field. There's no need to > deprecate it and add a replacement. Just change it as you see fit, > making sure to update all demuxers that may use it. > ___ > 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". ___ 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".
Re: [FFmpeg-devel] [PATCH 1/2] avformat/avformat: Introduced `AVInputFormat.read_timestamp2` to fix keyframe seeking for formats that rely on `read_timestamp` for seeking
That’s true. However, I think your approach would produce incorrect results when `AVSEEK_FLAG_BACKWARD` is used. The bisection would find the frame just before the target time and then we would search for the next keyframe, which would be after the target time. Instead, we want to return the keyframe just before the target time. Any ideas on how to do that more efficiently? > On Sep 2, 2019, at 7:33 AM, Michael Niedermayer > wrote: > > i think this is the wrong way to fix the issue unless iam missing something > > Bisecting on only keyframe packets needs to read > framesize * goplength * log(all frames) > Bisecting on any frame and only at the end searching for the next keyframe > needs > framesize * (log(all frames) + goplength) > that is more than an order of magnitude less data to read even with > small gop sizes > > Thanks > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > No human being will ever know the Truth, for even if they happen to say it > by chance, they would not even known they had done so. -- Xenophanes > ___ > 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". ___ 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".
Re: [FFmpeg-devel] Patchwork: how to reset password?
I have the same problem. Hopefully someone with access is able to fix it. > On Jul 26, 2019, at 4:38 AM, Andreas Håkon > wrote: > > Hi, > > I'm sorry to post this on this mailing list. However, I need to clean my > patches > on the Patchwork's FFmpeg server, but the "Reset Password" service doesn't > seem to work. After days of selecting the Reset Form with the correct email > address (if I try to register again, the email address is in use), I never > received > any email (I've also checked for the Spam folder). > > So, please, can anyone verify it? > Thank you. > A.H. > > -- > ___ > 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". ___ 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".
Re: [FFmpeg-devel] [PATCH] avcodec/decode: Do not output subtitle frames if the packet is marked with `AV_PKT_FLAG_DISCARD`.
To clarify, do you mean we should merge this now or wait for the second patch, which fixes the root cause? > On May 23, 2019, at 10:12 AM, Derek Buitenhuis > wrote: > >> On 22/05/2019 18:55, Darren Mo wrote: >> Good question. The subtitle would be discarded if it overlaps an edit >> boundary. >> >> The root cause is the MOV demuxer currently marks boundary packets for >> discard. However, due to subtitle frames not being discarded (fixed by this >> patch), the root cause is hidden. A potential fix for the root cause would >> be to handle boundary packets by changing their timestamps to fit the edit >> boundary. (That would be a separate patch though.) > > As a start, this patch seems reasonable then... > > - Derek > ___ > 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". ___ 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".
Re: [FFmpeg-devel] [PATCH] avcodec/decode: Do not output subtitle frames if the packet is marked with `AV_PKT_FLAG_DISCARD`.
Good question. The subtitle would be discarded if it overlaps an edit boundary. The root cause is the MOV demuxer currently marks boundary packets for discard. However, due to subtitle frames not being discarded (fixed by this patch), the root cause is hidden. A potential fix for the root cause would be to handle boundary packets by changing their timestamps to fit the edit boundary. (That would be a separate patch though.) > On May 22, 2019, at 10:30 AM, Derek Buitenhuis > wrote: > >> On 29/04/2019 23:45, fumoboy007 wrote: >> One situation where a subtitle packet can be marked for discard is when >> demuxing an MOV file that has an edit list. >> --- >> libavcodec/decode.c | 10 -- >> 1 file changed, 8 insertions(+), 2 deletions(-) > > Will this work properly if a given subtitle overlaps an edit boundary? > > - Derek > ___ > 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". ___ 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".
Re: [FFmpeg-devel] [PATCH] avcodec/decode: Do not output subtitle frames if the packet is marked with `AV_PKT_FLAG_DISCARD`.
Bump.
> On Apr 29, 2019, at 3:45 PM, fumoboy007 wrote:
>
> One situation where a subtitle packet can be marked for discard is when
> demuxing an MOV file that has an edit list.
> ---
> libavcodec/decode.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 6c31166ec2..204bd50fa3 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1149,8 +1149,14 @@ int avcodec_decode_subtitle2(AVCodecContext *avctx,
> AVSubtitle *sub,
> }
> }
>
> -if (*got_sub_ptr)
> -avctx->frame_number++;
> +if (*got_sub_ptr) {
> +if (avpkt->flags & AV_PKT_FLAG_DISCARD) {
> +*got_sub_ptr = 0;
> +avsubtitle_free(sub);
> +} else {
> +avctx->frame_number++;
> +}
> +}
> }
>
> return ret;
> --
> 2.21.0
>
___
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".
