ADM - AND - FFmpeg alone on Win. XP => garbled frames.

[hiro]

————————————
EDIT AUG. 7TH, 2019:
————————————
bottom page post



Hi,

Friends etc. and I are using Avidemux both on Win. 10 64-bit v. and XP 32-bit v. PCs. For instance, long AVC encodings often go to the XP machine – that will "grind" for hours if needed, so that the Win. 10 PC stays free for editing & other stuff.

On XP ONLY, whatever ADM version is used, and I noticed this in 3 different PCs — + using FFmpeg alone just the same —: SOME images, i.e. a 25th or 29.976th of a second, once in a while, comes out badly garbled!

In order to achieve a perfectly clean result, those few frames need to be replaced – therefore the whole (AVC) GOP. While it's not too difficult to to, it requires to watch the WHOLE video VERY carefully, which is no less than tedious.

It doesn't happen on few seconds test vids., but as soon as they exceed that short a duration, such as long footage, & also beyond one of a few minutes only...

I wonder if anyone has encountered the same problem and, of course, may be found some solution.


.

[eumagga0x2a]

As both Avidemux and FFmpeg in this case use x264 to encode to H.264, the issue probably resides in x264 and is specific to Windows XP and/or 32 bits. The former is entirely unsupported since ages, the latter gets almost no testing coverage. You are on your own, I fear.

[hiro]

Thanx for the answer. Yep, "on my own" indeed (+ as "suspected").

And yes, the problem seems to come from x264: also tried to recode to (AVI contained) AVC using "VirtualDub": same result...

Can't even blame it on a slow hard drive or OS etc. (would have been easier to solve),

as e.g. capturing — & digitizing from analog @576 px. + 25 FPS isn't the lightest "operation" (on old XP PCs anyway) —, with "VirtualDub" + "HuffYUV" or even "Lagarith", does output clean frames only.

Now, I'm wondering if ONE & probably old x264 32-bit version, out their x-zillion releases would do...

[eumagga0x2a]

Now, I'm wondering if ONE & probably old x264 32-bit version, out their x-zillion releases would do...

No, none would make a difference. FFmpeg builds for Windows have their libx264 library statically linked into a single ffmpeg.exe, Avidemux brings its own copy of libx264. Installing another x264 build would not affect them at all.

I used "x264" as the brand name of the project which provides the library libx264 along with the command line frontend x264.

If the hardware of the computer which runs Windows XP supports 64 bits operating systems, installing Linux on it would make as a rule much more sense.

[hiro]

IN CASE of some misunderstanding: ?,

and in short before further testing *, well... I haven't forgotten that ADM uses its own codecs exclusively;

that's why I tested x264: VfW version, thru "VirtualDub" => AVI avc files, that ADM easily "re-contains" to .mp4 or .mkv; but: same garbled frames.

* The above posts just reminded me of... may be the 1st thing I should have tested: x264 command line version — which I did, LONG ago, with no problem, on even older PCs (!), but on short vids. only.

And about 64-bit hardware: no, I was mentioning 32-bit capable machines ONLY — of course, and as I've tested 64-bit ones: successfully (always). On those 64-bit PCs, ANY Windows version including XP 64 outputs impeccable frames.

Linux? Well... that's one last thing I'm somewhat lazy about & that I'll never convince a bunch of people to do anyway: try (installing) some 32-bit Linux version in those old machines.

But thanx for that suggestion, as it — also — reminds me of my (~2013 or 14) USB key (32-bit) Linux test version, which included Avidemux (unless I installed it, at the time), if I remember. May be worth a try, except that few old PCs can boot from USB (gasp / back to CD burning, now...).

[eumagga0x2a]

If the hardware is 32 bits only, Linux is not a viable option either, because 32 bits versions get zero testing coverage.

[hiro]

Anyway, after MUCHO testing (3 days of nonstop hassle), here are some results. Can't be 100% affirmative of course but, on — 32-bit only — old Win. XP,

"x264 CLI version: core:133 r2334 a3ac64b" (dated 2013...)

recodes my "7-mn HuffYUV .avi test", to impeccable frames only / tested 4 times, to "make sure"...

while both "ADM", "FFmpeg CLI" & even "x264 VfW via VirtualDub or else" * garble several frames every time.

Code: [Select]

x264 --crf 24 --preset medium --profile high --level 3.2 -o RESULT-vid_no-sound.mp4 Test-7-mn-HuffYUV.avi
* "x264 VfW via VirtualDub" goofed much less frames, but at least one, out of my test vid.


About "ADM on Linux": I've read the above "32-bit warning" post (of course) but still wanted to give it a try. Guess I'll need a dedicated PC, but none at hand at the moment:

so I only tried to install ADM on an Xubuntu v°, running from a "live USB key"... NO WAY! "Get-deb" being down, I had to give up, after wasting some 24 hours; ADM (whatever v° I download) just REFUSES to install / I must say that I know NOTHING about Linux, though. What worked in ~2014 did not, anymore. 


Now, assuming that tests results are actually reliable (?? wouldn't bet a peanut, until further testing, on long footage), the silent .mp4 result vid. needs to be (re)muxed with its or some .aac audio stream

— using something ELSE than "FFmpeg", e.g. "Yamb/MP4box". Tested OK: no bad frames either.

Why? Because I also tried to save the test vid. w/ADM set to Copy & Copy, AND w/FFmpeg set to no recode... to end up with bad frames AGAIN: even in that case!


"In other words", back to the years ~2010 ** but "well", that's all I could get working (flawlessly).


[ ** as I intend to wear off those XP PCs until, say... 2050. Coming next: "How to encode to HEVC (x265) using a 1990 Amstrad PC?", since nothing's impossible, w/the help of Avidemux forum. ]


— BTW —, contrary to "FFmpeg" & "w264 VfW", since "x264 CLI" ONLY, recodes with no problem, doesn't it mean that "FFmpeg" & "x264 VfW" are somewhat buggy? OK: I KNOW that nobody wants to hear about 32 bits stuff anymore...  Have I read the above answers? Yes I HAVE.

But it's "kind of" disappointing; I'll have to modify quite a few of my help/instructions to those friends etc., who (stubbornly) stick to Win. XP. I more or less understand them, though, after messing w/Win. 10 since ~2015. What about Linux then? Well, that's an other story, + another forum too, after all...

[hiro]

————————————
EDIT AUG. 7TH, 2019
————————————

Oldie post, I know — but I often learn, & sometimes a lot, from (even) much older ones.


      After hunting for garbled frames again yesterday...

Yes, it is a regression (...) Should be fixed now, the workaround reinstated by way of precaution also for the git master, please try a future build.

... I just remembered not to have updated this post, although I'd found the cause — sometime in Sept. if not Oct. 2018, 

a completely different cause than yesterday's issue, was preventing and old PC to CLEAN encode, using "x264":

[ But "old" is/was not enough of a reason. ]


——— In Sept. 2018, it was a (darn) ONE faulty RAM stick!

Once removed, "x264" did work perfectly. Side note: good luck to find WHICH one fails, out of four sticks

(RAM inspection by Windows apps being unreliable, had to restart the PC under some "DOS" OS / have "fun"!..)

— knowing that it's totally unclear, when all other "operations", including video encoding (!), are flawless...

... except that I had noticed some Windows crashes, but very rarely; and of course, in that case, Windows BSOD reports always blame some FILE only ("xxx.ext caused an '0x0xxx...' error"), never a hardware component!

[ Should I remind that I am NO engineer, and that, on pure technical aspects, I hardly know what I'm talking about?.. ]


Now, how come it took DAYS of testing, to find it?

"Simply" because encoding to "HuffYUV", "Lagarith" and "PicVideo MJPEG" produced good frames exclusively. Yep, just that was enough to fool me

In such case, anybody suspects "x264" right off — and, in fact, it WAS more or less to blame, but not 100%:

knowing that several other codecs (cited above) would yield impeccable video, my very limited knowledge can only conclude that "x264" must be tougher on... RAM (not on CPUs only),

or may be (?), that it does not make the same exact use of those sticks, as "HuffYUV / Lagarith / etc." do.


So, reasons why I updated this post:

—— Again, THAT specific & rather unusual cause can be difficult to find, trace, understand: a time consuming bitch, believe me.

—— It's happened to friends using way more recent (e.g. 2014 to 2018) PCs. And at the time, I had to give up trying to clarify anything, so we'd just end up encoding with another machine: NOT an acceptable solution, of course.