MeGUI development

[berrinam]

0.2.3.2160
Commit by berrinam:
- Fixed bug of wrong raw filetype being assigned

[bob0r]

0.2.3.2157
Commit by berrinam:
- Fix bitrate calculation in AutoEncode and Calculator

0.2.3.2156
Commit by berrinam:
- Fix the mp4/aac bug with AutoEncoding.
- Partway to fix of bitrate calculations, but it is more complicated than it seems...

In Tools > Bitrate calculator, this is not refactored yet, correct?
Or should i file a bug report that the audio track(s) are not included in the results.

[Doom9]

@Sharktooth: About stable releases: you basically just said what I posted about two months ago as a roadmap. Right now we have reached the first milestone feature wise so it's time to fix remaining bugs, then it's time for another phase of adding features (cutlists for instance).

[Sharktooth]

yes, exactly.
forgive me but i have serious problems remembering some things...

[Doom9]

well.. I have a hard time remembering some megui code I wrote so don't sweat it ;)

[berrinam]

0.2.3.2161
Commit by berrinam:
- Fix deletion of intermediate files in AutoEncode and OneClick encode modes

[Sharktooth]

@devs: daverc kindly offered his help in developing a prototype wrapper class for mediainfo lib.
ill point him to this thread for discussing the details.

[daverc]

I have done some little coding about the mediainfo.dll,
i think i will be able to get everyinfo that it can provide in a few days.
I have a working test assembly for specific fields
If anyone is interested i can send him the code.

[berrinam]

@daverc: The fields I am interested in for MeGUI are:
Width/height
Aspect Ratio
FPS
Number of frames
Video Codec
Number of audio streamsUnfortunately I have no codebase for testing this on right now.

[daverc]

@daverc: The fields I am interested in for MeGUI are:
Width/height
Aspect Ratio
FPS
Number of frames
Video Codec
Number of audio streamsUnfortunately I have no codebase for testing this on right now.

Consider it's done ;)
Tracks will be accessible as a tree of properties, and infos as inner nodes of properties.

structure of the call will be for instance,

import MediaInfoWrapper;
MediaInfo M = new MediaInfo(filepath);
string fps=M.Video(TrackNumber).FPS;

I'm on it now, so if you have any requests ...

[Doom9]

wouldn't the audio properties be of use as well? As in "okay, this is an MP4 with an AAC audio track.. or an MP4 with an MP3 audio track.. or an MP4 with a Vorbis track (I know.. bad idea to do that).

[daverc]

wouldn't the audio properties be of use as well? As in "okay, this is an MP4 with an AAC audio track.. or an MP4 with an MP3 audio track.. or an MP4 with a Vorbis track (I know.. bad idea to do that).

It's planned.
Video, audio, subtitles tracks and container info will have the same behavior (as in genuine mediainfo actually)

[bob0r]

@berrinam
http://forum.doom9.org/showthread.php?p=835115#post835115

Sorry for reasking, but a quick simple answer should be in place (Yes i know there is still that not refactored pop-up) but calculation is not fixed for anywhere i can see, so where do your changes apply to?

[berrinam]

The units are now correct in AutoEncode mode calculation. They should also be correct in the Bitrate Calculator. The problem with the audio tracks missing is a separate one that I looked at when you mentioned, but promptly forgot again. I will look at again sometime, but I'm somewhat busy at the moment, so I can't say for sure when.

[berrinam]

0.2.3.2162
Commit by berrinam:
- Fix audio-filesize-being-ignored bug in bitrate calculator
- Fix AR calculation to be ITU-correct

Stable release candidate. Bugs, anyone?

[shon3i]

0.2.3.2162
Commit by berrinam:
- Fix audio-filesize-being-ignored bug in bitrate calculator
- Fix AR calculation to be ITU-correct

Stable release candidate. Bugs, anyone?
Yea, Bitrate calculator dosen't work again because duration is 0:0:0 and audio bitrate can't be higher than 100kbps, and can you make for CTAAC and FAAC to only have MP4 container because is more flexible when muxing (SBR signaling switch is not possible in megui) and other things, aslo CT support --mp4box switch who automaticly make mp4 container instead aac but mp4box.exe must be in same dir.

[dimzon]

aslo CT support --mp4box switch who automaticly make mp4 container instead aac but mp4box.exe must be in same dir.
yeah, it's only one limitation

[Sharktooth]

0.2.3.2162
Commit by berrinam:
- Fix audio-filesize-being-ignored bug in bitrate calculator
- Fix AR calculation to be ITU-correct

Stable release candidate. Bugs, anyone?
yes... :(
changes in video profiles doesnt get always (?!?) saved.
when quitting megui and reloading the previously changed profile it still has the old settings.

[shon3i]

yeah, it's only one limitation
OK dimzon but i don't know why all tools not in tools folder instead one tool in one folder, or video encoders, audio encoders etc, and you can include another mp4box in enc_aacplus package because is not so frequent update.

[berrinam]

Ok, so the bitrate calculator is causing a lot of problems..... I can see why Doom9 didn't want to touch it. I haven't looked too deeply into the code, so I just tried to make a temporary fix. It seems that has disturbed a whole lot of other things. I think getting a robust version of the bitrate calculator probably requires a lot of code change in that class, so it's not a good idea to expect it soon.

Does someone else want to look at it, because I can't spend a lot of time coding right now?

[shon3i]

@dimzon here is the log of muxing process

Log for job job2

mkvmerge v1.7.0 ('What Do You Take Me For') built on Apr 28 2006 17:19:57
'Firewall.mkv': Using the Matroska demultiplexer.
'track 07.aac': Using the AAC demultiplexer.
'Firewall.mkv' track 1: Using the MPEG-4 part 10 (AVC) video output module.
Warning: AAC files may contain HE-AAC / AAC+ / SBR AAC audio. This can NOT be detected automatically. Therefore you have to specifiy '--aac-is-sbr 0' manually for this input file if the file actually contains SBR AAC. The file will be muxed in the WRONG way otherwise. Also read mkvmerge's documentation.
'track 07.aac' track 0: Using the AAC output module.
The file 'pera.mkv' has been opened for writing.

The cue entries (the index) are being written...
Muxing took 84 seconds.

so it's better to always use mp4 container for CT AAC

[berrinam]

so it's better to always use mp4 container for CT AAC
MeGUI already chooses MP4-AAC over RAW-AAC when there is a choice in MuxPathFinding. I think it is wrong and unreliable to (a) expect that mp4box is in WAAC's directory and (b) only allow mp4-aac output.

Also, I don't know if it is possible, but perhaps MediaInfoLib can detect whether an AAC file is SBR, in which case that problem goes away.

[Doom9]

There's another point to this: ctaac is the one aac encoder causing way more problems than any other. Since it's not any better than neroaac and costs the same, why do we even have it?
At some point, it's better to cut your losses.. your head starts to hurt if you try to break through the wall headfirst a couple of times and the wall just won't crack.
Just look at all the issues people are having with different ctaac versions and dlls, and the fact that we can't bundle them in autoupdate. It is very much reminiscent of the mess we had with neroaac prior to the commandline encoder. Actually, I tend to think it was a little less worse as things were stable with Nero, but are still changing with ctaac.

[SeeMoreDigital]

Hmmm!

My foot's in the other camp... I'm of the opinion that CT's encoder generates better sounding encodes than Nero's free encoder, especially when it comes to generating 6Ch AAC-HE streams!

Now when it comes to knowing whether or not an AAC stream is LC or HE, is not one of the biggest indicators the encodes "sample rate"?

EDIT: For example, if you are encoding from a 6Ch AC3 source with a sample rate of 48.0KHz, the 6Ch AAC-HE encode will have a sample rate of 24.0KHz. Like-wise, if you are encoding from a 2Ch CD-WAV source with a sample rate of 44.1KHz, the 2Ch AAC-HE encode will have a sample rate of 21.050KHz.


Cheers

[shon3i]

MeGUI already chooses MP4-AAC over RAW-AAC when there is a choice in MuxPathFinding. I think it is wrong and unreliable to (a) expect that mp4box is in WAAC's directory and (b) only allow mp4-aac output.

Also, I don't know if it is possible, but perhaps MediaInfoLib can detect whether an AAC file is SBR, in which case that problem goes away.
Ok, but dimzon makes enc_aacplus.exe to can produce mp4 files but only via mp4box and this work fine whitout any bug, so ct aac itself can't produce mp4 only raw aac and now no sense to use raw aac. if you use mp4 extension for aac that is wrong. If you can make somehow to detect sbr like you say, that will soloved the problem.

There's another point to this: ctaac is the one aac encoder causing way more problems than any other. Since it's not any better than neroaac and costs the same, why do we even have it?
At some point, it's better to cut your losses.. your head starts to hurt if you try to break through the wall headfirst a couple of times and the wall just won't crack.
Just look at all the issues people are having with different ctaac versions and dlls, and the fact that we can't bundle them in autoupdate. It is very much reminiscent of the mess we had with neroaac prior to the commandline encoder. Actually, I tend to think it was a little less worse as things were stable with Nero, but are still changing with ctaac. I agree with SMD, nero newer had good 6ch encoding aslo stereo is not so good, only where is better nero is maybe 48kbs, but i think aslo that licesing test on HA is not anymore correct because nero @ 48kbs now sounds whrose than on the test.

[daverc]

MediaInfo c# is ready.

Just put these files next to mediainfo.dll, and add a button in the gui.

Sources available on request.

[daverc]

Here is the code.
Original idea was found in staxrip.mediainfo.
Thank you Stax :)


Media tracks are List<TrackType>.

For instance, syntax to acces the codec of the first video track is
MediaInfo M=new MediaInfo(path);
string codec=M.Video[0].Codec;

You also get free track counter, and everything mediainfo can provide.

An empty string is returned when no information is available.

[bob0r]

0.2.3.2162
Commit by berrinam:
- Fix audio-filesize-being-ignored bug in bitrate calculator
- Fix AR calculation to be ITU-correct

Stable release candidate. Bugs, anyone?


Quick answer: No
The calculator is still very bugged. (You should test it a little)
In this case, fill in audio size, then change minutes then the audio resets to 0 (will file bug report if wanted)
In the the bitrate calculator is pretty important for custom encoding.

Long answer: No
Ill run by all visual and most logical functions very quick tonight. Too see if there are any unclean "bugs".

Then people should test some variations of default encodings and features(updates/bitrate calc/etc..)

[berrinam]

0.2.3.2163
Commit by berrinam:
- Another go at the bitrate calculator
It seems to be fine for me....

[berrinam]

0.2.3.2164
Commit by berrinam:
- Make the UpdateWindow fixed-size
- Add ConvertToYV12() to the autodeint scripts
Right.... again, any problems?

[berrinam]

Could a moderator approve daverc's second attachment please, or could dave post it somewhere else?

[Doom9]

I approved the attachment. Being able to approve inline really is a major bonus of the 3.5 vbb series :)

[shon3i]

0.2.3.2164
Commit by berrinam:
- Make the UpdateWindow fixed-size
- Add ConvertToYV12() to the autodeint scripts
Right.... again, any problems?
Again Bitrate Calculator but now have minor bugs.

1. MKV and MP4 must have same bitrate for same settings because when i using mkv bitrate i always get undersize, the differences is about 2 bits

2. Audio bitrate values are non-standard, can you make only standard values like 16,32,48,64,80,96,112,128,160,192,224,256,320,384, etc

3. when i try to change from MKV to MP4 container in bitrate calculator, bitrate won't change for this 2 bits

[Doom9]

While the bitrate should be somewhat different between MP4 and MKV there's one thing to be kept in mind: you cannot accurately calculate MKV overhead prior to encoding. The exact formulas are in the container forum in a post by mosu as reply to one of mine.. the overhead depends on the distribution of frame types.. and you just can't know how many I, P and B frames you're going to get prior to encoding. Every MKV bitrate calc on the planet relies on assumptions that can be more or less correct, but no calculator is ever exact.

[shon3i]

While the bitrate should be somewhat different between MP4 and MKV there's one thing to be kept in mind: you cannot accurately calculate MKV overhead prior to encoding. The exact formulas are in the container forum in a post by mosu as reply to one of mine.. the overhead depends on the distribution of frame types.. and you just can't know how many I, P and B frames you're going to get prior to encoding. Every MKV bitrate calc on the planet relies on assumptions that can be more or less correct, but no calculator is ever exact.
Yes but when i use MP4 bitrate (+2bits per second different from mkv bitrate) and mkv container i always get choosen size, with mp4 bitrate i never get over/undersize, and aslo GordianKnot bitrate calculator, calcualte same bitrate for mkv like megui for mp4. So then in megui something wrong abut mkv calculation because must be same like mp4.

[berrinam]

Yes but when i use MP4 bitrate (+2bits per second different from mkv bitrate) and mkv container i always get choosen size, with mp4 bitrate i never get over/undersize, and aslo GordianKnot bitrate calculator, calcualte same bitrate for mkv like megui for mp4. So then in megui something wrong abut mkv calculation because must be same like mp4.
Woah, it is really hard to understand what you are saying. Nevertheless, it seems to be a problem with the MKV overheads, which is a known problem. Suffice to say, I don't see it either as drastic enough or as easy enough to solve immediately, so unless some other dev will look into it, you will have to cope, unless you can give direct instructions on what to change.

2. Audio bitrate values are non-standard, can you make only standard values like 16,32,48,64,80,96,112,128,160,192,224,256,320,384, etcThis isn't a bug, and all you're asking for is multiples of 16, basically. It steps in multiples of 16, but gets adjusted by some other calculations, which can skew this because of rounding errors. This is not actually a bug (it's just an interface detail) so I'm going to ignore this for now. You can manually enter your own bitrate if you want.

[shon3i]

Woah, it is really hard to understand what you are saying. Nevertheless, it seems to be a problem with the MKV overheads, which is a known problem. Suffice to say, I don't see it either as drastic enough or as easy enough to solve immediately, so unless some other dev will look into it, you will have to cope, unless you can give direct instructions on what to change.
Sorry berrinam for my very poor english, MKV must have same bitrate like MP4 because have similar overhead which is not so different, but in resulting bitrate must be same value. FOr example in GK for MKV and x264 bitrate is 1087.98 rounded this is 1088 which is bitrate of MP4 (and it's correct bitrate for both MP4 and MKV), but in MeGUI for MKV i get bitrate 1086.

This isn't a bug, and all you're asking for is multiples of 16, basically. It steps in multiples of 16, but gets adjusted by some other calculations, which can skew this because of rounding errors. This is not actually a bug (it's just an interface detail) so I'm going to ignore this for now. You can manually enter your own bitrate if you want.Ok for that but try to type 128 and you get 127 in box, Why?

[bob0r]

0.2.3.2163
Commit by berrinam:
- Another go at the bitrate calculator
It seems to be fine for me....


Mostly it works fine, here are some final reports/questions:
MeGUI Bug-Report Thread - audio tracks (http://forum.doom9.org/showthread.php?p=838779#post838779)

[berrinam]

0.2.3.2165
Commit by berrinam:
- Enable audio track 2
- Fix the 15kbps bitrate increment to a 16kbps increment

I had a look at the actual calculation code, and it seems like some of it is wrong (according to www.alexander-noe.com, anyway), but it isn't a fatal error, so I think that can wait, considering that it needs some more work and testing.

@Doom9: What did you use to write the calculation code? www.alexander-noe.com has stuff about AVI and MKV, and it is mostly the same as what you have, but some of what you did now seems outdated (eg the MKV frame-size issues are no problem with MKV v2, apparently -- all frames now have 7 bytes overhead).

[Doom9]

I used the information mosu gave me in this thread: http://forum.doom9.org/showthread.php?t=96703&page=2&highlight=overhead
Page 2 and 3 contain the relevant details. I was never quite happy with the existing code and asked if somebody had a better idea.. if you have one, feel free to adapt the calculations.. they're really suboptimal.

[berrinam]

What about for AVI?

[Doom9]

The AVI frame overhead is well known (24 bytes per frame). As far as audio overhead goes, I tested various sources in GKnot and knowing the video frame overhead I broke down the audio muxing overhead to a number per video frame. Basically the results should always match GKnot and from my personal experience, GKnot is very accurate when it comes to AVIs.

[berrinam]

The AVI frame overhead is well known (24 bytes per frame). As far as audio overhead goes, I tested various sources in GKnot and knowing the video frame overhead I broke down the audio muxing overhead to a number per video frame. Basically the results should always match GKnot and from my personal experience, GKnot is very accurate when it comes to AVIs.
I see. Reading through Alex Noe's website, however, gives quite a different explanation, especially regarding VBR-MP3 overhead, which is many times higher. I suppose testing is the only way to find out for sure what is right.

[Doom9]

one thing to keep in mind... alex basically refers to avimuxgui.. we're using mkvmerge and divxmux respectively.. avimuxgui has options the tools we have do not have.

[berrinam]

True.... I am keeping that in mind, and have checked that, say, mkvmerge does indeed support SimpleBlocks.

[Doom9]

one little thing: those codec configuration windows are non resizeable dialogs.. they shouldn't have an active maximize button as the result is buttugly ;)

[berrinam]

0.2.3.2166
Commit by berrinam:
- Fix the behavior of some dialogs

[Sharktooth]

0.2.3.2167
Commit by berrinam:
- Fix some profile bugs

[berrinam]

0.2.3.2168
Commit by berrinam:
- Fix XviD+CQ
- Hide some XviD options that don't work with xvid_encraw

[berrinam]

0.2.3.2169
Commit by berrinam:
- Fix Adaptive Mux Window 'Go' button bug
- Fix 1st-pass bug

You might have been folllowing the XviD presets thread, and the thing which is restricting Teegedeck at the moment is that it isn't possible to do a separate configuration of the first pass codec settings. What do you think about making this possible?

What I have in mind is adding a checkbox and two radio buttons to the base VideoConfigDialog. The checkbox would be, 'configure first pass separately', and the radio boxes would be 'configure first pass now' and 'configure non-first passes now'. Internally, the checkbox's value would be stored as a bool, and if it is true, then there would be another field inside which is a copy of the codec settings, which is a custom configuration of the first pass:

class VideoCodecSettings
{
bool customFirstPass;
VideoCodecSettings firstPassSettings;
}

It's a bit hackish, so I'm reluctant to do it immediately, so what do you think? Do you have any other ideas?