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...
Please provide the sample via WeTransfer so that I can access it.
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.
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.
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).
Quote from: hiro on August 07, 2019, 01:39:11 AM
but can you tell me if there's a problem with "DataFileHost" * – & if so, which hassle?
Domain not accessible from my location.
Quote[ * 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.
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.
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 (https://github.com/mean00/avidemux2/commit/f07945dc04629aa97c443de5acd9dd7490037a53), looking into it.
—— "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.
Quote from: eumagga0x2a on August 07, 2019, 04:44:42 AMWill 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.
Quote from: eumagga0x2a on August 07, 2019, 04:44:42 AMYes, it is a regression
So it's not "just me". I supposed so, since it happened on two Windows versions...
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.
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.
Fresh builds including a 32 bits MinGW one have been uploaded, please subject them to thorough testing.
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) :)...
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).