On Wed, Oct 25, 2017 at 4:59 AM, Michael Niedermayer <mich...@niedermayer.cc
> wrote:
> On Tue, Oct 24, 2017 at 06:42:54PM -0700, Thierry Foucu wrote:
> > Changed the return value when no VOD were encoded in Mpeg4 bistream.
> > And if we do have already a decoded frames and we are not in xvid_packed
> > mode, output the existing decoded frame instead of nothing.
> > ---
> > libavcodec/h263dec.c | 9 ++++++++-
> > libavcodec/mpeg4videodec.c | 2 +-
> > libavcodec/mpegutils.h | 1 +
> > 3 files changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
> > index c7cf4bc0c2..394a366f9c 100644
> > --- a/libavcodec/h263dec.c
> > +++ b/libavcodec/h263dec.c
> > @@ -506,8 +506,15 @@ retry:
> > s->height= avctx->coded_height;
> > }
> > }
> > - if (ret == FRAME_SKIPPED)
> > + if (ret == FRAME_SKIPPED || ret == FRAME_NOT_CODED) {
> > + if (s->next_picture_ptr && ret == FRAME_NOT_CODED &&
> !s->divx_packed) {
> > + if ((ret = av_frame_ref(pict, s->next_picture_ptr->f)) < 0)
> {
> > + return ret;
> > + }
> > + *got_frame = 1;
> > + }
> > return get_consumed_bytes(s, buf_size);
> > + }
> >
> > /* skip if the header was thrashed */
> > if (ret < 0) {
> > diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
> > index 82c4f8fc8c..3a9ed12971 100644
> > --- a/libavcodec/mpeg4videodec.c
> > +++ b/libavcodec/mpeg4videodec.c
> > @@ -2394,7 +2394,7 @@ static int decode_vop_header(Mpeg4DecContext
> *ctx, GetBitContext *gb)
> > if (get_bits1(gb) != 1) {
> > if (s->avctx->debug & FF_DEBUG_PICT_INFO)
> > av_log(s->avctx, AV_LOG_ERROR, "vop not coded\n");
> > - return FRAME_SKIPPED;
> > + return FRAME_NOT_CODED;
> > }
> > if (ctx->new_pred)
> > decode_new_pred(ctx, gb);
>
> the return codes are documented currently:
> * @return <0 if no VOP found (or a damaged one)
> * FRAME_SKIPPED if a not coded VOP is found
> * 0 if a VOP is found
>
> you added a case but did not update all use cases
>
>
I can update the text here. But i was waiting to get some idea if the patch
seems to be ok for all of you or not.
If the idea sounds ok, I will update it.
> which seems to
> lead to intermittent crashes (i cant say for sure as i failed to
> reproduce one in a debugger or with any debuging code added)
>
>
i tried some files here and could not get any crash so far. I used asan as
well to find out if something was wrong.
> Also returning frames for skiped frames when te match the previous
> would slow the code down as more frames would need to be processed.
> more so i think this is not the only codec that can skip frames
> so any downstream problems will likely not be worked around by forcing
> constant fps with frame duplication here
>
>
True, but the decoder does not return a frame, so the got_output is set to
false for those packets and in this case, we are not increasing the
ist->next_pts
So, in we do have a lot of n_vop frame at the end, we are not setting the
next_pts to them and when we are closing the filtergraph, we are setting
the EOF time to the last decoded frame. And so, we are not padding the
video to match the original timestamp/duration of the input.
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> It is what and why we do it that matters, not just one of them.
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
