2.6.10 output dropdown missing valid options

[TCmullet]

I have been using 2.6.8.  I am having a problem with one file.  (That problem is separate and I guess I should report that separately.)  I figured "maybe the genius(es) behind Avidemux have released something newer in which my problem may have already been solved".  I see you have 2.6.10 now.  The bug is that when I open my M2TS file then want to save the output, ONLY TS comes up in the dropdown.  Therefore I can't see the numerous other M2TS files I have in the same folder already.  I can manually type the new name with ".M2TS" at the end, but the old version gave the "all files" option when trying to pick an output file name.  It's too restrictive to show only .TS files.  I use M2TS all the time.  Perhaps you could have 3 dropdown options, "all files", ".ts", and ".m2ts".  This is a great irritation and a step backward.

And because of this plus my separately logged problem is not solved by 2.6.10, I'll go back to 2.6.8.  (Interestingly, 2.6.8 did not get removed from system upon 2.6.10 install.)

[mean]

arent you mixing 32 & 64 bits install ?

[TCmullet]

I doubt it.  I've endeavored to keep all video softwares (Avidemux, Virtualdub, Avisynth, etc.) as 32-bit, regardless of whether my target system is 32 or 64.  (I have both, but most video is processed on the 64, but with 32-bit softwares.  More reliable I've heard.)

Uh, I may have to retrace how I found the .exe to install the 2.6.10.  If a choice was presented, I would have intentionally picked 32.

[TCmullet]

No one ever responded with a solution.  I had forgotten about this as I've been using AviD a lot these months.  By observation, not memory, I infer that I "solved" the problem by reverting from 2.6.10 back to 2.6.8.  That then allowed me once again to save to the .M2TS extension (and also show the other .M2TS files that already exist in the same folder when I start the save dialog).

Now that I have attempted to upgrade from 2.6.8 to 2.6.14 for a different reason, I now find that the bug in .10 is still in .14.  PLEASE address this.  If you don't, then any of us who work with .M2TS files will NEVER be able to upgrade past 2.6.8.  Thank you!

(And I am not using 64-bit Avidemux even though I'm running on a 64-bit I5 system that originally ran Win7 Ultimate, but is now running Win10 Pro.)

[TCmullet]

I believe I am using 32-bit Avidemux, but the About panel does not reflect anything more than 2.6.8 (no reference to 32 or 64-bit version).  I'm still waiting for someone to respond to this.  If it's thought that the answer should be obvious, it's not.  Yes, there maybe be some alternate actions I could take, but each of them makes potentially faulty assumptions due to unknowns in the way Avidemux works.  And making these assumptions might make my output unacceptable, but unacceptable in a way that I wouldn't know until I had destroyed my source-capture file.

It's also puzzling that no one else seems to be bothered by this bug.  Am I the only one capturing M2TS files and using Avidemux to make new ones??

Won't someone please talk here?  I think that at the very least, the dropdown should be increased to two items, the *.mts one AND the original *.* one.

[eumagga0x2a]

Avidemux can't mux in m2ts transport stream format (192 byte sized packets instead of 188 byte sized packets in usual ts) as far as I understand the source code, but it should be able to read (demux) m2ts streams without issues. Each muxer in Avidemux can register only one file name extension.

In copy mode you should be able to mux the video and audio program streams (no subtitles!) within a m2ts container in a lossless way into another container like mkv.

File name extensions are mostly meaningless. "M2TS files" can contain streams in a variety of codecs.

[eumagga0x2a]

PS: I agree that QFileDialog should always allow *.* as filter, not just the particular extension specified by the demuxer muxer. IMVHO this is a bug and should be fixed.

[TCmullet]

Ah, thannk you, sir eumagga0x2a!  Hopefully now we can plow through what been happening at my end (all along), solve some mysteries, and figure where I should and/or can go.

I started into this by getting a Hauppauge H264 capture device.  I was presented with the decision to capture either to M2TS, TS, or MP4.  (It's an option on the capture GUI.)  I needed/wanted to pick one format and stick with that indefinitely, generally.  I elected M2TS over TS because I read that there's a bit more info in it that can possibly help some players play better, or at least play better in "damaged file" situations.  (I read this 3 years ago when I got the card--I don't remember where I read it.)  So I then needed a way to edit them, even if only on a GOP basis.  I found Avidemux.

I always wondered how it is that in the Output Format dropdown, there is Mpeg TS.  I figured this is what I need to do copy/copy from and to M2TS files.  But I was at a loss to know how Avidemux would know WHICH WAY it would generate the packet size (192 byte size packets for M2TS output instead of 188 size for TS output).  The only thing I could guess was that it looks at the extension I give my output file and acts accordingly.  I personally don't think this is a good idea; as a former programmer, I feel the output should be driven by a option choice and the user can give any extension (and file name) they want.

An observation I made early on was that all results were BIGGER than the originally captured file.  I inferred that at least things are getting bigger, not smaller, therefore my packets are probably 192.  Are you telling me that I have NEVER gotten 192-sized packets out of Avidemux?  If so, then what's the point of me captureing in M2TS instead of TS?

I thank you in advance for your reply, eumagga0x2a.   

[TCmullet]

PS: I agree that QFileDialog should always allow *.* as filter, not just the particular extension specified by the demuxer muxer. IMVHO this is a bug and should be fixed.

I fully agree.  Even if *.TS was the DEFAULT dropdown value, as long as I could switch to *.* on the fly, it would work.  (Hey, how about an option switch somewhere that lets US choose which is the default for my installation?

I am guessing that the reason the author changed it from *.* to *.TS after 2.6.8 was that he must have had files of lots of extensions in his folder and wanted to show only his *.TS files.  He didn't know that some of us use other extensions (such as M2TS).

[eumagga0x2a]

I started into this by getting a Hauppauge H264 capture device.

What does it capture? Analog video? Or is it maybe a DVB-S or -C card?

I was presented with the decision to capture either to M2TS, TS, or MP4.  (It's an option on the capture GUI.)  I needed/wanted to pick one format and stick with that indefinitely, generally.  I elected M2TS over TS because I read that there's a bit more info in it that can possibly help some players play better, or at least play better in "damaged file" situations.

M2TS has 4 bytes in the header of each packet for arrival timestamps thus dealing better with VBR streams and even allowing variable frame rate video streams. If the capture card doesn't use any of these features, there is no reason for M2TS as container format.

An observation I made early on was that all results were BIGGER than the originally captured file.  I inferred that at least things are getting bigger, not smaller, therefore my packets are probably 192.

Are you sure both video and audio encoders in Avidemux were set to the copy mode?

Are you telling me that I have NEVER gotten 192-sized packets out of Avidemux?

Well, I am not quite sure. Mean, the author of Avidemux, knows the code and could give a precise answer.

If so, then what's the point of me captureing in M2TS instead of TS?

It all depends on the capabilities and features of the h264 encoder in the card.

The relevant code for the file picker should be in https://github.com/mean00/avidemux2/commits/master/avidemux/qt4/ADM_userInterfaces/ADM_gui/file_qt4.cpp.

[eumagga0x2a]

I have no idea how stupid the following hack is, but it adds "All files" as filter to the filepicker when saving video:

Code: [Select]

diff --git a/avidemux/qt4/ADM_userInterfaces/ADM_gui/file_qt4.cpp b/avidemux/qt4/ADM_userInterfaces/ADM_gui/file_qt4.cpp
index 7466b2a..b254247 100644
--- a/avidemux/qt4/ADM_userInterfaces/ADM_gui/file_qt4.cpp
+++ b/avidemux/qt4/ADM_userInterfaces/ADM_gui/file_qt4.cpp
@@ -77,7 +77,7 @@ static void GUI_FileSelSelectWriteInternal(const char *label, const char *ext, c
 
     if(doFilter)
     {
-        filterFile=QString(ext)+QString(" files (*.")+QString(ext)+QString(")");
+        filterFile=(QString(ext)+QString(" files (*.")+QString(ext)+QString(");;All files (*.*)"));
     }
     fileName = QFileDialog::getSaveFileName(NULL,
                     label,  // caption
@@ -144,7 +144,7 @@ static void GUI_FileSelSelectReadInternal(const char *label, const char *ext, ch
 
         if(doFilter)
         {
-            filterFile=QString(ext)+QString(" files (*.")+QString(ext)+QString(")");
+            filterFile=(QString(ext)+QString(" files (*.")+QString(ext)+QString(");;All files (*.*)"));
         }
         fileName = QFileDialog::getOpenFileName(NULL,
                                 label,  // caption
(briefly tested)

[TCmullet]

> What does it capture? Analog video? Or is it maybe a DVB-S or -C card?

It, whether the Colussus I which I have or the USB-based PVR-2 or the new Colussus II which I may get one day, captures from composite (analog), HDMI or component.  Very high quality.
http://www.hauppauge.com/site/products/data_colossus.html

> M2TS has 4 bytes in the header of each packet for arrival timestamps thus dealing better with VBR streams and even allowing variable frame rate video streams. If the capture card doesn't use any of these features, there is no reason for M2TS as container format.

I'm sure there's no VFR, but the bitrate can be set to VBR or CBR.  So even though there wouldn't be any VFR, it seems that M2TS is a bit smarter.

Btw, while I can follow code, I cannot re-compile anything.

> Are you sure both video and audio encoders in Avidemux were set to the copy mode?

I've ALWAYS used copy/copy except for very rare experimentation and also a few sound track conversions.  I found Avidemux primarily as a way to edit out commercials.  Even though it's gop-only, the gop size generated by Colossus I is about 15 frames, so a half second is good enough for me.

>  "Are you telling me that I have NEVER gotten 192-sized packets out of Avidemux?"  Well, I am not quite sure. Mean, the author of Avidemux, knows the code and could give a precise answer.

If you're saying that the extension I type in for the output filename does not affect how the program works (in generating a muxed output file), then it has to be one or the other.  I'm guessing he would say "it never generates 192-sized packets, therefore it's not an M2TS file".  But I do wish he would say it here or somewhere in the docs.  If it's in the docs, I'd like to see it and humbly admit I missed it.

> "If so, then what's the point of me capturing in M2TS instead of TS?"  It all depends on the capabilities and features of the h264 encoder in the card.

The card docs say the H.264 (and whichever audio is specified, either ac3 direct or encoded aac) works the same no matter which of the 3 container options we pick.


Btw, while I can follow code a bit, I cannot re-compile anything.  I leave that to the developer.

[eumagga0x2a]

A transport stream container in any version suits capturing better than mp4. By the way, http://www.avidemux.org/admWiki/doku.php?id=general:output_formats states that MPEG TS and even MP4 supports variable frame rate (VBR audio is widely supported), so there is no necessity to use M2TS IMHO.

If you're saying that the extension I type in for the output filename does not affect how the program works (in generating a muxed output file)

Yes, it doesn't affect how the program works, for sure. Avidemux is not the GIMP

I'm guessing he would say "it never generates 192-sized packets, therefore it's not an M2TS file".  But I do wish he would say it here or somewhere in the docs.  If it's in the docs, I'd like to see it and humbly admit I missed it.

Apart from mostly outdated Avidemux wiki, the code has to replace the docs.

Btw, while I can follow code a bit, I cannot re-compile anything.  I leave that to the developer.

Building Avidemux is a cinch on Linux, but it may be quite hard to put all the prerequisites together on Windows.

[eumagga0x2a]

This is less awkward and adds translatable strings:

Code: [Select]

diff --git a/avidemux/qt4/ADM_userInterfaces/ADM_gui/file_qt4.cpp b/avidemux/qt4/ADM_userInterfaces/ADM_gui/file_qt4.cpp
index 7466b2a..5a08be4 100644
--- a/avidemux/qt4/ADM_userInterfaces/ADM_gui/file_qt4.cpp
+++ b/avidemux/qt4/ADM_userInterfaces/ADM_gui/file_qt4.cpp
@@ -37,7 +37,7 @@ static void GUI_FileSelSelectWriteInternal(const char *label, const char *ext, c
     *name = NULL;
     QString str ;
     QString fileName,dot=QString(".");
-    QString filterFile=QString("All files (*.*)");
+    QString filterFile=QString(QT_TRANSLATE_NOOP("qfile","All files (*.*)"));
     bool doFilter = !!(ext && strlen(ext));
     QFileDialog::Options opts;
     int extSize=1;
@@ -77,7 +77,7 @@ static void GUI_FileSelSelectWriteInternal(const char *label, const char *ext, c
 
     if(doFilter)
     {
-        filterFile=QString(ext)+QString(" files (*.")+QString(ext)+QString(")");
+        filterFile=QString(ext)+QString(QT_TRANSLATE_NOOP("qfile"," files (*."))+QString(ext)+QString(");;")+filterFile;
     }
     fileName = QFileDialog::getSaveFileName(NULL,
                     label,  // caption
@@ -105,7 +105,7 @@ static void GUI_FileSelSelectWriteInternal(const char *label, const char *ext, c
     if(newFile.exists())
     {
         QFileInfo fileInfo(newFile);
-        QString q=QString("Overwrite file ")+fileInfo.fileName()+QString("?");
+        QString q=QString(QT_TRANSLATE_NOOP("qfile","Overwrite file "))+fileInfo.fileName()+QString("?");
         if(!GUI_Question(q.toUtf8().constData()))
         {
             ADM_dezalloc(*name);
@@ -126,7 +126,7 @@ static void GUI_FileSelSelectReadInternal(const char *label, const char *ext, ch
         *name = NULL;
         QString str ;
         QString fileName,dot=QString(".");
-        QString filterFile=QString("All files (*.*)");
+        QString filterFile=QString(QT_TRANSLATE_NOOP("qfile","All files (*.*)"));
         bool doFilter = !!(ext && strlen(ext));
         QFileDialog::Options opts;
 
@@ -144,7 +144,7 @@ static void GUI_FileSelSelectReadInternal(const char *label, const char *ext, ch
 
         if(doFilter)
         {
-            filterFile=QString(ext)+QString(" files (*.")+QString(ext)+QString(")");
+            filterFile=QString(ext)+QString(QT_TRANSLATE_NOOP("qfile"," files (*."))+QString(ext)+QString(");;")+filterFile;
         }
         fileName = QFileDialog::getOpenFileName(NULL,
                                 label,  // caption
Have I missed anything? If the patch is OK, I'd suggest it for inclusion.

[TCmullet]

PS: I agree that QFileDialog should always allow *.* as filter, not just the particular extension specified by the demuxer muxer. IMVHO this is a bug and should be fixed.

I don't check in very often.  I see now that the version is up to 2.6.15.  Yet when I browse the change log, there are many changes, but nothing to indicate that the *.* filter has been added to the drop-down.  Does anyone have any idea when this will be added so I can get off of 2.6.8?  Thanks.