On Tue, 29 Aug 2017 15:11:55 +0200 Jorge Ramirez <jorge.ramirez-or...@linaro.org> wrote:
> On 08/25/2017 05:35 PM, wm4 wrote: > >> +static inline void set_pts(V4L2Buffer *out, int64_t pts) > >> +{ > >> + if (pts == AV_NOPTS_VALUE) { > >> + /* invalid timestamp: not sure how to handle this case */ > >> + out->timestamp.tv_sec = 0; > >> + out->timestamp.tv_usec = 0; > >> + } else { > >> + AVRational v4l2_timebase = { 1, 1000000 }; > >> + int64_t v4l2_pts = av_rescale_q(pts, out->context->time_base, > >> v4l2_timebase); > >> + out->timestamp.tv_sec = v4l2_pts / INT64_C(1000000); > >> + out->timestamp.tv_usec = v4l2_pts % INT64_C(1000000); > >> + } > >> +} > > Why does it require a fixed timebase? A decoder shouldn't even look at > > the timestamps, it should only pass them though. Also, not using DTS > > will make it a nightmare to support containers like avi. > > > > I suspect the decoder tries to "fix" timestamps, or maybe even does > > something particularly bad like reordering frames by timestamps. This > > is NOT something that should be in a kernel API. > > > > (FFmpeg native decoders_and_ hwaccels pass through both PTS and DTS, > > and don't touch their values.) > > > > ok I will just pass through the dts/pts and return them unmodified for > decoding and retest. > > what about for encoding? should I just read the pts from the driver, > rescale it back to time_base and set both pts&&dts on the returned > packet to the this same value? > > after this I think I am ready to post v7 with all the review comments > addressed so thanks a lot for all the responses! Things are different from encoders. These should synthesize correct pts and dts from the pts set on input frames. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel