If I open a .ts file with mp4 format with avidemux3_cli it creates a incorrect and not working idx2 index file with a size of 933 Bytes.
If I open the same .ts file with avidemux3_qt4 it creates a correct idx2 file with a size of 18,9 MB.
No answer?
@ Jan, can you reproduce this error?
@ Mean, can you fix it please
environment: Ubuntu 12.10 own ADM build from last git
Aahh! This must have slipped my attention.
Confirmed there is some issue with indexing from CLI
Does happen on mpeg-ts to
See attached idx2 by CLI and GUI from this sample file 720p4audioTracks3sat 69 MB (https://www.dropbox.com/s/a8scxh0m134zxh0/720p4audioTracks3sat.ts?dl=0)
I had for long time probably wrong naive end user impression,
that ADM2.6 GUI and CLI share common set of internal ADM libraries for muxing/demuxing/coding/decoding/indexing and whatever like that, and only interface ( CLI versus QT4 GUI ) differs.
I still have that perception!
But is sense of that, the error above looks strange, as it should not matter what version performs that.
But Murphy's law says: "Whatever change cannot matter, it can... " ;)
Interface GUI or CLI is more like command centre: most likely an instruction is not passed on correctly to one of the components. Should be looked at, but for now the time for doing so is not there.
Start both avidemux up from your dos command prompt.
I see. It was my guess as well, that libraries may do not get the same command from both.
@ mean: Can you repair this please?
until fixed:
you could replace the avidemux CLI by the avidemux GUI in batch or scripts and add this parameter ââ,¬â€œnogui
If that would be not functional. It should still work, just avidemux GUI would be running visual.
I'll look into it this weekend, that's weird they use the same code
The qt4 solution with the the parameter -nogui proposed by Jan also does not. In spite of setting the -nogui parameter a gui opens.
should be fixed; win64 binary building
It is a minimal fix, i.e. it works but no progress indicator