x264 & FFmpeg: "64-bit dictatorship"?

[bulgom]

Hi,

Has anyone encountered: some garbled video frames when reencoding to AVC H.264 using — 32-BIT VERSIONS of — "FFmpeg" and/or "x264, VfW only (not CLI)"?


_____________________________________

Edit Oct. 5th, 2018

May be not so obvious at 1st sight — and since videohelp.com does not harass its members with any "mark-it-solved-if-so" (plz don't change anything! ),

well, thanx a whole lot to LigH.de, poisondeathray and jagabo, the — overheating — problem, i.e. the cause of my aggravating / stubborn / endless garbled recoded to AVC video frames, was solved, (in my case) using "winThrottle" for Win. 2K/XP.


2nd edit: Oct. 17th, 2018

Should ONE video fan on Earth recode to AVC using mid-2000's PCs (= be crazy enough to do so, as I do), I hope this 2nd edit would / might help:

SECOND old piece of junk PC: bad frames again! but no overheating, this time. So I RESOLVED myself to follow poisondeathray's hint on RAM — & that advice sure gave me hell, due to hardly accessible sticks...

Anyway, an old "MemTest86" version detected a faulty one (while scanning them: 1 by 1). Result after replaced RAM stick: impeccable encoding.

_____________________________________



I really HOPE! I'm wrong;

and wondering if it's "MY new" problem only — which might NOT be "mine", neither "new" at all,

as, though I may be two if not four or more years late (...), I have observed this — several times now:


Encoding, but not encoding only, i.e. copying &/or demuxing + muxing using "FFmpeg", or "x264 incl. in FFmpeg" to recode, therefore "Avidemux" (both to recode or copy),

AND, 'more'over, "x264 VfW (Video for Windows) via VirtualDub for instance" to reencode:

— ON 32-BIT PCs ONLY —, I get a few garbled frames per 3 to 5 minutes of video. Systematically.

[ Sometimes the same frames, out of the video chunk I test on, sometimes other frames, if not a "mix" of the two; i.e. at random. ]


I did blame that on the old 2000 decade PCs I use, to let them "grind" overnight or even longer (to free my 64-bits PCs and go on with other stuff, editing etc.):

"may be their hardware is too old and skips or tweaks some video frames, huh?"


NOT AT ALL, in fact! Few days ago, I was explained that "32-bit versions of x264 get almost no testing coverage anymore".


Following that "great" news, you can bet I went thru quite a few hours of testing, as I don't want to post stuff I'm unsure of.

So: as already mentioned above, "32-bit x264 VfW via VirtualDub", though it messes LESS video frames than "32-bit FFmpeg (x264 function)", still ruins some images;

"quite" disappointing — to me anyway...


[ "OK", replacing a few GOPs afterwards is not all that complex: in itself, but way too TEDIOUS on long footage, since each lousy frame needs to be located to begin with. ]


THEN: I tested "x264 CLI (command-line) 32-bit version": several times, to make sure or as sure as possible, before posting;

in THAT case, i.e. "32-bit x264 CLI, on Windows XP (here its 32-bit version of course) / on 32-bit hardware capable only (of course)", result: ... NOT A SINGLE GARBLED FRAME.


Is it... me only — or what?

____________________


Tests: on an "HuffYUV" (set to best & best) 7-minute 768 × 576 .avi sample — recoded to AVC, .mp4 contained

& knowing that no setting (from veryslow to veryfast, profile High level 3.2 or baseline) makes a difference.


On — AVC — original samples & also long footage: less bad frames but still too many.

Not tested yet: lossless AVC intermediate recoding (of whatever original material to process: MPEG-2, lossy 'smartphone' AVCs, etc.), to finally recode to lossy AVC — in case "32-bit FFmpeg" would fuss on CERTAIN types of orig. streams mainly, such as HuffYUV?


BTW / to double or triple check (not done) yet: "32-bit FFmpeg" used on 64-bit Windows: ? But the goal & question remain: can some version or setting output impeccable frames only, on 32-bit Win. XP/machines?


And again/reminder: none of all that occurs on 64-bit Windows versions (whatever v°: XP to 10).


Tested also: "live USB 32-bit Windows 10 key", to boot old PCs = same result, bad frames again. So it's definitely not Win. XP, but actually the 32-bit versions of "x264" (whether incl. to "FFmpeg" or not), EXCEPT "CLI".



.

[LigH.de]

Not yet tested, but definitely worth an investigation.

If this is true, that might be a sign of a memory leak or another kind of overflow.

[jagabo]

Keep in mind that x264vfw is not an official build. The versions that are available are hacks from third parties. There's no reason to use x264vfw in this day and age.

[bulgom]

Hi & thanx for the answers


About "VfW": OK / I've been testing any available "x264" version, after making sure it's not the PC itself, that's causing the problem.

What I actually want to use is (or would be) "FFmpeg" but, in this ("particular"?) case, it corrupts even more frames than "x264 VfW".

What could it be, that lets the same PC reencode flawlessly, using "x264 CLI"?



My "programming knowledge" being worse than zero, I'm of course 100% unable to understand what's happening

— but, though the problem seems quite random, I sure wonder why it almost never occurs within the FIRST minute (or so), of any video I recode.

I've sometimes read about "memory leakage" and "overflows", without ever being able to fix such bugs by myself (as you can guess);

therefore, I suppose ( ? ) they are due to some programming error; i.e.: they would have nothing or not much to do with Windows itself and/or the hardware: ?

The ONLY — good or bad — reason that makes me think so is "x264 COMMAND-LINE version", which only outputs impeccable frames (on the same 32-bit machines + Windows versions, of course).

And, the good reason why I'm very disappointed by "FFmpeg" is simple:

despite its number of obscure commands (obscure to me anyway), it happens to be quite handy, to build interfaces, to automatize recoding, audio processing, (de)muxing, etc., in order to help beginners:

e.g., a basic "AutoIt" interface (incl. drag'n'dropping clips to join) that calls "FFmpeg" * command lines, sure is an EASY tool, to join + process/recode many video formats, to universal AVC flicks — without any knowledge & ONE mouse move only (or very few manipulations).


"In a perfect world", it would work on 32-bit systems as well... and it does, except for that weird/frustrating corrupt frames bug!



* "Transpose to x264 CLI + MP4box, then (instead of FFmpeg)"? I'm trying, and it... ~works — but, besides being more difficult to prepare, it's "somewhat" limited, in comparison to "FFmpeg".


.

[LigH.de]

Right now I have no access to PCs so old that only a real 32 bit OS runs on them ... any other PC in my reach already has a 64 bit OS. Next chance - Monday.

And you say that a 32 bit ffmpeg on a 64 bit Windows is not affected by this amount? Or did I misunderstand?

[bulgom]

No, you read right. I may have to test again (testing never ends) but, so far anyway, 32-bit "FFmpeg", as long as it runs on Win. 10 64 bits, never garbles any frame.


Thank you very much for testing if you can. I sure understand that finding those old machines can become difficult (a real/physical 32-bit one, yes, as I wouldn't really trust "VirtualBox" or so, run on a 64-bit PC, on such a test).

At the same time, I'm trying to help people who — stubbornly *— stick to XP, including... myself (for some reasons), though I use both XP 32 bits + Win. 10 64 bits*.


[ * To work on & manipulate stuff fast enough, I never liked "7" (although it's often considered the best version), due to its thick framed windows. Win. 10 is obviously a darn spyware in itself but, after, say... SEVERAL days of tweaking + without any upgrades, it CAN become "viable" (I don't care about viruses & so on: I just restore the partition if needed, using a "disk image"). ]



The reason why I included 32-bit "FFmpeg" instead of 64 (to the "toolkit" I'm preparing) is simply the fact that I want it to be compatible both w/32 & 64-bit Win. versions;

that said, a batch could easily autoswitch to "64-bit FFmpeg" when started on 64-bits Windows versions (I was just too lazy so far; also, I'd like to keep the whole "thing" light enough, in megabytes).


I don't know how hopeless all this might be but, IN CASE someone would be able to spot — even more or less only — the problem, several tools: "Avidemux", "x264", etc., could benefit from it; unless their developers don't give a damn, as... it seems to be the case!


.

[poisondeathray]

I still have an old 32bit XP machine laying around I can test on . But I know 100% that there are no problems with older 32bit FFMpeg builds (much older). So if there is a problem it might be because of newer FFMpeg builds limiting XP compatibility, or your particular machine (memory, psu, something else) . The solution would be to use older FFMpeg, older avidemux, older tools. You lose more recent developments, but hey that's life

I was going to say you'd need to submit a sample where it could be reproduced if you want it fixed, but probably nobody would bother to fix it. Low priority for developers, and XP compatibility is purposely excluded now




But I've seen that similar artifact pattern before several times, and it was a decoding bug in few the cases, a memory corruption issue in the others.

You would expect a decoding bug to affect the same frames in the same manner every time. But a hardware or memory corruption issue could produce a more random distribution. But you would expect at least a few random bad frames with the x264cli encode if it was a memory or hardware issue . Maybe you missed them, or your test wasn't long enough

So how are you decoding it in each test ? Which decoder was used , and exact test setup for each x264vfw, x264cli and ffmpeg x86 run?

[jagabo]

I suspect the problem is reading the source, not the encoding. What is the source container/codecs? Upload the exact version of ffmpeg you are using and the command line. I have an old computer that still boots 32 bit XP (64 bit CPU though) I can test on too.

[bulgom]

Well... thank you — VERY MUCH! —, LigH.de, poisondeathray and jagabo, for your test proposals — plus all-interesting suggestions.

I'm gathering "the stuff" to upload (+ as clearly as possible) but need a little time — w/one difficulty, though:

since 2010 (yep, no less!) the bad frames problem has been occurring on various long footage vids: DVD MPEG-2 (.VOB), DivX/Xvid .avi's — AND lately: an HuffYUV 7-mn .avi test, @25 fps & 768 × 576 px.

I wanted to upload a chunk of that HuffYUV clip but it's super heavy (1'12" = 924 MB)...


For now anyway:

ffmpeg version: N-90069-gdd8351b118-sherpya (c) 2000-2018; built with gcc 7.3-win32 (GCC) 20180208

+ 32-bit Avidemux*, several versions, as old as 2.5.6 & up to 2.7.1 (latest), all 32 bits = same problem

(*reminder: 64-bit 2.7.1 & standalone FFmpeg on 64-bit Win. 10 only = no problem at all)

+ (in despair) 32-bit x254VfW bd Jul 30 2017 13:50:19 libx264 core 152 r.2851bm ba24899, via VitualDub 1.10.4 bd 35491 = same problem with less errors than Avidemux...

... but another problem anyway: cannot use FFmpeg neither Avidemux to "re-contain" to .mp4 or .mkv, as even that (i.e. no recoding) ruins frames again! So, MP4box instead? Tested OK but somewhat complicated.


******************
+ 32-bit x264CLI, both "2011 11 10 core:119 r2106 07efeb4" and "core:133 r2334 a3ac64b (date? / 11945 ko anyway)"

= NO ERROR AT ALL (how is that possible?!)

******************


Note 1: another quite puzzling result:

I needed to capture (Super-8 flicks), using the old 32-bit "Pro." XP PC — & expected at least some dropped frames, but:

not only ALL frames were captured, moreover, though the CMOS reads "2006" (!), not a single garbled frame, @25 FPS & 768 × 576 px...

AND thru HuffYUV 2.1.1 set to "best & best" (not even "fastest"), via VirtualDub 1.10.4 (though the PC is dated from 2006 & worse: "HP" branded, its HD is a S-ATA...).


Note 2: also tried this : AVC "orig." vids. recoded to AVC. Result: much less bad frames. So I wondered if I should plan on intermediate lossless AVC recodings / not tested on long footage, though

— but & above all, too tedious a method, especially to the people I'm helping... as it takes too long or eats up huge amounts of space.

"BTW": I cannot "afford" to use AviSynth**, as it requires to be installed = not realistic in the "beginners' one-click & window basic interface" I'm preparing: all-portable.

** as I also suspected "color space", and AviSynth converts easily, if I remember — but so does FFmpeg, after all.


——— Precision @poisondeathray — you typed "or your particular machinE"... singular: I don't mean to fuss on any typo (& there is none, here), but sure need to remind this 'sad' fact: it's not one, but THREE 32-bit XP PCs,

PLUS a 32-bit WINDOWS 10 one, behaving just the same.


So, altough I wouldn't bet on this:

—— the problem does not SEEM (?) to be caused by Windows XP;

it sure looks like a 32-BIT VERSIONS bug — of both FFmpeg standalone and Avidemux (based on FFmpeg if I'm not mistaken)

BUT:

—— "kind of" tricky here: NOT when I run them 32-bit tools on... Win. 10 64 bits!


In a word, could it be a problem of 32-bit software run on 32-bit OS's?


I know that the three of you can — may be not solve but — UNDERSTAND the above complicated results;

let me tell you I've been trying to explain that, slowly enough, to quite a few so-called "specialists". Their answer? Some kind of void Buster Keaton face expression!..


COMING UP: FFmpeg + other elements upload + answers to your remarks & suggestions. Thanx again for those excellent hints.


.

[bulgom]

.

This time, I attached as much as I could, of what you suggested to upload [ 75.6 MB .7z, 113 MB uncompressed ]

– including a 61.5 MB HuffYUV .avi sample*; but don't concentrate too much on that one, as 32-bit FFmpeg & Avidemux alter several other formats frames...

* Note: needs to be "concatenated" several times, if you want to reproduce the problem on that particular file, say up to 5 or 6 GB / that's what I had to do (as my connection won't let me upload such heavy tests).

I'd even say that, though a 32-bit OS is NEEDED to test (no doubt), it does not seem to be some XP related issue but, rather, a 32-bit tools-plus-OS altogether bug.

Why? Reminder: same problem on a 32-bit Windows 10 PC...



Below: trying to answer your posts by points.
____________________________________


@LigH.de —— Next chance - Monday.

Any time's the right time. I've been wondering + complaining ever since... 2010 (!), about this, & anyway... Thank you very much in advance, if you can spare some time.

______________


@poisondeathray —— I still have an old 32bit XP machine laying around I can test on . But I know 100% that there are no problems with older 32bit FFMpeg builds (much older). So if there is a problem it might be because of newer FFMpeg builds limiting XP compatibility, or your particular machine (memory, psu, something else) . The solution would be to use older FFMpeg, older avidemux, older tools. You lose more recent developments, but hey that's life

— In the past months, that's precisely what I tried, but no luck I guess. Should one old FFmpeg version work right, I was not able to spot it... yet? Avidemux: same problem with 2.5.6, but may be not old enough / I have even older versions: so far not tested on this problem.

— I have encountered the issue on 4 machines, not just one: 3 XP PCs, PLUS 1 32-bit Win. 10 one.

— Missing some recent developments MIGHT become problematic, on audio processing for example, as I'm preparing some "all-auto. + one-click or almost, joining & recoding tool". But for now, one thing after another...


I was going to say you'd need to submit a sample where it could be reproduced if you want it fixed, but probably nobody would bother to fix it. Low priority for developers, and XP compatibility is purposely excluded now

— Obviouly, aging (to say the least) Win. XP will have to be (completely) abandoned/forgotten some day but, until then, I hate to answer the people I'm helping: "Just buy new equipment",

knowing it's the trivial answer they get everywhere, and that the bad frames bug is the only issue here (all the rest is working fine) = "kind of" frustrating!

About "XP compatibility purposely excluded", yep, I have noticed that 1000 times rather than once – but, after inspecting/testing more closely, "my" bug also affects recoding done on a 32-bit Win. 10 PC.

So, furthermore, it wouldn't be XP only, that they want to bash, but way more: i.e. 32-bit stuff in general (just summarizing several answers I was given in the past few years).

Though humans are everything but logical beings, no debate on that, I'm still wondering why many a developer keeps proposing 32-bit tools, then...

But I've seen that similar artifact pattern before several times, and it was a decoding bug in few the cases, a memory corruption issue in the others.

You would expect a decoding bug to affect the same frames in the same manner every time. But a hardware or memory corruption issue could produce a more random distribution. But you would expect at least a few random bad frames with the x264cli encode if it was a memory or hardware issue . Maybe you missed them, or your test wasn't long enough

So how are you decoding it in each test ? Which decoder was used , and exact test setup for each x264vfw, x264cli and ffmpeg x86 run?


— I've also been wondering about: color space (or whatever it's called more properly). Note: my batch contains "yuv420p" (which may not be enough / except that... I don't really know what I'm talking about, here).

— Memory corruption: doubtful on 4 different PCs;

and about "affecting the same frames": yes, I noticed that, several times... but... not only! In fact, I observed BOTH issues: "SAME altered frames"... AND other frames too (randomness is puzzling by definition, I guess).

— Decoding: do you mean playing? Because I also found players ("PotPlayer", "VLC") to alter a few frames sometimes; then, checking revealed no hardcoded mess – while the harcoded ones leave no doubt: "VirtualDub", "Avidemux", etc. display them (& them only) altered for "good".

Besides that, I don't know how FFmpeg & Avidemux are (actually / technically) decoding, while or right before recoding.

Attachment: I enclosed my bacthes, along with the encoders + test results.

______________


@jagabo —— I suspect the problem is reading the source, not the encoding. What is the source container/codecs? Upload the exact version of ffmpeg you are using and the command line. I have an old computer that still boots 32 bit XP (64 bit CPU though) I can test on too.

— So did I. That's why I tested on different orig. material: MPEG-2 DVD (.VOB), DivX/Xvid .avi's, MJPEG .avi's..., & because I need it anyway. As far as I remember: same problem over & over... with...

ONE exception! Recoding to AVC when the source is already an AVC flick generates clean frames only, or, since I don't recall VERY precisely, at least: WAY LESS lousy frames.

What is the source container/codecs? Upload the exact version of ffmpeg you are using and the command line. I have an old computer that still boots 32 bit XP (64 bit CPU though) I can test on too.

— Source containers: various – but this time: .avi. Format (codec): HuffYUV 2.1.1 (enclosed in attachment too), set to "Best & best" to creae the source (Super-8 capture...), & knowing that "Fastest" (tested also) made no difference.


About "I have an old computer that still boots 32 bit XP (64 bit CPU though) I can test on too.":

sure NOT meant to discourage any testing whatsoever!, I still wonder if the 64-bit CPU might distort the result, i.e. output impeccable frames only;

needless to say: impossible to predict without trying, though.

______________


Thanx again & so much for your precious help!


.

[jagabo]

I rendered all four videos under 32 bit XP SP3. The resulting videos played all played flawlessly under XP-32 bit and Win7 64 bit with several players I tried. VirtualDub2 32 bit played all videos without problems under XP-32 and Win7-64.

I also rendered all four videos under Win7 64 bit. All played fine under XP and Win7, as above.

Earlier I had reported playback problems under XP. But that was caused by an AviSynth script included in ffdshow (I was probably experimenting with something long ago and forgot to remove the script). After getting rid of that all the videos played fine.

[bulgom]

@jagabo —— Thanks — & mmh... difficult to interpret such results. Seems like no frame or rather: no lousy artifact was hardcoded in your case (= playback problems only?). It would mean that your PC (or may be your SP3, while I only installed SP2) encodes alright, i.e. we don't get the same results...

[jagabo]

Note I amended my previous post. I was having playback problems under XP but they were caused by unrelated issues. After eliminating the problem all the videos I rendered played fine.

I forgot to mention that your two videos indeed show problems on both XP 32bit and Win7 64 bit. So your computer screwed up for some reason.

[poisondeathray]

ffmpeg with that binary encodes ok here too . Mine was tested on 32bit XP SP2 (!) . I only appended 9 extra segments for the huffyuv test video. But the CPU is 64bit compatible too, but I doubt that would make a difference

Weird that all 4 (!) of your 32bit OS computers exhibit the same issue . But if "feels" like an isolated local issue to me . Something like this would have been reported already. And I still frequently use 32bit tools (including 32bit ffmpeg) for parts of various workflows (but on 64bit OS) on other computers

[bulgom]

@jagabo —— Yes, I did understand, as soon as you edited your 1st post (after testing), that the presence of the left behind AviSynth script distorted the playback (& the playback only).

OK... your GOOD result is not exactly good news to me.


@poisondeathray —— Thanx for the test. Nine extra segments = a total of 10 = between 90 & 100 seconds. That should be enough to "derail", like it does here;

"plus", it's not even the point, since the problem occurs on all kinds of videos anyway.


I confirm: no less than 4 PCs, which garble some frames every time. How could it be that local?..

But you're right: that would have been reported here & there, and quite a few times, say between ~2006 and ~2010 or 12 (= when people still / often used 32-bits CPUs);

unless nobody ever noticed or cared about a few bad frames? — which doesn't sound realistic...

Note · close to 2008 & even 2010, many people still encoded Xvid vids., rather than AVC...


Therefore, besides the stange lack of complaints mentioned above,

despite the fact that you doubt your flawless result probably has nothing to do with your 64-BIT COMPATIBLE CPU,

I cannot think of anything else, as an important / relevant difference between your machine and my XP + 32-bit Win. 10 ones.

Of course, I could be completely wrong, as I know nothing about interactions between CPU "architecture" and encoders.

Precision: my 32-bit Win. 10 PC is not 64-bit compatible at all (otherwise I'd have installed Win. 10 or 7 64), and it also alters videos, though run by Win. 10 32 bits...


At the moment / at hand, I only have one 64-bit CPU / PC and, though it's an ancestor (Dell Optiplex 740 AMD Athlon 64 X2 Tbird Dual core CPU 3800+ = 2.00 GHz, w/6 GB RAM), obviously built for XP in its day: 2006 (!) = before Vista,

it accepted Win. 10 64 — and encodes like yours: not a single bad frame.

I'm too lazy to reinstall XP on that mule (just for one test), but I'm quite sure it would recode flawlessly too.

So... same remark as above: your GOOD result is... my bad!


I'm really wondering what to test next. May be some hell, such as downloading ALL 32-bit FFmpeg versions?

Or may be give up and encode video using x264 CLI + the audio only with FFmpeg, and mux w/MP4box: not difficult MANUALLY, but that's going to be a real drag to automatize!


.

[LigH.de]

I do remember that some people occasionally reported issues with very long Huffyuv videos being undecodable from a certain point; but I hope that was long fixed since.

So I would agree to #7 to be more probably a decoding issue, like a memory alignment shift. So I am not sure what exactly I will be testing. And when ... today we have a bit trouble, but tomorrow is a national holiday (German Reunion), chances are better then that nobody needs me for any other task.

[bulgom]

@LigH.de —— Grüß Gott / hey, I DON'T mean "goodbye", here! And I don't really speak German, + it's not German, BTW.


What I'm wondering about now, is the kind of CPU you have: 100% 32-bit, as I hope and like mines, or a 64-bit?;

because running 32-bit XP & FFmpeg on a 64-bit CPU, like poisondeathray's & jagabo's did, MIGHT (?) be less reliable — though nothing's less sure.

"So I am not sure what exactly I will be testing.": inherent to a lot of testing anyway. So, we'll see...

(...) issues with very long Huffyuv videos being undecodable from a certain point (...) sounds more or less like my problem: garbling always seems to begin afterwhile (or almost);

but again, not on HuffYUV vids. only: above all, on LONG — enough — films.

So, please do not concentrate too much on HuffYUV: for instance, an MPEG-2 (or .VOB) or may be some old DivX/Xvid COULD be more appropriate.

(...) memory alignment shift (...): physical? If so, would be tough: who'd know how to fix that!

OR depending on how softwares manage memory? Reminder & some slight hope, though: "x264 CLI" always outputs impeccable frames: I suppose (?) it would be impossible in the case of a physical issue.

Although I'm crossing my fingers (if only I were superstitious...), if you get a chance to relax tomorrow, please do so. After waiting ~8 years, I can wait one or few more days. Thank you very much for your concern!


.

[LigH.de]

Not an old 32-bit CPU. But a 32-bit Windows 7. The CPU runs in 32-bit instruction mode.

If I need a "long enough" video, I would use an AviSynth script as source. I could let it loop your sample for hours. And then I can use an intermediate encode as source for a secondary ... if this issue is random, it may accumulate.

[bulgom]

@LigH.de —— Sounds like good / serious testing conditions; and, the problem being VERY tricky * (though QUITE systematic = at least 95% sure to happen),

well, that's probably what it takes to eliminate as much doubt as possible.


* For "instance" & just to drive me nuts: when preparing the sample I posted yesterday, THIS occurred:

I couldn't get a bad frame anymore, until I tried to join it to itself several times — and guess what: that FIRST result was still flawless! Darn...

It's only after adding instances of the obtained result (to that same result) AND RE-saving the whole thing (w/no recode), that I FINALLY got garbled images:

"by the end of the new video", would you think? Not at all: within its first 1 or 2 minutes again...

... knowing, and I'm positive about it, that the previous version was absolutely perfect all along, although it already lasted at least 3 to 5 minutes.



SORRY about such COMPLICATION!, as I can't find a simpler way to report it — if I want to be accurate about it.


But the fact IS, and remains: 95% of the time, using FFmpeg &/or Avidemux, the bug just won't let me recode any long footage... clean!


[ OK, I promise I'll believe in luck — in some next life only. ]



.

[jagabo]

I appended the huffyuv to itself to produce a 10x longer version and it still had no problems on the 32 bit XP system.

Check your CPU temps when encoding.

[LigH.de]

I converted "Tears of Steel" (my "original" as AVC, x264 CRF 6) twice with ffmpeg, libx264, CRF 6. The second copy had no bad frames.

So I would agree to jagabo: An age and temperature related bit failure in a frame address offset is a lot more probable than architecture limitations. I bet your 32-bit-only CPU (and RAM) is several years older than any other machine...

[bulgom]

@jagabo —— Thanx* for the new test. @LigH.de —— Thanx* for those long tests.

*And to the 3 of you, for the time you took on my — darn random — problem.


[ **Many thanx = even heavier posts, but "well": absolutely nobody helped me the way you did. In EIGHT years. ]



Hey: THIS TIME, it seems to be IT! No happy conclusion but: YES, the one PC CMOS I've been testing on lately, reads "year 2006".

3 other PCs: same year for the most "recent" one, & 2 last ones: even older. (I know, though I more or less forgot their exact bd dates.)


———— So: NEW x264 CLI exclusively TEST: a lossless AVC recode of an 18 mn HuffYUV 720×576 vid., took ~1 hour and...

as you detected: raised... the ROOM temperature itself! Had to open the window after ~20'.

Result: none of the previous rainbow artifacts, but MANY NEW (different) ones, this time.



I'd have expected overheating to cause problems BUT not THAT randomly! = quite puzzling (to me anyway)...

... especially knowing that those prehistoric boxes do CAPTURE flawlessly @768×576 px. & 25 fps, using HuffYUV. I insist: not a single dropped frame nor the least bad one.



Apparently, it also means —— that AVC encoding stresses CPUs (way) more than DivX/Xvid, for instance (Xvid tested again => no problem),

—— and that, MAY BE but also seems to happen: even encoding settings, such as LigH.de's "crf 6", are able to mistreat old 'mulas', as opposed to e.g. "crf 26".


—— PLUS: that, between 2006 & 2010, very few people I guess (?) would yet encode to AVC — since nobody reported such issues.



[ CPU/encoders interaction: due to randomness, steep & not so smooth a learning curve! Todo next? Shove the PC into the fridge: its freezer compartment of course... as the fanS I add to each one of them are not enough, by far. ]


.

[poisondeathray]

clean out the case and fans. Old computers are notorious for "dust bunnies" . Just cleaning them out can bring down temps substantially

monitor your temps (both under load, and idle) . Use diagnostics and utilities like cpu-z, coretemp, realtemp, hwmonitor , etc . Make sure there is good airflow (e.g. if cables are blocking the way, re-organize the case for better airflow)

Run memory diagnostics (you still haven't ruled that out) e.g. memtest86+ etc...

Reduce the ambient temperature (open a window, or place the computers somewhere cooler like a basement, or air conditioning) , and use external fans (like desk fans)

If you need to, perhaps underclock, undervolt the processor (e.g. if you live in the desert, ambient temps are very high, you might have to underclock/undervolt). It will work slower but reduce chance of errors

[bulgom]

@poisondeathray —— Mmh... interesting*, here. I've already dusted everything, not very lately, but usually often enough.

Desk fans: tried them also; they do have an effect, but not enough, yet.

Tests (mem. etc.): when putting together a new one of my pieces of junk, I will. But for now & the ones I've been testing lately on AVC, since they easily replace the room radiators (!), the "mystery" is now solved.

Thermal paste replacement: helped also, but still not enough to recode to AVC.


*Undervolting

All I've been undervolting so far is... for the sake of (more) silence (or less noise, rather), the 2 to 3 fans I add: i.e. one to the MB, close to the CPU, one to the HD (to maintain ~37 to 45°C / works well)

— and I KNOW that feeding them 5V (red) instead of 12 (yellow) is not a good idea — at least to encode AVC!


Besides that, I'd sure like to try undervolting the CPU itself. Plus: not much to lose, since I turned that bunch of old PCs into my "24/24 recoding pool" and nothing else (somewhat 'juice' greedy though, i.e. inflating electricity bills to wow/unprecedented values...);

except that I don't know how to put a CPU on diet (neither overclock) — & I dont' care if it's (even) slower:

One thing's sure: the AMOUNT of videos that friends & I shot + gathered within the last ~10 years is "beginning" to make us dizzy! Shrinking is becoming urgent/critical. Even buying some new "i7" won't be enough.

OK, "Googling" 'undevolt a CPU', on its way, now. Thanx for the hint!



_____________________________

PS / completely off-topic: the advice you gave me a "while" ago on how to force join a new clip to a video that's not respecting standards (making the join impossible a priori) still works like a breeze and still helps my friends + I. Though you warned about a "not so advisable method", even 'smart'phones (incl. as old as 2011) don't complain.


.

[poisondeathray]

I mean software undervolt it so it's adjustable (I'm not suggesting fixed permanent hardware mod through the motherboard and soldering) . Look for some overclocking utilities for your specific model of CPU and motherboard - they usually have the option to go the other way (slower clocks and less voltage, instead of higher clocks, higher voltage) .

You should also be able to place limits through windows too with lower power profiles

Essentially you want to reduce the clocks, reduce voltage, and power consumption - that will produce less heat

[bulgom]

Software undervolt: OK!.. Especially since my BIOS doesn't allow anything, or hardly. Next step, trying to find an XP compatible "ThrottleStop" version ("XTU": from Win. 7 on, only). Or equivalent...

[jagabo]

Have you said what CPU you are using? If it's a multicore CPU you can cut temps by using fewer threads than cores. For example, if it's a dual core CPU use only one thread. On a quad core use only 1, 2, or 3.

[bulgom]

Would Avidemux "Threading" setting do, if set to "1" instead of (default) "2"?

And above all: about FFmpeg, does a cmd exist, that'd limit usage to 1 core only?

My Win. 10 64 is a 2-core: no problem at all, though dated 2006. About the other ones, still have to check.

About the XP one I'm testing on right now: tried to slow down the CPU, following poisondeathray's suggestion*;

it's a single-core "Pentium D 2.8 GHz, RAM 2.5 GB", where "D" doesn't sound reinsuring at all, even at the time (2006 also), although that box was named "Media Center" (kind of a joke, knowing it's "HP" branded).



Hey! Hey there!:

*... but... WAIT A SEC'!! And I AM yelling out loud (I know it's not allowed), 'bout 300 Watts (RMS)!! or better: @100 dBA:

SOMETHING — hardly believable but true — just happened:

"XTU" & "ThrottleStop" refusing to start or recognize anything on XP SP2, I finally found an extremely simple but compatible one, named "winThrottle 007", applied a heavy footed CPU speed limit,

and launched the utra-fussy Avidemux. Test ended a mn ago with... NO DAMN ARTIFACT AT ALL!


Seeking disappointment, I of course still have to test, quite a lot.

Nevertheless & AT LAST, THAT incredible result gives me hope to put my herd of dinosaurs back to work — and not mine only —, instead of letting them sit here year after year, like a bunch of jerks!


[ I also read about some method, to link them all or at least two, into a home network, & then make each one recode its part or half, of one same video... But Windows networks, I can't think of anything messier. ]


.

[jagabo]

And above all: about FFmpeg, does a cmd exist, that'd limit usage to 1 core only?

After "-c:v libx264" add "-threads 1". Pentium D is about the worst CPU in terms of heat.

[bulgom]

So the "threads" cmd concerns CPU cores. OK, thank you.

"Pentium D". Selling a PC that's supposed to process video ("Media Center"), equipped with... THAT chip! I don't know now, but I also had an "HP" printer, and even an "HP" scanner: no better!..


.