"Too short" message on perfectly good files

[eumagga0x2a]

Code Select Expand

Percent:7
[adm_lavLogCallback] 19:08:25-205 [lavc] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 31882000 >= 31882000
[FF]Error writing video packet

As expected, duplicated decode timestamps, caught by the bundled FFmpeg which gets actually used when you select MP4 as muxer.

By the way, it doesn't look easy to communicate relevant FFmpeg messages to the user, at least without further going into patching the bundled FFmpeg.

I have samples few MiB in size exhibiting the same problem.

[eumagga0x2a]

Not directly related to the issue, but why do you use 32 bit Avidemux on a 64 bit Windows? With 64 bit, you could use DXVA2 hardware accelerated display, on Windows > 7 with some luck also decoding.

[TCmullet]

Not directly related to the issue, but why do you use 32 bit Avidemux on a 64 bit Windows? With 64 bit, you could use DXVA2 hardware accelerated display, on Windows > 7 with some luck also decoding.

Because (1) up til a few years ago when I gained one PC with 64-bit i5 and 64-bit Windows, all my other systems were WinXP-32bit whether 32-bit PC or not.  And (2), I got advice from various boards suggesting to keep all video tools 32-bit, as many of the 64-bit ones (filters, programs, etc.) were not as bugfree as the 32-bit.

I don't know what  DVXA2 is, but I don't see why accelerating the display is relevant to an editing program such as Avidemux.  The display window doesn't have to look like a hi-res TV; only has to show me what frame of video I'm on.

[TCmullet]

Code Select Expand

Percent:7
[adm_lavLogCallback] 19:08:25-205 [lavc] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 31882000 >= 31882000
[FF]Error writing video packet

As expected, duplicated decode timestamps, caught by the bundled FFmpeg which gets actually used when you select MP4 as muxer.

I don't begin to claim to know much about FFMpeg, only that it's been around a long time, is a great standalone tool for those hardy enough to get buried in the muck of specifying parameters in an age of GUIs, AND that it's the core driver (or maybe core functionality would be a better term) underlying many GUI-based programs.

I didn't know that AVIDemux was using it for things.  But I DO know that Replay Video Converter (from Applian), the program that created my file, DOES use FFMpeg to generate/encode to H.264 this file.  So on the surface, I want to ask, how is it that FFMpeg could generate encoded video that would cause an error when the same program (FFMpeg) is used to read the file??

I'd like your thoughts on that, please.  I did google much of the big phrase and found that this has been going on a long time, and that supposedly a bug-ticket has long since been filed with FFMpeg.  But I'll make one more observation...

In this thread,
https://superuser.com/questions/978888/application-provided-invalid-non-monotonically-increasing-dts-in-ffmpeg

the answer given is, "If the files play fine, you don't have to worry about it.  It means that in the input file, the timestamps associated with samples are not increasing monotonically. That shouldn't be the case, but I think that ffmpeg will usually correct these problems on its own.  If you are using an outdated ffmpeg version, updating to a newer one may help resolve these issues, in case it's a problem with the decoder rather than the actual input files."

What I want to observe is this:  This reminds me of what I read about Mpeg encoding years ago with regard to B-frames.  I thought I read it in connection with Mpeg4 (H.264, et al), but it may have been referring to Mpeg2 as well.  The B-frames (as I'm sure you know) are bi-directional predictors, not just prior-frame predictors like the P frames.  Therefore they can point FORWARD in time as well as backward.  This is what makes them so efficiency-producing.  But one of the points made years ago was that the encoder is not required to always write out the frames in chronological order.  As long as the PTSes (presentation timestamps) or DTSes (display timestamps, apparently they are synonyms) are properly attached to the frames to which they belong, it shouldn't matter what order they are written out in.  It's the job of the decoder to decode all the frames within a GOP and then SORT them into timestamp order for output to the player.  So, given this concept, why does any player or muxer care that the frames are not in order?  With regard to a muxer, I would think it's job is to simple shove the GOP out the door.  I'll appreciate any explanation you could give.   (And that's enough questions for one posting.)

[TCmullet]

I have samples few MiB in size exhibiting the same problem.

Could you please tell how you solve that problem?  That is, how do you reclaim the file, shuffling in whatever way necessary BUT WITHOUT reencoding?  Is there an FFMpeg command that (again, without reenoding) will shuffle things back into proper order so that FFMpeg inside of AVD will not barf at it??

[eumagga0x2a]

Your sample would still be warmly welcome. I don't have a full solution for now. In my sample, the DTS collision happens due to rounding by Avidemux (timestamps are still increasing in the sample, but the values are very close; when rounded, they become identical).

With the rounding logic commented out, saving the sample in copy mode still fails later due to a real DTS collision, which mostly points at a too high frame increment value got by the demuxer.

[eumagga0x2a]

I don't know what  DVXA2 is, but I don't see why accelerating the display is relevant to an editing program such as Avidemux.

This massively saves CPU cycles for stuff like scaling. I'm not sure whether this works with the DirectX video acceleration version 2.0, but with decoding in hardware enabled, it should short-circuit decoding and display, avoiding downloading vast amount of data from the graphics card to the RAM and uploading it back.

[TCmullet]

I don't know what  DVXA2 is, but I don't see why accelerating the display is relevant to an editing program such as Avidemux.

This massively saves CPU cycles for stuff like scaling. I'm not sure whether this works with the DirectX video acceleration version 2.0, but with decoding in hardware enabled, it should short-circuit decoding and display, avoiding downloading vast amount of data from the graphics card to the RAM and uploading it back.

Again, I don't see what this has to do with Avidemux when in "copy/copy" mode.  It sounds like you're talking about when ADM is H264 encoding or other number crunching.  But in copy/copy, the video and audio streams are not being decoded or encoded; just mixed (muxed) together on output.  No video is being displayed while muxing.

[eumagga0x2a]

Sure, hardware accel is relevant for tasks like identifying suitable positions for the markers, not for saving in copy mode.

It would be beneficial for solving the issue you raised here if you finally provide a sample video.

Thanks.

[eumagga0x2a]

@TCmullet, you could test the latest win64 nightly. The latest changes in the code should have made it more tolerant to timestamp errors  and the "The video has been saved but seems to be incomplete" error has been altered to provide at least the linear time of the location where the muxer had to bail out.

[TCmullet]

Hey, I want to say that I just recently changed from using 2.7.0 32-bit to 2.7.1 64-bit.  I am THRILLED that "too short" no longer appears!  This has opened worlds to me in what I can do now!  Thank you to whoever fixed that!  Notorious for creating files that would trigger the error was Applian's Replay Media Converter, which I wanted to use a lot.  I wanted to create files with it, THEN use ADM for various things.  Now I can!  Also nifty is the mild "deep six" it goes into to rebuild PTSes from defective videos. Ran into a bunch of these from a source long ago.  Interestingly it warns "this could take a while".  For me it has never taken more than about 6 minutes for about 2 hr HD video.  But the big issue is the "too short".  NOW, the only time that should happen is when you run out of output disk space, ha ha!