AVANTI - FFmpeg/Avisynth GUI (support thread).

[Gavino]

I can't use the % character as a key because Windows allows % in file names. E.g.; "test%video%clip.avi" is a valid file name and even "img%03d.jpg" would be valid if you really renamed a jpeg to this.

It seems that ffmpeg always takes a name like "img%03d.jpg" as meaning an image sequence - when given an existing file of that name (or even "img%vid.jpg", which doesn't make sense as a format string), it throws an error.

Another issue you would have to consider if doing this is whether to allow Avisynth processing for such a source. You could use ImageSource as the source filter, but you would need to know how many images were in the sequence.

[Chris K]

It seems that ffmpeg always takes a name like "img%03d.jpg" as meaning an image sequence - when given an existing file of that name (or even "img%vid.jpg", which doesn't make sense as a format string), it throws an error.

Did some experiments where I still used % as a key to skip file validity checking. I then enterted "G:/image sequence/movie%03d.jpg" at "Source 1" and it works better than expected. FFmpeg does count the number of images and calculate the duration itself in conjunction with the selected destination frame rate This means progress display will stay fully functional.

Input #0, image2, from 'G:/image sequence/movie%03d.jpg':
  Duration: 00:00:04.24, start: 0.000000, bitrate: N/A
    Stream #0.0: Video: mjpeg, yuvj420p, 720x576, 25 fps, 25 tbr, 25 tbn, 25 tbc
---------------------------------------------------------------------------------
Output #0, avi, to 'F:/temp/test_final.mp4':
    Stream #0.0: Video: libx264, yuvj420p, 320x240, q=10-51, 750 kb/s, 25 tbn,
      25 tbc
---------------------------------------------------------------------------------
Stream mapping:
  Stream #0.0 -> #0.0

Another issue you would have to consider if doing this is whether to allow Avisynth processing for such a source. You could use ImageSource as the source filter, but you would need to know how many images were in the sequence.

I want to leave that as an option in Avisynth user mode. I have already some "source 1" path adaption when SegmentedXXsource() commands are used in a user script. Perhaps I can expand that with ImageSource. I'll look at it.

EDIT:

The opposite (save image sequence from a video clip) can already be done with the current Avanti version.

At the "User Video options" command line, I used -f image2 -vcodec mjpeg.

Jpeg quality can be set at the "VBR qscale" field. I used 1 for best quality.

At the "Destination" file path set C:/your destination path/image%03d.jpg.user

The extra .user extension is a switch that locks the automatic extension update.

[Chris K]

Another issue you would have to consider if doing this is whether to allow Avisynth processing for such a source. You could use ImageSource as the source filter, but you would need to know how many images were in the sequence.

The same path I used for FFmpeg "G:/image sequence/movie%03d.jpg" is also accepted in a Avisynth script like...

ImageSource("@source1_path", 0, 106, 25.00)

It's all low-level and expects the user to be familiar with C language like format strings but it enables working with image sequences. I wonder if it would help much if I try to make it more user friendly?

[Gavino]

Thanks for following this up, Chris.

The same path I used for FFmpeg "G:/image sequence/movie%03d.jpg" is also accepted in a Avisynth script like...
ImageSource("@source1_path", 0, 106, 25.00)

That's right. I assume you have to do some work scanning the file directory to work out that 0 and 106 are the required start and end numbers, as I don't think ffmpeg will give you that information. From a simple test, it looks like ffmpeg starts at the lowest numbered existing file and continues consecutively until no file exists for a number (even if higher numbered files exist, ie no gaps are allowed in the sequence).

It's all low-level and expects the user to be familiar with C language like format strings but it enables working with image sequences. I wonder if it would help much if I try to make it more user friendly?

I'd be happy just with the low-level approach, in fact I'd prefer it as that's a straightforward mapping to ffmpeg and Avisynth. You don't really need to know the full format-string syntax (far less the C language), just be aware that "%d" stands for a number and can optionally be qualified by a number of digits, with leading zeros ("%04d") or without ("%4d").

[Chris K]

FFmpeg does count the number of images and calculate the duration itself in conjunction with the selected destination frame rate

This needs a correction. FFmpeg does count the images and calculates the duration based on a default of 25 fps.
If you want to change this, you need to add a infile framerate to the command line like e.g. ...

ffmpeg -r 23.976 -i "infile%04d.jpg" -vcodec libxvid -r 23.976 -y outfile.avi

The infile framerate comes close to the framerate you have to give in the Avisynth ImageSource() command, except that FFmpeg doesn't accept a range. It simply process the lowest to highest that matches the format pattern.

[Gavino]

The infile framerate comes close to the framerate you have to give in the Avisynth ImageSource() command

It should be the same, at least up to 7 significant figures.
Note that Avisynth's Info() only reports the framerate to 4 decimal places, so you can't rely on that to be an exact statement of the actual rate used.

except that FFmpeg doesn't accept a range. It simply process the lowest to highest that matches the format pattern.

With the qualification that I mentioned - it stops as soon as a gap is found, so if you use "img%03d.jpg" and files img002.jpg, img003.jpg and img005.jpg exist, it will only use the first two. (By contrast, Avisynth's ImageSource gives a blank frame for any missing files.)

[Chris K]

except that FFmpeg doesn't accept a range. It simply process the lowest to highest that matches the format pattern.

With the qualification that I mentioned - it stops as soon as a gap is found, so if you use "img%03d.jpg" and files img002.jpg, img003.jpg and img005.jpg exist, it will only use the first two. (By contrast, Avisynth's ImageSource gives a blank frame for any missing files.)

In addition; Ramiro Polla reminded me of a bug in FFmpeg where it only accepts a image range to start from 0-4. So if it finds e.g. image005.jpg up, it throws a "No such file or directory" error.

I'm trying to get in a full implementation which for Avisynth means that it can be used in all modes (auto/force/user). To compose the ImageSource() command, I added a filepath enumerator to collect the range and use the framerate from the "Destination Video Settings". For the user mode, I added a menu item "Get ImageSource() range" that collects the range and desired framerate and can copy this to the command like; ImageSource("@source1_path", 1, 600, 25.00).

For FFmpeg, I add the framerate from the "Destination Video settings" to both the infile and outfile section of the internal command line. This way the image sequence fps is seen as equal to the desired destination fps.

As I never worked with image sequences before, any comment or suggestion on above procedures is welcome.

[Gavino]

Ramiro Polla reminded me of a bug in FFmpeg where it only accepts a image range to start from 0-4. So if it finds e.g. image005.jpg up, it throws a "No such file or directory" error.

LOL. In my earlier tests, I found it worked with a starting number of 0, 1 or 2, so assumed it worked for any number. An overly optimistic assumption, it seems.

For FFmpeg, I add the framerate from the "Destination Video settings" to both the infile and outfile section of the internal command line. This way the image sequence fps is seen as equal to the desired destination fps.

As I never worked with image sequences before, any comment or suggestion on above procedures is welcome.

You might consider allowing a different framerate for input and output. ffmpeg supports this and will drop or duplicate frames to achieve the desired output rate (just as it does for 'real' video input). However, this is less commonly wanted, and the user can always add it to the command-line options himself if really desired.

[Chris K]

You might consider allowing a different framerate for input and output. ffmpeg supports this and will drop or duplicate frames to achieve the desired output rate (just as it does for 'real' video input). However, this is less commonly wanted, and the user can always add it to the command-line options himself if really desired.

Thanks! I'll change the position where I insert the infile framerate so command redirection like e.g. -r 23.976 < will always overrule it.

[Chris K]

@ Avanti 0.5.4 release ...

http://avanti.arrozcru.org/upgrade.htm

Some changes not mentioned there ...

When you hold down the <Ctrl> key when you open a numbered image, Avanti uses the filename as a template to create the required format specifier.

When you save the command line to a Windows bat file, Avanti inserts a extra % character like e.g. image%%03d.jpg else Windows sees the %0 as a command line argument (actually the batfile name).

The "Limit encode duration" field now also accepts a string in time format like e.g; 00:03:26

Something about the libavfilter "movie" source filter. Giving a file path for that filter is critical (also a bit weird). It must not contain spaces, must be enclosed in single quotes and you have to escape the colon character like movie='C\:/path/clip.avi'. Avanti doesn't accept this on the command line but you can replace it by using two colons like movie='C::/path/clip.avi'.

Hope it all works as expected,

Chris

[Chris K]

It's been a month since Avanti 0.5.4 release. There has been changes in the latest FFmpeg builds that broke the DAR option of this and earlier Avanti versions. I can fix that but since nobody seems to care and/or took the time to report bugs over about the last ten versions, I'm not anymore going "automatically" into the time consuming procedure of fixing things, updating the help, making new packages, updating the website, etc., etc.

Thanks to those who did reply in the past,

Chris.

[ricardouk]

my opinion from a newbie point of view:

With the recent move from sourceforge to github i'm no longer able to know which ffmpeg version is the latest one, with the older SF builds i knew which one was the latest by comparing the version mumbers between all the people that compiled ffmpeg, i can't do that now with builds from github, knowing the ffmpeg universe changes every so often and brings problems to software developers, im sticking with and old version of avanti and ffmpeg, the versions i have work for what i need.

These changes with ffmpeg (they change stuff so many times) behaviour has made me stay with what works for me and that means an older version, i'm not reporting bugs because i dont have any to report.

[Gavino]

I think that's a sensible attitude, ricardouk.
Backwards compatibility (a basic guiding principle in software engineering) seems to be given a very low priority by the ffmpeg developers.

By contrast, Chris K does a fantastic job of working around all these problems and making sure that, as far as humanly possible, Avanti itself remains compatible. Thanks, Chris, your efforts are much appreciated.

[Chris K]

Notes @ AVANTI version 0.5.5 ... http://avanti.arrozcru.org/upgrade.htm

New features in Avanti 0.5.5 like the chapters option are tested with the following FFmpeg builds;

Sherpya build ... git-N-28849-ga82cfad-Sherpya ... http://oss.netfarm.it/mplayer-win32.php

Bizzeh build ... git-N-28847-g3e3ea93 ... http://www.bizzeh.com/ffmpeg/free/

Newer builds have broken components (libavfilter, metadata muxer ?) that may cause unpredictable side effects up to FFmpeg crashes.

It is currently hard to keep track of what works and what doesn't. E.g.; -vf setdar was for a short while taken off (even from the docs) and set back to the -aspect option. After a few revisions, -vf setdar is back again and -aspect seems to be redirected to setdar. There seems to be bugs in libavfilter that show up with certain source pixel formats (e.g. yuvj422p). The wtv demuxer is still broken since the switchover to git.

But we shouldn't blame the FFmpeg developers or those who provide the Win32 builds since these are only snapshots, not official releases.

The last official release was FFmpeg 0.6.1 (or libav 0.6.2 if you like). FFmpeg 0.6.1 will work with Avanti but doesn't support the full featured libavfilter and the metadata muxer/demuxer needed for the Avanti "Metadata Manager" options.

Chris.

[arubenstein]

Hi,

I am attempting to use the latest version on 64 bit win7, and cannot get the app to run. There is an entry in eventvwr:

Faulting application name: Avanti-GUI.exe, version: 0.5.5.0, time stamp: 0x4bebfba7
Faulting module name: Avanti-GUI.exe, version: 0.5.5.0, time stamp: 0x4bebfba7
Exception code: 0xc0000005
Fault offset: 0x0005ef35
Faulting process id: 0x1030
Faulting application start time: 0x01cbfd27fd790e42
Faulting application path: D:\partridge time lapse working folder\avanti\Avanti-GUI.exe
Faulting module path: D:\partridge time lapse working folder\avanti\Avanti-GUI.exe
Report Id: 3b57a682-691b-11e0-8b54-0019d1aa4001

Fault bucket 2394776710, type 1
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: Avanti-GUI.exe
P2: 0.5.5.0
P3: 4bebfba7
P4: Avanti-GUI.exe
P5: 0.5.5.0
P6: 4bebfba7
P7: c0000005
P8: 0005ef35
P9:
P10:

Attached files:
C:\Users\alex.NAC\AppData\Local\Temp\WER3D88.tmp.W ERInternalMetadata.xml

These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportArchive \AppCrash_Avanti-GUI.exe_77fea7530ab2f111febdede38df124fa889f2_0466 476c

Analysis symbol:
Rechecking for solution: 0
Report Id: 3b57a682-691b-11e0-8b54-0019d1aa4001




Any thoughts?

[Chris K]

Hi arubenstein,

There was already a comment on this problem here at the tools section.

AFAIK, it has to do with the new menus I've added. Works fine in XP, perhaps also Vista and Win7 if running in XP mode?

I'm working on a solution that solves the problem. I'll send you a PM about it.

Chris

[NighthawkGuy]

Thanks for releasing a new fixed version of Avanti (v0.5.6) that works with Windows 7 x64 this past week.
I'm running on a new system I put together a few months back with an AMD Phenom II x6 1090T CPU plus Asus Nvidia GTX460 video.
I can confirm it works fine on Windows 7 x64 using FFmpeg version git-N-28849-ga82cfad-Sherpya
I also tried the latest Bizzeh build and that works fine too. But the Sherpya one supports an external aac library while the Bizzeh one didn't appear to. The conversion speeds were similar, so I ended up going with Sherpya's.

In some test runs today converting a WinTV recorded 720x480 (4:3 aspect ratio) interlaced MPEG-2 video source to de-interlaced MPEG-4 (XVID) with MP3 audio the same setup ran nearly twice as fast then that under Windows XP 32bit too. I have a dual boot setup so I could test it on the same system both ways. Even aspect ratio setting worked correctly too!

The Avanti tool to restream an MPEG-2 video stream worked for me to fix a problem that WinTV's software has in recording MPEG-2 videos: apparently they encode the interlaced stream data with top field first order, but set the flag for bottom field first. That causes some MPEG-2 decoders and DVD players that follow that flag to playback jittery. Redoing the stream without re-encoding just setting the top field first flag correctly solves the problem. Thanks for that tool built-in to Avanti.

For some unknown reason, I noticed in my conversion tests that conversion with deinterlacing to xvid video with mp3 audio apparently needs to be output as an .avi by ffmpeg however, not directly to .mp4 or .mkv container or it appears to playback odd, not smooth. I can convert the .avi to .mp4 or .mkv with other utilities like mkvmerge however and that resulting video plays fine.

[Chris K]

Thanks for the comprehensive reporting of your findings!

For some unknown reason, I noticed in my conversion tests that conversion with deinterlacing to xvid video with mp3 audio apparently needs to be output as an .avi by ffmpeg however, not directly to .mp4 or .mkv container or it appears to playback odd, not smooth. I can convert the .avi to .mp4 or .mkv with other utilities like mkvmerge however and that resulting video plays fine.

I don't know if this applicable to your workflow but I found a problem with the mkv muxer. When I mux separated audio/video sources, the mkv muxer comes up with the following message...

[matroska @ 01c53bd0] Can't write packet with unknown timestamp

This seems to only concern the last decoded gop. When I check things out with MediaInfo, it doesn't see a duration, same as the player in my Samsung TV (It plays it but there is no navigation possible).

I found a rather easy solution for it by calling up the source properties and copying the by Avanti reported duration into the "Limit encode duration" field. In some cases you may need to leave off the fractional seconds part like 00:09:20.44 becomes 00:09:20.

You could also give it a try by remuxing the xvid avi to mkv or mp4 with the "Rewrite PTS", "Sync Audio" options enabled.

Chris

[NighthawkGuy]

You could also give it a try by remuxing the xvid avi to mkv or mp4 with the "Rewrite PTS", "Sync Audio" options enabled.

Chris

I tried using the remux template which has those options enabled to convert the smooth playing xvid+mp3 .avi file to .mp4 or .mkv via ffmpeg but it produced the same non-smooth playing file that direct converting to .mp4 or .mkv did before. The audio was in sync that wasn't the issue, the video just plays back on the .mp4 or .mkv like it isn't getting the full frame rate. But converting the .avi to .mp4 or .mkv with other utilties like mkvmerge they play back smooth.

I just tried something else, I was converting to xvid with video options that included " -bf 2" for B-frames. If I removed that option, then I could convert to xvid with ffmpeg to .mp4 or .mkv directly and it played smooth just like converting to .avi
The resulting stream only had I and P frames in this case.
Does ffmpeg have an issue converting to .mp4 or .mkv containers using b-frames? mkvmerge didn't have a problem with b-frames in the .avi file for comparison for it to convert to .mkv ok.

Any idea why I am seeing faster speed in conversion with the same latest version avanti+ffmpeg on windows 7x64 compared to in windows xp-sp3x32 on the same machine?
With conversion test of a 720x480 mpeg-2 video to xvid+mp3 (constant q=4, video options: -qmax 10 -g 30 -bf 2) I get a around 2x conversion speed on WinXP-SP3x32 and about 3.4x speed on Win7x64.

Strangely, a different video conversion app I tested that used x264 were the other way, over 2x faster in WinXPx32 over Win7x64 and x264 even has a native 64bit. Other conversion apps I tested were pretty much the same speed.
Weird, but in avanti/ffmpeg case its a nice anomoly. Just curious if any ideas on why that is.

[Chris K]

Does ffmpeg have an issue converting to .mp4 or .mkv containers using b-frames? mkvmerge didn't have a problem with b-frames in the .avi file for comparison for it to convert to .mkv ok.

It looks like it's a specific xvid problem. I did some tests and have the same issues. When I use mpeg4 with b-frames, it does fine. But the developers of mkvmerge seems to know how to handle it.

Any idea why I am seeing faster speed in conversion with the same latest version avanti+ffmpeg on windows 7x64 compared to in windows xp-sp3x32 on the same machine?
With conversion test of a 720x480 mpeg-2 video to xvid+mp3 (constant q=4, video options: -qmax 10 -g 30 -bf 2) I get a around 2x conversion speed on WinXP-SP3x32 and about 3.4x speed on Win7x64.

Only thing I can imagine is that since Win7 x64 can address more memory, FFmpeg uses it in some way?

Strangely, a different video conversion app I tested that used x264 were the other way, over 2x faster in WinXPx32 over Win7x64 and x264 even has a native 64bit. Other conversion apps I tested were pretty much the same speed.
Weird, but in avanti/ffmpeg case its a nice anomoly. Just curious if any ideas on why that is.

You could check out the used cores in the Windows taskmanager. Current FFmpeg builds use w32threads instead of pthreadGC2. I'm not an expert on that but I guess it's a improvement.

[oncletom]

Hi there.
I'm a new user of Avanti (and I basically do not know how to use options lines), and I'm a little bit disappointed by an issue I got while using this GUI, exporting a h264 (or Mpeg2) from a QT Animation. I do not have the issue while exporting with dnxhd codec.

Here's the references : Avanti 0.5.6 - FFmpeg version git-a304071 - Avisynth 2.5
Check the jpg attached, it explains everything !

BTW, I got another issue, basically when I try to use Avisynth (CC, crop-scale-pad page,...). The process stops and I got that message :

Input #0, not reported and process canceled by FFmpeg with the message:
C:/Users/My_Name/Desktop/Avanti GUI (Dossier)/avtemp/HAMLET: No such file or directory

I actually can't have the preview window with a similar error message :

Import could'nt open "C:/Users/My_Name/Desktop/Avanti GUI (Dossier)/avtemp/HAMLET.avs"

I think it's a auto-load problem, but I can't figure out where do I change this mode.

I'm pretty sure my questions are basics, but I searched many pages around the web and did not find answers.
Thanks a lot.

Maxime

[Chris K]

Here's the references : Avanti 0.5.6 - FFmpeg version git-a304071 - Avisynth 2.5
Check the jpg attached, it explains everything !

The vertical pink/green bars are most likely caused by a bug in the FFmpeg version you use. It has been in for quite some time but is recently fixed. Try one of the latest versions from here ...

http://ffmpeg.arrozcru.org/wiki/index.php?title=Builds

BTW, I got another issue, basically when I try to use Avisynth (CC, crop-scale-pad page,...). The process stops and I got that message :

Input #0, not reported and process canceled by FFmpeg with the message:
C:/Users/My_Name/Desktop/Avanti GUI (Dossier)/avtemp/HAMLET: No such file or directory

I actually can't have the preview window with a similar error message :

Import could'nt open "C:/Users/My_Name/Desktop/Avanti GUI (Dossier)/avtemp/HAMLET.avs"

I think it's a auto-load problem, but I can't figure out where do I change this mode.

By default, Avanti is in the Avisynth AUTO mode. This should be OK for the crop-scale-pad option. To change the mode, right-click on the "Start process" button.

It seems that both FFmpeg and Avisynth have problems with the Avanti install path. For testing, I run Avanti from several partitions and paths. I'll try to create a simular path as yours and let you know what happens.

[oncletom]

Here's the references : Avanti 0.5.6 - FFmpeg version git-a304071 - Avisynth 2.5
Check the jpg attached, it explains everything !

The vertical pink/green bars are most likely caused by a bug in the FFmpeg version you use. It has been in for quite some time but is recently fixed. Try one of the latest versions from here ...

http://ffmpeg.arrozcru.org/wiki/index.php?title=Builds

Ok, now it works. I was in bad luck, I downloaded the "last" version 3 or 4 days ago ! Thanks.

It seems that both FFmpeg and Avisynth have problems with the Avanti install path. For testing, I run Avanti from several partitions and paths. I'll try to create a simular path as yours and let you know what happens.

OK. I'll wait for your tests. I changed the Avisynth mode, but it is still the same. As the export now works, I noticed the classical color change between my source (601) and the destination (RGB I presume). Will the "expand luminance" option be the solution ? If so, I definitely wait for your Avisynth tests !

[Chris K]

As the export now works, I noticed the classical color change between my source (601) and the destination (RGB I presume). Will the "expand luminance" option be the solution ? If so, I definitely wait for your Avisynth tests !

I suppose you mean with "export" that you can convert the source when not using the Avisynth option?

FFmpeg always converts the source to yuv420p. The "expand luminance" option isn't useful for that.

I created a folder at the desktop and launched Avanti from there. I have no problems with the Avisynth crop-scale-pad option but I run in XP.

0:17:40 - Process started using ffmpeg version git-N-29582-g707e861
======================================================================================

Input #0, avs, from
    'C:/Documents and Settings/Administrator/Desktop/Avanti GUI (dossier)/avtemp/input.avs':
  Duration: 00:00:41.70, start: 0.000000, bitrate: 0 kb/s
    Stream #0.0: Video: rawvideo, yuv420p, 640x480, 88385 kb/s, 23.98 tbr,
      23.98 tbn, 23.98 tbc
    Stream #0.1: Audio: pcm_s16le, 44100 Hz, 2 channels, s16, 1411 kb/s
---------------------------------------------------------------------------------
Output #0, mp4, to 'F:/VirtualDub Capture/test_final.mp4':
    Stream #0.0: Video: libx264, yuv420p, 640x480 [PAR 1:1 DAR 4:3], q=10-51,
      750 kb/s, 25 tbn, 25 tbc
    Stream #0.1: Audio: aac, 44100 Hz, 2 channels, s16, 128 kb/s
---------------------------------------------------------------------------------
Stream mapping:
  Stream #0.0 -> #0.0
  Stream #0.1 -> #0.1

======================================================================================
                                         +--------------------+
                  +----------------+     |                    |
   Source [1] --> | Avisynth AUTO  | --> | FFmpeg + user opts | --> Destination [1]
                  +----------------+     |                    |
                                         +--------------------+
======================================================================================

0:17:42 - Attention! Avisynth C/S/P enabled (scaling to 640x480).
0:17:42 - FFmpeg user VIDEO option(s) included.
0:17:42 - Free space on destination disk at start 28,182 Mb.

No idea why it doesn't work in your case but you could try a simple install path at the Windows 7 directory that is meant for Win32 applications (don't know what it's called).

[NighthawkGuy]

the Windows 7 directory that is meant for Win32 applications (don't know what it's called).

In Windows 7 x64 that would be: C:\Program Files (x86)

[Chris K]

@NighthawkGuy

Thanks!


@oncletom

I noticed in the paths at your first post that the path to FFmpeg lost its file extension...

Input #0, not reported and process canceled by FFmpeg with the message:
C:/Users/My_Name/Desktop/Avanti GUI (Dossier)/avtemp/HAMLET: No such file or directory

I then forced some things and found a bug that shows up depending on the file name (if contains spaces). I could fix it in a DLL function that extracts file extensions. Can you replace this DLL in your Avanti install directory and report your findings?

EDIT:

Removed "avcom32_dll_bug_fix.7z" attachment. The above mentioned bug (and a related second one) is fixed in Avanti version 0.5.7

Should you have a reason to revert or stay at version 0.5.6 or 0.5.5, it's recommended to copy the "avcom32.dll" from version 0.5.7 to your Avanti install directory (not for older versions).

[oncletom]

As the export now works, I noticed the classical color change between my source (601) and the destination (RGB I presume). Will the "expand luminance" option be the solution ? If so, I definitely wait for your Avisynth tests !

I suppose you mean with "export" that you can convert the source when not using the Avisynth option?

FFmpeg always converts the source to yuv420p. The "expand luminance" option isn't useful for that.

Well, what's the solution to solve this problem (video washed out, since - sorry if I'm mistaken about the process - it seems that Avanti does not consider my video as a YUV signal) ? Is there a way to tell Avanti my source file is YUV signal ?
I'm deeply sorry about my relative ignorance, it's just that it seems a very good software to use (when you know how to use it !) and I don't wanna give up but still need help...
I'll try your fix tonight when I'll go back home. Many thanks.

[thezanny]

Hello, I wonder, can this tool be used to make a BRRip off a mkv into a specific size and make it clear/sharpen/encode in H264?

[Chris K]

Is there a way to tell Avanti my source file is YUV signal ?
I'm deeply sorry about my relative ignorance, it's just that it seems a very good software to use (when you know how to use it !) and I don't wanna give up but still need help...

Avanti is GUI for FFmpeg. It isn't able to do more than FFmpeg allows.

Incompatible pixel format 'yuvj422p' for codec 'libx264', auto-selecting format 'yuv420p'

The "expand luminance" option scales a [16,235] clip to [0,255]. This might help a bit but isn't the same as preserving the original source colorspace.

[Chris K]

Hello, I wonder, can this tool be used to make a BRRip off a mkv into a specific size and make it clear/sharpen/encode in H264?

Perhaps, with some extra user efforts. Main goal of Avanti is to offer easier control over FFmpeg (than plain CLI usage). There are no features like output size control etc.