My working environment is Windows XP SP3.
I use avidemux_cli + JS scripts in a Visual Basic GUI project to join multiple .MOD MPEG2 files into a single MPEG2 Program Stream output file (the input files are capture files from a Panasonic SDR-S150 video camera and are plain SD format MPEG-PS, frame size 704x576, aspect-ratio 4:3, with display size 540x576 in Sequence Display Extension header, 25 fps, GOP length 12, 3 P-frames per GOP).
In my project, the join is "raw": Avidemux_cli + JS scripts do basically "copy" (load and appends), no cutting or trimming of input segments is involved at this stage.
Because I have a problem with stable Avidemux v2.5.6 (produces output with the 2 missing B-frames at the end of each segment (*); this happens with both Avidemux GUI manually joins and with Avidemux_cli + script automated joins), I gave the Avidemux Experimental 2.6 builds a try.
The good news is: the 3 experimental V2.6 versions I tried (Grunster builds r7959, r7989, r7990) entirely solve my '2 missing B-frames' problem.
With the Avidemux GUI of these versions, I produce complete and clean joined output when I manually load+append and copy to PS-MPEG output.
The bad news is: with none of the 3 tested experimental V2.6 versions I tried, I was capable to make my avidemux_cli + scripts work (not even the most simple test script, based on a 'template' saved as a project with a avidemux V2.6 GUI version).
This is what happens:
(1) Javascripts fail with a message "Avidemux is not defined" (example) :
run-->1
[Script] SpiderMonkey INFO - Compiling "C:/My Programs and Doc/MyMpegJoiner/TEMPLATES/TestScript_BetaVersion.js"...
[Script] SpiderMonkey INFO - Done.
[Script] SpiderMonkey INFO - Executing C:/My Programs and Doc/MyMpegJoiner/TEMPLATES/TestScript_BetaVersion.js...
[Script] SpiderMonkey ERROR - ReferenceError: Avidemux is not defined
[Script] SpiderMonkey INFO - Done
quit-->0
Probably error when Spidermonkey starts reading my script that begins like this (example):
//AD <- Needed to identify//
//--automatically built--
//--Project: E:\PANASONIC_CAPTURES\STEP_3_JOIN_AVIDEMUX_AVI\VARIA1\Avidemix_Join_project
var app = new Avidemux();
(2) Python scripts are partially executed, but I never got an output file : neither with the '--save(fullPathNameOutputFile)' argument in the CLI command line, nor with a (example) 'adm.save("E:/PANASONIC_CAPTURES/STEP_3_JOIN_AVIDEMUX_AVI/VARIA1/OUTPUT_123.MPG")' command in the .py script file;
There is also always this error(?) message in the (very verbose) StdOu/ErrorOut (example):
[switchToSegment] Switched ok to segment 0 (dontdecode=0)
[start] admPreview,starting
*********** BACKTRACE **************
PythonEngine::runScript(std::string, IScriptEngine::RunMode) <+0x6DBF> [D:\users\hv\AVIDEMUX\avidemux_2.6_r7990_win32(no_installer)\libADM_coreScriptPython.dll]
unknown function <+0x6DBF> [unknown module]
*********** BACKTRACE **************
Cleaning up
[deleteAll] [Editor] Deleting all videos
This situation is rather frustrating (because I managed relatively well with scripting in the V.2.5.6 version) and I have the feeling I am doing somewhere a basic mistake.
So: if someone could point my nose in the right direction, I will be very, very grateful.
Remark: actually, all my avidemux experiments - both with stable v.2.5.6 version and experimental v.2.6 versions are done with 'no-windows-installer' win32 builds.
I have also a question about apparent difference in scripting syntax between V2.5.6 Javascript and V2.6 Python script:
(1) In V2.5.6 JavaScript (examples auto-generated scripts in the GUI) the following commands have 'frameNumbers' as parameter-values:
app.addSegment(segmentIndex,beginFrameNumber,endFrameNumber)
app.markerA=beginFrameNumber
app.markerB=endFrameNumber
(2) In v2.6 Python scripts (examples also auto-generated scripts in the GUI) the same commands seem to have 'beginTime' and 'endTime' as parameter-values (instead of frameNumbers):
app.addSegment(segmentIndex,beginTime,endTime)
app.markerA=beginTime
app.markerB=endTime
and from what I have seen in the StdOut/ErrOut when I do a 'load' or 'append' of an PS MPEG2 source file in such a Python script , the procedure followed by v2.6 avidemux to find the beginTime and EndTime seems not so simple (looking for PTS and DTS at the begin end end of the file, doing extrapolations and adjustments).
My question is:
(a) Do Python scripts in V2.6 accept 'addSegment' , 'markerA' and 'markerB' commands with frameNumber parameter-values (instead if 'time' values) ?
(b) I yes, is the syntax different or is there an 'option' parameter to make the choice ?
(c) If no, is there a simple application command (something like maybe 'amd.video.duration') to find the length (in time) of an MPEG2 Program stream source file?
(d) What is the time unit and exact syntax of those 'timeBegin' and 'timeEnd' parameter-values in V2.6 Pyton scripts.
I saw some remarkable 'endTime' values in auto-generated v2.6 Python scripts; example :
adm.clearSegments()
adm.addSegment(0,0,55680000)
adm.addSegment(1,0,18942222)
adm.addSegment(2,0,10080000)
adm.markerA=0
adm.markerB=84702222
[/code]
where '18942222' of segment #1 source is a rather unexpected value for a source file with a total of 466 frames at 25 fps = 18.640000 sec (or maybe this type of camera captures in variable frame-rate, and not in variable bit-rate [joke] ;)).
(*) The '2 missing B-frames in output' problem has also been mentioned in another forum (see: //forum.doom9.org/showthread.php?p=789053 post #25)
Thank you for being so patient and read until the end of this story. I hope someone will comment.
Can't help you much on these issues: one question: you do use avidemux3_cli.exe for 2.6 trials?
If you dont do edit at all, just dont use the clearSegment/addSegment
As for saving if you do
avidemux3_cli --runpy foobar.py --save foo.mpg
with foo.mpg a very very simple path, does it work ?
Quote from: Jan Gruuthuse on May 31, 2012, 05:59:48 AM
Can't help you much on these issues: one question: you do use avidemux3_cli.exe for 2.6 trials?
The V2.6 Windows win32 builds from grunster I tested (r7959, r7989, r7990) all contain an executable with name = 'avidemux_cli.exe'. But what is in a name ?
I also downloaded 'nightly' win32 builds r7989-win32 and r7989-dev-win32 from www.avidemux.org/nightly (http://www.avidemux.org/nightly) but those packages contains no '_cli' executable at all (not an avidemux_cli.exe, not an avidemux2_cli.exe, not an 'avidemux3_cli.exe).
(btw: what is the difference between the 'rxxxx-win32' and the 'rxxxx-dev-win32' packaging ?)
So, where should I look to find an v2.6 'avidemux3_cli.exe' executable (with matching libraries) ?
Same thing, it's just that on windows it's called avidemux_cli, on linux avidemux3_cli
In that case, if you have several versions (2.5.6, 2.6) installed to different paths, check you're using the intended one.
Quote from: mean on May 31, 2012, 06:30:59 AM
If you dont do edit at all, just dont use the clearSegment/addSegment
As for saving if you do
avidemux3_cli --runpy foobar.py --save foo.mpg
with foo.mpg a very very simple path, does it work ?
I tested as you suggested (with grunster v2.6 r7990 win32), but same result as described in my initial post:
- no output (for the output file, I even respected the old DOS rule "File Name not longer than 8 characters")
- always the "unknown module" Python error.
This is the command-line of my test:
"D:\users\hv\AVIDEMUX\avidemux_2.6_r7990_win32(no_installer)\avidemux_cli.exe" --runpy "C:/My Programs and Doc/MyMpegJoiner/TEMPLATES/TestScript_SimpleJoin_BetaVersion.py" --save "E:/JOIN_OUT.MPG" --quit >"C:\My Programs and Doc\MyMpegJoiner\LOG\TestScript_SimpleJoin_BetaVersion.log" 2<&1
This is the script from file TestScript_SimpleJoin_BetaVersion.py
#PY <- Needed to identify#
#--automatically built--
#--Project: C:/My Programs and Doc/MyMpegJoiner/TEMPLATES/TestScript_SimpleJoin_BetaVersion.py
adm=Avidemux()
#** Video **
# 03 videos source
adm.loadVideo("E:/PANASONIC_CAPTURES/STEP_3_JOIN_AVIDEMUX_AVI/VARIA1/2000-01-01_00.MPG")
adm.appendVideo("E:/PANASONIC_CAPTURES/STEP_3_JOIN_AVIDEMUX_AVI/VARIA1/2000-01-01_01.MPG")
adm.appendVideo("E:/PANASONIC_CAPTURES/STEP_3_JOIN_AVIDEMUX_AVI/VARIA1/2000-01-01_02.MPG")
#** Postproc **
adm.setPostProc(0,0,0)
#** Video Codec conf **
adm.videoCodec("Copy")
#** Filters **
#** Audio **
adm.audioClearTracks()
#** Track 0 **
adm.audioAddTrack(0)
adm.audioCodec(0,"copy");
adm.audioSetPal2Film(0,0)
adm.audioSetFilm2Pal(0,0)
adm.audioSetNormalize(0,0,0)
#** Muxer **
adm.setContainer("ffPS","muxingType=2","acceptNonCompliant=True","muxRatekBits=11000","videoRatekBits=9800","bufferSizekBytes=224")
#End of script
The file TestScript_SimpleJoin_BetaVersion.log, containing redirected StandardOut and ErrorOut is in attachment.
Although being no expert at all in Python scripting, the following messages striked me in that log file:
- Apparantly the load of the first segment source file succeeds but the 'appends' of the succeeding source files never happen.
- The error message comes after some 'admPreview' command . What is this admPreview command supposed to do and what command line in my script triggers a 'Preview' ?
extract from log file:
......(previous lines in log file)
[switchToSegment] Switched ok to segment 0 (dontdecode=0)
[start] admPreview,starting
*********** BACKTRACE **************
PythonEngine::runScript(std::string, IScriptEngine::RunMode) <+0x6DBF> [D:\users\hv\AVIDEMUX\avidemux_2.6_r7990_win32(no_installer)\libADM_coreScriptPython.dll]
unknown function <+0x6DBF> [unknown module]
*********** BACKTRACE **************
Cleaning up
......(following lines in log file)
Other: some idea why a JavaScript aborts with the "avidemux is not defined" message ?
Quote from: Jan Gruuthuse on May 31, 2012, 08:23:20 AM
In that case, if you have several versions (2.5.6, 2.6) installed to different paths, check you're using the intended one.
As stated in my initial post : NO Avidemux versions are "installed" (I am not a big fan of the Windows Register)
extract from my initial post :
Quote
Remark: actually, all my avidemux experiments - both with stable v.2.5.6 version and experimental v.2.6 versions are done with 'no-windows-installer' win32 builds.
As for using the intended one, I am quite confident (look at the command line example in my previous post in answer to mean).
OK, did overlook that.
Scripting could also cause problems when there are spaces or other ASCII like ( ) in the filenames/paths or length and depth could also be an issue. If I remember correctly form the old days?
Keep paths and names as short and simple as possible, specially while testing.
Quote from: Jan Gruuthuse on May 31, 2012, 11:04:41 AM
OK, did overlook that.
Scripting could also cause problems when there are spaces or other ASCII like ( ) in the filenames/paths or length and depth could also be an issue. If I remember correctly form the old days?
Keep paths and names as short and simple as possible, specially while testing.
Remember from my initial post: my scripts are 'replicata' of automatic generated scripts (projects) by avidemux when doing the same thing (join mpeg files) in GUI mode, with exactly the same fullpath/filenames.
So my guess is: if a script can do in avidemux GUI, then that script should also be able to do in avidemux CLI.
I believe the problems are rather elsewhere:
- why a JavaScript aborts with the "avidemux is not defined" message ?
- why does the Python script loads the first source file OK, but then chokes on that 'admPreview' command (+"unknown module" Python error ) and never appends the other source files (see log file attached in my previous post) ?
You could test the scripting and replace the avidemux_cli.exe with its graphic equivalent and see what is going on when scripting. Will be a bit annoying: opening and closing windows.
Regarding paths and filenames: In the program everything stays in that program, scripting passes info to external processes.
The javascript syntax is different between 2.5 & 2.6
tinyPy is the preffered way for 2.6
As far as the render issue is concerned, i'm looking into it
Quote from: Jan Gruuthuse on May 31, 2012, 02:10:06 PM
You could test the scripting and replace the avidemux_cli.exe with its graphic equivalent and see what is going on when scripting. Will be a bit annoying: opening and closing windows.
[/i]
Jan, this was a VERY GOOD IDEA.
The results are interesting:
(1) DOS commands, with avidemux.exe (GUI avidemux from avidemux_2.6_r7990_win32) in the command-line and Python .py script as the avidemux argument, work OK and produce a correct and clean result of a join of mpeg source files.
I tested both cases:
(a) with the avidemux '--save' argument in the DOS command line.
(b) with the 'adm.save(targetFile)' command in the Python script.
I verified with good old GSPOT and checked with the Visual GOP Structure function: the GOP structures, the number of frames, the B-frame dependencies, the closed GOPs, the coded-order versus presentation-order of the frames, the GOP structure of the last GOP and the B-frames in the last GOP of every segment; all is correct and all frames are there.
Conclusion #1: my Python script is correct but probably something in the actual V2.6 avidemux_cli.exe of a "non-installed" win32 build is not working correctly. I think someone should look into "
why does the Python script loads the first source file OK, but then chokes on that 'admPreview' command (+"unknown module" Python error ) and never appends the other source files (see log file attached in my previous post)".
For information, this is a tested DOS command line with avidemux.exe running a Python script:
"D:\users\hv\AVIDEMUX\avidemux_2.6_r7990_win32(no_installer)\avidemux.exe" --runpy "C:/My Programs and Doc/MyMpegJoiner/TEMPLATES/TestScript_SimpleJoin_BetaVersion.py" --quit >"C:\My Programs and Doc\MyMpegJoiner\LOG\TestScript_SimpleJoin_BetaVersion.log" 2<&1
(2) DOS commands, with avidemux.exe (GUI avidemux from avidemux_2.6_r7990_win32) in the command-line and JavaScript .js script as the avidemux argument, do NOT work ok.
Because the redirection of StandardOut and ErrorOut in my DOS command line do not work with a avidemux GUI executable, I can not check the error reason (but I guess it is still something like ""avidemux is not defined"). The avidemux GUI executable opens a fraction of a second but closes instantly.
Conclusion #2: someone should tell us whether yes or no v2.6 avidemux win32 builds are supposed to accept JavaScripts or if the 'needed to identify' code in the first line of the script should be adapted.
For information, this is the DOS command line with avidemux.exe not liking my Javascript:
"D:\users\hv\AVIDEMUX\avidemux_2.6_r7990_win32(no_installer)\avidemux.exe" --run "C:/My Programs and Doc/MyMpegJoiner/TEMPLATES/TestScript_SimpleJoin_BetaVersion.js" --quit >"C:\My Programs and Doc\MyMpegJoiner\LOG\TestScript_SimpleJoin_BetaVersion.log" 2<&1
Thanks again for the suggestion, but I will leave this thread open, because the real problem (avidemux_cli.exe not working) persists.
Quote from: mean on May 31, 2012, 03:18:53 PM
The javascript syntax is different between 2.5 & 2.6
tinyPy is the preffered way for 2.6
OK, that is good to know.
But in my initial post I was more concerned about the difference in argument
contents between a V2.5.6 addSegment script command and a v2.6 addsegment script command (independant from the language in which the script is written).
For me a command 'addSegment(segmentNumber,beginFrameNumber,endFrameNumber)' is essentially different from a command 'addSegment(segmentNumber,beginTime,endTime)
But if you want, I can open a different thread for this kind of subject, and remain concentrated in this thread on the main issue: how to make avidemux cli + script work in a win32 environment.
I've seen mean made new revision available, can you test that one? most likely dealing with your issue?
2.60 r7996 http://avidemux.org/nightly/
Quote from: Jan Gruuthuse on May 31, 2012, 04:18:33 PM
I've seen mean made new revision available, can you test that one? most likely dealing with your issue?
2.60 r7996 http://avidemux.org/nightly/
Allright, I did my test of the DOS command, with avidemux_cli.exe (CLI avidemux from nightly 2.60 r7996 win32) in the command-line and Python .py script as the avidemux argument.
The DOS command line is as follows:
"D:\users\hv\AVIDEMUX\avidemux_r7996_win32\Release\avidemux_cli.exe" --runpy "C:/My Programs and Doc/MyMpegJoiner/TEMPLATES/TestScript_SimpleJoin_BetaVersion.py" --quit >"C:\My Programs and Doc\MyMpegJoiner\LOG\TestScript_SimpleJoin_BetaVersion.log" 2<&1
The script file TestScript_SimpleJoin_BetaVersion.py contains following script:
#PY <- Needed to identify#
#--automatically built--
#--Project: C:/My Programs and Doc/MyMpegJoiner/TEMPLATES/TestScript_SimpleJoin_BetaVersion.py
adm=Avidemux()
targetFile="E:/PANASONIC_CAPTURES/STEP_3_JOIN_AVIDEMUX_AVI/VARIA1/OUTPUT_BY_PY.MPG"
#** Video **
# 03 videos source
adm.loadVideo("E:/PANASONIC_CAPTURES/STEP_3_JOIN_AVIDEMUX_AVI/VARIA1/2000-01-01_00.MPG")
adm.appendVideo("E:/PANASONIC_CAPTURES/STEP_3_JOIN_AVIDEMUX_AVI/VARIA1/2000-01-01_01.MPG")
adm.appendVideo("E:/PANASONIC_CAPTURES/STEP_3_JOIN_AVIDEMUX_AVI/VARIA1/2000-01-01_02.MPG")
#** Postproc **
adm.setPostProc(0,0,0)
#** Video Codec conf **
adm.videoCodec("Copy")
#** Filters **
#** Audio **
adm.audioClearTracks()
#** Track 0 **
adm.audioAddTrack(0)
adm.audioCodec(0,"copy");
adm.audioSetPal2Film(0,0)
adm.audioSetFilm2Pal(0,0)
adm.audioSetNormalize(0,0,0)
#** Muxer **
adm.setContainer("ffPS","muxingType=2","acceptNonCompliant=True","muxRatekBits=11000","videoRatekBits=9800","bufferSizekBytes=224")
adm.save(targetFile)
#End of script
The log file with redirected StandardOut and redirected ErrorOut of the test with avidemux_cli.exe 2.60 r7996 is in attachment.
(I made a reduction: deleted similar error messages because the original log file is really hugh)
These are the results:
(1) There is progress in so far that now the 'appends' of the other source files start working (in the previous builds only the 'load' of the first source seemed to work).
But what strikes me: at
every append of a source file, the program seems to do a rescan of ALL similar .mpg source files as if the program is willing to do an automatic append.
So : if for example a directory contains 100 .mpg source files and I want to join (Load+append) these 100 .mpeg source files, than the program will do 100*100 rescans (=10 000). Does not seem performant (and will flood a log file or in my case a streamreader who will be "listening" for progress information).
Reminder: this rescan does not happen with the v2.5.6 version. In the log file of a similar run with v2.5.6 avidemux_cli.exe, you will find a message like "There was several files, but dont append was forced" and no more scans are done when each source file is appended.
(2) After the 'load'+'append' messages in the log file followed a hugh portion (more than 2 megabytes, now reduced) of error overflow messages (as a result of these errors, no output is generated): this is certainly something to work on.
The buffer underflow warning are not really a problem
I'm more concerned about these ones
[AudioStream] Warning skew in dts =-55608000,
[AudioStream] Warning skew lastDts= 00:00:55,648
[AudioStream] Warning skew newDts= 00:00:00,040
Could you provide a couple of files which, when joined produce these messages ?
They dont need to be be long
If the files are too large, does these skew messages appear when you use the Qt4 version ?
Quote from: mean on May 31, 2012, 07:21:42 PM
If the files are too large, does these skew messages appear when you use the Qt4 version ?
First of all: thank you very much for spending your time on my problem case.
As to Qt4 version : could you please point me to a v.2.6 win32 build that contains an avidemux_Qt4.exe (and works on Windows XP) ;I have access to archive builds on this site http://sourceforge.net/projects/avidemux-mswin/files/beta/2.6/ (http://sourceforge.net/projects/avidemux-mswin/files/beta/2.6/).
From searching the forum, I understood that a Qt4 executable can be launched from the command line. Is that right ? But will redirection of StandardOut and ErrorOut work in that case, so that I can capture a complete log of all what happens ? (I work in a Windows environment... ;D).
For the tests: give me a few hours and I'l be back with the result.
Edit 06h06 : forget my question about redirection of StdOut and ErrOut. I can always look in user\Application Data\avidemux\admlog.txt.
Quote from: mean on May 31, 2012, 07:21:04 PM
The buffer underflow warning are not really a problem
I'm more concerned about these ones
[AudioStream] Warning skew in dts =-55608000,
[AudioStream] Warning skew lastDts= 00:00:55,648
[AudioStream] Warning skew newDts= 00:00:00,040
Could you provide a couple of files which, when joined produce these messages ?
They dont need to be be long
Is there a "threshold" skew value from which on there is reason to be concerned ?
For example: are following skew values relevant for the case or do I have to search better examples (I am looking for the smallest files possible)
[switchToSegment] Switched ok to segment 0 (dontdecode=0)
[ADM_videoStreamCopy] Fixating start time by 0
[ADM_videoStreamCopy] Starting DTS=0, PTS=262 ms
[goToTime] go to time 0.00 secs
[goToTime] => seg 0, rel time 0.00 secs
[AudioStream] Warning skew in dts =262222,
[AudioStream] Warning skew lastDts= 00:00:00,000
[AudioStream] Warning skew newDts= 00:00:00,262
[setupAudio] Setting up 1 audio track(s)
[setupAudio] [audioTrack 0] Creating audio encoding stream, starttime 00:00:00,000 (copy)
[goToTime] go to time 0.00 secs
[goToTime] => seg 0, rel time 0.00 secs
[AudioStream] Warning skew in dts =262222,
[AudioStream] Warning skew lastDts= 00:00:00,000
[AudioStream] Warning skew newDts= 00:00:00,262
[FF] Muxer opened
EDIT 7h10 : I am not so certain you should be concerned about the 'Warning skew' messages.
The 'Warning skew' sample message I provided above comes when joining this files in this order:
(1) First source (load): file 2000-01-01_32.MPG
(2) Second source (append) : file 2000-01-01_33.MPG
But when I do the joining of the same files in the following order:
(1) First source (load): file 2000-01-01_33.MPG
(2) Second source (append) : file 2000-01-01_32.MPG
then the 'Warning skew' messages become as follows:
[AudioStream] Warning skew in dts =-4752000,
[AudioStream] Warning skew lastDts= 00:00:04,792
[AudioStream] Warning skew newDts= 00:00:00,040
If you check the duration of file 2000-01-01_33.MPG (=4sec800)(*), then you will see that the 'skew' = duration of the first joined file if you inverse the "logical" (? whatever that means) order of the two files in a join.
The initial sample result (the one with the 'skew' of 55 sec) comes from a set of files, provided to me by the owner of the files. The files in this test set were originally named 2000-01-01.MPG, 2000-01-01_01.MPG, 2000-01-01_02.MPG, etc.
To make the test set coherent, I renamed the 2000-01-01.MPG file to 2000-01-01_00.MPG (and I am not even certain these files were transfered from the same SD memory card). In this case, the 55 sec 'skew warning' corresponds to the duration of file 2000-01-01_00.MPG in the join-experiment; file 2000-01-01_00.MPG being the first file in the join.
(*) I still feel unhappy the way avidemux 2.6 expresses the 'duration' of file, example : 18.9422222 sec for a file of 466 frames at 25 fps (I am used to the simple arithmetics: for MPEG2 video, duration is calc NumberOfFrames/FPS)
If nevertheless you want to continue the 'skew warning' investigations, please let me know.
Quote from: SeventyPlus on May 31, 2012, 05:56:27 PM
2000-01-01_00.MPG
2000-01-01_01.MPG
2000-01-01_02.MPG
This naming scheme may cause the auto append function even when appending one file?
QuoteBut what strikes me: at every append of a source file, the program seems to do a rescan of ALL similar .mpg source files as if the program is willing to do an automatic append.
So : if for example a directory contains 100 .mpg source files and I want to join (Load+append) these 100 .mpeg source files, than the program will do 100*100 rescans (=10 000). Does not seem performant (and will flood a log file or in my case a streamreader who will be "listening" for progress information).
Reminder: this rescan does not happen with the v2.5.6 version. In the log file of a similar run with v2.5.6 avidemux_cli.exe, you will find a message like "There was several files, but dont append was forced" and no more scans are done when each source file is appended.
Don't know if the developers already addressed/planned
--append no switch, stopping auto append. Issue raised here: batch processing: append (http://www.avidemux.org/smf/index.php?topic=10247.0)
A skew more than a few ms is a problem
The only case where it is "normal" is when the file are autoloaded because they are sequential (i.e. a001.mpg, a002.mpg) because in that case
no timing correction is done as the file are considered to be one logicial file split into several physical files
Quote from: mean on June 01, 2012, 04:44:55 AM
A skew more than a few ms is a problem
The only case where it is "normal" is when the file are autoloaded because they are sequential (i.e. a001.mpg, a002.mpg) because in that case
no timing correction is done as the file are considered to be one logicial file split into several physical files
May I conclude that when a user manually joins several files (whether yes or no they come from a set) i
n the order the user prefers, then this becomes a problem for avidemux ? Or will avidemux be capable to produce allways a correct mpeg program stream, whatever the input "order" of the source files ?
The response is very important for me, because the GUI application I am developping (to be used by someone else) is explicitly based on the principle that the user can freely pick which files he will join (even from different "sets" and directories) and freely choose the order in which the source files will be joined (provided all source files have identical characteristics).
If you choose the files one per one, the timing will be automatically corrected
If you load 1 file and let it autoload the others, no timing correction is done
Problem status on 02 june 2012:
- With V2.6 avidemux_r7996_win32 (nightly) version, the CLI executable (avidemux_cli.exe) with tinyPy scripts now produces 'joined' program stream MPEG output files (.mpg) with correct video (no longer are 2 B-frames lost at the end of each segment, as what happened with V2.5.6).
I then concentrated on audio checks with the V2.6 r7996 win32 version, joining MPEG sources with 'plain stero' audio (= MPEG Audio Version 1 Layer 2, CBR, 256 kbps, sample rate 48 kHz, 2 channels) into an MPEG Program stream output.
This are my findings :
- With both CLI and GUI executables, when joining multiple mpeg source files (= pure copy, without transcoding neither video nor audio), audio is present in the beginning of the output but from a 'variable-and-I-cannot-find-the-pattern' moment on there is no more audio in the output.
When audio ceases to be present, it is always on an imput segment boundary, but never on the same boundary and never for the same input file (*).
No audio present means: there is no audio. To check that, I demultiplexed (with TMPGenc) the MPEG program stream output and imported the elementary audio stream in Audacity to check and measure the length.
The problem occurs at every 'join' test I did, both with CLI executable and GUI executable (also tested with the nigthly updated version of avidemux_r7996_win32 of 02-Jun-2012 06:46).
As I said: I cannot find a pattern, but I made certain to have a final test set of input source files with each individual source file having produced audio in the output during a previous test (where of course the sequence-order of the input files in the test-set was different).
I tested with the files in "ascending" and "descending" order (files are named 2000-01-01_nn.MPG, where nn is the variable) but no fixed pattern appears. At a moment I thought I found a pattern when all tests with test-sets of files in "descending" order ceased to produce audio after 7 segments (no audio more from the 8th segment on), but this pattern is broken with tests in "ascending" order (in tests with "ascending" ordered input files, there was no more audio in the output from the 4th segment on), but this may all be coincidence.
I also checked (with Audacity) if audio in the output was limited on a "total-time" boundary, but that does not seem the case (example of some "total audio durations" in the output: 43 sec, 1m05sec).
The log file of one test is huge (> 4Mbyte). Error lines that concern me, are like this:
[adm_lavLogCallback] [lavc] buffer underflow i=0 bufi=23855 size=25080
[adm_lavLogCallback] [lavc] buffer underflow i=0 bufi=794 size=9264
[adm_lavLogCallback] [lavc] buffer underflow i=0 bufi=2813 size=9264
[adm_lavLogCallback] [lavc] buffer underflow i=0 bufi=4832 size=9264
[adm_lavLogCallback] [lavc] buffer underflow i=0 bufi=6851 size=9264
[adm_lavLogCallback] [lavc] buffer underflow i=0 bufi=8870 size=9264
[adm_lavLogCallback] [lavc] buffer underflow i=1 bufi=42 size=768
[AudioStream] Warning skew in dts =-14832000,
[AudioStream] Warning skew lastDts= 00:00:14,872
[AudioStream] Warning skew newDts= 00:00:00,040
[adm_lavLogCallback] [lavc] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 3948319 >= 2615599
[saveLoop] [FF]Error writing audio packet
[adm_lavLogCallback] [lavc] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 3948319 >= 2617759
[saveLoop] [FF]Error writing audio packet
[adm_lavLogCallback] [lavc] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 3948319 >= 2619919
[saveLoop] [FF]Error writing audio packetMy request: is someone willing to look into this issue.
I can of course provide: the CLI command line + py script (or the saved job for a GUI 'join' test) and the corresponding log file.
But can someone tell me the procdure for providing a 200 kilobyte (rar compressed format) log file:
- Can such a 200 kbyte file be "attached" to a forum post ?
- Or is there an avidemux ftp server for this, where someone can put input to, and in that case: is there a 'ticket' procedure and rule for name-references of the input provided ?
(*) My audio-tests were 'contaminated' by the fact that V2.6 avidemux (both GUI and CLI) wrongly indexed one particular source file (the audio section is missing in the idx2 file). This one particular mpeg source file has audio in it and is correctly indexed by avidemux v2.5.6. For this v2.6 indexing problem, I prefer to start a different Post.
Please use rapidshare or similar to upload large files.
Are you sure the files are loaded one per one and not auto-appent ?
The loss of audio is probably linked to the skew, i.e. discontinuous audio
As mean says. You can check this if each video in that folder processed has it's own index (.idx2). While testing better to delete these, when these where made by a previous avidemux 2.6 (lower revison number as the one your testing)
Quote from: mean on June 02, 2012, 08:17:36 AM
Please use rapidshare or similar to upload large files.
Are you sure the files are loaded one per one and not auto-appent ?
The loss of audio is probably linked to the skew, i.e. discontinuous audio
Following information documents the problem that, when joining with avidemux v.2.6.0 r7996 (and previous builds) several MPEG2 Program stream source files (coming from a Panasonic SD video camera) into one single MPEG program stream output file, at some point there is no more audio in the output file (see Reply #24 for a description of the problem).
This documented test was done with the GUI program of avidemux v.2.6.0 r7996 win32 : all input source files where manually loaded one per one ('load' for the first source file, then 'append' for each other source file), no auto-append was done.
The join of the source files is a "raw" join (copy), no trimming of the input sources was done.
The characteristics of the input source files are as follows (information gathered with MediaInfo); all input source files have identical characteristics.
Example
characteristics of input source file 2000-01-01_01.MPG (by MediaInfo)
General
Complete name : E:\PANASONIC_CAPTURES\STEP_3_JOIN_AVIDEMUX_AVI\VARIA1\2000-01-01_01.MPG
Format : MPEG-PS
File size : 14.5 MiB
Duration : 18s 648ms
Overall bit rate mode : Variable
Overall bit rate : 6 524 Kbps
Video
ID : 224 (0xE0)
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : M=3, N=12
Duration : 18s 640ms
Bit rate mode : Variable
Bit rate : 6 138 Kbps
Maximum bit rate : 9 558 Kbps
Width : 704 pixels
Height : 576 pixels
Display aspect ratio : 1.738
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.605
Stream size : 13.6 MiB (94%)
Color primaries : BT.470-2 System B, BT.470-2 System G
Transfer characteristics : BT.470-2 System B, BT.470-2 System G
Matrix coefficients : BT.470-2 System B, BT.470-2 System G
Audio
ID : 192 (0xC0)
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 2
Duration : 18s 648ms
Bit rate mode : Constant
Bit rate : 256 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 583 KiB (4%)
The
content of the project file (automated generated tinyPi script), created by the GUI program avidemux V2.6 rr7996 win32 for this particular 'copy' join test is as follows:
#PY <- Needed to identify#
#--automatically built--
#--Project: C:/My Programs and Doc/MyMpegJoiner/TEMPLATES/JoinScript_Files01+02+75-81+00_v26r7776_Project.py
adm=Avidemux()
#** Video **
# 10 videos source
adm.loadVideo("E:/PANASONIC_CAPTURES/STEP_3_JOIN_AVIDEMUX_AVI/VARIA1/2000-01-01_01.MPG")
adm.appendVideo("E:/PANASONIC_CAPTURES/STEP_3_JOIN_AVIDEMUX_AVI/VARIA1/2000-01-01_02.MPG")
adm.appendVideo("E:/PANASONIC_CAPTURES/STEP_3_JOIN_AVIDEMUX_AVI/VARIA1/2000-01-01_75.MPG")
adm.appendVideo("E:/PANASONIC_CAPTURES/STEP_3_JOIN_AVIDEMUX_AVI/VARIA1/2000-01-01_76.MPG")
adm.appendVideo("E:/PANASONIC_CAPTURES/STEP_3_JOIN_AVIDEMUX_AVI/VARIA1/2000-01-01_77.MPG")
adm.appendVideo("E:/PANASONIC_CAPTURES/STEP_3_JOIN_AVIDEMUX_AVI/VARIA1/2000-01-01_78.MPG")
adm.appendVideo("E:/PANASONIC_CAPTURES/STEP_3_JOIN_AVIDEMUX_AVI/VARIA1/2000-01-01_79.MPG")
adm.appendVideo("E:/PANASONIC_CAPTURES/STEP_3_JOIN_AVIDEMUX_AVI/VARIA1/2000-01-01_80.MPG")
adm.appendVideo("E:/PANASONIC_CAPTURES/STEP_3_JOIN_AVIDEMUX_AVI/VARIA1/2000-01-01_81.MPG")
adm.appendVideo("E:/PANASONIC_CAPTURES/STEP_3_JOIN_AVIDEMUX_AVI/VARIA1/2000-01-01_00.MPG")
#10 segments
adm.clearSegments()
adm.addSegment(0,0,18942222)
adm.addSegment(1,0,10080000)
adm.addSegment(2,0,14880000)
adm.addSegment(3,0,13440000)
adm.addSegment(4,0,10560000)
adm.addSegment(5,0,5982222)
adm.addSegment(6,0,7902222)
adm.addSegment(7,0,5982222)
adm.addSegment(8,0,5502222)
adm.addSegment(9,0,55680000)
adm.markerA=0
adm.markerB=148951110
#** Postproc **
adm.setPostProc(0,0,0)
#** Video Codec conf **
adm.videoCodec("Copy")
#** Filters **
#** Audio **
adm.audioClearTracks()
#** Track 0 **
adm.audioAddTrack(0)
adm.audioCodec(0,"copy");
adm.audioSetPal2Film(0,0)
adm.audioSetFilm2Pal(0,0)
adm.audioSetNormalize(0,0,0)
#** Muxer **
adm.setContainer("ffPS","muxingType=2","acceptNonCompliant=False","muxRatekBits=11000","videoRatekBits=9800","bufferSizekBytes=224")
#End of script
This project file shows in which order the source files were loaded. The join of the source files is a "raw" join (copy), no trimming of the input sources was done.
In the output MPEG program stream .MPG file, audio is present for the 3 first segments (segment #0 2000-01-01_01.MPG, segment #1 2000-01-01_02.MPG and segment #2 2000-01-01_75.MPG), but audio is missing in the output starting from segment #3 (2000-01-01_75.MPG) and this until the end of the output file.
Each individual source file has audio and, when joined in a different order, the audio of that source file may (or may not) be present in the output.
The
log file produced by avidemux GUI V2.6 r7996 win32 GUI for this particular test (admlog.txt) is available for download at this URL (available for 30 days): http://home.scarlet.be/hvda/avidemux01/ (http://home.scarlet.be/hvda/avidemux01/) (log file in rar packed size: 200KB, unpacked: 4MB)
[EDIT August 14 2012 : download no longer available]
Similar tests, done with avidemux_cli v2.6r7996 win32 CLI (instead of GUI), produce similar results : at some point in the output file, there is no more audio.
The difference between the GUI generated script (project file) and my CLI script files is : in my CLI script file there is no 'clearSegments', no 'addSements', no 'markerA' and no 'markerB' commands.
Remarks:
- The same source files can be joined with avidemux V2.5.6 without audio loss in the output.
These files will certainly have different timings, but the purpose of these tests is: to evaluate the capability of avidemux to join source files where "the user can freely pick which files he will join (even from different "sets" and directories) and freely choose the order in which the source files will be joined (provided all source files have identical characteristics)". So if there are timing differences between source file, my understanding is that "If you choose the files one per one, the timing will be automatically corrected" (by avidemux).
I hope that this information may contribute in finding a correction for this issue.
EDIT: 03 june 2012 12h10 : same result as described above when test done with 'nightly' r79997 win32
Looks like from where you selected the file to append, it auto appends the remaining video parts that follow in sequence and by doing so not making the a seperate .idx2 for the appended video?
Can't change the --append behavior as it has no parameter to auto append or not?
Unless you would try to not append in the job (.py)
But append each file at a time from script that passes filename to command line that runs job.py?
Also try to build the index file at this stage with --index-mpeg.
Don't know if this will work as expected?
Reduce your folder only to 10 video clips for testing. makes test shorter and probably no memory problems in this stage.
command line usage (http://www.avidemux.org/admWiki/doku.php?d=using:command_line_usage)
Quote from: Jan Gruuthuse on June 04, 2012, 06:13:26 AM
Looks like from where you selected the file to append, it auto appends the remaining video parts that follow in sequence and by doing so not making the a seperate .idx2 for the appended video?
Can't change the --append behavior as it has no parameter to auto append or not?
Unless you would try to not append in the job (.py)
But append each file at a time from script that passes filename to command line that runs job.py?
Also try to build the index file at this stage with --index-mpeg.
Don't know if this will work as expected?
Reduce your folder only to 10 video clips for testing. makes test shorter and probably no memory problems in this stage.
command line usage (http://www.avidemux.org/admWiki/doku.php?d=using:command_line_usage)
Jan,
I would like to remind that the documented test was not done by starting an avidemux executable (neither avidemux3.exe nor avidemux_cli.exe) from the command line but was done with the interactive avidemux GUI version, and that :
Quoteall input source files where manually loaded one per one ('load' for the first source file, then 'append' for each other source file), no auto-append was done.
I preferred to submit the test-result of a plain GUI test, rather than a CLI test, in order to cut short on all eventual discussions on whether my own py scripts are good or not, so that we can keep concentrated on the real problem.
We should also keep in mind that:
QuoteThe same source files can be joined with avidemux V2.5.6 without audio loss in the output.
Some jobs are better handled by 2.5.6 others by 2.6. 2.5.6 is frame based, 2.6 is timed based. 2.6 would be orientated more to H.264 and AVC, ... like HD TV streams. 2.5.6 would be mpg, SD TV, ...
If something does not work in 2.6, I switchback to 2.5.6.
So you did reply every time, when you appended a video part on the all ready loaded video, no to the question where avidemux asks to load the other parts?
the manually part was misunderstood here. Understood this was done in your VB script and passed on to ....
Basic test: erase all .idx2 files in that folder
load 00.mpg
save exit and verify only 1 .idx2 index found for 00.mpg take note of its size
erase all .idx2 files in that folder
load 00.mpg
append 01.mpg
append 72.mpg
save
for what videos do you find .idx2 indexes?
is size for 00.mpg .idx2 the same as 1st time or not.