Hi all,
I have missed a few versions but recently upgraded from 2.6.10 (150723_efbeb572fce) to 2.6.15 (Win 32). I completely uninstalled 2.6.10 before then installing 2.6.15.
When I now do a two-pass recode with x264, the first pass "time remaining" indicator behaves strangely. Sometimes it reaches zero much too soon, more often it shows zero from the outset and never changes. Meanwhile the "Elapsed" indicator does not freeze, but shows a very large number many times greater than the real time elapsed. I don't recall this ever happening with 2.6.10.
The first pass % complete indicator does not seem to be affected, and works normally. The second pass "time remaining" is working too. The output is fine provided the program does not stop responding. The problem is therefore somewhat cosmetic and perhaps not worth mentioning except that AviDemux also now stops responding quite often while encoding (not every time, and not at the same point in the recode [for a given file] every time when it does happen), whereas with 2.6.10, I can hardly ever remember it stopping responding. I wondered whether the two things might be related.
I also wondered whether this might be simply down to my settings, and I have done the best I can in trying to set the decoding to DXVA2 as instructed on the website. Unfortunately my knowledge of windows codecs, opengl, DXVA and so on is next to non-existent so really it's just guesswork.
The program is still usable, but I often have to take several attempts at a file before I can get it to run right through without stopping responding. I have no hardware changes since 2.6.10.
Sorry to raise something that is relatively trivial, but if anyone could offer any suggestions as to settings that might improve the situation then that would be greatly appreciated.
As ever, thanks for this wonderful software.
You did switch to latest 2.6.15 from November 24th 2016 found @ http://www.avidemux.org/nightly?
Many thanks. The version I was running was downloaded from the download link (http://fixounet.free.fr/avidemux/download.html) via Fosshub on 24th Nov. I have now uninstalled, followed your link to the nightly builds and reinstalled r161124. I am pleased to report that the weird pass 1 time remaining problem has been cured. I'll report back on the "stops responding" problem if it continues. Thanks again.
For completeness/information only: recode of HD video now works fine with hardware acceleration (DXVA2) decoding on. For some reason encoding of standard definition almost always stops responding with the same settings. With hardware acceleration completely off, however, SD is fine. No need to follow up, I am happy with hardware acceleration off, I am posting this just for information in case anyone else is having the same problem with SD, in which case turning off hardware acceleration is worth a try.
your SD are mpeg2 or h264 ?
mpeg2.
Sadly, my initial success at recoding HD video with x264 on 2.6.15 must have been down to luck. Now that I have done a greater volume my success rate is rather hit-and-miss before Avidemux stops responding. The best combination of settings seems to be to use DXVA2 decoding (and same display driver). I have tried direct3d, direct3d11, opengl and 'software' for the sdl driver, but this doesn't seem to make any difference one way or the other (perhaps that is what you would expect - I'm afraid have no idea what this setting is!). Some files do work first time, but sometimes it is the third or fourth attempt before Avidemux gets all the way through any given file without freezing. Remuxing the input file to mkv with MKVToolNix seems to help a bit, but not much. Any further ideas for settings I might change/try would be greatly appreciated.
Please attach a compressed Avidemux log (admlog.txt) from an encoding ending in such a freeze.
Please find attached the log from a test I just did. The first pass was complete and the second pass more than half complete before Avidemux stopped responding. Hope this helps shed some light on the matter.
In the attached log, Avidemux is launched and subsequently closed in a regular fashion ~12 seconds later. No video loaded, nothing encoded and of course no freeze.
maybe 2nd pass is same/similar issue as this: x265 pass 2 failure (http://avidemux.org/smif/index.php/topic,17296.0.html)
diacritic characters, path depth, total length pathname depth + length filename, ...
Apologies, afraid I can't explain that. Perhaps it is because I killed the app with task manager before copying the file. I have run it again, and this time copied the log while the program is showing "not responding" on the screen, but before killing it. The log file is much bigger this time, so I think that has worked. The project (source and settings) was exactly the same as before but this time it stopped responding on the first pass rather than the second. I'm afraid I don't have sufficient technical knowledge to interpret the log, but it looks as though the problem is with the decoding - there are a vast number of error messages. The source is a DVB S broadcast. Despite the trouble with the decoding, the preview looks fine and plays fine on screen in Avidemux, and I can seek through it no problem. The source file plays perfectly in VLC media player. I had already remuxed the source into mkv from the original ts (otherwise the crash tends to happen sooner).
Unfortunately the log file is much too big to attach (45MB), due to the large number of error messages. The last few lines reads as follows:
[DecodeNextPicture] 09:10:29-550 Decoding error for frame 244388, not necessarily a problem
Surface to admImage = 115D1180
Retrieving image pitch=2048 width=1920 height=1080
Align 1080,16 => 1088
[uncompress] 09:10:29-575 [DXVA] --No pictureÂ
[decompressImage] uncompress failed
[DecodeNextPicture] 09:10:29-575 Decoding error for frame 244390, not necessarily a problem
Surface to admImage = 115D0140
Retrieving image pitch=2048 width=1920 height=1080
Align 1080,16 => 1088
[uncompress] 09:10:29-593 [DXVA] --No pictureÂ
[decompressImage] uncompress failed
[DecodeNextPicture] 09:10:29-593 Decoding error for frame 244392, not necessarily a problem
Surface to admImage = 115D1040
Retrieving image pitch=2048 width=1920 height=1080
Align 1080,16 => 1088
There are also a lot of error messages like this, earlier in the file:
[getRecoveryFromSei] 08:28:06-549 Cannot decode SEI
[getRecoveryFromSei] 08:28:06-549 Cannot decode SEI
[getRecoveryFromSei] 08:28:06-549 Cannot decode SEI
[MKV/H264] Frame 58444 is a keyframe
[getRecoveryFromSei] 08:28:06-550 Cannot decode SEI
[getRecoveryFromSei] 08:28:06-550 Cannot decode SEI
Max size of an attachment is 128KB. I have edited the log file by removing thousands of lines of what looks like mere repetition (different frame numbers), then zipped the file. Hopefully this will be sufficient, but it is not the original log file.
Can you state your exact used OS Windows (32-bit)
Is the OS localized? Not using standard English?
- What is device H: ?
- "Avidemux Test 001.mkv" try avoiding spaces in the files
- what is the name of the input file?
- Don't use the root to work in! There are file amount limitations in there. Use different source and destination folder, Use short folder names like /TestOut/ (source videos) and /TestIn/ (target video).
Hi, and thanks once again for looking into this.
OS is Windows 10 Professional (build 14393) 32 bit.
The source file was G:\Avidemux Test 1-002.mkv. The output file was H:\Avidemux Test 001.mkv
G: is Western Digital WDC WD20EARS 2TB
H: is Toshiba X300 4TB
Neither is the root, which is C: (Crucial_CT500MX)
Also an update: out of curiosity I uninstalled 2.6.15 and installed 2.6.11. The "video decoder" on the main screen now reads "Lavcodec RGB". I then ran the same job (same project, same input file, same settings, same filenames) and it worked first time no trouble at all. I am no expert but this suggests to me that decoding with dxva2 is causing the trouble. On the other hand, 2.6.15 crashed even quicker if dxva2 was not used. The 2.6.11 log file still shows the same huge number of errors, but I guess they are being dealt with more gracefully. If dxva2 is the problem, I guess that means Avidemux itself might not be the issue here and hence there is not much you can do. Unless the solution is quick and easy (or just settings) there is no need to take this any further on my account, as I am more than happy with 2.6.11.
Quote from: TimW on December 08, 2016, 12:18:33 PM
The source file was G:\Avidemux Test 1-002.mkv. The output file was H:\Avidemux Test 001.mkv
G: is Western Digital WDC WD20EARS 2TB
H: is Toshiba X300 4TB
Neither is the root, which is C: (Crucial_CT500MX)
G:\ is the root of hard disc WDC WD20EARS 2TB
H:\ is the root of hard disc Toshiba X300 4TB
ssd is setup correctly? no temp writing on (Crucial_CT500MX)
developer(s) could still respond, to the log.
Quote from: Jan Gruuthuse on December 08, 2016, 12:59:35 PM
Quote from: TimW on December 08, 2016, 12:18:33 PM
ssd is setup correctly? no temp writing on (Crucial_CT500MX)
I'm afraid you will have to excuse my ignorance on that point. Are you referring to an Avidemux setting regarding where it stores temporary/work files? Or to something more generic to do with windows? If you can give me a pointer as to what it is I need to check I shall certainly do so.
Quote from: TimW on December 08, 2016, 01:35:12 PM
Quote from: Jan Gruuthuse on December 08, 2016, 12:59:35 PM
ssd is setup correctly? no temp writing on (Crucial_CT500MX)
I'm afraid you will have to excuse my ignorance on that point. Are you referring to an Avidemux setting regarding where it stores temporary/work files? Or to something more generic to do with windows? If you can give me a pointer as to what it is I need to check I shall certainly do so.
In an unrelated topic http://avidemux.org/smif/index.php/topic,17296.0.html (http://avidemux.org/smif/index.php/topic,17296.0.html) 2-pass encoding using the HEVC encoder failed because some code specific to the x265 plugin converted paths to files containing the first pass stats from utf8 to ANSI on Windows in a bad way. This is not what we see here.
Could you please comment on the following?
[updateLoaded] 08:29:53-069 conf updated
[deleteSegments] 08:29:53-069 Clearing a new segment
[addSegment] 08:29:53-070 Adding a new segment
[updateStartTime] 08:29:53-070 Using pts2=00:00:00,320 to get dts, as this video does not start at zero
[addSegment] 08:29:53-070 Adding a new segment
[updateStartTime] 08:29:53-070 Using pts2=00:00:00,320 to get dts, as this video does not start at zero
[addSegment] 08:29:53-072 Adding a new segment
[updateStartTime] 08:29:53-072 Using pts2=00:00:00,320 to get dts, as this video does not start at zero
[addSegment] 08:29:53-076 Adding a new segment
[updateStartTime] 08:29:53-076 Using pts2=00:00:00,320 to get dts, as this video does not start at zero
Adding Filter changeFps -> 5...
[ADM_vf_addFilterFromTag] 08:29:53-085 Creating video filter using tag 5 How do you arrive at this segment layout? Did you append the same file to itself twice? What is the changeFps filter doing here?
Decoding errors might be significant because every second frame fails to decode.
Releases prior to 2.6.15 could not use hardware accelerated decoding and display on Windows, this is why you always see "Lavcodec" as decoder and "RGB" as display with 2.6.11.
There is no direct cue about the reason of the hang in the log IMHO. Maybe the hang is the result of running out of memory due to a memleak? This would explain why it doesn't happen with short videos.
Quote from: TimW on December 08, 2016, 01:35:12 PM
I'm afraid you will have to excuse my ignorance on that point. Are you referring to an Avidemux setting regarding where it stores temporary/work files? Or to something more generic to do with windows? If you can give me a pointer as to what it is I need to check I shall certainly do so.
SSD: https://www.cnet.com/how-to/how-ssds-solid-state-drives-work-increase-lifespan/
Hi eumagga0x2a. I'm really sorry but I'm afraid I don't know what you mean by segment layout. However what I can tell you is that there is no appending going on here, though there is some cutting, to remove adverts. The change fps filter is required because Avidemux incorrectly sees interlaced PAL DVB-S HD broadcast input as being 50 frames per second. In fact such input is 50 fields per second, equating to 25 interlaced frames. If you don't put the change fps filter in there the output comes out as 50 frames ps and this confuses hardware players quite badly as it is not Blu-ray compliant. As a result the encoded files won't play on blu-ray players (though they will usually play in software). The fps filter overcomes this (thanks to Aquar for telling me this). This might be related to why every second frame (or perhaps every second field?) fails to decode? However if the recode does actually finish, the output is 25 frames per second and is fine and plays correctly in both hardware and software. Hope this answers your question. Thanks also for the info about versions - I intend to try v2.6.14 when I get chance, which will give me the most up-to-date version that does not use hardware decoding. Much obliged.
A video is internally represented in Avidemux as a collection of video segments. These segments may originate from the same or from different (but compatible) video files.
The delete operation ("cut" is "copy to clipboard" + "delete", "delete" is just delete) got deleted from the log then :)
If the source is interlaced, you should not reduce fps but insert a deinterlacing filter instead (yadif should be the best). This is computationally very expensive but better than just dropping every second field.
I would strongly advise against any version prior to 2.6.15. You can always disable hw accel (both decoding and display, independently from each other) in 2.6.15, this is not an issue.
edit: Please watch the memory consumption of Avidemux during encoding.
you should use resample fps instead of change fps
Quote from: mean on December 08, 2016, 06:00:13 PM
you should use resample fps instead of change fps
After yadif or just alone? (I don't have 1080i samples to test, unfortunately)
There is usually no need to use a de-interlacer at all if the source is broadcast PAL DVB-S HD interlaced video. If you remove the interlaced flag in Avidemux x264 settings it will produce progressive output anyway. Since broadcast HD PAL video these days is usually artificially interlaced by creating each pair of fields from the same source frame, the resulting progressive frame will be fine. However, if you want it to play back on a Blu-ray player, you then have to also set the "fake interlaced" flag to get the player to play the stream (though some will play it anyway).
As mean says, you do need to use the filter. Apologies if I caused confusion with nomenclature. The filter needed is called "Change FPS". To use this you have to set a fps for both source and output, but in this case they both need to be set to 25. This is because the source is really 25fps to start with, but the interlacing causes Avidemux to mistakenly believe it is 50fps. Confusingly the sub-heading of this filter says "resample from X to Y fps". The other fps filter is called "Resample fps" and it is therefore easy to confuse the two. If you don't use the "Change FPS" filter the output will incorrectly be identified by mediainfo as 50fps. It might play anyway depending on your player, but more importantly on a two-pass encode with a target filesize, the filesize will only be half what you wanted it to be, with correspondingly lower quality.
Returning to the crashing problem, I have gone back to 2.6.15 from the latest nightly build. I will do some further experiments with settings to see if turning off hw decoding can be made to run as smoothly as on 2.6.11 and report back my findings in due course.
FPS update: Based on some tests I just did the "Resample fps" filter (set to 25) produces output indistinguishable (by mediainfo) from using "Change fps" with both source and destination set to 25. Both filters also result in correct file size (if you don't use either of them, two pass with target file size, the output will only be half the expected size). I should be grateful if someone could clarify whether there is any reason to prefer "resample to 25" over "change fps with both source and destination set to 25" in this particular circumstance (clearly they are radically different if the frame rate is actually being changed). Very sorry if this has taken us off topic, but I am currently running the crash tests as well.
Observing the memory consumption by Avidemux would save a lot of time and be much more useful as "crash tests". Why do you re-encode the video stream in the first place? Usually remuxing the transport stream into MKV suffices.
Could you please provide a 1080i sample (~5 minutes in duration should be enough) cut from such a .ts file for me to play with?
If Avidemux is not able to tell interlaced videos from progressive with twice as high fps, this is an issue, sure. I just don't know if and how this can be detected.
Does the indistinguishable by MediaInfo output remains indistinguishable when loaded in Avidemux?
1080i 25FPS, there is also 30FPS (USA). Don't have access to these.
ID : 2050 (0x802)
Complete name : /home/jan/Upload/avidemux/20161209 1015 - BBC One HD - bbc one HD 5 minutes.ts
Format : MPEG-TS
File size : 287 MiB
Duration : 5 min 0 s
Overall bit rate mode : Variable
Overall bit rate : 7 995 kb/s
Video
ID : 5400 (0x1518)
Menu ID : 6941 (0x1B1D)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : 27
Duration : 4 min 59 s
Bit rate : 7 148 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
DVB-S2 recording:
Files (287 MB total): 20161209 1015 - BBC One HD - bbc one HD 5 minutes.ts
Will be deleted on: 16 December, 2016
Download link: https://we.tl/8Mztbj2iSh
Observing memory consumption: Is there a way to log it? I'd rather not sit and watch it, and I wouldn't really know what I was looking for.
Why recode?: To place on blu ray disc. Broadcast h264 streams are not blu-ray compliant, and won't play in most hardware players. Mainly because there are too many B frames, see this thread: http://avidemux.org/smif/index.php/topic,16163.0.html
Sample: See Jan Gruuthuse's previous post.
Interlaced v progressive: According to Aquar, the developers are already aware of the quirk where 2.6.x interprets interlaced fields as frames, doubling the frame count. Since there is a very simple workaround with the filter it's probably not a priority, although I can't speak for them.
Different filters: yes, I can't see any difference between the two in either media info or avidemux. There may however be some difference during encoding, but that's well beyond my expertise I'm afraid.
Resample fps will output what you ask for whatever the input , it will not shorten or lengthen the speed / duration
Change fps is somewhat different, it may change speed or duration or not
For your use case, resample fps is more suited
Hi mean. In cases where a true frame rate change is needed, or you want to speed up/slow down the video, then I can see that the two filters do completely different jobs. In the current case though, where we are not truly changing the frame rate but merely overcoming the field/frame quirk such that in reality both the input and output are 25 frames per second, both seem to produce the same result. This is so both visually (to my eye at any rate) and according to mediainfo and so on. I am curious and so should be extremely grateful if you could expand, if only for completeness, on whether there is some technical reason (stability? speed? quality?) to prefer "resample fps" over "change fps" in these particular circumstances, when superficially they produce the same result. Many thanks.
In your case it's the same thing
Jan, thank you very much for the sample. The first thing which attracts attention is Avidemux often navigating to P-frames instead of I-frames as next/previous keyframe (pressing UP or DOWN). Is this a result of misdetection (or lack of detection) for interlaced frames?
To workaround misdetection, I close the video after it has been indexed (this is only applicable to transport streams) and edit the .idx2 file correcting the value for "Fps" and "Interlaced" accordingly, then load the stream again. Now it can be processed without need to insert a filter. The whole is definitely worth fixing, there should not be any need for a workaround (ffprobe gets or guesses the fps right).
WRT to archiving on bluray, I'd avoid this due to being a legacy technology and a huge waste of resources on top of some quality loss.
WRT to observing memory consumption, http://stackoverflow.com/questions/69332/tracking-cpu-and-memory-usage-per-process (http://stackoverflow.com/questions/69332/tracking-cpu-and-memory-usage-per-process) seems to match the requirements.
Quote from: eumagga0x2a on December 09, 2016, 05:23:45 PM
Jan, thank you very much for the sample. The first thing which attracts attention is Avidemux often navigating to P-frames instead of I-frames as next/previous keyframe (pressing UP or DOWN). Is this a result of misdetection (or lack of detection) for interlaced frames?
Mean can probably enlighten you more on P-frames instead of I-frames. (I remember something about pseudo frames when the switch was made from frame based to times based avidemux editor).
First field is an intra, 2nd is not
Thanks all, especially mean and Jan for the help provided so far. In my latest tests 2.6.15 with hw acceleration disabled did manage to complete a full recode of a 2hr file. With hw enabled, it failed 12 times out of 12 attempts, usually on the second pass. With hw disabled, I had to set video display to Qt to get it to work, but this may have just been coincidence as sample size is so small. I now have a workable solution with 2.6.15, so that's great. On the grounds that I am pretty much up and running I probably won't be posting to this thread again but I am so grateful for you all getting me to this point and for the clarification on the side-issue of the filters. Many thanks.
Quote from: mean on December 09, 2016, 08:42:22 PM
First field is an intra, 2nd is not
Sure, but how does Avidemux (more precisely ADM_Composer::searchNextKeyFrameInRef) end up with a P-frame while looking for an intra? It is not like it were just one field off: there is really no keyframe next to such a P-frame.
Just a guess but if Field 1 is intra and field 2 is P, it needs to decode both to get an image
The last decoded stuff is a P (2nd field)
Wouldn't all keyframes get marked as P-frames then, would they? This is not the case. Some are true I-frames and saving a video in copy mode starting with such a frame results in a perfectly playable cut. Navigating with the UP or DOWN key to a "keyframe" marked as P and starting there results (as expected) in garbage when saved in copy mode.
Depends if the 2nd field is a P or a I
Just a guess
Is it possible that the 2nd field is an intra?? This would complicate the things a lot. Did you have a chance to look at Jan's sample?
nothing prevents it from it afaik
no time to look at it yet
There was a slight buffer overflow
Today's nightly *MIGHT* be better
Unfortunately, not yet. By the way, the number of frames reported in ADM_Composer::searchNextKeyFrameInRef at line 200 of avidemux/common/ADM_editor/src/ADM_edSearch.cpp is also rather off (amounts to ~40fps) for the sample.
2 different issues here
* 2 pass that seems to be stalling (or is stalled)
* Seeking on mixed type fields
Only the 1st one has been maybe fixed
Sorry for reviving old topic but when the developers of the program don't do something, we have to share the valuable info. I was just having crash after crash using the more recent version of avidemux, then I switched back to v2.5.5 (because it was the most downloaded of the old versions on sourceforge), and now I finally can convert my h264 video again without crashes and without weird artifacts on screen. I don't know what they tried to do with version 2.6.x but it's clearly not working.
To everybody out there, I strongly recommend using avidemux version 2.5.5 .
--- Thanks for sharing the solution of going back to 2.5 ---
Looks clearly like a user error to me. avidemux branch 2.6.x does what it should supposed to do.
Not according to multiple google results of many people complaining about the same. And the solution is simple, but took too much time for me to find it: Go back to v2.5.5