Per-track audio configuration.
Forum rules
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.
*******************************
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.
*******************************
Per-track audio configuration.
Here is a patch for per-track audio configuration. It allows much more fancy things than are currently possible with the current audio setup. Eg: AC3 for the main track, with the commentary track encoded in AAC with a higher DRC, and lower sample rate. Basically everything for an audio track is per-track (this includes output codec, bitrate, sample rate, drc, input track, mixdown). As a side effect, we are allowed an almost unlimited number of output audio tracks.
In the CLI, the tracks are specified by CSV, with the first output track relating to the first position after the switch. If only one argument is given, then that is used across all tracks specified in the input. If not enough arguments are given for the number of audio tracks, then the default setting is used for the rest of the tracks. Any input for (AC3) pass-through tracks is ignored, it still needs to be specified, but it is not used. This is really best shown with examples:
AppleTV (old ac3+aac codec): -a 1,1 -E faac,ac3 -B 160 -R 48000 -6ch dpl2
The following line:
-a 1,3-5,1 -E ac3,faac,lame,faac -B 160 -6 6ch,dpl2,stereo,6ch,6ch -R 48000,32000
Would result in the following output tracks:
1: DVD track 1, AC3 pass-through
2: DVD track 3, AAC @ 160 kbps, DPL2, 32000kHz samplerate
3: DVD track 4, MP3 @ 160 kbps, Stereo, Default samplerate
4: DVD track 5, AAC @ 160 kbps, 6ch, Default samplerate
5: DVD track 1, Default audio codec for container @ 160kbps, 6ch, Default samplerate
Update:
One last change. The client is now in charge of allocating it's own hb_audio_config_t to pass to hb_audio_add. Barring any bugs, this is final.
After talking with eddyg I rewrote the hb_audio_t layout. There is now an opaque hb_audio_t type for use within libhb, and a hb_audio_config_t accessible to the UI (after a fashion).
I split the patch up into two parts to make it a little cleaner.
Also added the macgui patch which allows compiling on mac successfully.
First is a patch for just the files in libhb.
Second is a patch to just the CLI.
Third is the patch for the macgui thereby allowing successful compiling on mac.
The series is here: Please play with it, by all means break it. I would like to get as many people looking at as I can, so any bugs can be worked out (not to mention some of the nastieness I have created).
In the CLI, the tracks are specified by CSV, with the first output track relating to the first position after the switch. If only one argument is given, then that is used across all tracks specified in the input. If not enough arguments are given for the number of audio tracks, then the default setting is used for the rest of the tracks. Any input for (AC3) pass-through tracks is ignored, it still needs to be specified, but it is not used. This is really best shown with examples:
AppleTV (old ac3+aac codec): -a 1,1 -E faac,ac3 -B 160 -R 48000 -6ch dpl2
The following line:
-a 1,3-5,1 -E ac3,faac,lame,faac -B 160 -6 6ch,dpl2,stereo,6ch,6ch -R 48000,32000
Would result in the following output tracks:
1: DVD track 1, AC3 pass-through
2: DVD track 3, AAC @ 160 kbps, DPL2, 32000kHz samplerate
3: DVD track 4, MP3 @ 160 kbps, Stereo, Default samplerate
4: DVD track 5, AAC @ 160 kbps, 6ch, Default samplerate
5: DVD track 1, Default audio codec for container @ 160kbps, 6ch, Default samplerate
Update:
One last change. The client is now in charge of allocating it's own hb_audio_config_t to pass to hb_audio_add. Barring any bugs, this is final.
After talking with eddyg I rewrote the hb_audio_t layout. There is now an opaque hb_audio_t type for use within libhb, and a hb_audio_config_t accessible to the UI (after a fashion).
I split the patch up into two parts to make it a little cleaner.
Also added the macgui patch which allows compiling on mac successfully.
First is a patch for just the files in libhb.
Second is a patch to just the CLI.
Third is the patch for the macgui thereby allowing successful compiling on mac.
The series is here: Please play with it, by all means break it. I would like to get as many people looking at as I can, so any bugs can be worked out (not to mention some of the nastieness I have created).
Last edited by dynaflash on Mon Mar 31, 2008 8:00 pm, edited 9 times in total.
Reason: Added the MacGui Patch which also facilitates compiling successfully on the mac.
Reason: Added the MacGui Patch which also facilitates compiling successfully on the mac.
Re: Per-track audio configuration.
Yay, there goes one major item on the roadmap for 0.9.3. =)
Hey, everyone remember when HB was down to just *one* track at a time, period, let alone all this fancy stuff with per-track config? And then saintdev came to the rescue
Why do I have a feeling the MacGui implementation is going to take a long time to iron out...
Hey, everyone remember when HB was down to just *one* track at a time, period, let alone all this fancy stuff with per-track config? And then saintdev came to the rescue
Why do I have a feeling the MacGui implementation is going to take a long time to iron out...
Re: Per-track audio configuration.
I've gone through the diff and like the design - I haven't patched it in, but I see nothing in it that would make me think that it wouldn't work as yet.
Personally I think commit it, and we'll hammer at it until it is perfect.
Would be nice to make the changes to Controller.mm first though.. should be a breeze.
Cheers, Ed.
Personally I think commit it, and we'll hammer at it until it is perfect.
Would be nice to make the changes to Controller.mm first though.. should be a breeze.
Cheers, Ed.
Re: Per-track audio configuration.
Controller.mm should be a breeze. Finding real estate in the macgui for the widgets, now that could be another issue altogether.eddyg wrote:Would be nice to make the changes to Controller.mm first though.. should be a breeze.
Unless we do something where we have common widgets for each track such as the drc slider, bitrate, etc. Then each track has a radio button next to it or something. The common widgets change the values on whatever track you have "active" in the gui and the settings are represented as a string read out next to each track radio button. This could allow you to squeeze room to represent probably six audio tracks. Though I do think some discussion should take place as to how many audio tracks you *realistically* need to have in the gui. If eddyg's new hybrid audio for the atv is going to use up two of those slots now. I still can only see where you would use four total 99% of the time. But that's just me.
Cripes, what's the most audio tracks anyone has seen on a dvd ? for me probably six, although two of those were director commentaries in two different languages.
Re: Per-track audio configuration.
My main test disc is the Criterion edition of Fear and Loathing in Las Vegas. It's got the main audio in DPL2, DD5.1, and DTS, plus three different commentary tracks (director, star, writer). So I'd want the option of doing 5 for that:dynaflash wrote:Cripes, what's the most audio tracks anyone has seen on a dvd ? for me probably six, although two of those were director commentaries in two different languages.
1: DPL2 of main audio in AAC
2: DD5.1 of main audio in pass-through
3: Gilliam commentary in AAC
4: Depp commentary in AAC
5: Thompson commentary in AAC
The ones people are going to care about are the LotR extended editions. There people will want:
1: DTS of main audio in AAC mixdown
2: DD5.1 of main audio in pass-through
3: Writer-Director commentary in AAC
4: Design commentary in AAC
5: Production commentary in AAC
6: Cast commentary in AAC
Re: Per-track audio configuration.
um, I think we need a bigger window.
Re: Per-track audio configuration.
I think we need a dynamically expansible view like the one to add more search parameters in spotlight or itunes smart playlist.
Re: Per-track audio configuration.
(slightly) newer patches above. These don't change any code, just split the patch up a little more logically.
Re: Per-track audio configuration.
Hey, thats not funny ... or maybe it is ...jbrjake wrote:Why do I have a feeling the MacGui implementation is going to take a long time to iron out...
Re: Per-track audio configuration.
That's the first thing that came to my mind when I thought of how they could do it in the GUIRitsuka wrote:I think we need a dynamically expansible view like the one to add more search parameters in spotlight or itunes smart playlist.
Re: Per-track audio configuration.
Aaaaw , as usual when you hardcore libhb devs keep throwing new stuff at us. We will try to figure something out
Re: Per-track audio configuration.
Something such as the following alright for the new audio panel?
Re: Per-track audio configuration.
Okay saintdev: would it be possible for you to update your patch(es) to svn rev 1364, trying to apply them I get HUNK failures in
ommon.h , muxogm.c and sync.c . Which I am sure have changed since then. Of course I cannot track which rev each file is patched against with your git diffs
While your at it, whats the chance of getting it in an svn diff and posted to handbrake.pastebin.ca ? I figured while I am at it I might just as well ask for the moon.
ommon.h , muxogm.c and sync.c . Which I am sure have changed since then. Of course I cannot track which rev each file is patched against with your git diffs
While your at it, whats the chance of getting it in an svn diff and posted to handbrake.pastebin.ca ? I figured while I am at it I might just as well ask for the moon.
Re: Per-track audio configuration.
After some guess work as to which rev your patches would apply against, I did get them to apply against 1318. So, now of course I have a bunch of errors in controller.mm which is to be expected. Of course things start to get fuzzy for me as soon as I am in libhb, so here is one example of where I get an error:
which returns an error:
presumably because we have changed how that is determined ? I am going to need help on this one as the macGui needs to access the stuff in common.c and h. and I suspect those changes are responsible here.
Code: Select all
job->vcodec = FormatSettings[format][codecs] & HB_VCODEC_MASK;
Code: Select all
error: 'HB_MUX_MASK' was not declared in this scope
Re: Per-track audio configuration.
Okay, I have it now compiling and working on the macgui, which means that it builds normally with xcode without errors. As well I re wired a good portion of how the audio is setup in macosx/Controller.mm particularly in prepareJob and so far in my testing everything is working as expected. However, there is one issue in the queue and how it copies the jobs audio settings and displays them. Not critical by any means and it works fine, you just do not get audio info showing in your queue job details. I view this as minor for initial implementation especially since holding it up makes it so that an official commit is unlikely do to it breaking the mac build with jam.
I am not really sure how much it will take to fix that queue audio display since most/all of that is travistex, but I will start working on it. Other than that I know saintdev has updated his patch so far. Note, I am not working with the enum patch as yet. Just the audio portion. The enum change would mean more changes to macgui. Personally I am in favor of getting the audio portion committed first. Then the enum part if everyone wants it in a separate commit. Incremental changes are good imho.
I am not really sure how much it will take to fix that queue audio display since most/all of that is travistex, but I will start working on it. Other than that I know saintdev has updated his patch so far. Note, I am not working with the enum patch as yet. Just the audio portion. The enum change would mean more changes to macgui. Personally I am in favor of getting the audio portion committed first. Then the enum part if everyone wants it in a separate commit. Incremental changes are good imho.
Re: Per-track audio configuration.
And now that you got everything (mostly) working, I had to go and completely mess it updynaflash wrote:Okay, I have it now compiling and working on the macgui, which means that it builds normally with xcode without errors. As well I re wired a good portion of how the audio is setup in macosx/Controller.mm particularly in prepareJob and so far in my testing everything is working as expected.
Here are a few notes.
- What used to be hb_audio_t should now be hb_audio_config_t. The layout as viewed from the UI is the same.
- You should no longer directly interact with title->list_audio or job->list_audio, except to remove audio tracks. I could make a helper function to remove audio tracks, but it would be almost identical to hb_list_rem.
- If you need a new hb_audio_config_t you can allocate it yourself, but it's recommended to use hb_audio_config_new().
- To add audio tracks to the job do
no more need to copy it off the title list yourself
Code: Select all
hb_add_audio(job, audio_config);
- To change the config of a audio track that is already part of job->list_audio or title->list_audio. You would use hb_audio_list_config_item(hb_list_t, int).
- If you (somehow) end up with a pointer to a hb_audio_t you can use hb_audio_get_config(hb_audio_t) to get the config.
Re: Per-track audio configuration.
Great, seems to be working here minus one intermittent crash glitch when using the queue. The queue now displays the tracks in a list form and will dynamically expand to however many tracks there are down the road (used to be hardwired for two).
Re: Per-track audio configuration.
Okay, the intermittent crash is happening in macosx/Controller.mm where I clear out the job audio list:
before adding the newly configured audio for the next encode.
If I comment out
I never get a crash, and can configure and encode all day long without a crash. However subsequent encodes also include the audio tracks from previous encodes when taken from the same source. Obviously not desireable.
So, other than that small issue things seem to work well and the queue will show as many audio tracks as we want instead of being hard coded to the macgui's current two.
http://handbrake.dynaflashtech.net/list ... tqueue.png
Code: Select all
/* Audio tracks and mixdowns */
/* Lets make sure there arent any erroneous audio tracks in the job list, so lets make sure its empty*/
for( int i = 0; i < hb_list_count(job->list_audio);i++)
{
audio = (hb_audio_config_t*) hb_list_item( job->list_audio, i );
hb_list_rem(job->list_audio, audio);
}
If I comment out
Code: Select all
//hb_list_rem(job->list_audio, audio);
So, other than that small issue things seem to work well and the queue will show as many audio tracks as we want instead of being hard coded to the macgui's current two.
http://handbrake.dynaflashtech.net/list ... tqueue.png
Re: Per-track audio configuration.
Durrr, not sure how I missed that before.dynaflash wrote:Okay, the intermittent crash is happening in macosx/Controller.mm where I clear out the job audio list:Code: Select all
/* Audio tracks and mixdowns */ /* Lets make sure there arent any erroneous audio tracks in the job list, so lets make sure its empty*/ for( int i = 0; i < hb_list_count(job->list_audio);i++) { audio = (hb_audio_config_t*) hb_list_item( job->list_audio, i ); hb_list_rem(job->list_audio, audio); }
Replace
Code: Select all
audio = (hb_audio_config_t*) hb_list_item( job->list_audio, i );
Code: Select all
audio = (hb_audio_config_t*) hb_list_item( job->list_audio, 0 );
Re: Per-track audio configuration.
Okay, so that fixes it. I should have figured that out as well, I guess.
Thanks.
Thanks.
- JohnAStebbins
- HandBrake Team
- Posts: 5725
- Joined: Sat Feb 09, 2008 7:21 pm
Re: Per-track audio configuration.
Isn't there still a problem with this in that hb_list_count(job->list_audio) is re-evaluated each time through the loop?saintdev wrote:Durrr, not sure how I missed that before.dynaflash wrote:Okay, the intermittent crash is happening in macosx/Controller.mm where I clear out the job audio list:Code: Select all
/* Audio tracks and mixdowns */ /* Lets make sure there arent any erroneous audio tracks in the job list, so lets make sure its empty*/ for( int i = 0; i < hb_list_count(job->list_audio);i++) { audio = (hb_audio_config_t*) hb_list_item( job->list_audio, i ); hb_list_rem(job->list_audio, audio); }
ReplacewithCode: Select all
audio = (hb_audio_config_t*) hb_list_item( job->list_audio, i );
Code: Select all
audio = (hb_audio_config_t*) hb_list_item( job->list_audio, 0 );
If initially the count it say 2. After the first iteration, one item is removed, i will be 1 and hb_list_count wil re-evaluate to 1.
i is not < 1 so the loop will exit leaving an item in the list.
Re: Per-track audio configuration.
right, I should have noted a change I made which is:
which should work, I think.
Code: Select all
/* Lets make sure there arent any erroneous audio tracks in the job list, so lets make sure its empty*/
int num_audio_tracks = hb_list_count(job->list_audio);
for( int i = 0; i < num_audio_tracks;i++)
{
audio = (hb_audio_config_t*) hb_list_item( job->list_audio, 0 );
hb_list_rem(job->list_audio, audio);
}
Re: Per-track audio configuration.
Patches updated to latest. Unless anyone finds any bugs, this should be the final set.
Re: Per-track audio configuration.
Added the third patch for the macgui allowing for a successful compile on mac.