Hi,
I have been using Avidemux for a long time and have never had any problems. But now I have a problem while opening an mpg-file (error message attached). I hope somebody can help me.
Updating to the latest version didn't help either.
Best regards
Michael
The latest build is from 2019-09-24: https://avidemux.org/nightly/win64/
Did you try it (just to be sure)?
Please rename the corresponding *.idx2 file, let Avidemux re-index the video. If the problem persists, please compress (7z, zip) the new *.idx2 file as well as the corresponding admlog.txt from %localappdata%\avidemux and attach them to your reply.
It may be necessary to have a look at the .mpg video itself later in the process.
Yes, I have used the latest build.
I could only attach the log, the packed idx2 file is too large (8 MB). The corresponding MPG file has a size of 20 GB (a record from a whole night). However, the large size has never caused any problems.
Best regards
Michael
Would you please upload the compressed *.idx2 file to a service like WeTransfer, Mega, Dropbox or Google Drive?
The size and the duration of the source video is really huge, maybe we do hit some internal limits.
Thank you for the log and the index file, will try to look into the latter soon.
If you have a text editor capable to handle files that large and able to preserve unix-style line endings (LF instead of CR+LF), you could copy the end of the index
# Found 1019367 images
# Found 1019367 frame pictures
# Found 0 field pictures
[Video]
Width=720
Height=576
Fps=25000
Interlaced=0
AR=3
[Audio]
Tracks=1
Track0.pid=c0
Track0.codec=80
Track0.fq=48000
Track0.chan=2
Track0.br=24000
[End]
to a different file, delete e.g. the half of the index (always pairwise the lines starting with "Audio:" and "Video:"), then append the end of the index and see whether the problem is located in the second half of the index.
We crash reading the entry 6476 from the index. As suspected, the max line length of 2000 chars allocated is too small, this happens at line 12961 of the index.
If I delete the first 15,000 lines, it'll work. I can work with it for now.
Thank you very much for the quick help!
Best regards
Michael
Fix upcoming.
Should be fixed by [demuxers/MpegPS] Increase max video index entry length, fix NULL pointer dereference from a truncated entry (https://github.com/mean00/avidemux2/commit/2c6756f0add3be4038cb8af4fa4879185088c8dd), please try a future nightly.
Thank you for your report.
Fresh nighly builds have been uploaded, please try a 191003 one --> https://avidemux.org/nightly/win64/
Yeah, it's working. But now there is a new problem. Saving doesn't work anymore (already with the last nighly build).
The following message appears:
More info, please (admlog.txt).
as requested
[open] 15:51:15-249 [Mkv]: Failed to open file ://192.168.101.22/Public/Media/Pub_Videos/Test.mkv, er=-2
This looks like the destination were a network drive. I'm not sure this is supported by Avidemux (the only protocol enabled in the internal libavformat is the file protocol). Please retest with a local output target.
Right, that's a NAS. But it still worked with version 2.73. Local saving also works with the latest nighly build.
It would be a pity if functionalities that once worked were removed.
Best regards
Michael
Nothing was changed regarding supported protocols in bundled FFmpeg. The FFmpeg itself was updated numerous times, however. Can you reproduce Avidemux VC++ or MinGW 2.7.3 successfully saving to MKV (or MP4) on that NAS right now?
No problem, still works - see attachment.
Thanks, I forgot that we don't print the output filename and path in case of success.
I wonder wether this could be a regression from the patch [ffmpeg] Update patch for libavutil/file_open.c to fix '-movflags faststart' option in MP4 muxer on Windows (https://github.com/mean00/avidemux2/commit/c8c05ee55882e1001a1627a54ea2b79936b0b902#diff-a1f9456ee33c93730824fd7fc0a3f163) which allowed to optimize MP4 files for streaming on Windows too.
If the problem affects also the 32 bits version, where FFmpeg stays at 3.3.9 – the last version compatible with Windows XP – then it is very likely that this patch is the culprit. Even when so, I won't backout it to fix a rarely used feature by breaking a highly needed one (this doesn't mean that a better fix will be ruled out in the long term, of course).
The above means that your test with the latest 32 bits nightly would be appreciated.
QuoteThe above means that your test with the latest 32 bits nightly would be appreciated.
I already understood that, but of course I still have a life next to the Internet. ;)
I just tried it. No even with the current 32 nightly build saving to a network drive does not work. So it seems to have another cause.
Best regards
Michael
Quote from: DerAndereMicha on October 06, 2019, 08:00:37 AM
I just tried it. No even with the current 32 nightly build saving to a network drive does not work.
Thank you, this means that the patch which fixed the "-movflags faststart" option for mp4 is almost for sure at fault here. I'll return to this issue at some point in the future (and I'll need to setup some sort of a network drive to test it in the first place). In any case, even if saving to a NAS gets fixed, I would recommend to use fast local storage for output.
Thanks, then I'll just use the old version.
To gather info for future investigation of the issue, could you please try during a brief internet moment a non-libavformat-muxer (MP4v2, still available in MinGW builds, or AVI) with output file on your NAS?
(Using 2.7.3 and then 2.7.5, release or nightly)
I have neither MP4 nor AVI as output format, no matter which input format I use.
What's a MinGW build?
The output format (container type) does not depend on the source video container apart from usual codec compatibility considerations (e.g. you can't mix HuffYUV into WebM and AVI is a bad choice for anything newer than DivX/mpeg4).
You set output container in the dropdown menu below the menu for audio codec. MKV is the default, other muxers can be selected.
MinGW is a compiler able to produce Windows binaries on Linux. Windows builds of Avidemux releases up to 2.7.1 were built on Linux with MinGW, from 2.7.2 on they are generated with Microsoft Visual Studio C++ on Windows. MinGW builds are still available as nightlies.
VC++ builds don't include the libmp4v2-based MP4v2 muxer for mp4.
QuoteYou set output container in the dropdown menu below the menu for audio codec. MKV is the default, other muxers can be selected.
I think I'm too stupid to find it. I don't have a dropdown menu like this, I have only a combobox in the save dialog.
How do I recognize the MinGW builds at www.avidemux.org/nightly/ ?
Please look at the old official screenshot http://fixounet.free.fr/avidemux/index_files/screenshot1.png – do you see the bold label "Output Format" in the half-bottom part on the left side (in the area of the codec widget) above a combobox which is on the screeshot set to "Mkv Muxer"?
This label is "Ausgabeformat" in the German translation.
Please click on "Mkv Muxer" in your Avidemux window and select either "AVI Muxer" from the dropdown menu or "MP4v2 Muxer" (if you are going to test saving a H.264 or HEVC sample to NAS, requires an Avidemux build without "VC++" in installer name).
"FLV Muxer", "MP4 Muxer", "Mkv Muxer", "Mpeg TS Muxer (ff)" and "Mpeg-PS Muxer (ff)" all use the same bundled libavformat. The purpose of this test is to find out how other muxers,
not based on libavformat, fare saving to NAS in the transition from Avidemux 2.7.3 to 2.7.5.
Quote from: DerAndereMicha on October 07, 2019, 03:51:25 PM
How do I recognize the MinGW builds at www.avidemux.org/nightly/ ?
https://avidemux.org/nightly/win64/ (git master, 64 bits)
and
https://avidemux.org/nightly/win32/ (legacy-compat branch, 32 bits, old compiler, old Qt for Windows XP compatibility).
VC++-built nightlies are in https://avidemux.org/nightly/vsWin64/
QuotePlease look at the old official screenshot http://fixounet.free.fr/avidemux/index_files/screenshot1.png – do you see the bold label "Output Format" in the half-bottom part on the left side (in the area of the codec widget) above a combobox which is on the screeshot set to "Mkv Muxer"?
Oh, God, I was really blind. Sorry!
Here my test results:
2.7.3 Release 64bit - "Mkv Muxer" - save to NAS works
2.7.3 190727 64bit VC++ - "Mkv Muxer" - saving to NAS does not work
2.7.3 190727 64bit VC++ - "AVI Muxer" - save to NAS works
2.7.5 191005 64bit VC++ - "Mkv Muxer" - saving to NAS does not work
2.7.5 191005 64bit VC++ - "AVI Muxer"- save to NAS works
2.7.3 190727 64bit - "Mkv Muxer" - saving to NAS does not work
2.7.3 190727 64bit - "AVI Muxer" - save to NAS works
2.7.5 191005 64bit - "Mkv Muxer" - saving to NAS does not work
2.7.5 191005 64bit - "AVI Muxer" - save to NAS works
2.7.3 190727 32bit - "Mkv Muxer" - saving to NAS does not work
2.7.3 190727 32bit - "AVI Muxer" - save to NAS works
2.7.5 191005 32bit - "Mkv Muxer" - saving to NAS does not work
2.7.5 191005 32bit - "AVI Muxer" - save to NAS works
For me it looks like saving MKV to the NAS will only work in the release version 2.7.3. All versions after that - no matter if with or without VC++ don't work.
Best regards
Michael
Wow, thank you very much for this extensive testing. The results match the hypothesis that the patch from 2019-04-19 which fixed moving the index in mp4 to the start of the file has caused the failure saving to shares.