Some files fail to open

[Zuikkis]

An example file: http://zuik.org/00407.MTS  (5.5MB)

This is directly from my video camera. Most of the files open fine and I can edit them successfully. But some files don't open, Avidemux opens a requester "Attempt to open (file) failed!". But the file plays fine on Xplayer, VLC and totem. Also if I run it through "ffmpeg -i 00407.MTS -vcodec copy -acodec copy 00407.mkv"  the resulting mkv loads fine in avidemux.

This is Linux 64bit. I have tried on 2.6.0 stable, and also latest 2.7.0 dev version. I haven't tried latest 2.6 nightly because there is no recent Linux binary available in http://www.avidemux.org/nightly/ unless I'm missing something obvious?

[eumagga0x2a]

I don't experience any problems loading the sample (and saving it in copy mode) in Avidemux from the latest git master + ffmpeg 3.3.5 on macOS. Did you build Avidemux yourself? There are no current official Linux dev builds, but compiling Avidemux on Linux is very easy.

The 2.6 branch is dead.

[Zuikkis]

I used the latest binary version from this thread: http://avidemux.org/smif/index.php/topic,17915.0.html

However, now after I had rebooted the system, I now can load the file. I first tried it with older version of avidemux and encountered the problem, then upgraded to this dev version and didn't reboot afterwards, so there perhaps was some files still in use by the old version? Anyway, now that single file loading works.

But, there still is a problem. If I try to drag&drop a lot of files (entire directory), it fails. I logged the output to file: http://zuik.org/dump.txt

It looks as it always scans entire directory for sequential files, even if it does not ask about that in this version of avidemux. Are the files accidentially left open? Because eventually almost everything starts to fail with "Liian monta avointa tiedostoa" which is Finnish and means "Too many open files"..

Even if I drag&drop the files one by one, it fails at the same point.

[Zuikkis]

I now compiled avidemux myself, from github..

The multiple file open problem is still there.

[eumagga0x2a]

It looks as it always scans entire directory for sequential files, even if it does not ask about that in this version of avidemux.

Yes, just the dialog asking user confirmation to treat not yet indexed multiple files as a single one has been disabled, the entire logic behind that remains in place.

Are the files accidentially left open?

I guess this is exactly what happens here as files are closed only when fileParser is destructed.

[Zuikkis]

I commented out this bit on the source:

Code Select Expand


        if(*multi!=FP_DONT_APPEND)
        {
            aprintf("Checking if there are several files...\n");
            splitFile=ADM_splitSequencedFile(filename, &left, &right,&decimals,&base);
            if(splitFile)
            {   
                aprintf("left:<%s>, right=<%s>,base=%" PRIu32",digit=%" PRIu32"\n",left,right,base,decimals);
            }else       
            {
                aprintf("No.\n");
            }
        }


Works now nicely.

[eumagga0x2a]

Your modification breaks loading video DVD structures where append at the demuxer level is mandatory. You should rather change occurrences of FP_PROBE in avidemux_plugins/ADM_demuxers/MpegTS/ADM_tsBruteForce.cpp and avidemux_plugins/ADM_demuxers/MpegTS/ADM_tsPatPmt.cpp to FP_DONT_APPEND.

[eumagga0x2a]

Actually, the culprit might be located in the code which reads the audio section of the index as both TS_guessContent and TS_scanForPrograms delete the fileParser which they create. Could you please revert your own change in the core and test if the following patch works for you?

Code Select Expand

diff --git a/avidemux_plugins/ADM_demuxers/MpegTS/ADM_tsReadIndex.cpp b/avidemux_plugins/ADM_demuxers/MpegTS/ADM_tsReadIndex.cpp
index 31fe2650..c89b4868 100644
--- a/avidemux_plugins/ADM_demuxers/MpegTS/ADM_tsReadIndex.cpp
+++ b/avidemux_plugins/ADM_demuxers/MpegTS/ADM_tsReadIndex.cpp
@@ -355,7 +355,8 @@ bool    tsHeader::readAudio(indexFile *index,const char *name)
         {
             ADM_info("No extradata (%s)\n",body);
         }
-        ADM_tsAccess *access=new ADM_tsAccess(name,pid,true,(ADM_TS_MUX_TYPE)muxing,extraLen,extraData);
+        bool append=(bool)index->getAsUint32("Append");
+        ADM_tsAccess *access=new ADM_tsAccess(name,pid,append,(ADM_TS_MUX_TYPE)muxing,extraLen,extraData);
         if(extraData) delete [] extraData;
         extraData=NULL;
         ADM_tsTrackDescriptor *desc=new ADM_tsTrackDescriptor;

[eumagga0x2a]

I'm pretty sure the patch above fixes the issue, greatly reducing the number of open file descriptors (we still hold three fd per loaded ts video), so I pushed it to the git master.