Virtual PC 2004 SP1+
Windows XP+
avidemux_2.6.18_r170313_win32.exe (r723b9080f91) ((ffmpeg 3.0.7))
I've got 1 .ts file (2.55 GB), accessed through
Shared Folders,
Indexing seems to go well up to 98%,
then reading the created index file crashes:
Quote
...
[ADM_tsAccess] 22:48:12-676 Creating audio track, pid=84, muxing =0
[TsDemuxerer] Reading index
Saving crash file to Z:\...\crash.py
Crash Dump for Assert failed :3==sscanf(cur,"%" PRIx32":%" PRId64":%" PRId64,&len,&ppts,&ddts) at line 140, file /home/fx/hudson/workspace/mingw32QT5Mxe/avidemux_plugins/ADM_demuxers/MpegTS/ADM_tsReadIndex.cpp
ADM_setCrashHook [libADM_core6.dll]
ADM_backTrack [libADM_core6.dll]
Paint event
[abortExitHandler] 22:50:43-184 Abnormal exit handler, trying to clean up
See CDafv-170319.ts.idx2.7z (http://dl.free.fr/srpKMyZlD) (400 KB).
1)
Is it indexing or reading code that is actually wrong? Indexing does create a bad .ts.idx2! Then reading it crashes...
2)
If need be, I could upload (part of) the .ts file, but I would need to know which one is interested. The file content is not the trigger, it is the file size: ">= 2 GiB".
NB:
*
First time I ever get this crash. Because I was not using a/this virtual environment before!
*
"Regression": ADM 2.6.8 works fine with this .ts file. Actually, no: v2.6.8 has the same issue when run on VPC+WXP+SF.
PS:
*I have not tried (yet) VPC+WXP without indexing through SF.
A stupidly long gop is processed at the end
Workaround : delete the very last long line just before [End]
Without the ts file i can't check why
Quote from: mean on March 20, 2017, 05:13:30 AM
A stupidly long gop is processed at the end
Workaround : delete the very last long line just before [End]
Without the ts file i can't check why
I updated my initial comment:
I reproduced this issue with 2 other files, and found the trigger:
something is going wrong when reaching file offset ">= 2 GiB".
Example .ts.idx2 ends with:
...
Audio bf:7ff61734 ...
Video at:7ff3c690:0019 ...
Audio bf:7fff69ec ...
Video at:7ffd6140:0019 ... (<- overly long line)
[End]
I assume next offset would be ">= 0x80000000".
Ftb, I would assume the size limitation is (somehow) caused by my virtual environment.
Yet, it would look like ADM is not handling it correctly.
[ts/demux] Make it more robust (https://github.com/mean00/avidemux2/commit/1dc1ee1b17891e6bd995f6829dded9305789e122)
worked around the reading crash.
This is nicer, though it silently "truncates" the file (size) to its first 2 GiB.
(2h27mn52s in my case.)
Thus, it seems wanted to check(/improve) index writing code (too)...
Are you reading the file over samba ?
Quote from: mean on April 14, 2017, 01:45:56 PM
Are you reading the file over samba ?
Not explicitly. (But could be under the hood?)
"Shared Folders" is a Guest Additions feature of VPC:
as a user, it maps a host drive/path to a guest drive;
internally, it works like/using "network", but there is no further details.
Ah, "reproduced" with EditPad Pro 7.6.0:
file can be open and navigated normally,
but all data are 0x00 starting at 0x80000000.
EPP does not report any failure either :-|
(Scary (environment)!)
Some more VPC+WXP+SF tests:
copy starts then errors out at 2 GiB.
*copy:
"The request could not be performed because of an I/O device error."
*Xcopy:
"Access denied"
*Explorer (Copy+Paste):
"The request could not be performed because of an I/O device error."
This fully confirms trigger is at OS/VM level.
Yet, it would look like the error can be detected and reported. (Hopefully by non-OS software too.)
Maybe ADM (video file reading) can be improved with this regard?