V2.6.14 hangs after error message while copying Mpeg2

[TCmullet]

Was on 2.6.8.  Had problem.  Upgraded to 2.6.14 after uninstalling 2.6.8.  Have same problem.  I am doing "copy/copy" of Mpeg2 program stream, free format.  At a point very early in the show (6 min. into 90 min. show), it gives the ubiquitous "Too short" message.  However, Avidemux doesn't stop, but seems to hang.  I "okay" the "too short" window, but the progress window is still there, albeit not doing anything.  It does give the "(not responding)" in the "Encoding" title bar.  It does not allow a graceful shut down.   (Of course there's still the trigger problem of why it's "giving up" and saying "too short", which would be nice to solve.  I DID try cutting out a couple of GOPs around the point in question, but no difference.)

[Jan Gruuthuse]

Delete the config2 file, somewhere in avidemux related user folder: ..\AppData\Roaming\avidemux\
You did delete the old .idx2 files?
Try again.
If not working with 2.6 branch try with 2.5.6 https://sourceforge.net/projects/avidemux/files/avidemux/2.5.6/

[eumagga0x2a]

I am doing "copy/copy" of Mpeg2 program stream, free format.  At a point very early in the show (6 min. into 90 min. show), it gives the ubiquitous "Too short" message.

Does this happen with one particular video or generally with mpeg2 videos? Do ffplay or mplayer play the video without issues? If it is just one video, please upload a sample from the beginning of the file more or less beyond the spot which makes problems to a publicly accessible service like e.g. WeTransfer. At 5000 kbit/s 250 MiB should be enough, but please check the total bitrate first.

[TCmullet]

I am doing "copy/copy" of Mpeg2 program stream, free format.  At a point very early in the show (6 min. into 90 min. show), it gives the ubiquitous "Too short" message.

Does this happen with one particular video or generally with mpeg2 videos? Do ffplay or mplayer play the video without issues? If it is just one video, please upload a sample from the beginning of the file more or less beyond the spot which makes problems to a publicly accessible service like e.g. WeTransfer. At 5000 kbit/s 250 MiB should be enough, but please check the total bitrate first.

It's the first time I'm using Avidemux with an Mpeg2 file and it's one I captured from live streaming.  Also it's 13 GB, so probably prohibitive to upload.  "Upload a sample"??  To do that I'd have to use Avidemux to chop it and it's this very process where the bug is that is keeping me from doing this!  I'm trying to trim off junk from the start and end, then save the file.

[TCmullet]

Delete the config2 file, somewhere in avidemux related user folder: ..\AppData\Roaming\avidemux\
You did delete the old .idx2 files?
Try again.
If not working with 2.6 branch try with 2.5.6 https://sourceforge.net/projects/avidemux/files/avidemux/2.5.6/

I did find the config2 there, as well as config3.  I deleted config2, and restarted AviD.  I didn't have an idx, but as I recall, I had created one under 2.6.8.  The instructions for 2.6.14 said to uninstall any prior version which I did.  It did not say to delete .idx files.  I DO remember in the past that the idx format changed. AviD would give an error if I opened the old idx.  In any case, now I created a new .idx after deleting config2.  It still bombs with the error message, "Too short:  The video has been saved but seems to be incomplete."  And most importantly, the program does not end.  The copy/copy window is still there.  I can drag it around, but it still says "(not responding)".

Regardless of what the "too short" problem is, it's still a bug that AviD does not return to wait-state at all, but stays "operating", i.e., stuck.

Now I have a more severe problem to me.  But it's partly covered in an older thread which happened to be started by me.  I'll post info there.

[TCmullet]

Another VERY odd quirk about this process of copy/copy of Mpeg2 exists.  Normally my .M2TS files do a copy/copy VERY quickly, hundreds of frames per second.  When this Mpeg-PS stream copy/copy runs, it starts out very slow, maybe around 40 fps, but by the time the "too short" message happens (which is in both 2.6.8 and 2.6.14), it's gone way down to about 8 fps.  WHY?

[Jan Gruuthuse]

now I created a new .idx after deleting config2.  It still bombs with the error message, "Too short:  The video has been saved but seems to be incomplete."

- idx is from 2.5.6 branch, the files needing deleting are .idx2
- try re-muxing the video with mkvtoolnix gui and see if loading the mkv does help.

[Jan Gruuthuse]

Another VERY odd quirk about this process of copy/copy of Mpeg2 exists.  Normally my .M2TS files do a copy/copy VERY quickly, hundreds of frames per second.  When this Mpeg-PS stream copy/copy runs, it starts out very slow, maybe around 40 fps, but by the time the "too short" message happens (which is in both 2.6.8 and 2.6.14), it's gone way down to about 8 fps.  WHY?

You could have memory issues (ram/hard disc), see if a memory cleaner like ccleaner helps?
Hard disk has errors on it? ageing, defects  ...

[eumagga0x2a]

"Upload a sample"??  To do that I'd have to use Avidemux to chop it

No, no, no. Doing this would make the sample useless. Use a tool like dd

Code Select Expand

dd if=/path1/to/the/source/video of=/path2/to/output/sample bs=1M count=250

to copy the first 250 MiB of the file "video" in folder /path1/to/the/source (e.g.) to the file "sample" in the folder /path2/to/output (e.g.). Avidemux wiki suggests VirtualDub for this purpose on Windows, but you could also use dd in a ported Unix environment like Cygwin.

Can you play this video transport stream with other FFmpeg-based software like ffplay, mplayer or VLC without issues?

[AQUAR]

Most windows based users of ADM would only know about Cygwin or MSYS if they have an interest in running a POSIX environment on windows.
A free file splitter like HJSplit would probably work - split the video into small parts (100 MB or so) and keep/post the first part.

PS:
ADM endusers may not know what a MiB is.
MiB is short for Mebibyte (a unit of binary multiples of bytes).
1 MiB equals 1024 Kibibytes or 1,048,576 bytes (1024X1024).

[fish]

I have encountered this problem occasionally, admittedly not with mpeg files as I have other software that I would use for that. The symptoms you give are what I have experienced with mp4 files occasionally. I have found that cutting the video into 2 or more parts, having made the edits required to each part separately and saved them. The first part should end one frame before the last I-frame, of the 'too short' video ends. The next part should start at that I-frame. This process may need repeated if the second part is also too short and so on until all the parts make up the whole length you want. Then join those parts. It may take a few attempts, choosing different durations for the various parts. 
It may seem like a stupid question but of course you are sure you have enough free drive space to receive and process such a large file? (just asking)

Edit: I have just read your first post again and although I have had the approximate message of 'video too short' Avidemux doesn't hang, it simply saves a video that is shorter than intended and I can the ok the warning. Everything else happens as normal.
From memory I think this 'video too short' has only happened with video that has already been edited and is being re-edited, must keep an eye out for that.

[eumagga0x2a]

A free file splitter like HJSplit would probably work - split the video into small parts (100 MB or so) and keep/post the first part.

Thank you for your input. Windows' software ecosystem is too alien to me. Chunk size of 100 MiB would be probably too small though.

ADM endusers may not know what a MiB is.

They may be excused as Microsoft seems not to know what a MB is ;-)

[AQUAR]

Windows' software ecosystem is too alien to me

M$ Windows is very much more supported and user friendly to typical users of computers.
Not saying its a better operating system though than Unix types.

I use Linux as well but find many things about it "simply frustrating".
 

[Jan Gruuthuse]

End user: Windows is kind of addiction: old habits don't die. Switching to linux after working windows for ages causes adaptation issues.

[AQUAR]

Sorry Jan,

But linux has always had issues in terms of "ease of use" for the average end user.
The average end user of an OS is not interested in anything much deeper than Installing a program, Finding a program and Running a program.
In each of these categories, windows performs these tasks easier and quicker.

Installing a program is a  single, all inclusive step on windows - not so with the different distributions approach of Linux.
Finding a program is simple on windows, its found in the installation folder, and that is easily locatable in a "logically sensible to the average user" linear virtual directory structure.
Running a program is easy on windows, just one click to create a shortcut to it on the desktop.

None of these easy to use attributes (basically GUI aspects!) say anything about the strength - stability - flexibility - safety etc of the underlying OS. No doubt Linux/Unix is the better OS, but only for the geeks.

I do run both these OS's:
For security reasons all my online banking is done with a version of macpup that I've reworked to be totally non-persistent.
For shear program variety and support, only windows makes the cut (at a $ price of course!).

There's a joke: Linux is user friendly, it's just very picky about who its friends are.