v.2.7.4 – 32-bit: garbled Xvid decoded frames

[hiro]

Hi,

ADM 2.7.4 32-bit, tested both on Win. 10 64-bit and XP 32-bit, displays an old 2006 "Xvid" file with some garbled frames,

while ADM 2.7.4 64-bit – and ADM 2.7.1 32-bit as well as 64-bit – play the same file + section with no problem at all.

Here's a 2.5 MB sample of the "Xvid" video: https://www.datafilehost.com/d/5eedd324

Hoping the next – 32-bit – versions (nightlies or else) will fix the problem...

[eumagga0x2a]

Please provide the sample via WeTransfer so that I can access it.

[eumagga0x2a]

Could you please also compare with the r190726 32 bits build?

Recently, there was a change which affected handling of empty frames in mpeg4 video to fix a regression. While the change was needed both for the git master and the legacy-compat branch, the legacy-compat patch had to be slightly different.

[hiro]

OK: "WeTransfer" sample download link: https://we.tl/t-5fml1ViIs6

but can you tell me if there's a problem with "DataFileHost" * – & if so, which hassle?

[ * Quicker, since no e-mail (check) required. ]


I'll also test 32-bit "r190726" (in a few minutes or hours, depending on stuff-to-do aside...) – & report, of course.

[hiro]

Done testing * 2.7.3   r190726  win32: no problem, no garbled frame. Thank you.

* On THIS same sample + section of the whole vid. anyway (= didn't have time to watch the whole 2-hour+ film, though).

[eumagga0x2a]

but can you tell me if there's a problem with "DataFileHost" * – & if so, which hassle?

Domain not accessible from my location.

[ * Quicker, since no e-mail (check) required. ]

No email is required for WeTransfer, even if a cursory look seems to suggest otherwise.

So far I can confirm just that there is nothing extraordinary with the sample and that Avidemux builds off the git master decode it completely fine. Will have to try really with a build off legacy-compat branch.

[eumagga0x2a]

I can reproduce the issue (the keyframe with frame number 266 counting from zero can't be decoded) with the latest legacy-compat. Now testing whether this is a regression.

[eumagga0x2a]

Yes, it is a regression from [coreVideoCodec/editor] Fix handling of empty frames for mpeg4 and fraps regressed by ade4b26, drop coded_frame, unused for decoding since FFmpeg 2.2, looking into it.

[hiro]

—— "DataFileHost": OK, took note (as it might happen to other people).

—— "WeTransfer": Okay... had to notice the circled "..." bottom left button / not so obvious at 1st sight.

Will have to try really with a build off legacy-compat branch.

Yep, somewhat tricky as some versions do play it fine – but the problem did not occur on Win. XP only: on Win. 10 64-bit ALSO, "2.7.4 190729 32-bit" won't decode that sample right...

Other old "Xvid" films: I don't know / not tested yet.


Anyway, since 2.7.4 64-bit seems to work fine on Win. 10 (64-bit), AND now: "2.7.3 190726" too on XP (32-bit), I just switched to that build.

Yes, it is a regression

So it's not "just me". I supposed so, since it happened on two Windows versions...

[eumagga0x2a]

It was immediately clear what was the cause, but looking for something more elegant than just reverting the offending part of the patch. It is not related / not limited to Windows, it is older ffmpeg on legacy-compat not trusting the provided compressed frame length. The patch removed the workaround for this problem, not needed with the current ffmpeg.

[eumagga0x2a]

Should be fixed now, the workaround reinstated by way of precaution also for the git master, please try a future build.

Thank you for your report.

[eumagga0x2a]

Fresh builds including a 32 bits MinGW one have been uploaded, please subject them to thorough testing.

[hiro]

Good; + thanx for the news.

I just don't how thoroughly I'm able to test, according to your expectations, I mean

— but I will, as soon as possible (i.e. after some delay, sometimes, as ALL my PCs are Avidemuxing stuff, often up to 24/24) ...

[hiro]

OK: "2.7.4 r190808", both win64 & 32: not "thoroughly" * tested yet, but no more problem, at least on the (above) fussy "Xvid" chunk:

all frames decode perfectly. No problem either on a few short recodes — so far, i.e. not relevant enough:


* "Thorough" — or... more or less... —, in my case, just means opening (+ playing) "all" kinds of formats & containers,

& also: applying several filters, if not quite a bunch (stack of 5 to 10 filters...)

+ playing & converting audio streams flawlessly,

+ checking the available still image outputs compatibility (w/main editors, mainly "Photoshop").


Testing goes on ; also expecting friends' reports in a few days or weeks.

________________

Needless to say (?), I sure appreciate ADM new ability to move "moov-atom" to top = one of my 1st requests, way back in 2014 https://avidemux.org/smif/index.php/topic,16009.0.html (had been done but slowed down processing, at the time).