On Fri, 31 Mar 2017 03:49:16 +0200 Michael Niedermayer <mich...@niedermayer.cc> wrote:
> On Thu, Mar 30, 2017 at 05:05:36PM +0200, wm4 wrote: > > Not sure if it behaves ideally in presence of decoding errors. > > --- > > The original version of this patch is actually 1 year old. > > --- > > ffprobe.c | 42 +++++++++++++++++++++++++++++------------- > > 1 file changed, 29 insertions(+), 13 deletions(-) > > changes: > http://samples.mplayerhq.hu/A-codecs/WMA/wav/FLCL_Ending_My.wav > ./ffprobe -v 0 -show_frames -of compact=nk=1:p=0 > ~/tickets/1905/FLCL_Ending_My.wav > > after the patch there are alot of "N/A" in the output where numbers > where before This is just what the API returns. It has nothing to do with this patch. One packet results in multiple frames in this case, and with the new decode API, the timestamp fields in subsequent frames have the timestamp fields unset, while the old API duplicates the ones from the first frame of a packet. This in turn happens because the "emulation" code in utils.c resets the timestamps on subsequent frames explicitly: avctx->internal->buffer_pkt->pts = AV_NOPTS_VALUE; avctx->internal->buffer_pkt->dts = AV_NOPTS_VALUE; So this is very much by design, and I think the result with the new API is better too. (Old API users probably had to explicitly handle this case themselves, because nobody wants non-increasing timestamps.) _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
