Avidemux Forum

Ich habe gelesen, daß in einem TS-Stream sogenannte Null-Bytes (oder Füll-Bytes) enthalten sind. Das Programm TS-Doctor soll in der Lage sein, solche Null-Bytes (oder Füll-Bytes) zu entfernen. Wie groß ist ungefähr der Anteil von Null-Bytes bei so einer TS-Datei? Lohnt es sich hier überhaupt, Null-Bytes zu entfernen?

Wenn ich eine Sendung von den öffentlich-rechtlichen Sendern in HD aufnehme, hat so eine Aufnahme schnell mal 6 GB bis 8 GB und mehr. Wenn diese Sendung in Mediathekwebview verfügbar ist, ist die Sendung um ein Vielfaches kleiner, vielleicht so 3 GB groß. Ich könnte hier nun vermuten, daß dieser Größenunterschied zum Teil an diesen Null-Bytes liegt. Liegt das daran?

Kann Avidemux auch Null-Bytes entfernen? Gibt es ein anderes kostenloses Programm (z.B. ffmpeg), daß zügig solche Null-Bytes aus einen TS-Stream entfernt?

Ich nehme nur Sendungen auf von den öffentlich-rechtlichen und den privaten Sendern über Satellit. Alle aufgenommenen Sendungen sind in 720p oder 1080i (H.264). Meine Fragen oben beziehen sich nur auf 720p oder 1080i Aufnahmen.

I am running Avidemux V2.82 on windows 11.

I generally use the DRC settings with the default options. However, at times the resultant audio volume still varies to much with some areas too soft and others quite loud.

I understand most of the setting except the 'Ratio' and 'Normalize' settings.

Could someone please explain the meaning of these settings?

Usually, inconsistent indentation in Python should not work, at least, one should not use it ;-)

What is the purpose of encoding the audio track with LAME in default configuration to MP3 when better codecs (AAC) are available?

Is throwing an exception on encountering a file without an audio track while ignoring a possible failure of save() deliberate or just a blind copy from other people's old scripts?

Anyway, you could use something like

# -------- select input directory --------
inputFolder = ui.dirSelect("Select source folder")
if inputFolder is None:
    ui.displayError("Oops", "No source folder selected")
    return

# -------- read content --------
list = get_folder_content(inputFolder, ext)
if list is None:
    ui.displayError("Oops", "No " + ext + " files found in \"" + inputFolder + "\"")
    return

# -------- select output directory --------
outputFolder = ui.dirSelect("Select output folder")
if outputFolder is None:
    ui.displayError("Oops", "No output folder selected")
    return

if(inputFolder == outputFolder):
    ui.displayError("Error","Output folder cannot be the same as the input one")
    return
To strip directory from filein, use

filein = basename(filein)
and pass outputFolder + "\\" + filein as argument to save().

Working script, but I need to change the output location to a different folder other than the input folder (c:\tmp).

Since it will be saved to a different folder, I want to use the same filename that is being loaded (like in this one), but without the ".edit.mp4"


ext="mp4"
inputFolder="c:\\tmp\\"
#
def convert(filein):
    if(0 == adm.loadVideo(filein)):
        ui.displayError("oops","cannot load "+filein)
        raise
    adm.videoCodec("Copy")
    adm.audioClearTracks()
    adm.setSourceTrackLanguage(0,"und")
    if adm.audioTotalTracksCount() <= 0:
            raise("Cannot add audio track 0, total tracks: " + str(adm.audioTotalTracksCount()))
    adm.audioAddTrack(0)
    adm.audioCodec(0, "Lame")
    adm.audioSetDrc(0, 1)
    adm.audioSetShift(0, 0, 0)
    adm.audioSetNormalize2(0, 2, 150, -30)
    adm.setContainer("MP4", "muxerType=0", "optimize=1", "forceAspectRatio=False", "aspectRatio=1", "displayWidth=1280", "rotation=0", "clockfreq=0")
    adm.save(filein+".edit.mp4")

    print("Done")

#
# Main
#
ui=Gui()
adm=Avidemux()
#
list=get_folder_content(inputFolder,ext)
if(list is None):
    raise
for i in list:
        convert(i)
print("Done")



Thanks a lot eumagga0x2a! You have solved my problem as by using the latest version available, fast conversion has come back again!! . However, if possible, I would like to keep the thread open in case other slow conversion-related problems may arise.

You need to know the frame by frame image rate for the original media.  29.97 fps is a NTSC US Standard TV playback speed.  Any 24 fps original movie can be converted to playback in 29.97 by adding in a 3:2 pulldown which is a staggered repeat every 4th frame.  We cannot see this happening and often no one looks closely at the frame by frame sequence to check for this issue.  It's usually there on films converted to DVD or films from standard TV recording.

Showing frame by frame you get this in a 3:2 pulldown.

A B C D D E

Frame D is duplicated and playback is 29.97 fps.  Now, how do you get the new number?

29.97 * 4/5 = 23.976

This can take away the duplicate D frame.  The problem becomes it is not easy to do this precisely because the editing software tries to guess where the duplicate frames are, but any time someone has edited the master or if the editing software cannot find the duplicate frames, it will miss or get out of order.  So, the answer to that is either to have production quality editor with a original master media or just set the frames to blend when you convert the fsp.  This way, any missed frame is smoothed over.

All well and good, but what happens if 29.97 fps is converted to a slower fps, without any attempt to find the duplicate frames or if the original media was already converted to some other fps like 25 fps for PAL TV in the UK, or 30 fps because many editors have that as a default setting?  Then you have a messed up copy that is far from being master original.  Now changing the fps again, can really mess it up and cause stuttering.

So, it's important to look closely and with what the media is exactly.  Open it in the editor and advance frame by frame to see if the 29.97 fps was converted from an original 24 fps using a 3:2 pulldown and duplicating the 4th frame. Every 4th frame will duplicate. If so, then you want to set the filter to remove the 3:2 pulldown go to 23.976 fps and blend the frames.

If the media is has different staggered frames, is an old film running at 30 fps, or all frames are already blended, then it's already been copied and the only option is if you have to edit it, try to leave the fps alone and maybe it will play back without stuttering with the new codec or whatever you are doing.

If the media is 25 fps and it's a US / Canadian film, it's probably just been sped up for playback in the UK. If there are no repeated frames, then changing the fps to 24 with the first filter that also changes the speed and length of the content could make people sound better and the music back to the correct tuning. Sometimes you can spot this if the media length is 24/25 as long as it is suppose to be.

Hope that helps.

Please start by...

1) ...using the latest available official appImage or build Avidemux from source yourself (best);

2) ...providing some usable information, i.e. the properties of the source MKV and MP4 files you are converting (re-encoding) as reported by MediaInfo (do not paste the textual output of MediaInfo into the body of a post, but attach it to your reply instead), the filter chain in use, the settings of the video encoder plugin in Avidemux etc.

Quote from: sl1pkn07 on December 30, 2025, 12:39:55 AMneeds fix for use to "new" API v4

Ideally, yes. Disabling VapourSynth >= 73 to fix build for now: https://github.com/mean00/avidemux2/commit/23b1d8fb1e931660a1a8f1f3cab20186a7b74eb0

Thank you for the heads-up.

Ouch and Bingo:
the solution is provided by the 7z command line switch/value "-t#", which type-triggers the 7z extractor to operate in parser mode,
eg.:  7z x afile.exe  -t#
Solved ..

And for to grep only the .7z files from the setup container: using the -i switch:
eg.:  7z x afile.exe  -t#    -i!*.7z

Hi

vapoursynth removes recently the support for VSScript API3 https://github.com/vapoursynth/vapoursynth/commit/ae7fa51078eacc75f0a6fba16eb4de9c21c6a80e

this means avidemux stop build due missing file in https://github.com/mean00/avidemux2/blob/master/avidemux_plugins/ADM_demuxers/VapourSynth/ADM_vsProxy.h#L20

needs fix for use to "new" API v4

greetings