jp9000
/
obs-studio
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
obs-studio/obs/forms/OBSBasicSettings.ui

3674 lines
141 KiB
Plaintext
Raw Normal View History

Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<?xml version="1.0" encoding="UTF-8"?>
<ui version="4.0">
<class>OBSBasicSettings</class>
<widget class="QDialog" name="OBSBasicSettings">
<property name="geometry">
<rect>
<x>0</x>
<y>0</y>
UI: Add recording presets to simple output So certain high-profile individuals were complaining that it was difficult to configure recording settings for quality in OBS. So, I decided to add a very easy-to-use auto-configuration for high quality encoding -- including lossless encoding. This feature will automatically configure ideal recording settings based upon a specified quality level. Recording quality presets added to simple output: - Same as stream: Copies the encoded streaming data with no extra usage hit. - High quality: uses a higher CRF value (starting at 23) if using x264. - Indistinguishable quality: uses a low CRF value (starting at 16) if using x264. - Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a user tries to select lossless, they will be warned both via a dialog prompt and a warning message in the settings window to ensure they understand that it requires tremendous amounts of free space. It will always use the AVI file format. Extra Notes: - When High/Indistinguishable quality is set, it will allow you to select the recording encoder. Currently, it just allows you to select x264 (at either veryfast or ultrafast). Later on, it'll be useful to be able to set up pre-configured presets for hardware encoders once more are implemented and tested. - I decided to allow the use of x264 at both veryfast or ultrafast presets. The reasoning is two-fold: 1.) ultrafast is perfectly viable even for near indistinguishable quality as long as it has the appropriate CRF value. It's nice if you want to record but would like to or need to reduce the impact of encoding on the CPU. It will automatically compensate for the preset at the cost of larger file size. 2.) It was suggested to just always use ultrafast, but ultrafast requires 2-4x as much disk space for the same CRF (most likely due to x264 compensating for the preset). Providing veryfast is important if you really want to reduce file size and/or reduce blocking at lower quality levels. - When a recording preset is used, a secondary audio encoder is also spawned at 192 bitrate to ensure high quality audio. I chose 192 because that's the limit of the media foundation aac encoder on windows, which I want to make sure is used if available due to its high performance. - The CRF calculation is based upon resolution, quality, and whether it's set to ultrafast. First, quality sets the base CRF, 23 for "good" quality, 16 for "very high" quality. If set to ultrafast, it'll subtract 2 points from the CRF value to help compensate. Lower resolutions will also lower the CRF value to help improve higher details with a smaller pixel ratio.
2015-09-18 22:29:36 -07:00
<width>896</width>
<height>667</height>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</rect>
</property>
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
<property name="sizePolicy">
<sizepolicy hsizetype="Fixed" vsizetype="Fixed">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<property name="windowTitle">
Add text for missing window titles
2014-07-13 13:09:56 -07:00
<string>Settings</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
<layout class="QVBoxLayout" name="verticalLayout">
<item>
<layout class="QHBoxLayout" name="horizontalLayout">
<item alignment="Qt::AlignLeft">
<widget class="QListWidget" name="listWidget">
<property name="sizePolicy">
<sizepolicy hsizetype="Minimum" vsizetype="Expanding">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="maximumSize">
<size>
<width>135</width>
<height>16777215</height>
</size>
</property>
<property name="iconSize">
<size>
<width>48</width>
<height>48</height>
</size>
</property>
UI: Pre-select "General" entry when launching settings This is just for visuals, no functionality change
2015-05-13 12:55:46 -07:00
<property name="currentRow">
<number>0</number>
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<item>
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Settings.General</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
<property name="icon">
<iconset resource="obs.qrc">
<normaloff>:/settings/images/settings/system-settings-3.png</normaloff>:/settings/images/settings/system-settings-3.png</iconset>
</property>
</item>
<item>
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Settings.Stream</string>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</property>
<property name="icon">
<iconset resource="obs.qrc">
<normaloff>:/settings/images/settings/network.png</normaloff>:/settings/images/settings/network.png</iconset>
</property>
</item>
<item>
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Settings.Output</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
<property name="icon">
<iconset resource="obs.qrc">
<normaloff>:/settings/images/settings/network-bluetooth.png</normaloff>:/settings/images/settings/network-bluetooth.png</iconset>
</property>
</item>
<item>
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Settings.Audio</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
<property name="icon">
<iconset resource="obs.qrc">
<normaloff>:/settings/images/settings/decibel_audio_player.png</normaloff>:/settings/images/settings/decibel_audio_player.png</iconset>
</property>
</item>
<item>
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Settings.Video</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
<property name="icon">
<iconset resource="obs.qrc">
<normaloff>:/settings/images/settings/video-display-3.png</normaloff>:/settings/images/settings/video-display-3.png</iconset>
</property>
</item>
UI: Add hotkeys page in settings dialog
2014-11-01 13:50:36 -07:00
<item>
<property name="text">
<string>Basic.Settings.Hotkeys</string>
</property>
<property name="icon">
<iconset resource="obs.qrc">
<normaloff>:/settings/images/settings/preferences-desktop-keyboard-shortcuts.png</normaloff>:/settings/images/settings/preferences-desktop-keyboard-shortcuts.png</iconset>
</property>
</item>
UI: Add 'Advanced' settings section Currently, this allows the setting of values such as: - Audio buffering time - Color format (still somewhat unsupported) - YUV color space (if a YUV format) = YUV color range (if a YUV format) More color formats will be added in the future, such as RGB and YUV 4:2:2 formats.
2015-02-11 12:55:06 -08:00
<item>
<property name="text">
<string>Basic.Settings.Advanced</string>
</property>
<property name="icon">
<iconset resource="obs.qrc">
<normaloff>:/settings/images/settings/advanced.png</normaloff>:/settings/images/settings/advanced.png</iconset>
</property>
</item>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</widget>
</item>
<item>
<widget class="QStackedWidget" name="settingsPages">
<property name="currentIndex">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<number>0</number>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
<widget class="QWidget" name="generalPage">
<layout class="QFormLayout" name="formLayout_2">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<property name="fieldGrowthPolicy">
<enum>QFormLayout::AllNonFixedFieldsGrow</enum>
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<property name="labelAlignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
<item row="0" column="0">
<spacer name="verticalSpacer">
<property name="orientation">
<enum>Qt::Vertical</enum>
</property>
<property name="sizeHint" stdset="0">
<size>
<width>20</width>
<height>40</height>
</size>
</property>
</spacer>
</item>
<item row="1" column="0">
<widget class="QLabel" name="label">
<property name="minimumSize">
<size>
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<width>170</width>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<height>0</height>
</size>
</property>
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Settings.General.Language</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
<property name="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>language</cstring>
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</widget>
</item>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<item row="1" column="1">
<widget class="QComboBox" name="language"/>
</item>
UI: Implement theme selection option OBS will offer the user a list of themes which are .qss files inside data/obs-studio/themes. If no theme is found in the configuration, it loads the default theme for the system.
2015-02-16 23:45:34 -08:00
<item row="2" column="0">
<widget class="QLabel" name="label_42">
<property name="text">
<string>Basic.Settings.General.Theme</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>theme</cstring>
</property>
UI: Implement theme selection option OBS will offer the user a list of themes which are .qss files inside data/obs-studio/themes. If no theme is found in the configuration, it loads the default theme for the system.
2015-02-16 23:45:34 -08:00
</widget>
</item>
<item row="2" column="1">
<widget class="QComboBox" name="theme"/>
</item>
UI: Add options to enable/disable stream confirm dialogs Some streamers would accidentally hit start/stop streaming, which on certain services would send out mass emails to all their followers. This just adds options to general settings to optionally enable dialogs that confirm whether to actually start/stop streaming when the button is clicked.
2016-01-22 08:09:04 -08:00
<item row="3" column="1">
<widget class="QCheckBox" name="warnBeforeStreamStart">
<property name="text">
<string>Basic.Settings.General.WarnBeforeStartingStream</string>
</property>
</widget>
</item>
<item row="4" column="1">
<widget class="QCheckBox" name="warnBeforeStreamStop">
<property name="text">
<string>Basic.Settings.General.WarnBeforeStoppingStream</string>
</property>
</widget>
</item>
UI: Add snap options to general settings section Allows the user to disable snapping all together or control the snap threshold.
2016-04-06 18:03:29 -07:00
<item row="5" column="0" colspan="2">
<widget class="Line" name="line_4">
<property name="orientation">
<enum>Qt::Horizontal</enum>
</property>
</widget>
</item>
<item row="6" column="0" colspan="2">
<widget class="QGroupBox" name="groupBox_10">
<property name="enabled">
<bool>true</bool>
</property>
<property name="sizePolicy">
<sizepolicy hsizetype="Preferred" vsizetype="Maximum">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="title">
<string>Basic.Settings.General.Snapping</string>
</property>
<property name="flat">
<bool>false</bool>
</property>
<layout class="QFormLayout" name="formLayout_21">
<property name="labelAlignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
<item row="0" column="1">
<widget class="QCheckBox" name="snappingEnabled">
<property name="text">
<string>Enable</string>
</property>
<property name="checked">
<bool>true</bool>
</property>
</widget>
</item>
<item row="2" column="1">
<widget class="QCheckBox" name="screenSnapping">
<property name="text">
<string>Basic.Settings.General.ScreenSnapping</string>
</property>
<property name="checked">
<bool>true</bool>
</property>
</widget>
</item>
UI: Add option to snap to vertical/horizontal center Allows users to snap sources to the horizontal or vertical centers of the screen. Off by default. Closes jp9000/obs-studio#528
2016-04-06 18:10:39 -07:00
<item row="4" column="1">
<widget class="QCheckBox" name="centerSnapping">
<property name="text">
<string>Basic.Settings.General.CenterSnapping</string>
</property>
<property name="checked">
<bool>true</bool>
</property>
</widget>
</item>
UI: Add option to snap to edges of other sources Allows the user to snap sources to the edges of other sources, on by default. Closes jp9000/obs-studio#530
2016-04-06 18:13:56 -07:00
<item row="3" column="1">
<widget class="QCheckBox" name="sourceSnapping">
<property name="text">
<string>Basic.Settings.General.SourceSnapping</string>
</property>
<property name="checked">
<bool>true</bool>
</property>
</widget>
</item>
UI: Add snap options to general settings section Allows the user to disable snapping all together or control the snap threshold.
2016-04-06 18:03:29 -07:00
<item row="1" column="1">
<widget class="QDoubleSpinBox" name="snapDistance">
<property name="decimals">
<number>1</number>
</property>
<property name="singleStep">
<double>0.500000000000000</double>
</property>
<property name="value">
<double>10.000000000000000</double>
</property>
</widget>
</item>
<item row="1" column="0">
<widget class="QLabel" name="label_9">
<property name="minimumSize">
<size>
<width>170</width>
<height>0</height>
</size>
</property>
<property name="text">
<string>Basic.Settings.General.SnapDistance</string>
</property>
<property name="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
</widget>
</item>
</layout>
</widget>
</item>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</layout>
</widget>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
<widget class="QWidget" name="streamPage">
<layout class="QVBoxLayout" name="verticalLayout_5">
<property name="leftMargin">
<number>0</number>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
<property name="topMargin">
<number>0</number>
Add preliminary streaming code for testing - Add some temporary streaming code using FFmpeg. FFmpeg itself is not very ideal for streaming; lack of direct control of the sockets and no framedrop handling means that FFmpeg is definitely not something you want to use without wrapper code. I'd prefer writing my own network framework in this particular case just because you give away so much control of the network interface. Wasted an entire day trying to go through FFmpeg issues. There's just no way FFmpeg should be used for real streaming (at least without being patched or submitting some sort of patch, but I'm sort of feeling "meh" on that idea) I had to end up writing multiple threads just to handle both connecting and writing, because av_interleaved_write_frame blocks every call, stalling the main encoder thread, and thus also stalling draw signals. - Add some temporary user interface for streaming settings. This is just temporary for the time being. It's in the outputs section of the basic-mode settings - Make it so that dynamic arrays do not free all their data when the size just happens to be reduced to 0. This prevents constant reallocation when an array keeps going from 1 item to 0 items. Also, it was bad to become dependent upon that functionality. You must now always explicitly call "free" on it to ensure the data is free, and that's how it should be. Implicit functionality can lead to confusion and maintainability issues.
2014-03-10 13:10:35 -07:00
</property>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item>
<widget class="QWidget" name="streamContainer" native="true">
<property name="sizePolicy">
<sizepolicy hsizetype="Preferred" vsizetype="Minimum">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
Add preliminary streaming code for testing - Add some temporary streaming code using FFmpeg. FFmpeg itself is not very ideal for streaming; lack of direct control of the sockets and no framedrop handling means that FFmpeg is definitely not something you want to use without wrapper code. I'd prefer writing my own network framework in this particular case just because you give away so much control of the network interface. Wasted an entire day trying to go through FFmpeg issues. There's just no way FFmpeg should be used for real streaming (at least without being patched or submitting some sort of patch, but I'm sort of feeling "meh" on that idea) I had to end up writing multiple threads just to handle both connecting and writing, because av_interleaved_write_frame blocks every call, stalling the main encoder thread, and thus also stalling draw signals. - Add some temporary user interface for streaming settings. This is just temporary for the time being. It's in the outputs section of the basic-mode settings - Make it so that dynamic arrays do not free all their data when the size just happens to be reduced to 0. This prevents constant reallocation when an array keeps going from 1 item to 0 items. Also, it was bad to become dependent upon that functionality. You must now always explicitly call "free" on it to ensure the data is free, and that's how it should be. Implicit functionality can lead to confusion and maintainability issues.
2014-03-10 13:10:35 -07:00
</property>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
<layout class="QVBoxLayout" name="verticalLayout_6">
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item alignment="Qt::AlignTop">
<widget class="QWidget" name="widget_5" native="true">
<property name="sizePolicy">
<sizepolicy hsizetype="Preferred" vsizetype="Maximum">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<layout class="QVBoxLayout" name="verticalLayout_7">
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item>
<widget class="QWidget" name="widget_6" native="true">
<layout class="QFormLayout" name="formLayout_8">
<property name="fieldGrowthPolicy">
<enum>QFormLayout::AllNonFixedFieldsGrow</enum>
</property>
<item row="0" column="0">
<widget class="QLabel" name="label_21">
<property name="minimumSize">
<size>
<width>170</width>
<height>0</height>
</size>
</property>
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Settings.Stream.StreamType</string>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</property>
<property name="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>streamType</cstring>
</property>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</widget>
</item>
<item row="0" column="1">
<widget class="QComboBox" name="streamType"/>
</item>
</layout>
</widget>
</item>
<item>
<widget class="Line" name="line">
<property name="orientation">
<enum>Qt::Horizontal</enum>
</property>
</widget>
</item>
</layout>
</widget>
</item>
</layout>
Add preliminary streaming code for testing - Add some temporary streaming code using FFmpeg. FFmpeg itself is not very ideal for streaming; lack of direct control of the sockets and no framedrop handling means that FFmpeg is definitely not something you want to use without wrapper code. I'd prefer writing my own network framework in this particular case just because you give away so much control of the network interface. Wasted an entire day trying to go through FFmpeg issues. There's just no way FFmpeg should be used for real streaming (at least without being patched or submitting some sort of patch, but I'm sort of feeling "meh" on that idea) I had to end up writing multiple threads just to handle both connecting and writing, because av_interleaved_write_frame blocks every call, stalling the main encoder thread, and thus also stalling draw signals. - Add some temporary user interface for streaming settings. This is just temporary for the time being. It's in the outputs section of the basic-mode settings - Make it so that dynamic arrays do not free all their data when the size just happens to be reduced to 0. This prevents constant reallocation when an array keeps going from 1 item to 0 items. Also, it was bad to become dependent upon that functionality. You must now always explicitly call "free" on it to ensure the data is free, and that's how it should be. Implicit functionality can lead to confusion and maintainability issues.
2014-03-10 13:10:35 -07:00
</widget>
</item>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</layout>
</widget>
<widget class="QWidget" name="outputPage">
<layout class="QVBoxLayout" name="verticalLayout_2">
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item alignment="Qt::AlignTop">
<widget class="QWidget" name="widget" native="true">
Adjust the way properties view UI displays It didn't really look very nice in most cases and the controls were always compacted, doing this makes it look a bit better. Also change it so the properties window shows the properties on the bottom below the source rather than to the right, seeing as in most cases the source has a greater width than height, and it feels just a little bit better to look at (thought that's just my opinion). Controls still stretch really far sometimes though, I wonder what should be done about that to be honest. Maybe prevent it from scrolling to the right?
2014-04-24 21:12:23 -07:00
<property name="sizePolicy">
<sizepolicy hsizetype="Expanding" vsizetype="Preferred">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
<layout class="QFormLayout" name="formLayout_5">
Properties VIew: Fix a more form layout issues
2014-04-24 21:28:56 -07:00
<property name="fieldGrowthPolicy">
<enum>QFormLayout::AllNonFixedFieldsGrow</enum>
</property>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
<item row="0" column="0">
UI: Make "output mode" label disabled if active I had previous made the output mode list box become disabled, but neglected to do it for the label as well.
2015-03-12 08:49:07 -07:00
<widget class="QLabel" name="outputModeLabel">
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
<property name="minimumSize">
<size>
<width>170</width>
<height>0</height>
</size>
</property>
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Settings.Output.Mode</string>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</property>
<property name="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>outputMode</cstring>
</property>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</widget>
</item>
<item row="0" column="1">
<widget class="QComboBox" name="outputMode">
<property name="enabled">
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<bool>true</bool>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</property>
Adjust the way properties view UI displays It didn't really look very nice in most cases and the controls were always compacted, doing this makes it look a bit better. Also change it so the properties window shows the properties on the bottom below the source rather than to the right, seeing as in most cases the source has a greater width than height, and it feels just a little bit better to look at (thought that's just my opinion). Controls still stretch really far sometimes though, I wonder what should be done about that to be honest. Maybe prevent it from scrolling to the right?
2014-04-24 21:12:23 -07:00
<property name="sizePolicy">
<sizepolicy hsizetype="Expanding" vsizetype="Fixed">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
<property name="currentIndex">
<number>0</number>
</property>
<item>
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Settings.Output.Mode.Simple</string>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</property>
</item>
<item>
<property name="text">
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<string>Basic.Settings.Output.Mode.Adv</string>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</property>
</item>
</widget>
</item>
</layout>
Add preliminary streaming code for testing - Add some temporary streaming code using FFmpeg. FFmpeg itself is not very ideal for streaming; lack of direct control of the sockets and no framedrop handling means that FFmpeg is definitely not something you want to use without wrapper code. I'd prefer writing my own network framework in this particular case just because you give away so much control of the network interface. Wasted an entire day trying to go through FFmpeg issues. There's just no way FFmpeg should be used for real streaming (at least without being patched or submitting some sort of patch, but I'm sort of feeling "meh" on that idea) I had to end up writing multiple threads just to handle both connecting and writing, because av_interleaved_write_frame blocks every call, stalling the main encoder thread, and thus also stalling draw signals. - Add some temporary user interface for streaming settings. This is just temporary for the time being. It's in the outputs section of the basic-mode settings - Make it so that dynamic arrays do not free all their data when the size just happens to be reduced to 0. This prevents constant reallocation when an array keeps going from 1 item to 0 items. Also, it was bad to become dependent upon that functionality. You must now always explicitly call "free" on it to ensure the data is free, and that's how it should be. Implicit functionality can lead to confusion and maintainability issues.
2014-03-10 13:10:35 -07:00
</widget>
</item>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
<item>
<widget class="Line" name="line_2">
<property name="orientation">
<enum>Qt::Horizontal</enum>
Add preliminary streaming code for testing - Add some temporary streaming code using FFmpeg. FFmpeg itself is not very ideal for streaming; lack of direct control of the sockets and no framedrop handling means that FFmpeg is definitely not something you want to use without wrapper code. I'd prefer writing my own network framework in this particular case just because you give away so much control of the network interface. Wasted an entire day trying to go through FFmpeg issues. There's just no way FFmpeg should be used for real streaming (at least without being patched or submitting some sort of patch, but I'm sort of feeling "meh" on that idea) I had to end up writing multiple threads just to handle both connecting and writing, because av_interleaved_write_frame blocks every call, stalling the main encoder thread, and thus also stalling draw signals. - Add some temporary user interface for streaming settings. This is just temporary for the time being. It's in the outputs section of the basic-mode settings - Make it so that dynamic arrays do not free all their data when the size just happens to be reduced to 0. This prevents constant reallocation when an array keeps going from 1 item to 0 items. Also, it was bad to become dependent upon that functionality. You must now always explicitly call "free" on it to ensure the data is free, and that's how it should be. Implicit functionality can lead to confusion and maintainability issues.
2014-03-10 13:10:35 -07:00
</property>
</widget>
</item>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
<item>
<widget class="QStackedWidget" name="outputModePages">
<property name="currentIndex">
<number>0</number>
Add preliminary streaming code for testing - Add some temporary streaming code using FFmpeg. FFmpeg itself is not very ideal for streaming; lack of direct control of the sockets and no framedrop handling means that FFmpeg is definitely not something you want to use without wrapper code. I'd prefer writing my own network framework in this particular case just because you give away so much control of the network interface. Wasted an entire day trying to go through FFmpeg issues. There's just no way FFmpeg should be used for real streaming (at least without being patched or submitting some sort of patch, but I'm sort of feeling "meh" on that idea) I had to end up writing multiple threads just to handle both connecting and writing, because av_interleaved_write_frame blocks every call, stalling the main encoder thread, and thus also stalling draw signals. - Add some temporary user interface for streaming settings. This is just temporary for the time being. It's in the outputs section of the basic-mode settings - Make it so that dynamic arrays do not free all their data when the size just happens to be reduced to 0. This prevents constant reallocation when an array keeps going from 1 item to 0 items. Also, it was bad to become dependent upon that functionality. You must now always explicitly call "free" on it to ensure the data is free, and that's how it should be. Implicit functionality can lead to confusion and maintainability issues.
2014-03-10 13:10:35 -07:00
</property>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
<widget class="QWidget" name="easyOutputsPage">
<layout class="QVBoxLayout" name="verticalLayout_3">
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
UI: Add recording presets to simple output So certain high-profile individuals were complaining that it was difficult to configure recording settings for quality in OBS. So, I decided to add a very easy-to-use auto-configuration for high quality encoding -- including lossless encoding. This feature will automatically configure ideal recording settings based upon a specified quality level. Recording quality presets added to simple output: - Same as stream: Copies the encoded streaming data with no extra usage hit. - High quality: uses a higher CRF value (starting at 23) if using x264. - Indistinguishable quality: uses a low CRF value (starting at 16) if using x264. - Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a user tries to select lossless, they will be warned both via a dialog prompt and a warning message in the settings window to ensure they understand that it requires tremendous amounts of free space. It will always use the AVI file format. Extra Notes: - When High/Indistinguishable quality is set, it will allow you to select the recording encoder. Currently, it just allows you to select x264 (at either veryfast or ultrafast). Later on, it'll be useful to be able to set up pre-configured presets for hardware encoders once more are implemented and tested. - I decided to allow the use of x264 at both veryfast or ultrafast presets. The reasoning is two-fold: 1.) ultrafast is perfectly viable even for near indistinguishable quality as long as it has the appropriate CRF value. It's nice if you want to record but would like to or need to reduce the impact of encoding on the CPU. It will automatically compensate for the preset at the cost of larger file size. 2.) It was suggested to just always use ultrafast, but ultrafast requires 2-4x as much disk space for the same CRF (most likely due to x264 compensating for the preset). Providing veryfast is important if you really want to reduce file size and/or reduce blocking at lower quality levels. - When a recording preset is used, a secondary audio encoder is also spawned at 192 bitrate to ensure high quality audio. I chose 192 because that's the limit of the media foundation aac encoder on windows, which I want to make sure is used if available due to its high performance. - The CRF calculation is based upon resolution, quality, and whether it's set to ultrafast. First, quality sets the base CRF, 23 for "good" quality, 16 for "very high" quality. If set to ultrafast, it'll subtract 2 points from the CRF value to help compensate. Lower resolutions will also lower the CRF value to help improve higher details with a smaller pixel ratio.
2015-09-18 22:29:36 -07:00
<item>
<widget class="QGroupBox" name="groupBox_8">
<property name="sizePolicy">
<sizepolicy hsizetype="Preferred" vsizetype="Maximum">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="title">
<string>Basic.Settings.Output.Adv.Streaming</string>
</property>
<layout class="QFormLayout" name="formLayout_20">
<property name="fieldGrowthPolicy">
<enum>QFormLayout::AllNonFixedFieldsGrow</enum>
</property>
<property name="labelAlignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
<item row="0" column="0">
<widget class="QLabel" name="label_19">
<property name="minimumSize">
<size>
<width>170</width>
<height>0</height>
</size>
</property>
<property name="text">
<string>Basic.Settings.Output.VideoBitrate</string>
</property>
<property name="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>simpleOutputVBitrate</cstring>
</property>
UI: Add recording presets to simple output So certain high-profile individuals were complaining that it was difficult to configure recording settings for quality in OBS. So, I decided to add a very easy-to-use auto-configuration for high quality encoding -- including lossless encoding. This feature will automatically configure ideal recording settings based upon a specified quality level. Recording quality presets added to simple output: - Same as stream: Copies the encoded streaming data with no extra usage hit. - High quality: uses a higher CRF value (starting at 23) if using x264. - Indistinguishable quality: uses a low CRF value (starting at 16) if using x264. - Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a user tries to select lossless, they will be warned both via a dialog prompt and a warning message in the settings window to ensure they understand that it requires tremendous amounts of free space. It will always use the AVI file format. Extra Notes: - When High/Indistinguishable quality is set, it will allow you to select the recording encoder. Currently, it just allows you to select x264 (at either veryfast or ultrafast). Later on, it'll be useful to be able to set up pre-configured presets for hardware encoders once more are implemented and tested. - I decided to allow the use of x264 at both veryfast or ultrafast presets. The reasoning is two-fold: 1.) ultrafast is perfectly viable even for near indistinguishable quality as long as it has the appropriate CRF value. It's nice if you want to record but would like to or need to reduce the impact of encoding on the CPU. It will automatically compensate for the preset at the cost of larger file size. 2.) It was suggested to just always use ultrafast, but ultrafast requires 2-4x as much disk space for the same CRF (most likely due to x264 compensating for the preset). Providing veryfast is important if you really want to reduce file size and/or reduce blocking at lower quality levels. - When a recording preset is used, a secondary audio encoder is also spawned at 192 bitrate to ensure high quality audio. I chose 192 because that's the limit of the media foundation aac encoder on windows, which I want to make sure is used if available due to its high performance. - The CRF calculation is based upon resolution, quality, and whether it's set to ultrafast. First, quality sets the base CRF, 23 for "good" quality, 16 for "very high" quality. If set to ultrafast, it'll subtract 2 points from the CRF value to help compensate. Lower resolutions will also lower the CRF value to help improve higher details with a smaller pixel ratio.
2015-09-18 22:29:36 -07:00
</widget>
</item>
<item row="0" column="1">
<widget class="QSpinBox" name="simpleOutputVBitrate">
<property name="minimum">
<number>200</number>
</property>
<property name="maximum">
<number>1000000</number>
</property>
<property name="value">
<number>2000</number>
</property>
</widget>
</item>
UI: Add support for QSV encoder to simple output
2016-04-18 00:56:51 -07:00
<item row="2" column="0">
UI: Add recording presets to simple output So certain high-profile individuals were complaining that it was difficult to configure recording settings for quality in OBS. So, I decided to add a very easy-to-use auto-configuration for high quality encoding -- including lossless encoding. This feature will automatically configure ideal recording settings based upon a specified quality level. Recording quality presets added to simple output: - Same as stream: Copies the encoded streaming data with no extra usage hit. - High quality: uses a higher CRF value (starting at 23) if using x264. - Indistinguishable quality: uses a low CRF value (starting at 16) if using x264. - Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a user tries to select lossless, they will be warned both via a dialog prompt and a warning message in the settings window to ensure they understand that it requires tremendous amounts of free space. It will always use the AVI file format. Extra Notes: - When High/Indistinguishable quality is set, it will allow you to select the recording encoder. Currently, it just allows you to select x264 (at either veryfast or ultrafast). Later on, it'll be useful to be able to set up pre-configured presets for hardware encoders once more are implemented and tested. - I decided to allow the use of x264 at both veryfast or ultrafast presets. The reasoning is two-fold: 1.) ultrafast is perfectly viable even for near indistinguishable quality as long as it has the appropriate CRF value. It's nice if you want to record but would like to or need to reduce the impact of encoding on the CPU. It will automatically compensate for the preset at the cost of larger file size. 2.) It was suggested to just always use ultrafast, but ultrafast requires 2-4x as much disk space for the same CRF (most likely due to x264 compensating for the preset). Providing veryfast is important if you really want to reduce file size and/or reduce blocking at lower quality levels. - When a recording preset is used, a secondary audio encoder is also spawned at 192 bitrate to ensure high quality audio. I chose 192 because that's the limit of the media foundation aac encoder on windows, which I want to make sure is used if available due to its high performance. - The CRF calculation is based upon resolution, quality, and whether it's set to ultrafast. First, quality sets the base CRF, 23 for "good" quality, 16 for "very high" quality. If set to ultrafast, it'll subtract 2 points from the CRF value to help compensate. Lower resolutions will also lower the CRF value to help improve higher details with a smaller pixel ratio.
2015-09-18 22:29:36 -07:00
<widget class="QLabel" name="label_20">
<property name="text">
<string>Basic.Settings.Output.AudioBitrate</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>simpleOutputABitrate</cstring>
</property>
UI: Add recording presets to simple output So certain high-profile individuals were complaining that it was difficult to configure recording settings for quality in OBS. So, I decided to add a very easy-to-use auto-configuration for high quality encoding -- including lossless encoding. This feature will automatically configure ideal recording settings based upon a specified quality level. Recording quality presets added to simple output: - Same as stream: Copies the encoded streaming data with no extra usage hit. - High quality: uses a higher CRF value (starting at 23) if using x264. - Indistinguishable quality: uses a low CRF value (starting at 16) if using x264. - Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a user tries to select lossless, they will be warned both via a dialog prompt and a warning message in the settings window to ensure they understand that it requires tremendous amounts of free space. It will always use the AVI file format. Extra Notes: - When High/Indistinguishable quality is set, it will allow you to select the recording encoder. Currently, it just allows you to select x264 (at either veryfast or ultrafast). Later on, it'll be useful to be able to set up pre-configured presets for hardware encoders once more are implemented and tested. - I decided to allow the use of x264 at both veryfast or ultrafast presets. The reasoning is two-fold: 1.) ultrafast is perfectly viable even for near indistinguishable quality as long as it has the appropriate CRF value. It's nice if you want to record but would like to or need to reduce the impact of encoding on the CPU. It will automatically compensate for the preset at the cost of larger file size. 2.) It was suggested to just always use ultrafast, but ultrafast requires 2-4x as much disk space for the same CRF (most likely due to x264 compensating for the preset). Providing veryfast is important if you really want to reduce file size and/or reduce blocking at lower quality levels. - When a recording preset is used, a secondary audio encoder is also spawned at 192 bitrate to ensure high quality audio. I chose 192 because that's the limit of the media foundation aac encoder on windows, which I want to make sure is used if available due to its high performance. - The CRF calculation is based upon resolution, quality, and whether it's set to ultrafast. First, quality sets the base CRF, 23 for "good" quality, 16 for "very high" quality. If set to ultrafast, it'll subtract 2 points from the CRF value to help compensate. Lower resolutions will also lower the CRF value to help improve higher details with a smaller pixel ratio.
2015-09-18 22:29:36 -07:00
</widget>
</item>
UI: Add support for QSV encoder to simple output
2016-04-18 00:56:51 -07:00
<item row="2" column="1">
UI: Add recording presets to simple output So certain high-profile individuals were complaining that it was difficult to configure recording settings for quality in OBS. So, I decided to add a very easy-to-use auto-configuration for high quality encoding -- including lossless encoding. This feature will automatically configure ideal recording settings based upon a specified quality level. Recording quality presets added to simple output: - Same as stream: Copies the encoded streaming data with no extra usage hit. - High quality: uses a higher CRF value (starting at 23) if using x264. - Indistinguishable quality: uses a low CRF value (starting at 16) if using x264. - Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a user tries to select lossless, they will be warned both via a dialog prompt and a warning message in the settings window to ensure they understand that it requires tremendous amounts of free space. It will always use the AVI file format. Extra Notes: - When High/Indistinguishable quality is set, it will allow you to select the recording encoder. Currently, it just allows you to select x264 (at either veryfast or ultrafast). Later on, it'll be useful to be able to set up pre-configured presets for hardware encoders once more are implemented and tested. - I decided to allow the use of x264 at both veryfast or ultrafast presets. The reasoning is two-fold: 1.) ultrafast is perfectly viable even for near indistinguishable quality as long as it has the appropriate CRF value. It's nice if you want to record but would like to or need to reduce the impact of encoding on the CPU. It will automatically compensate for the preset at the cost of larger file size. 2.) It was suggested to just always use ultrafast, but ultrafast requires 2-4x as much disk space for the same CRF (most likely due to x264 compensating for the preset). Providing veryfast is important if you really want to reduce file size and/or reduce blocking at lower quality levels. - When a recording preset is used, a secondary audio encoder is also spawned at 192 bitrate to ensure high quality audio. I chose 192 because that's the limit of the media foundation aac encoder on windows, which I want to make sure is used if available due to its high performance. - The CRF calculation is based upon resolution, quality, and whether it's set to ultrafast. First, quality sets the base CRF, 23 for "good" quality, 16 for "very high" quality. If set to ultrafast, it'll subtract 2 points from the CRF value to help compensate. Lower resolutions will also lower the CRF value to help improve higher details with a smaller pixel ratio.
2015-09-18 22:29:36 -07:00
<widget class="QComboBox" name="simpleOutputABitrate">
<property name="currentIndex">
<number>8</number>
</property>
<item>
<property name="text">
<string>32</string>
</property>
</item>
<item>
<property name="text">
<string>48</string>
</property>
</item>
<item>
<property name="text">
<string>64</string>
</property>
</item>
<item>
<property name="text">
<string>80</string>
</property>
</item>
<item>
<property name="text">
<string>96</string>
</property>
</item>
<item>
<property name="text">
<string>112</string>
</property>
</item>
<item>
<property name="text">
<string>128</string>
</property>
</item>
<item>
<property name="text">
<string>160</string>
</property>
</item>
<item>
<property name="text">
<string>192</string>
</property>
</item>
<item>
<property name="text">
<string>256</string>
</property>
</item>
<item>
<property name="text">
<string>320</string>
</property>
</item>
</widget>
</item>
UI: Add support for QSV encoder to simple output
2016-04-18 00:56:51 -07:00
<item row="3" column="1">
UI: Add recording presets to simple output So certain high-profile individuals were complaining that it was difficult to configure recording settings for quality in OBS. So, I decided to add a very easy-to-use auto-configuration for high quality encoding -- including lossless encoding. This feature will automatically configure ideal recording settings based upon a specified quality level. Recording quality presets added to simple output: - Same as stream: Copies the encoded streaming data with no extra usage hit. - High quality: uses a higher CRF value (starting at 23) if using x264. - Indistinguishable quality: uses a low CRF value (starting at 16) if using x264. - Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a user tries to select lossless, they will be warned both via a dialog prompt and a warning message in the settings window to ensure they understand that it requires tremendous amounts of free space. It will always use the AVI file format. Extra Notes: - When High/Indistinguishable quality is set, it will allow you to select the recording encoder. Currently, it just allows you to select x264 (at either veryfast or ultrafast). Later on, it'll be useful to be able to set up pre-configured presets for hardware encoders once more are implemented and tested. - I decided to allow the use of x264 at both veryfast or ultrafast presets. The reasoning is two-fold: 1.) ultrafast is perfectly viable even for near indistinguishable quality as long as it has the appropriate CRF value. It's nice if you want to record but would like to or need to reduce the impact of encoding on the CPU. It will automatically compensate for the preset at the cost of larger file size. 2.) It was suggested to just always use ultrafast, but ultrafast requires 2-4x as much disk space for the same CRF (most likely due to x264 compensating for the preset). Providing veryfast is important if you really want to reduce file size and/or reduce blocking at lower quality levels. - When a recording preset is used, a secondary audio encoder is also spawned at 192 bitrate to ensure high quality audio. I chose 192 because that's the limit of the media foundation aac encoder on windows, which I want to make sure is used if available due to its high performance. - The CRF calculation is based upon resolution, quality, and whether it's set to ultrafast. First, quality sets the base CRF, 23 for "good" quality, 16 for "very high" quality. If set to ultrafast, it'll subtract 2 points from the CRF value to help compensate. Lower resolutions will also lower the CRF value to help improve higher details with a smaller pixel ratio.
2015-09-18 22:29:36 -07:00
<widget class="QCheckBox" name="simpleOutAdvanced">
<property name="text">
<string>Basic.Settings.Output.Advanced</string>
</property>
<property name="checked">
<bool>true</bool>
</property>
</widget>
</item>
UI: Add support for QSV encoder to simple output
2016-04-18 00:56:51 -07:00
<item row="5" column="1">
<widget class="QComboBox" name="simpleOutPreset"/>
UI: Add recording presets to simple output So certain high-profile individuals were complaining that it was difficult to configure recording settings for quality in OBS. So, I decided to add a very easy-to-use auto-configuration for high quality encoding -- including lossless encoding. This feature will automatically configure ideal recording settings based upon a specified quality level. Recording quality presets added to simple output: - Same as stream: Copies the encoded streaming data with no extra usage hit. - High quality: uses a higher CRF value (starting at 23) if using x264. - Indistinguishable quality: uses a low CRF value (starting at 16) if using x264. - Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a user tries to select lossless, they will be warned both via a dialog prompt and a warning message in the settings window to ensure they understand that it requires tremendous amounts of free space. It will always use the AVI file format. Extra Notes: - When High/Indistinguishable quality is set, it will allow you to select the recording encoder. Currently, it just allows you to select x264 (at either veryfast or ultrafast). Later on, it'll be useful to be able to set up pre-configured presets for hardware encoders once more are implemented and tested. - I decided to allow the use of x264 at both veryfast or ultrafast presets. The reasoning is two-fold: 1.) ultrafast is perfectly viable even for near indistinguishable quality as long as it has the appropriate CRF value. It's nice if you want to record but would like to or need to reduce the impact of encoding on the CPU. It will automatically compensate for the preset at the cost of larger file size. 2.) It was suggested to just always use ultrafast, but ultrafast requires 2-4x as much disk space for the same CRF (most likely due to x264 compensating for the preset). Providing veryfast is important if you really want to reduce file size and/or reduce blocking at lower quality levels. - When a recording preset is used, a secondary audio encoder is also spawned at 192 bitrate to ensure high quality audio. I chose 192 because that's the limit of the media foundation aac encoder on windows, which I want to make sure is used if available due to its high performance. - The CRF calculation is based upon resolution, quality, and whether it's set to ultrafast. First, quality sets the base CRF, 23 for "good" quality, 16 for "very high" quality. If set to ultrafast, it'll subtract 2 points from the CRF value to help compensate. Lower resolutions will also lower the CRF value to help improve higher details with a smaller pixel ratio.
2015-09-18 22:29:36 -07:00
</item>
UI: Add support for QSV encoder to simple output
2016-04-18 00:56:51 -07:00
<item row="5" column="0">
UI: Add recording presets to simple output So certain high-profile individuals were complaining that it was difficult to configure recording settings for quality in OBS. So, I decided to add a very easy-to-use auto-configuration for high quality encoding -- including lossless encoding. This feature will automatically configure ideal recording settings based upon a specified quality level. Recording quality presets added to simple output: - Same as stream: Copies the encoded streaming data with no extra usage hit. - High quality: uses a higher CRF value (starting at 23) if using x264. - Indistinguishable quality: uses a low CRF value (starting at 16) if using x264. - Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a user tries to select lossless, they will be warned both via a dialog prompt and a warning message in the settings window to ensure they understand that it requires tremendous amounts of free space. It will always use the AVI file format. Extra Notes: - When High/Indistinguishable quality is set, it will allow you to select the recording encoder. Currently, it just allows you to select x264 (at either veryfast or ultrafast). Later on, it'll be useful to be able to set up pre-configured presets for hardware encoders once more are implemented and tested. - I decided to allow the use of x264 at both veryfast or ultrafast presets. The reasoning is two-fold: 1.) ultrafast is perfectly viable even for near indistinguishable quality as long as it has the appropriate CRF value. It's nice if you want to record but would like to or need to reduce the impact of encoding on the CPU. It will automatically compensate for the preset at the cost of larger file size. 2.) It was suggested to just always use ultrafast, but ultrafast requires 2-4x as much disk space for the same CRF (most likely due to x264 compensating for the preset). Providing veryfast is important if you really want to reduce file size and/or reduce blocking at lower quality levels. - When a recording preset is used, a secondary audio encoder is also spawned at 192 bitrate to ensure high quality audio. I chose 192 because that's the limit of the media foundation aac encoder on windows, which I want to make sure is used if available due to its high performance. - The CRF calculation is based upon resolution, quality, and whether it's set to ultrafast. First, quality sets the base CRF, 23 for "good" quality, 16 for "very high" quality. If set to ultrafast, it'll subtract 2 points from the CRF value to help compensate. Lower resolutions will also lower the CRF value to help improve higher details with a smaller pixel ratio.
2015-09-18 22:29:36 -07:00
<widget class="QLabel" name="label_24">
<property name="enabled">
<bool>true</bool>
</property>
<property name="text">
<string>Basic.Settings.Output.EncoderPreset</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>simpleOutPreset</cstring>
</property>
UI: Add recording presets to simple output So certain high-profile individuals were complaining that it was difficult to configure recording settings for quality in OBS. So, I decided to add a very easy-to-use auto-configuration for high quality encoding -- including lossless encoding. This feature will automatically configure ideal recording settings based upon a specified quality level. Recording quality presets added to simple output: - Same as stream: Copies the encoded streaming data with no extra usage hit. - High quality: uses a higher CRF value (starting at 23) if using x264. - Indistinguishable quality: uses a low CRF value (starting at 16) if using x264. - Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a user tries to select lossless, they will be warned both via a dialog prompt and a warning message in the settings window to ensure they understand that it requires tremendous amounts of free space. It will always use the AVI file format. Extra Notes: - When High/Indistinguishable quality is set, it will allow you to select the recording encoder. Currently, it just allows you to select x264 (at either veryfast or ultrafast). Later on, it'll be useful to be able to set up pre-configured presets for hardware encoders once more are implemented and tested. - I decided to allow the use of x264 at both veryfast or ultrafast presets. The reasoning is two-fold: 1.) ultrafast is perfectly viable even for near indistinguishable quality as long as it has the appropriate CRF value. It's nice if you want to record but would like to or need to reduce the impact of encoding on the CPU. It will automatically compensate for the preset at the cost of larger file size. 2.) It was suggested to just always use ultrafast, but ultrafast requires 2-4x as much disk space for the same CRF (most likely due to x264 compensating for the preset). Providing veryfast is important if you really want to reduce file size and/or reduce blocking at lower quality levels. - When a recording preset is used, a secondary audio encoder is also spawned at 192 bitrate to ensure high quality audio. I chose 192 because that's the limit of the media foundation aac encoder on windows, which I want to make sure is used if available due to its high performance. - The CRF calculation is based upon resolution, quality, and whether it's set to ultrafast. First, quality sets the base CRF, 23 for "good" quality, 16 for "very high" quality. If set to ultrafast, it'll subtract 2 points from the CRF value to help compensate. Lower resolutions will also lower the CRF value to help improve higher details with a smaller pixel ratio.
2015-09-18 22:29:36 -07:00
</widget>
</item>
UI: Add support for QSV encoder to simple output
2016-04-18 00:56:51 -07:00
<item row="6" column="0">
UI: Add recording presets to simple output So certain high-profile individuals were complaining that it was difficult to configure recording settings for quality in OBS. So, I decided to add a very easy-to-use auto-configuration for high quality encoding -- including lossless encoding. This feature will automatically configure ideal recording settings based upon a specified quality level. Recording quality presets added to simple output: - Same as stream: Copies the encoded streaming data with no extra usage hit. - High quality: uses a higher CRF value (starting at 23) if using x264. - Indistinguishable quality: uses a low CRF value (starting at 16) if using x264. - Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a user tries to select lossless, they will be warned both via a dialog prompt and a warning message in the settings window to ensure they understand that it requires tremendous amounts of free space. It will always use the AVI file format. Extra Notes: - When High/Indistinguishable quality is set, it will allow you to select the recording encoder. Currently, it just allows you to select x264 (at either veryfast or ultrafast). Later on, it'll be useful to be able to set up pre-configured presets for hardware encoders once more are implemented and tested. - I decided to allow the use of x264 at both veryfast or ultrafast presets. The reasoning is two-fold: 1.) ultrafast is perfectly viable even for near indistinguishable quality as long as it has the appropriate CRF value. It's nice if you want to record but would like to or need to reduce the impact of encoding on the CPU. It will automatically compensate for the preset at the cost of larger file size. 2.) It was suggested to just always use ultrafast, but ultrafast requires 2-4x as much disk space for the same CRF (most likely due to x264 compensating for the preset). Providing veryfast is important if you really want to reduce file size and/or reduce blocking at lower quality levels. - When a recording preset is used, a secondary audio encoder is also spawned at 192 bitrate to ensure high quality audio. I chose 192 because that's the limit of the media foundation aac encoder on windows, which I want to make sure is used if available due to its high performance. - The CRF calculation is based upon resolution, quality, and whether it's set to ultrafast. First, quality sets the base CRF, 23 for "good" quality, 16 for "very high" quality. If set to ultrafast, it'll subtract 2 points from the CRF value to help compensate. Lower resolutions will also lower the CRF value to help improve higher details with a smaller pixel ratio.
2015-09-18 22:29:36 -07:00
<widget class="QLabel" name="label_23">
<property name="text">
<string>Basic.Settings.Output.CustomEncoderSettings</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>simpleOutCustom</cstring>
</property>
UI: Add recording presets to simple output So certain high-profile individuals were complaining that it was difficult to configure recording settings for quality in OBS. So, I decided to add a very easy-to-use auto-configuration for high quality encoding -- including lossless encoding. This feature will automatically configure ideal recording settings based upon a specified quality level. Recording quality presets added to simple output: - Same as stream: Copies the encoded streaming data with no extra usage hit. - High quality: uses a higher CRF value (starting at 23) if using x264. - Indistinguishable quality: uses a low CRF value (starting at 16) if using x264. - Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a user tries to select lossless, they will be warned both via a dialog prompt and a warning message in the settings window to ensure they understand that it requires tremendous amounts of free space. It will always use the AVI file format. Extra Notes: - When High/Indistinguishable quality is set, it will allow you to select the recording encoder. Currently, it just allows you to select x264 (at either veryfast or ultrafast). Later on, it'll be useful to be able to set up pre-configured presets for hardware encoders once more are implemented and tested. - I decided to allow the use of x264 at both veryfast or ultrafast presets. The reasoning is two-fold: 1.) ultrafast is perfectly viable even for near indistinguishable quality as long as it has the appropriate CRF value. It's nice if you want to record but would like to or need to reduce the impact of encoding on the CPU. It will automatically compensate for the preset at the cost of larger file size. 2.) It was suggested to just always use ultrafast, but ultrafast requires 2-4x as much disk space for the same CRF (most likely due to x264 compensating for the preset). Providing veryfast is important if you really want to reduce file size and/or reduce blocking at lower quality levels. - When a recording preset is used, a secondary audio encoder is also spawned at 192 bitrate to ensure high quality audio. I chose 192 because that's the limit of the media foundation aac encoder on windows, which I want to make sure is used if available due to its high performance. - The CRF calculation is based upon resolution, quality, and whether it's set to ultrafast. First, quality sets the base CRF, 23 for "good" quality, 16 for "very high" quality. If set to ultrafast, it'll subtract 2 points from the CRF value to help compensate. Lower resolutions will also lower the CRF value to help improve higher details with a smaller pixel ratio.
2015-09-18 22:29:36 -07:00
</widget>
</item>
UI: Add support for QSV encoder to simple output
2016-04-18 00:56:51 -07:00
<item row="6" column="1">
UI: Add recording presets to simple output So certain high-profile individuals were complaining that it was difficult to configure recording settings for quality in OBS. So, I decided to add a very easy-to-use auto-configuration for high quality encoding -- including lossless encoding. This feature will automatically configure ideal recording settings based upon a specified quality level. Recording quality presets added to simple output: - Same as stream: Copies the encoded streaming data with no extra usage hit. - High quality: uses a higher CRF value (starting at 23) if using x264. - Indistinguishable quality: uses a low CRF value (starting at 16) if using x264. - Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a user tries to select lossless, they will be warned both via a dialog prompt and a warning message in the settings window to ensure they understand that it requires tremendous amounts of free space. It will always use the AVI file format. Extra Notes: - When High/Indistinguishable quality is set, it will allow you to select the recording encoder. Currently, it just allows you to select x264 (at either veryfast or ultrafast). Later on, it'll be useful to be able to set up pre-configured presets for hardware encoders once more are implemented and tested. - I decided to allow the use of x264 at both veryfast or ultrafast presets. The reasoning is two-fold: 1.) ultrafast is perfectly viable even for near indistinguishable quality as long as it has the appropriate CRF value. It's nice if you want to record but would like to or need to reduce the impact of encoding on the CPU. It will automatically compensate for the preset at the cost of larger file size. 2.) It was suggested to just always use ultrafast, but ultrafast requires 2-4x as much disk space for the same CRF (most likely due to x264 compensating for the preset). Providing veryfast is important if you really want to reduce file size and/or reduce blocking at lower quality levels. - When a recording preset is used, a secondary audio encoder is also spawned at 192 bitrate to ensure high quality audio. I chose 192 because that's the limit of the media foundation aac encoder on windows, which I want to make sure is used if available due to its high performance. - The CRF calculation is based upon resolution, quality, and whether it's set to ultrafast. First, quality sets the base CRF, 23 for "good" quality, 16 for "very high" quality. If set to ultrafast, it'll subtract 2 points from the CRF value to help compensate. Lower resolutions will also lower the CRF value to help improve higher details with a smaller pixel ratio.
2015-09-18 22:29:36 -07:00
<widget class="QLineEdit" name="simpleOutCustom"/>
</item>
UI: Add support for QSV encoder to simple output
2016-04-18 00:56:51 -07:00
<item row="4" column="1">
UI: Add "Enforce streaming bitrate limits" setting Allows the user to disable streaming bitrate limits in simple output mode if they so choose. This option is enabled by default.
2016-04-10 03:10:36 -07:00
<widget class="QCheckBox" name="simpleOutEnforce">
<property name="text">
<string>Basic.Settings.Output.EnforceBitrate</string>
</property>
</widget>
</item>
UI: Add support for QSV encoder to simple output
2016-04-18 00:56:51 -07:00
<item row="1" column="1">
<widget class="QComboBox" name="simpleOutStrEncoder"/>
</item>
<item row="1" column="0">
<widget class="QLabel" name="simpleOutRecEncoderLabel_2">
<property name="text">
<string>Basic.Settings.Output.Encoder</string>
</property>
<property name="buddy">
<cstring>simpleOutRecEncoder</cstring>
</property>
</widget>
</item>
UI: Add recording presets to simple output So certain high-profile individuals were complaining that it was difficult to configure recording settings for quality in OBS. So, I decided to add a very easy-to-use auto-configuration for high quality encoding -- including lossless encoding. This feature will automatically configure ideal recording settings based upon a specified quality level. Recording quality presets added to simple output: - Same as stream: Copies the encoded streaming data with no extra usage hit. - High quality: uses a higher CRF value (starting at 23) if using x264. - Indistinguishable quality: uses a low CRF value (starting at 16) if using x264. - Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a user tries to select lossless, they will be warned both via a dialog prompt and a warning message in the settings window to ensure they understand that it requires tremendous amounts of free space. It will always use the AVI file format. Extra Notes: - When High/Indistinguishable quality is set, it will allow you to select the recording encoder. Currently, it just allows you to select x264 (at either veryfast or ultrafast). Later on, it'll be useful to be able to set up pre-configured presets for hardware encoders once more are implemented and tested. - I decided to allow the use of x264 at both veryfast or ultrafast presets. The reasoning is two-fold: 1.) ultrafast is perfectly viable even for near indistinguishable quality as long as it has the appropriate CRF value. It's nice if you want to record but would like to or need to reduce the impact of encoding on the CPU. It will automatically compensate for the preset at the cost of larger file size. 2.) It was suggested to just always use ultrafast, but ultrafast requires 2-4x as much disk space for the same CRF (most likely due to x264 compensating for the preset). Providing veryfast is important if you really want to reduce file size and/or reduce blocking at lower quality levels. - When a recording preset is used, a secondary audio encoder is also spawned at 192 bitrate to ensure high quality audio. I chose 192 because that's the limit of the media foundation aac encoder on windows, which I want to make sure is used if available due to its high performance. - The CRF calculation is based upon resolution, quality, and whether it's set to ultrafast. First, quality sets the base CRF, 23 for "good" quality, 16 for "very high" quality. If set to ultrafast, it'll subtract 2 points from the CRF value to help compensate. Lower resolutions will also lower the CRF value to help improve higher details with a smaller pixel ratio.
2015-09-18 22:29:36 -07:00
</layout>
</widget>
</item>
<item>
<widget class="QGroupBox" name="groupBox_9">
<property name="sizePolicy">
<sizepolicy hsizetype="Preferred" vsizetype="Maximum">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="title">
<string>Basic.Settings.Output.Adv.Recording</string>
</property>
<layout class="QFormLayout" name="formLayout_6">
<property name="fieldGrowthPolicy">
<enum>QFormLayout::AllNonFixedFieldsGrow</enum>
</property>
<property name="labelAlignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="0" column="1">
UI: Add recording presets to simple output So certain high-profile individuals were complaining that it was difficult to configure recording settings for quality in OBS. So, I decided to add a very easy-to-use auto-configuration for high quality encoding -- including lossless encoding. This feature will automatically configure ideal recording settings based upon a specified quality level. Recording quality presets added to simple output: - Same as stream: Copies the encoded streaming data with no extra usage hit. - High quality: uses a higher CRF value (starting at 23) if using x264. - Indistinguishable quality: uses a low CRF value (starting at 16) if using x264. - Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a user tries to select lossless, they will be warned both via a dialog prompt and a warning message in the settings window to ensure they understand that it requires tremendous amounts of free space. It will always use the AVI file format. Extra Notes: - When High/Indistinguishable quality is set, it will allow you to select the recording encoder. Currently, it just allows you to select x264 (at either veryfast or ultrafast). Later on, it'll be useful to be able to set up pre-configured presets for hardware encoders once more are implemented and tested. - I decided to allow the use of x264 at both veryfast or ultrafast presets. The reasoning is two-fold: 1.) ultrafast is perfectly viable even for near indistinguishable quality as long as it has the appropriate CRF value. It's nice if you want to record but would like to or need to reduce the impact of encoding on the CPU. It will automatically compensate for the preset at the cost of larger file size. 2.) It was suggested to just always use ultrafast, but ultrafast requires 2-4x as much disk space for the same CRF (most likely due to x264 compensating for the preset). Providing veryfast is important if you really want to reduce file size and/or reduce blocking at lower quality levels. - When a recording preset is used, a secondary audio encoder is also spawned at 192 bitrate to ensure high quality audio. I chose 192 because that's the limit of the media foundation aac encoder on windows, which I want to make sure is used if available due to its high performance. - The CRF calculation is based upon resolution, quality, and whether it's set to ultrafast. First, quality sets the base CRF, 23 for "good" quality, 16 for "very high" quality. If set to ultrafast, it'll subtract 2 points from the CRF value to help compensate. Lower resolutions will also lower the CRF value to help improve higher details with a smaller pixel ratio.
2015-09-18 22:29:36 -07:00
<layout class="QHBoxLayout" name="horizontalLayout_5">
<item>
<widget class="QLineEdit" name="simpleOutputPath">
<property name="enabled">
<bool>true</bool>
</property>
</widget>
</item>
<item>
<widget class="QPushButton" name="simpleOutputBrowse">
<property name="enabled">
<bool>true</bool>
</property>
<property name="text">
<string>Browse</string>
</property>
</widget>
</item>
</layout>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="0" column="0">
UI: Add recording presets to simple output So certain high-profile individuals were complaining that it was difficult to configure recording settings for quality in OBS. So, I decided to add a very easy-to-use auto-configuration for high quality encoding -- including lossless encoding. This feature will automatically configure ideal recording settings based upon a specified quality level. Recording quality presets added to simple output: - Same as stream: Copies the encoded streaming data with no extra usage hit. - High quality: uses a higher CRF value (starting at 23) if using x264. - Indistinguishable quality: uses a low CRF value (starting at 16) if using x264. - Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a user tries to select lossless, they will be warned both via a dialog prompt and a warning message in the settings window to ensure they understand that it requires tremendous amounts of free space. It will always use the AVI file format. Extra Notes: - When High/Indistinguishable quality is set, it will allow you to select the recording encoder. Currently, it just allows you to select x264 (at either veryfast or ultrafast). Later on, it'll be useful to be able to set up pre-configured presets for hardware encoders once more are implemented and tested. - I decided to allow the use of x264 at both veryfast or ultrafast presets. The reasoning is two-fold: 1.) ultrafast is perfectly viable even for near indistinguishable quality as long as it has the appropriate CRF value. It's nice if you want to record but would like to or need to reduce the impact of encoding on the CPU. It will automatically compensate for the preset at the cost of larger file size. 2.) It was suggested to just always use ultrafast, but ultrafast requires 2-4x as much disk space for the same CRF (most likely due to x264 compensating for the preset). Providing veryfast is important if you really want to reduce file size and/or reduce blocking at lower quality levels. - When a recording preset is used, a secondary audio encoder is also spawned at 192 bitrate to ensure high quality audio. I chose 192 because that's the limit of the media foundation aac encoder on windows, which I want to make sure is used if available due to its high performance. - The CRF calculation is based upon resolution, quality, and whether it's set to ultrafast. First, quality sets the base CRF, 23 for "good" quality, 16 for "very high" quality. If set to ultrafast, it'll subtract 2 points from the CRF value to help compensate. Lower resolutions will also lower the CRF value to help improve higher details with a smaller pixel ratio.
2015-09-18 22:29:36 -07:00
<widget class="QLabel" name="label_18">
<property name="minimumSize">
<size>
<width>170</width>
<height>0</height>
</size>
</property>
<property name="text">
<string>Basic.Settings.Output.Simple.SavePath</string>
</property>
<property name="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>simpleOutputPath</cstring>
</property>
UI: Add recording presets to simple output So certain high-profile individuals were complaining that it was difficult to configure recording settings for quality in OBS. So, I decided to add a very easy-to-use auto-configuration for high quality encoding -- including lossless encoding. This feature will automatically configure ideal recording settings based upon a specified quality level. Recording quality presets added to simple output: - Same as stream: Copies the encoded streaming data with no extra usage hit. - High quality: uses a higher CRF value (starting at 23) if using x264. - Indistinguishable quality: uses a low CRF value (starting at 16) if using x264. - Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a user tries to select lossless, they will be warned both via a dialog prompt and a warning message in the settings window to ensure they understand that it requires tremendous amounts of free space. It will always use the AVI file format. Extra Notes: - When High/Indistinguishable quality is set, it will allow you to select the recording encoder. Currently, it just allows you to select x264 (at either veryfast or ultrafast). Later on, it'll be useful to be able to set up pre-configured presets for hardware encoders once more are implemented and tested. - I decided to allow the use of x264 at both veryfast or ultrafast presets. The reasoning is two-fold: 1.) ultrafast is perfectly viable even for near indistinguishable quality as long as it has the appropriate CRF value. It's nice if you want to record but would like to or need to reduce the impact of encoding on the CPU. It will automatically compensate for the preset at the cost of larger file size. 2.) It was suggested to just always use ultrafast, but ultrafast requires 2-4x as much disk space for the same CRF (most likely due to x264 compensating for the preset). Providing veryfast is important if you really want to reduce file size and/or reduce blocking at lower quality levels. - When a recording preset is used, a secondary audio encoder is also spawned at 192 bitrate to ensure high quality audio. I chose 192 because that's the limit of the media foundation aac encoder on windows, which I want to make sure is used if available due to its high performance. - The CRF calculation is based upon resolution, quality, and whether it's set to ultrafast. First, quality sets the base CRF, 23 for "good" quality, 16 for "very high" quality. If set to ultrafast, it'll subtract 2 points from the CRF value to help compensate. Lower resolutions will also lower the CRF value to help improve higher details with a smaller pixel ratio.
2015-09-18 22:29:36 -07:00
</widget>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="1" column="1">
<widget class="QCheckBox" name="simpleNoSpace">
<property name="text">
<string>Basic.Settings.Output.NoSpaceFileName</string>
</property>
<property name="checked">
<bool>true</bool>
</property>
</widget>
</item>
UI: Add recording presets to simple output So certain high-profile individuals were complaining that it was difficult to configure recording settings for quality in OBS. So, I decided to add a very easy-to-use auto-configuration for high quality encoding -- including lossless encoding. This feature will automatically configure ideal recording settings based upon a specified quality level. Recording quality presets added to simple output: - Same as stream: Copies the encoded streaming data with no extra usage hit. - High quality: uses a higher CRF value (starting at 23) if using x264. - Indistinguishable quality: uses a low CRF value (starting at 16) if using x264. - Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a user tries to select lossless, they will be warned both via a dialog prompt and a warning message in the settings window to ensure they understand that it requires tremendous amounts of free space. It will always use the AVI file format. Extra Notes: - When High/Indistinguishable quality is set, it will allow you to select the recording encoder. Currently, it just allows you to select x264 (at either veryfast or ultrafast). Later on, it'll be useful to be able to set up pre-configured presets for hardware encoders once more are implemented and tested. - I decided to allow the use of x264 at both veryfast or ultrafast presets. The reasoning is two-fold: 1.) ultrafast is perfectly viable even for near indistinguishable quality as long as it has the appropriate CRF value. It's nice if you want to record but would like to or need to reduce the impact of encoding on the CPU. It will automatically compensate for the preset at the cost of larger file size. 2.) It was suggested to just always use ultrafast, but ultrafast requires 2-4x as much disk space for the same CRF (most likely due to x264 compensating for the preset). Providing veryfast is important if you really want to reduce file size and/or reduce blocking at lower quality levels. - When a recording preset is used, a secondary audio encoder is also spawned at 192 bitrate to ensure high quality audio. I chose 192 because that's the limit of the media foundation aac encoder on windows, which I want to make sure is used if available due to its high performance. - The CRF calculation is based upon resolution, quality, and whether it's set to ultrafast. First, quality sets the base CRF, 23 for "good" quality, 16 for "very high" quality. If set to ultrafast, it'll subtract 2 points from the CRF value to help compensate. Lower resolutions will also lower the CRF value to help improve higher details with a smaller pixel ratio.
2015-09-18 22:29:36 -07:00
<item row="3" column="1">
<widget class="QComboBox" name="simpleOutRecFormat">
<item>
<property name="text">
<string notr="true">flv</string>
</property>
</item>
<item>
<property name="text">
<string notr="true">mp4</string>
</property>
</item>
<item>
<property name="text">
<string notr="true">mov</string>
</property>
</item>
<item>
<property name="text">
<string notr="true">mkv</string>
</property>
</item>
<item>
<property name="text">
<string notr="true">ts</string>
</property>
</item>
UI: Add HLS entries for ffmpeg-mux output
2015-11-23 06:36:24 -08:00
<item>
<property name="text">
<string notr="true">m3u8</string>
</property>
</item>
UI: Add recording presets to simple output So certain high-profile individuals were complaining that it was difficult to configure recording settings for quality in OBS. So, I decided to add a very easy-to-use auto-configuration for high quality encoding -- including lossless encoding. This feature will automatically configure ideal recording settings based upon a specified quality level. Recording quality presets added to simple output: - Same as stream: Copies the encoded streaming data with no extra usage hit. - High quality: uses a higher CRF value (starting at 23) if using x264. - Indistinguishable quality: uses a low CRF value (starting at 16) if using x264. - Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a user tries to select lossless, they will be warned both via a dialog prompt and a warning message in the settings window to ensure they understand that it requires tremendous amounts of free space. It will always use the AVI file format. Extra Notes: - When High/Indistinguishable quality is set, it will allow you to select the recording encoder. Currently, it just allows you to select x264 (at either veryfast or ultrafast). Later on, it'll be useful to be able to set up pre-configured presets for hardware encoders once more are implemented and tested. - I decided to allow the use of x264 at both veryfast or ultrafast presets. The reasoning is two-fold: 1.) ultrafast is perfectly viable even for near indistinguishable quality as long as it has the appropriate CRF value. It's nice if you want to record but would like to or need to reduce the impact of encoding on the CPU. It will automatically compensate for the preset at the cost of larger file size. 2.) It was suggested to just always use ultrafast, but ultrafast requires 2-4x as much disk space for the same CRF (most likely due to x264 compensating for the preset). Providing veryfast is important if you really want to reduce file size and/or reduce blocking at lower quality levels. - When a recording preset is used, a secondary audio encoder is also spawned at 192 bitrate to ensure high quality audio. I chose 192 because that's the limit of the media foundation aac encoder on windows, which I want to make sure is used if available due to its high performance. - The CRF calculation is based upon resolution, quality, and whether it's set to ultrafast. First, quality sets the base CRF, 23 for "good" quality, 16 for "very high" quality. If set to ultrafast, it'll subtract 2 points from the CRF value to help compensate. Lower resolutions will also lower the CRF value to help improve higher details with a smaller pixel ratio.
2015-09-18 22:29:36 -07:00
</widget>
</item>
<item row="3" column="0">
<widget class="QLabel" name="simpleOutRecFormatLabel">
<property name="text">
<string>Basic.Settings.Output.Format</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>simpleOutRecFormat</cstring>
</property>
UI: Add recording presets to simple output So certain high-profile individuals were complaining that it was difficult to configure recording settings for quality in OBS. So, I decided to add a very easy-to-use auto-configuration for high quality encoding -- including lossless encoding. This feature will automatically configure ideal recording settings based upon a specified quality level. Recording quality presets added to simple output: - Same as stream: Copies the encoded streaming data with no extra usage hit. - High quality: uses a higher CRF value (starting at 23) if using x264. - Indistinguishable quality: uses a low CRF value (starting at 16) if using x264. - Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a user tries to select lossless, they will be warned both via a dialog prompt and a warning message in the settings window to ensure they understand that it requires tremendous amounts of free space. It will always use the AVI file format. Extra Notes: - When High/Indistinguishable quality is set, it will allow you to select the recording encoder. Currently, it just allows you to select x264 (at either veryfast or ultrafast). Later on, it'll be useful to be able to set up pre-configured presets for hardware encoders once more are implemented and tested. - I decided to allow the use of x264 at both veryfast or ultrafast presets. The reasoning is two-fold: 1.) ultrafast is perfectly viable even for near indistinguishable quality as long as it has the appropriate CRF value. It's nice if you want to record but would like to or need to reduce the impact of encoding on the CPU. It will automatically compensate for the preset at the cost of larger file size. 2.) It was suggested to just always use ultrafast, but ultrafast requires 2-4x as much disk space for the same CRF (most likely due to x264 compensating for the preset). Providing veryfast is important if you really want to reduce file size and/or reduce blocking at lower quality levels. - When a recording preset is used, a secondary audio encoder is also spawned at 192 bitrate to ensure high quality audio. I chose 192 because that's the limit of the media foundation aac encoder on windows, which I want to make sure is used if available due to its high performance. - The CRF calculation is based upon resolution, quality, and whether it's set to ultrafast. First, quality sets the base CRF, 23 for "good" quality, 16 for "very high" quality. If set to ultrafast, it'll subtract 2 points from the CRF value to help compensate. Lower resolutions will also lower the CRF value to help improve higher details with a smaller pixel ratio.
2015-09-18 22:29:36 -07:00
</widget>
</item>
<item row="2" column="1">
<widget class="QComboBox" name="simpleOutRecQuality"/>
</item>
<item row="2" column="0">
<widget class="QLabel" name="label_26">
<property name="text">
<string>Basic.Settings.Output.Simple.RecordingQuality</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>simpleOutRecQuality</cstring>
</property>
UI: Add recording presets to simple output So certain high-profile individuals were complaining that it was difficult to configure recording settings for quality in OBS. So, I decided to add a very easy-to-use auto-configuration for high quality encoding -- including lossless encoding. This feature will automatically configure ideal recording settings based upon a specified quality level. Recording quality presets added to simple output: - Same as stream: Copies the encoded streaming data with no extra usage hit. - High quality: uses a higher CRF value (starting at 23) if using x264. - Indistinguishable quality: uses a low CRF value (starting at 16) if using x264. - Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a user tries to select lossless, they will be warned both via a dialog prompt and a warning message in the settings window to ensure they understand that it requires tremendous amounts of free space. It will always use the AVI file format. Extra Notes: - When High/Indistinguishable quality is set, it will allow you to select the recording encoder. Currently, it just allows you to select x264 (at either veryfast or ultrafast). Later on, it'll be useful to be able to set up pre-configured presets for hardware encoders once more are implemented and tested. - I decided to allow the use of x264 at both veryfast or ultrafast presets. The reasoning is two-fold: 1.) ultrafast is perfectly viable even for near indistinguishable quality as long as it has the appropriate CRF value. It's nice if you want to record but would like to or need to reduce the impact of encoding on the CPU. It will automatically compensate for the preset at the cost of larger file size. 2.) It was suggested to just always use ultrafast, but ultrafast requires 2-4x as much disk space for the same CRF (most likely due to x264 compensating for the preset). Providing veryfast is important if you really want to reduce file size and/or reduce blocking at lower quality levels. - When a recording preset is used, a secondary audio encoder is also spawned at 192 bitrate to ensure high quality audio. I chose 192 because that's the limit of the media foundation aac encoder on windows, which I want to make sure is used if available due to its high performance. - The CRF calculation is based upon resolution, quality, and whether it's set to ultrafast. First, quality sets the base CRF, 23 for "good" quality, 16 for "very high" quality. If set to ultrafast, it'll subtract 2 points from the CRF value to help compensate. Lower resolutions will also lower the CRF value to help improve higher details with a smaller pixel ratio.
2015-09-18 22:29:36 -07:00
</widget>
</item>
<item row="4" column="1">
<widget class="QComboBox" name="simpleOutRecEncoder"/>
</item>
<item row="4" column="0">
<widget class="QLabel" name="simpleOutRecEncoderLabel">
<property name="text">
<string>Basic.Settings.Output.Encoder</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>simpleOutRecEncoder</cstring>
</property>
UI: Add recording presets to simple output So certain high-profile individuals were complaining that it was difficult to configure recording settings for quality in OBS. So, I decided to add a very easy-to-use auto-configuration for high quality encoding -- including lossless encoding. This feature will automatically configure ideal recording settings based upon a specified quality level. Recording quality presets added to simple output: - Same as stream: Copies the encoded streaming data with no extra usage hit. - High quality: uses a higher CRF value (starting at 23) if using x264. - Indistinguishable quality: uses a low CRF value (starting at 16) if using x264. - Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a user tries to select lossless, they will be warned both via a dialog prompt and a warning message in the settings window to ensure they understand that it requires tremendous amounts of free space. It will always use the AVI file format. Extra Notes: - When High/Indistinguishable quality is set, it will allow you to select the recording encoder. Currently, it just allows you to select x264 (at either veryfast or ultrafast). Later on, it'll be useful to be able to set up pre-configured presets for hardware encoders once more are implemented and tested. - I decided to allow the use of x264 at both veryfast or ultrafast presets. The reasoning is two-fold: 1.) ultrafast is perfectly viable even for near indistinguishable quality as long as it has the appropriate CRF value. It's nice if you want to record but would like to or need to reduce the impact of encoding on the CPU. It will automatically compensate for the preset at the cost of larger file size. 2.) It was suggested to just always use ultrafast, but ultrafast requires 2-4x as much disk space for the same CRF (most likely due to x264 compensating for the preset). Providing veryfast is important if you really want to reduce file size and/or reduce blocking at lower quality levels. - When a recording preset is used, a secondary audio encoder is also spawned at 192 bitrate to ensure high quality audio. I chose 192 because that's the limit of the media foundation aac encoder on windows, which I want to make sure is used if available due to its high performance. - The CRF calculation is based upon resolution, quality, and whether it's set to ultrafast. First, quality sets the base CRF, 23 for "good" quality, 16 for "very high" quality. If set to ultrafast, it'll subtract 2 points from the CRF value to help compensate. Lower resolutions will also lower the CRF value to help improve higher details with a smaller pixel ratio.
2015-09-18 22:29:36 -07:00
</widget>
</item>
UI: Add custom muxer settings for ffmpeg-mux
2015-11-23 06:36:06 -08:00
<item row="5" column="0">
<widget class="QLabel" name="label_420">
<property name="text">
<string>Basic.Settings.Output.CustomMuxerSettings</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>simpleOutMuxCustom</cstring>
</property>
UI: Add custom muxer settings for ffmpeg-mux
2015-11-23 06:36:06 -08:00
</widget>
</item>
<item row="5" column="1">
<widget class="QLineEdit" name="simpleOutMuxCustom"/>
</item>
UI: Add recording presets to simple output So certain high-profile individuals were complaining that it was difficult to configure recording settings for quality in OBS. So, I decided to add a very easy-to-use auto-configuration for high quality encoding -- including lossless encoding. This feature will automatically configure ideal recording settings based upon a specified quality level. Recording quality presets added to simple output: - Same as stream: Copies the encoded streaming data with no extra usage hit. - High quality: uses a higher CRF value (starting at 23) if using x264. - Indistinguishable quality: uses a low CRF value (starting at 16) if using x264. - Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a user tries to select lossless, they will be warned both via a dialog prompt and a warning message in the settings window to ensure they understand that it requires tremendous amounts of free space. It will always use the AVI file format. Extra Notes: - When High/Indistinguishable quality is set, it will allow you to select the recording encoder. Currently, it just allows you to select x264 (at either veryfast or ultrafast). Later on, it'll be useful to be able to set up pre-configured presets for hardware encoders once more are implemented and tested. - I decided to allow the use of x264 at both veryfast or ultrafast presets. The reasoning is two-fold: 1.) ultrafast is perfectly viable even for near indistinguishable quality as long as it has the appropriate CRF value. It's nice if you want to record but would like to or need to reduce the impact of encoding on the CPU. It will automatically compensate for the preset at the cost of larger file size. 2.) It was suggested to just always use ultrafast, but ultrafast requires 2-4x as much disk space for the same CRF (most likely due to x264 compensating for the preset). Providing veryfast is important if you really want to reduce file size and/or reduce blocking at lower quality levels. - When a recording preset is used, a secondary audio encoder is also spawned at 192 bitrate to ensure high quality audio. I chose 192 because that's the limit of the media foundation aac encoder on windows, which I want to make sure is used if available due to its high performance. - The CRF calculation is based upon resolution, quality, and whether it's set to ultrafast. First, quality sets the base CRF, 23 for "good" quality, 16 for "very high" quality. If set to ultrafast, it'll subtract 2 points from the CRF value to help compensate. Lower resolutions will also lower the CRF value to help improve higher details with a smaller pixel ratio.
2015-09-18 22:29:36 -07:00
</layout>
</widget>
</item>
<item>
<layout class="QVBoxLayout" name="simpleOutInfoLayout">
<property name="leftMargin">
<number>10</number>
</property>
<property name="topMargin">
<number>10</number>
</property>
<property name="rightMargin">
<number>10</number>
</property>
<property name="bottomMargin">
<number>10</number>
</property>
</layout>
</item>
<item>
<spacer name="verticalSpacer_2">
<property name="orientation">
<enum>Qt::Vertical</enum>
</property>
<property name="sizeHint" stdset="0">
<size>
<width>20</width>
<height>40</height>
</size>
</property>
</spacer>
</item>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
<item alignment="Qt::AlignTop">
<widget class="QWidget" name="simpleOutputContainer" native="true">
<layout class="QVBoxLayout" name="verticalLayout_4">
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
</layout>
</widget>
</item>
</layout>
</widget>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<widget class="QWidget" name="advOutputsPage">
<layout class="QVBoxLayout" name="verticalLayout_8">
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item>
<widget class="QTabWidget" name="advOutTabs">
<property name="currentIndex">
<number>0</number>
</property>
<property name="usesScrollButtons">
<bool>true</bool>
</property>
<widget class="QWidget" name="advOutputStreamTab">
<attribute name="title">
<string>Basic.Settings.Output.Adv.Streaming</string>
</attribute>
<layout class="QVBoxLayout" name="verticalLayout_12">
<property name="leftMargin">
<number>9</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>9</number>
</property>
<property name="bottomMargin">
<number>9</number>
</property>
<item alignment="Qt::AlignTop">
<widget class="QWidget" name="widget_4" native="true">
<layout class="QVBoxLayout" name="verticalLayout_14">
<property name="spacing">
<number>0</number>
</property>
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item>
<widget class="QWidget" name="advOutTopContainer" native="true">
<property name="sizePolicy">
<sizepolicy hsizetype="Preferred" vsizetype="Maximum">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<layout class="QFormLayout" name="formLayout_7">
<property name="fieldGrowthPolicy">
<enum>QFormLayout::AllNonFixedFieldsGrow</enum>
</property>
<property name="labelAlignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
<item row="1" column="0">
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
<widget class="QLabel" name="label_28">
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<property name="minimumSize">
<size>
<width>170</width>
<height>0</height>
</size>
</property>
<property name="text">
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
<string>Basic.Settings.Output.Adv.AudioTrack</string>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</property>
<property name="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
</widget>
</item>
<item row="1" column="1">
<widget class="QWidget" name="widget_8" native="true">
<property name="sizePolicy">
<sizepolicy hsizetype="Maximum" vsizetype="Preferred">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<layout class="QHBoxLayout" name="horizontalLayout_7">
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item>
<widget class="QRadioButton" name="advOutTrack1">
<property name="text">
<string notr="true">1</string>
</property>
<property name="checked">
<bool>true</bool>
</property>
</widget>
</item>
<item>
<widget class="QRadioButton" name="advOutTrack2">
<property name="text">
<string notr="true">2</string>
</property>
</widget>
</item>
<item>
<widget class="QRadioButton" name="advOutTrack3">
<property name="text">
<string notr="true">3</string>
</property>
</widget>
</item>
<item>
<widget class="QRadioButton" name="advOutTrack4">
<property name="text">
<string notr="true">4</string>
</property>
</widget>
</item>
</layout>
</widget>
</item>
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
<item row="2" column="0">
<widget class="QLabel" name="advOutEncLabel">
<property name="text">
<string>Basic.Settings.Output.Encoder</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>advOutEncoder</cstring>
</property>
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
</widget>
</item>
<item row="2" column="1">
<widget class="QComboBox" name="advOutEncoder"/>
</item>
<item row="3" column="1">
UI: Add "enforce streaming service settings" Add a checkbox named "Enforce streaming service encoder settings" checkbox to advanced output. Disabling this checkbox allows the user to optionally disable the enforcement of streaming service encoder settings. I had a user complain that they didn't want to always have the service's preferred encoder settings forced on them.
2015-02-10 20:06:00 -08:00
<widget class="QCheckBox" name="advOutApplyService">
<property name="text">
<string>Basic.Settings.Output.Adv.ApplyServiceSettings</string>
</property>
<property name="checked">
<bool>true</bool>
</property>
</widget>
</item>
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
<item row="4" column="0">
<widget class="QCheckBox" name="advOutUseRescale">
<property name="sizePolicy">
<sizepolicy hsizetype="Minimum" vsizetype="Expanding">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="layoutDirection">
<enum>Qt::RightToLeft</enum>
</property>
<property name="text">
<string>Basic.Settings.Output.Adv.Rescale</string>
</property>
</widget>
</item>
<item row="4" column="1">
<widget class="QComboBox" name="advOutRescale">
<property name="enabled">
<bool>false</bool>
</property>
<property name="editable">
<bool>true</bool>
</property>
</widget>
</item>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</layout>
</widget>
</item>
</layout>
</widget>
</item>
</layout>
</widget>
<widget class="QWidget" name="advOutputRecordTab">
<attribute name="title">
<string>Basic.Settings.Output.Adv.Recording</string>
</attribute>
<layout class="QVBoxLayout" name="verticalLayout_11">
<property name="leftMargin">
<number>9</number>
</property>
<property name="topMargin">
<number>9</number>
</property>
<property name="rightMargin">
<number>9</number>
</property>
<property name="bottomMargin">
<number>9</number>
</property>
<item>
<widget class="QWidget" name="advOutRecTypeContainer" native="true">
<layout class="QFormLayout" name="formLayout_9">
<property name="fieldGrowthPolicy">
<enum>QFormLayout::AllNonFixedFieldsGrow</enum>
</property>
<property name="labelAlignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item row="0" column="0">
<widget class="QLabel" name="label_31">
<property name="minimumSize">
<size>
<width>170</width>
<height>0</height>
</size>
</property>
<property name="text">
<string>Basic.Settings.Output.Adv.Recording.Type</string>
</property>
<property name="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>advOutRecType</cstring>
</property>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</widget>
</item>
<item row="0" column="1">
<widget class="QComboBox" name="advOutRecType">
<item>
<property name="text">
<string>Basic.Settings.Output.Adv.Recording.Type.Standard</string>
</property>
</item>
<item>
<property name="text">
<string>Basic.Settings.Output.Adv.Recording.Type.FFmpegOutput</string>
</property>
</item>
</widget>
</item>
</layout>
</widget>
</item>
<item>
<widget class="Line" name="line_3">
<property name="orientation">
<enum>Qt::Horizontal</enum>
</property>
</widget>
</item>
<item>
<widget class="QStackedWidget" name="stackedWidget">
<property name="currentIndex">
<number>0</number>
</property>
<widget class="QWidget" name="advOutRecStandard">
<layout class="QVBoxLayout" name="verticalLayout_13">
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item alignment="Qt::AlignTop">
<widget class="QWidget" name="widget_7" native="true">
<layout class="QVBoxLayout" name="verticalLayout_15">
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item>
<widget class="QWidget" name="advOutRecTopContainer" native="true">
<property name="sizePolicy">
<sizepolicy hsizetype="Preferred" vsizetype="Maximum">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<layout class="QFormLayout" name="formLayout_16">
<property name="fieldGrowthPolicy">
<enum>QFormLayout::AllNonFixedFieldsGrow</enum>
</property>
<property name="labelAlignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
<property name="topMargin">
<number>0</number>
</property>
<item row="0" column="0">
<widget class="QLabel" name="label_32">
<property name="sizePolicy">
<sizepolicy hsizetype="Preferred" vsizetype="Expanding">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="minimumSize">
<size>
<width>170</width>
<height>0</height>
</size>
</property>
<property name="text">
<string>Basic.Settings.Output.Simple.SavePath</string>
</property>
<property name="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>advOutRecPath</cstring>
</property>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</widget>
</item>
<item row="0" column="1">
<layout class="QHBoxLayout" name="horizontalLayout_6">
<item>
<widget class="QLineEdit" name="advOutRecPath">
<property name="enabled">
<bool>true</bool>
</property>
</widget>
</item>
<item>
<widget class="QPushButton" name="advOutRecPathBrowse">
<property name="enabled">
<bool>true</bool>
</property>
<property name="text">
<string>Browse</string>
</property>
</widget>
</item>
</layout>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="1" column="1">
<widget class="QCheckBox" name="advOutNoSpace">
<property name="text">
<string>Basic.Settings.Output.NoSpaceFileName</string>
</property>
<property name="checked">
<bool>true</bool>
</property>
</widget>
</item>
<item row="2" column="0">
UI: Add option to select recording format Add a listboxes to recording to allow changing file formats (allows mp4, mov, mkv, ts, flv)
2015-05-29 09:45:54 -07:00
<widget class="QLabel" name="label_43">
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<property name="text">
UI: Add option to select recording format Add a listboxes to recording to allow changing file formats (allows mp4, mov, mkv, ts, flv)
2015-05-29 09:45:54 -07:00
<string>Basic.Settings.Output.Format</string>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>advOutRecFormat</cstring>
</property>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</widget>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="2" column="1">
UI: Add option to select recording format Add a listboxes to recording to allow changing file formats (allows mp4, mov, mkv, ts, flv)
2015-05-29 09:45:54 -07:00
<widget class="QComboBox" name="advOutRecFormat">
<item>
<property name="text">
<string notr="true">flv</string>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</property>
UI: Add option to select recording format Add a listboxes to recording to allow changing file formats (allows mp4, mov, mkv, ts, flv)
2015-05-29 09:45:54 -07:00
</item>
<item>
<property name="text">
<string notr="true">mp4</string>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</property>
UI: Add option to select recording format Add a listboxes to recording to allow changing file formats (allows mp4, mov, mkv, ts, flv)
2015-05-29 09:45:54 -07:00
</item>
<item>
<property name="text">
<string notr="true">mov</string>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</property>
UI: Add option to select recording format Add a listboxes to recording to allow changing file formats (allows mp4, mov, mkv, ts, flv)
2015-05-29 09:45:54 -07:00
</item>
<item>
<property name="text">
<string notr="true">mkv</string>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</property>
UI: Add option to select recording format Add a listboxes to recording to allow changing file formats (allows mp4, mov, mkv, ts, flv)
2015-05-29 09:45:54 -07:00
</item>
<item>
<property name="text">
<string notr="true">ts</string>
</property>
</item>
UI: Add HLS entries for ffmpeg-mux output
2015-11-23 06:36:24 -08:00
<item>
<property name="text">
<string notr="true">m3u8</string>
</property>
</item>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</widget>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="3" column="0">
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<widget class="QLabel" name="label_29">
<property name="text">
<string>Basic.Settings.Output.Adv.AudioTrack</string>
</property>
</widget>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="3" column="1">
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<widget class="QWidget" name="widget_9" native="true">
<property name="sizePolicy">
<sizepolicy hsizetype="Maximum" vsizetype="Preferred">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<layout class="QHBoxLayout" name="horizontalLayout_9">
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item>
UI: Allow multi-track recording in advanced output
2015-05-30 21:45:14 -07:00
<widget class="QCheckBox" name="advOutRecTrack1">
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<property name="text">
<string notr="true">1</string>
</property>
</widget>
</item>
<item>
UI: Allow multi-track recording in advanced output
2015-05-30 21:45:14 -07:00
<widget class="QCheckBox" name="advOutRecTrack2">
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<property name="text">
<string notr="true">2</string>
</property>
</widget>
</item>
<item>
UI: Allow multi-track recording in advanced output
2015-05-30 21:45:14 -07:00
<widget class="QCheckBox" name="advOutRecTrack3">
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<property name="text">
<string notr="true">3</string>
</property>
</widget>
</item>
<item>
UI: Allow multi-track recording in advanced output
2015-05-30 21:45:14 -07:00
<widget class="QCheckBox" name="advOutRecTrack4">
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<property name="text">
<string notr="true">4</string>
</property>
</widget>
</item>
</layout>
</widget>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="4" column="0">
UI: Add option to select recording format Add a listboxes to recording to allow changing file formats (allows mp4, mov, mkv, ts, flv)
2015-05-29 09:45:54 -07:00
<widget class="QLabel" name="advOutRecEncLabel">
<property name="text">
<string>Basic.Settings.Output.Encoder</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>advOutRecEncoder</cstring>
</property>
UI: Add option to select recording format Add a listboxes to recording to allow changing file formats (allows mp4, mov, mkv, ts, flv)
2015-05-29 09:45:54 -07:00
</widget>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="4" column="1">
UI: Add option to select recording format Add a listboxes to recording to allow changing file formats (allows mp4, mov, mkv, ts, flv)
2015-05-29 09:45:54 -07:00
<widget class="QComboBox" name="advOutRecEncoder"/>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="5" column="0">
UI: Add option to select recording format Add a listboxes to recording to allow changing file formats (allows mp4, mov, mkv, ts, flv)
2015-05-29 09:45:54 -07:00
<widget class="QCheckBox" name="advOutRecUseRescale">
<property name="sizePolicy">
<sizepolicy hsizetype="Minimum" vsizetype="Expanding">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="layoutDirection">
<enum>Qt::RightToLeft</enum>
</property>
<property name="text">
<string>Basic.Settings.Output.Adv.Rescale</string>
</property>
</widget>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="5" column="1">
UI: Add option to select recording format Add a listboxes to recording to allow changing file formats (allows mp4, mov, mkv, ts, flv)
2015-05-29 09:45:54 -07:00
<widget class="QWidget" name="advOutRecRescaleContainer" native="true">
<layout class="QHBoxLayout" name="horizontalLayout_4">
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item>
<widget class="QComboBox" name="advOutRecRescale">
<property name="enabled">
<bool>false</bool>
</property>
<property name="editable">
<bool>true</bool>
</property>
</widget>
</item>
</layout>
</widget>
</item>
UI: Add custom muxer settings for ffmpeg-mux
2015-11-23 06:36:06 -08:00
<item row="6" column="0">
<widget class="QLabel" name="label_9001">
<property name="text">
<string>Basic.Settings.Output.CustomMuxerSettings</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>advOutMuxCustom</cstring>
</property>
UI: Add custom muxer settings for ffmpeg-mux
2015-11-23 06:36:06 -08:00
</widget>
</item>
<item row="6" column="1">
<widget class="QLineEdit" name="advOutMuxCustom"/>
</item>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</layout>
</widget>
</item>
</layout>
</widget>
</item>
</layout>
</widget>
<widget class="QWidget" name="advOutRecFFmpeg">
<layout class="QFormLayout" name="formLayout_15">
<property name="fieldGrowthPolicy">
<enum>QFormLayout::AllNonFixedFieldsGrow</enum>
</property>
<property name="labelAlignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
<property name="topMargin">
<number>0</number>
</property>
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<item row="1" column="0">
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<widget class="QLabel" name="label_36">
<property name="sizePolicy">
<sizepolicy hsizetype="Preferred" vsizetype="Expanding">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="minimumSize">
<size>
<width>170</width>
<height>0</height>
</size>
</property>
<property name="text">
<string>Basic.Settings.Output.Adv.FFmpeg.SavePathURL</string>
</property>
<property name="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
</widget>
</item>
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<item row="1" column="1">
<widget class="QStackedWidget" name="stackedWidget_2">
<property name="currentIndex">
<number>0</number>
</property>
<widget class="QWidget" name="page_5">
<layout class="QHBoxLayout" name="horizontalLayout_12">
<property name="spacing">
<number>3</number>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</property>
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<property name="leftMargin">
<number>0</number>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</property>
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<property name="topMargin">
<number>0</number>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</property>
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item>
<widget class="QLineEdit" name="advOutFFRecPath">
<property name="readOnly">
<bool>true</bool>
</property>
</widget>
</item>
<item>
<widget class="QPushButton" name="advOutFFPathBrowse">
<property name="text">
<string>Browse</string>
</property>
</widget>
</item>
</layout>
</widget>
<widget class="QWidget" name="page_4">
<layout class="QHBoxLayout" name="horizontalLayout_8">
<property name="spacing">
<number>0</number>
</property>
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item>
<widget class="QLineEdit" name="advOutFFURL">
<property name="enabled">
<bool>true</bool>
</property>
</widget>
</item>
</layout>
</widget>
</widget>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="3" column="0">
UI: Add Format, Audio and Video ComboBoxes Adds ComboBoxes for selecting format and audio/video codecs. The ComboBoxes also show only valid codec combinations for a particular container format.
2015-03-28 00:21:16 -07:00
<widget class="QLabel" name="label_16">
<property name="text">
<string>Basic.Settings.Output.Adv.FFmpeg.Format</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>advOutFFFormat</cstring>
</property>
UI: Add Format, Audio and Video ComboBoxes Adds ComboBoxes for selecting format and audio/video codecs. The ComboBoxes also show only valid codec combinations for a particular container format.
2015-03-28 00:21:16 -07:00
</widget>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="3" column="1">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<widget class="QComboBox" name="advOutFFFormat"/>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="4" column="0">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<widget class="QLabel" name="label_44">
<property name="text">
<string>Basic.Settings.Output.Adv.FFmpeg.FormatDesc</string>
</property>
</widget>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="4" column="1">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<widget class="QLabel" name="advOutFFFormatDesc">
<property name="text">
<string/>
</property>
</widget>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="6" column="0">
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<widget class="QLabel" name="label_40">
<property name="text">
<string>Basic.Settings.Output.VideoBitrate</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>advOutFFVBitrate</cstring>
</property>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</widget>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="6" column="1">
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<widget class="QSpinBox" name="advOutFFVBitrate">
<property name="minimum">
<number>0</number>
</property>
<property name="maximum">
<number>1000000000</number>
</property>
<property name="value">
<number>2500</number>
</property>
</widget>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="7" column="0">
UI: Add Format, Audio and Video ComboBoxes Adds ComboBoxes for selecting format and audio/video codecs. The ComboBoxes also show only valid codec combinations for a particular container format.
2015-03-28 00:21:16 -07:00
<widget class="QCheckBox" name="advOutFFUseRescale">
<property name="sizePolicy">
<sizepolicy hsizetype="Minimum" vsizetype="Expanding">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="layoutDirection">
<enum>Qt::RightToLeft</enum>
</property>
<property name="text">
<string>Basic.Settings.Output.Adv.Rescale</string>
</property>
</widget>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="7" column="1">
UI: Add Format, Audio and Video ComboBoxes Adds ComboBoxes for selecting format and audio/video codecs. The ComboBoxes also show only valid codec combinations for a particular container format.
2015-03-28 00:21:16 -07:00
<widget class="QComboBox" name="advOutFFRescale">
<property name="enabled">
<bool>false</bool>
</property>
<property name="editable">
<bool>true</bool>
</property>
</widget>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="8" column="0">
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<widget class="QLabel" name="label_37">
<property name="text">
<string>Basic.Settings.Output.Adv.FFmpeg.VEncoder</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>advOutFFVEncoder</cstring>
</property>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</widget>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="8" column="1">
UI: Add Format, Audio and Video ComboBoxes Adds ComboBoxes for selecting format and audio/video codecs. The ComboBoxes also show only valid codec combinations for a particular container format.
2015-03-28 00:21:16 -07:00
<widget class="QComboBox" name="advOutFFVEncoder"/>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="10" column="0">
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<widget class="QLabel" name="label_38">
<property name="text">
<string>Basic.Settings.Output.Adv.FFmpeg.VEncoderSettings</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>advOutFFVCfg</cstring>
</property>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</widget>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="10" column="1">
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<widget class="QLineEdit" name="advOutFFVCfg"/>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="11" column="0">
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<widget class="QLabel" name="label_41">
<property name="text">
<string>Basic.Settings.Output.AudioBitrate</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>advOutFFABitrate</cstring>
</property>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</widget>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="11" column="1">
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<widget class="QSpinBox" name="advOutFFABitrate">
<property name="minimum">
<number>32</number>
</property>
<property name="maximum">
<number>4096</number>
</property>
<property name="singleStep">
<number>16</number>
</property>
<property name="value">
<number>128</number>
</property>
</widget>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="12" column="0">
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<widget class="QLabel" name="label_47">
<property name="text">
<string>Basic.Settings.Output.Adv.AudioTrack</string>
</property>
</widget>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="12" column="1">
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<widget class="QWidget" name="widget_10" native="true">
<property name="sizePolicy">
<sizepolicy hsizetype="Maximum" vsizetype="Preferred">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<layout class="QHBoxLayout" name="horizontalLayout_10">
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item>
<widget class="QRadioButton" name="advOutFFTrack1">
<property name="text">
<string notr="true">1</string>
</property>
<property name="checked">
<bool>true</bool>
</property>
</widget>
</item>
<item>
<widget class="QRadioButton" name="advOutFFTrack2">
<property name="text">
<string notr="true">2</string>
</property>
</widget>
</item>
<item>
<widget class="QRadioButton" name="advOutFFTrack3">
<property name="text">
<string notr="true">3</string>
</property>
</widget>
</item>
<item>
<widget class="QRadioButton" name="advOutFFTrack4">
<property name="text">
<string notr="true">4</string>
</property>
</widget>
</item>
</layout>
</widget>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="13" column="0">
UI: Add Format, Audio and Video ComboBoxes Adds ComboBoxes for selecting format and audio/video codecs. The ComboBoxes also show only valid codec combinations for a particular container format.
2015-03-28 00:21:16 -07:00
<widget class="QLabel" name="label_39">
<property name="text">
<string>Basic.Settings.Output.Adv.FFmpeg.AEncoder</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>advOutFFAEncoder</cstring>
</property>
UI: Add Format, Audio and Video ComboBoxes Adds ComboBoxes for selecting format and audio/video codecs. The ComboBoxes also show only valid codec combinations for a particular container format.
2015-03-28 00:21:16 -07:00
</widget>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="13" column="1">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<widget class="QComboBox" name="advOutFFAEncoder"/>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="14" column="0">
UI: Add Format, Audio and Video ComboBoxes Adds ComboBoxes for selecting format and audio/video codecs. The ComboBoxes also show only valid codec combinations for a particular container format.
2015-03-28 00:21:16 -07:00
<widget class="QLabel" name="label_46">
<property name="text">
<string>Basic.Settings.Output.Adv.FFmpeg.AEncoderSettings</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>advOutFFACfg</cstring>
</property>
UI: Add Format, Audio and Video ComboBoxes Adds ComboBoxes for selecting format and audio/video codecs. The ComboBoxes also show only valid codec combinations for a particular container format.
2015-03-28 00:21:16 -07:00
</widget>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="14" column="1">
UI: Add Format, Audio and Video ComboBoxes Adds ComboBoxes for selecting format and audio/video codecs. The ComboBoxes also show only valid codec combinations for a particular container format.
2015-03-28 00:21:16 -07:00
<widget class="QLineEdit" name="advOutFFACfg"/>
</item>
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<item row="0" column="0">
<widget class="QLabel" name="label_48">
<property name="sizePolicy">
<sizepolicy hsizetype="Preferred" vsizetype="Expanding">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="minimumSize">
<size>
<width>170</width>
<height>0</height>
</size>
UI: Add Format, Audio and Video ComboBoxes Adds ComboBoxes for selecting format and audio/video codecs. The ComboBoxes also show only valid codec combinations for a particular container format.
2015-03-28 00:21:16 -07:00
</property>
<property name="text">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<string>Basic.Settings.Output.Adv.FFmpeg.Type</string>
</property>
<property name="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
UI: Add Format, Audio and Video ComboBoxes Adds ComboBoxes for selecting format and audio/video codecs. The ComboBoxes also show only valid codec combinations for a particular container format.
2015-03-28 00:21:16 -07:00
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>advOutFFType</cstring>
</property>
UI: Add Format, Audio and Video ComboBoxes Adds ComboBoxes for selecting format and audio/video codecs. The ComboBoxes also show only valid codec combinations for a particular container format.
2015-03-28 00:21:16 -07:00
</widget>
</item>
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<item row="0" column="1">
<widget class="QComboBox" name="advOutFFType">
<item>
<property name="text">
<string>Basic.Settings.Output.Adv.FFmpeg.Type.RecordToFile</string>
</property>
</item>
<item>
<property name="text">
<string>Basic.Settings.Output.Adv.FFmpeg.Type.URL</string>
</property>
</item>
</widget>
UI: Add Format, Audio and Video ComboBoxes Adds ComboBoxes for selecting format and audio/video codecs. The ComboBoxes also show only valid codec combinations for a particular container format.
2015-03-28 00:21:16 -07:00
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="5" column="0">
UI: Add custom muxer settings to advanced FFmpeg output
2015-09-16 01:26:48 -07:00
<widget class="QLabel" name="label_1337">
<property name="text">
<string>Basic.Settings.Output.Adv.FFmpeg.MuxerSettings</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>advOutFFMCfg</cstring>
</property>
UI: Add custom muxer settings to advanced FFmpeg output
2015-09-16 01:26:48 -07:00
</widget>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="5" column="1">
UI: Add custom muxer settings to advanced FFmpeg output
2015-09-16 01:26:48 -07:00
<widget class="QLineEdit" name="advOutFFMCfg"/>
</item>
UI: Allow file name generation without spaces This will probably go away once proper file name formatting is implemented (https://obsproject.com/mantis/view.php?id=361)
2015-11-27 03:14:18 -08:00
<item row="2" column="1">
<widget class="QCheckBox" name="advOutFFNoSpace">
<property name="text">
<string>Basic.Settings.Output.NoSpaceFileName</string>
</property>
<property name="checked">
<bool>true</bool>
</property>
</widget>
</item>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</layout>
</widget>
</widget>
</item>
</layout>
</widget>
<widget class="QWidget" name="advOutputAudioTracksTab">
<attribute name="title">
<string>Basic.Settings.Audio</string>
</attribute>
<layout class="QVBoxLayout" name="verticalLayout_9">
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item alignment="Qt::AlignTop">
<widget class="QWidget" name="widget_3" native="true">
<property name="sizePolicy">
<sizepolicy hsizetype="Preferred" vsizetype="Preferred">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<layout class="QVBoxLayout" name="verticalLayout_10">
<item>
<widget class="QGroupBox" name="groupBox">
<property name="sizePolicy">
<sizepolicy hsizetype="Preferred" vsizetype="Maximum">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="title">
<string>Basic.Settings.Output.Adv.Audio.Track1</string>
</property>
<layout class="QFormLayout" name="formLayout_10">
<property name="fieldGrowthPolicy">
<enum>QFormLayout::AllNonFixedFieldsGrow</enum>
</property>
<property name="labelAlignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
<item row="0" column="1">
<widget class="QComboBox" name="advOutTrack1Bitrate">
<property name="currentIndex">
UI: Add Audio bitrate CoreAudio AAC encoder is now available for both AAC-LC and HE-AAC. Added some Audio bitrate settings for lower bitrate region.
2015-07-01 04:00:19 -07:00
<number>8</number>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</property>
<item>
<property name="text">
<string>32</string>
</property>
</item>
UI: Add Audio bitrate CoreAudio AAC encoder is now available for both AAC-LC and HE-AAC. Added some Audio bitrate settings for lower bitrate region.
2015-07-01 04:00:19 -07:00
<item>
<property name="text">
<string>48</string>
</property>
</item>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<item>
<property name="text">
<string>64</string>
</property>
</item>
UI: Add Audio bitrate CoreAudio AAC encoder is now available for both AAC-LC and HE-AAC. Added some Audio bitrate settings for lower bitrate region.
2015-07-01 04:00:19 -07:00
<item>
<property name="text">
<string>80</string>
</property>
</item>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<item>
<property name="text">
<string>96</string>
</property>
</item>
UI: Add Audio bitrate CoreAudio AAC encoder is now available for both AAC-LC and HE-AAC. Added some Audio bitrate settings for lower bitrate region.
2015-07-01 04:00:19 -07:00
<item>
<property name="text">
<string>112</string>
</property>
</item>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<item>
<property name="text">
<string>128</string>
</property>
</item>
<item>
<property name="text">
<string>160</string>
</property>
</item>
<item>
<property name="text">
<string>192</string>
</property>
</item>
<item>
<property name="text">
<string>256</string>
</property>
</item>
<item>
<property name="text">
<string>320</string>
</property>
</item>
</widget>
</item>
<item row="0" column="0">
<widget class="QLabel" name="label_25">
<property name="minimumSize">
<size>
<width>170</width>
<height>0</height>
</size>
</property>
<property name="text">
<string>Basic.Settings.Output.AudioBitrate</string>
</property>
<property name="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>advOutTrack1Bitrate</cstring>
</property>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</widget>
</item>
<item row="1" column="0">
<widget class="QLabel" name="label_55">
<property name="text">
<string>Name</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>advOutTrack1Name</cstring>
</property>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</widget>
</item>
<item row="1" column="1">
<widget class="QLineEdit" name="advOutTrack1Name"/>
</item>
</layout>
</widget>
</item>
<item>
<widget class="QGroupBox" name="groupBox_2">
<property name="sizePolicy">
<sizepolicy hsizetype="Preferred" vsizetype="Maximum">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="title">
<string>Basic.Settings.Output.Adv.Audio.Track2</string>
</property>
<layout class="QFormLayout" name="formLayout_11">
<property name="fieldGrowthPolicy">
<enum>QFormLayout::AllNonFixedFieldsGrow</enum>
</property>
<property name="labelAlignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
<item row="0" column="0">
<widget class="QLabel" name="label_49">
<property name="minimumSize">
<size>
<width>170</width>
<height>0</height>
</size>
</property>
<property name="text">
<string>Basic.Settings.Output.AudioBitrate</string>
</property>
<property name="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>advOutTrack2Bitrate</cstring>
</property>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</widget>
</item>
<item row="0" column="1">
<widget class="QComboBox" name="advOutTrack2Bitrate">
<property name="currentIndex">
UI: Add Audio bitrate CoreAudio AAC encoder is now available for both AAC-LC and HE-AAC. Added some Audio bitrate settings for lower bitrate region.
2015-07-01 04:00:19 -07:00
<number>8</number>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</property>
<item>
<property name="text">
<string>32</string>
</property>
</item>
UI: Add Audio bitrate CoreAudio AAC encoder is now available for both AAC-LC and HE-AAC. Added some Audio bitrate settings for lower bitrate region.
2015-07-01 04:00:19 -07:00
<item>
<property name="text">
<string>48</string>
</property>
</item>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<item>
<property name="text">
<string>64</string>
</property>
</item>
UI: Add Audio bitrate CoreAudio AAC encoder is now available for both AAC-LC and HE-AAC. Added some Audio bitrate settings for lower bitrate region.
2015-07-01 04:00:19 -07:00
<item>
<property name="text">
<string>80</string>
</property>
</item>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<item>
<property name="text">
<string>96</string>
</property>
</item>
UI: Add Audio bitrate CoreAudio AAC encoder is now available for both AAC-LC and HE-AAC. Added some Audio bitrate settings for lower bitrate region.
2015-07-01 04:00:19 -07:00
<item>
<property name="text">
<string>112</string>
</property>
</item>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<item>
<property name="text">
<string>128</string>
</property>
</item>
<item>
<property name="text">
<string>160</string>
</property>
</item>
<item>
<property name="text">
<string>192</string>
</property>
</item>
<item>
<property name="text">
<string>256</string>
</property>
</item>
<item>
<property name="text">
<string>320</string>
</property>
</item>
</widget>
</item>
<item row="1" column="0">
<widget class="QLabel" name="label_50">
<property name="text">
<string>Name</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>advOutTrack2Name</cstring>
</property>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</widget>
</item>
<item row="1" column="1">
<widget class="QLineEdit" name="advOutTrack2Name"/>
</item>
</layout>
</widget>
</item>
<item>
<widget class="QGroupBox" name="groupBox_3">
<property name="sizePolicy">
<sizepolicy hsizetype="Preferred" vsizetype="Maximum">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="title">
<string>Basic.Settings.Output.Adv.Audio.Track3</string>
</property>
<layout class="QFormLayout" name="formLayout_12">
<property name="fieldGrowthPolicy">
<enum>QFormLayout::AllNonFixedFieldsGrow</enum>
</property>
<property name="labelAlignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
<item row="0" column="0">
<widget class="QLabel" name="label_51">
<property name="minimumSize">
<size>
<width>170</width>
<height>0</height>
</size>
</property>
<property name="text">
<string>Basic.Settings.Output.AudioBitrate</string>
</property>
<property name="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>advOutTrack3Bitrate</cstring>
</property>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</widget>
</item>
<item row="0" column="1">
<widget class="QComboBox" name="advOutTrack3Bitrate">
<property name="currentIndex">
UI: Add Audio bitrate CoreAudio AAC encoder is now available for both AAC-LC and HE-AAC. Added some Audio bitrate settings for lower bitrate region.
2015-07-01 04:00:19 -07:00
<number>8</number>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</property>
<item>
<property name="text">
<string>32</string>
</property>
</item>
UI: Add Audio bitrate CoreAudio AAC encoder is now available for both AAC-LC and HE-AAC. Added some Audio bitrate settings for lower bitrate region.
2015-07-01 04:00:19 -07:00
<item>
<property name="text">
<string>48</string>
</property>
</item>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<item>
<property name="text">
<string>64</string>
</property>
</item>
UI: Add Audio bitrate CoreAudio AAC encoder is now available for both AAC-LC and HE-AAC. Added some Audio bitrate settings for lower bitrate region.
2015-07-01 04:00:19 -07:00
<item>
<property name="text">
<string>80</string>
</property>
</item>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<item>
<property name="text">
<string>96</string>
</property>
</item>
UI: Add Audio bitrate CoreAudio AAC encoder is now available for both AAC-LC and HE-AAC. Added some Audio bitrate settings for lower bitrate region.
2015-07-01 04:00:19 -07:00
<item>
<property name="text">
<string>112</string>
</property>
</item>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<item>
<property name="text">
<string>128</string>
</property>
</item>
<item>
<property name="text">
<string>160</string>
</property>
</item>
<item>
<property name="text">
<string>192</string>
</property>
</item>
<item>
<property name="text">
<string>256</string>
</property>
</item>
<item>
<property name="text">
<string>320</string>
</property>
</item>
</widget>
</item>
<item row="1" column="0">
<widget class="QLabel" name="label_52">
<property name="text">
<string>Name</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>advOutTrack3Name</cstring>
</property>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</widget>
</item>
<item row="1" column="1">
<widget class="QLineEdit" name="advOutTrack3Name"/>
</item>
</layout>
</widget>
</item>
<item>
<widget class="QGroupBox" name="groupBox_4">
<property name="sizePolicy">
<sizepolicy hsizetype="Preferred" vsizetype="Maximum">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="title">
<string>Basic.Settings.Output.Adv.Audio.Track4</string>
</property>
<layout class="QFormLayout" name="formLayout_13">
<property name="fieldGrowthPolicy">
<enum>QFormLayout::AllNonFixedFieldsGrow</enum>
</property>
<property name="labelAlignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
<item row="0" column="0">
<widget class="QLabel" name="label_53">
<property name="minimumSize">
<size>
<width>170</width>
<height>0</height>
</size>
</property>
<property name="text">
<string>Basic.Settings.Output.AudioBitrate</string>
</property>
<property name="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>advOutTrack4Bitrate</cstring>
</property>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</widget>
</item>
<item row="0" column="1">
<widget class="QComboBox" name="advOutTrack4Bitrate">
<property name="currentIndex">
UI: Add Audio bitrate CoreAudio AAC encoder is now available for both AAC-LC and HE-AAC. Added some Audio bitrate settings for lower bitrate region.
2015-07-01 04:00:19 -07:00
<number>8</number>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</property>
<item>
<property name="text">
<string>32</string>
</property>
</item>
UI: Add Audio bitrate CoreAudio AAC encoder is now available for both AAC-LC and HE-AAC. Added some Audio bitrate settings for lower bitrate region.
2015-07-01 04:00:19 -07:00
<item>
<property name="text">
<string>48</string>
</property>
</item>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<item>
<property name="text">
<string>64</string>
</property>
</item>
UI: Add Audio bitrate CoreAudio AAC encoder is now available for both AAC-LC and HE-AAC. Added some Audio bitrate settings for lower bitrate region.
2015-07-01 04:00:19 -07:00
<item>
<property name="text">
<string>80</string>
</property>
</item>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<item>
<property name="text">
<string>96</string>
</property>
</item>
UI: Add Audio bitrate CoreAudio AAC encoder is now available for both AAC-LC and HE-AAC. Added some Audio bitrate settings for lower bitrate region.
2015-07-01 04:00:19 -07:00
<item>
<property name="text">
<string>112</string>
</property>
</item>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<item>
<property name="text">
<string>128</string>
</property>
</item>
<item>
<property name="text">
<string>160</string>
</property>
</item>
<item>
<property name="text">
<string>192</string>
</property>
</item>
<item>
<property name="text">
<string>256</string>
</property>
</item>
<item>
<property name="text">
<string>320</string>
</property>
</item>
</widget>
</item>
<item row="1" column="0">
<widget class="QLabel" name="label_54">
<property name="text">
<string>Name</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>advOutTrack4Name</cstring>
</property>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</widget>
</item>
<item row="1" column="1">
<widget class="QLineEdit" name="advOutTrack4Name"/>
</item>
</layout>
</widget>
</item>
</layout>
</widget>
</item>
</layout>
</widget>
</widget>
</item>
</layout>
</widget>
Add preliminary streaming code for testing - Add some temporary streaming code using FFmpeg. FFmpeg itself is not very ideal for streaming; lack of direct control of the sockets and no framedrop handling means that FFmpeg is definitely not something you want to use without wrapper code. I'd prefer writing my own network framework in this particular case just because you give away so much control of the network interface. Wasted an entire day trying to go through FFmpeg issues. There's just no way FFmpeg should be used for real streaming (at least without being patched or submitting some sort of patch, but I'm sort of feeling "meh" on that idea) I had to end up writing multiple threads just to handle both connecting and writing, because av_interleaved_write_frame blocks every call, stalling the main encoder thread, and thus also stalling draw signals. - Add some temporary user interface for streaming settings. This is just temporary for the time being. It's in the outputs section of the basic-mode settings - Make it so that dynamic arrays do not free all their data when the size just happens to be reduced to 0. This prevents constant reallocation when an array keeps going from 1 item to 0 items. Also, it was bad to become dependent upon that functionality. You must now always explicitly call "free" on it to ensure the data is free, and that's how it should be. Implicit functionality can lead to confusion and maintainability issues.
2014-03-10 13:10:35 -07:00
</widget>
</item>
</layout>
</widget>
<widget class="QWidget" name="audioPage">
<layout class="QFormLayout" name="formLayout">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<property name="fieldGrowthPolicy">
<enum>QFormLayout::AllNonFixedFieldsGrow</enum>
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<property name="labelAlignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
<item row="0" column="0">
<widget class="QLabel" name="label_14">
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Settings.Audio.SampleRate</string>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>sampleRate</cstring>
</property>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
</widget>
</item>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<item row="0" column="1">
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
<widget class="QComboBox" name="sampleRate">
<property name="currentText">
<string notr="true">44.1khz</string>
</property>
<property name="currentIndex">
UI: Remove 22.05khz 22.05khz audio really doesn't make sense to have available, and causes issues with encoders (primarily CoreAudio)
2015-09-21 19:31:08 -07:00
<number>0</number>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
<item>
<property name="text">
<string>44.1khz</string>
</property>
</item>
<item>
<property name="text">
<string>48khz</string>
</property>
</item>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</widget>
</item>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
<item row="1" column="0">
<widget class="QLabel" name="label_15">
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Settings.Audio.Channels</string>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>channelSetup</cstring>
</property>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
</widget>
</item>
<item row="1" column="1">
<widget class="QComboBox" name="channelSetup">
<property name="currentText">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Mono</string>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
</property>
<property name="currentIndex">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<number>0</number>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
</property>
<item>
<property name="text">
<string>Mono</string>
</property>
</item>
<item>
<property name="text">
<string>Stereo</string>
</property>
</item>
</widget>
</item>
<item row="2" column="0">
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<widget class="QLabel" name="label_2">
<property name="minimumSize">
<size>
<width>170</width>
<height>0</height>
</size>
</property>
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Settings.Audio.DesktopDevice</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
<property name="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>desktopAudioDevice1</cstring>
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</widget>
</item>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
<item row="2" column="1">
<widget class="QComboBox" name="desktopAudioDevice1">
<property name="enabled">
Load up the lists of audio devices in settings It will now load up a the list of audio input/output devices in the combo boxes in audio settings.
2014-03-06 06:02:25 -08:00
<bool>true</bool>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
</property>
</widget>
</item>
<item row="3" column="0">
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<widget class="QLabel" name="label_3">
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Settings.Audio.DesktopDevice2</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
<property name="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>desktopAudioDevice2</cstring>
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</widget>
</item>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
<item row="3" column="1">
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<widget class="QComboBox" name="desktopAudioDevice2">
<property name="enabled">
Load up the lists of audio devices in settings It will now load up a the list of audio input/output devices in the combo boxes in audio settings.
2014-03-06 06:02:25 -08:00
<bool>true</bool>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
</widget>
</item>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
<item row="4" column="0">
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<widget class="QLabel" name="label_4">
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Settings.Audio.AuxDevice</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>auxAudioDevice1</cstring>
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</widget>
</item>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
<item row="4" column="1">
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<widget class="QComboBox" name="auxAudioDevice1">
<property name="enabled">
Load up the lists of audio devices in settings It will now load up a the list of audio input/output devices in the combo boxes in audio settings.
2014-03-06 06:02:25 -08:00
<bool>true</bool>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
</widget>
</item>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
<item row="5" column="0">
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<widget class="QLabel" name="label_5">
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Settings.Audio.AuxDevice2</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>auxAudioDevice2</cstring>
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</widget>
</item>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
<item row="5" column="1">
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<widget class="QComboBox" name="auxAudioDevice2">
<property name="enabled">
Load up the lists of audio devices in settings It will now load up a the list of audio input/output devices in the combo boxes in audio settings.
2014-03-06 06:02:25 -08:00
<bool>true</bool>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
</widget>
</item>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
<item row="6" column="0">
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<widget class="QLabel" name="label_6">
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Settings.Audio.AuxDevice3</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>auxAudioDevice3</cstring>
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</widget>
</item>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
<item row="6" column="1">
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<widget class="QComboBox" name="auxAudioDevice3">
<property name="enabled">
Load up the lists of audio devices in settings It will now load up a the list of audio input/output devices in the combo boxes in audio settings.
2014-03-06 06:02:25 -08:00
<bool>true</bool>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
</widget>
</item>
UI: Add option to select recording format Add a listboxes to recording to allow changing file formats (allows mp4, mov, mkv, ts, flv)
2015-05-29 09:45:54 -07:00
<item row="7" column="0" colspan="2">
UI: Add Push-to-talk/mute settings to audio settings
2015-04-30 22:07:42 -07:00
<widget class="QScrollArea" name="audioSourceScrollArea">
<property name="widgetResizable">
<bool>true</bool>
</property>
<widget class="QWidget" name="audioSourceWidget">
UI: Add option to select recording format Add a listboxes to recording to allow changing file formats (allows mp4, mov, mkv, ts, flv)
2015-05-29 09:45:54 -07:00
<property name="geometry">
<rect>
<x>0</x>
<y>0</y>
UI: Add support for QSV encoder to simple output
2016-04-18 00:56:51 -07:00
<width>80</width>
<height>16</height>
UI: Add option to select recording format Add a listboxes to recording to allow changing file formats (allows mp4, mov, mkv, ts, flv)
2015-05-29 09:45:54 -07:00
</rect>
</property>
UI: Add Push-to-talk/mute settings to audio settings
2015-04-30 22:07:42 -07:00
</widget>
</widget>
</item>
<item row="8" column="1">
Make ffmpeg test output sync A/V properly FFmpeg test output wasn't make any attempt to sync data before. Should be much more accurate now. Also, added a restart message to audio settings if base audio settings are changed.
2014-02-24 00:48:14 -08:00
<widget class="QLabel" name="audioMsg">
<property name="styleSheet">
<string notr="true">color: rgb(255, 0, 4);</string>
</property>
<property name="text">
<string notr="true"/>
</property>
<property name="wordWrap">
<bool>true</bool>
</property>
</widget>
</item>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</layout>
</widget>
<widget class="QWidget" name="videoPage">
<layout class="QFormLayout" name="formLayout_3">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<property name="fieldGrowthPolicy">
<enum>QFormLayout::AllNonFixedFieldsGrow</enum>
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<property name="labelAlignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
<item row="0" column="0">
UI: Move Renderer/Adapter to advanced These really are advanced options that users shouldn't need to change normally, so moving them to advanced makes sense, and keeps them away from users who don't know what they're doing.
2016-01-25 05:55:01 -08:00
<widget class="QLabel" name="label_8">
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<property name="minimumSize">
<size>
<width>170</width>
<height>0</height>
</size>
</property>
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Settings.Video.BaseResolution</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
UI: Fix a wrong label alignment in settings window
2016-01-30 09:00:23 -08:00
<property name="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>baseResolution</cstring>
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</widget>
</item>
UI: Move Renderer/Adapter to advanced These really are advanced options that users shouldn't need to change normally, so moving them to advanced makes sense, and keeps them away from users who don't know what they're doing.
2016-01-25 05:55:01 -08:00
<item row="0" column="1">
Fix/update forms for main and settings window - Had the wrong names set for the up/down widgets for sources/scenes - Updated the settings dialog and gave most of the widgets actual object names - Added code for the settings window. Settings window should now at least display.
2014-01-24 20:19:50 -08:00
<widget class="QComboBox" name="baseResolution">
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<property name="editable">
<bool>true</bool>
</property>
<property name="currentText">
<string notr="true"/>
</property>
<property name="duplicatesEnabled">
<bool>false</bool>
</property>
<property name="frame">
<bool>true</bool>
</property>
</widget>
</item>
UI: Move Renderer/Adapter to advanced These really are advanced options that users shouldn't need to change normally, so moving them to advanced makes sense, and keeps them away from users who don't know what they're doing.
2016-01-25 05:55:01 -08:00
<item row="1" column="0">
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<widget class="QLabel" name="label_10">
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Settings.Video.ScaledResolution</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>outputResolution</cstring>
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</widget>
</item>
UI: Move Renderer/Adapter to advanced These really are advanced options that users shouldn't need to change normally, so moving them to advanced makes sense, and keeps them away from users who don't know what they're doing.
2016-01-25 05:55:01 -08:00
<item row="1" column="1">
Fix/update forms for main and settings window - Had the wrong names set for the up/down widgets for sources/scenes - Updated the settings dialog and gave most of the widgets actual object names - Added code for the settings window. Settings window should now at least display.
2014-01-24 20:19:50 -08:00
<widget class="QComboBox" name="outputResolution">
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<property name="editable">
<bool>true</bool>
</property>
<property name="currentText">
<string notr="true"/>
</property>
</widget>
</item>
UI: Move Renderer/Adapter to advanced These really are advanced options that users shouldn't need to change normally, so moving them to advanced makes sense, and keeps them away from users who don't know what they're doing.
2016-01-25 05:55:01 -08:00
<item row="2" column="0">
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<widget class="QLabel" name="label_11">
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Settings.Video.DownscaleFilter</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>downscaleFilter</cstring>
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</widget>
</item>
UI: Move Renderer/Adapter to advanced These really are advanced options that users shouldn't need to change normally, so moving them to advanced makes sense, and keeps them away from users who don't know what they're doing.
2016-01-25 05:55:01 -08:00
<item row="2" column="1">
<widget class="QComboBox" name="downscaleFilter">
<property name="enabled">
<bool>true</bool>
</property>
</widget>
</item>
<item row="3" column="0">
Fix/update forms for main and settings window - Had the wrong names set for the up/down widgets for sources/scenes - Updated the settings dialog and gave most of the widgets actual object names - Added code for the settings window. Settings window should now at least display.
2014-01-24 20:19:50 -08:00
<widget class="QComboBox" name="fpsType">
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<property name="sizePolicy">
<sizepolicy hsizetype="Expanding" vsizetype="Fixed">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="currentText">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Settings.Video.FPSCommon</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
<property name="sizeAdjustPolicy">
<enum>QComboBox::AdjustToContents</enum>
</property>
<item>
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Settings.Video.FPSCommon</string>
Fix/update forms for main and settings window - Had the wrong names set for the up/down widgets for sources/scenes - Updated the settings dialog and gave most of the widgets actual object names - Added code for the settings window. Settings window should now at least display.
2014-01-24 20:19:50 -08:00
</property>
</item>
<item>
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Settings.Video.FPSInteger</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
</item>
<item>
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Settings.Video.FPSFraction</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
</item>
</widget>
</item>
UI: Move Renderer/Adapter to advanced These really are advanced options that users shouldn't need to change normally, so moving them to advanced makes sense, and keeps them away from users who don't know what they're doing.
2016-01-25 05:55:01 -08:00
<item row="3" column="1">
Finish the rest of the settings dialog code - Move over the last of the original settings dialog code to QT. It was actually a bit easier to write in the QT version. wxWidgets was definitely not ideal for that because the pages would fully create/destroy every time. - [Win32] Fix os_dlopen so that it only appends .dll if not present - [MacOS] Fix name dialog text edit widget issue (it would be better if we could just use the list widget for editing labels, will have to look in to that in the future) - Tweak the settings UI a bit more and make 30 FPS default - Add a macro to convert a QString to a UTF-8 const char * string - Rename build/plugins to build/obs-plugins - Remove the last of the wxWidgets code
2014-01-26 14:36:15 -08:00
<widget class="QStackedWidget" name="fpsTypes">
Fix/update forms for main and settings window - Had the wrong names set for the up/down widgets for sources/scenes - Updated the settings dialog and gave most of the widgets actual object names - Added code for the settings window. Settings window should now at least display.
2014-01-24 20:19:50 -08:00
<property name="currentIndex">
UI: Move Renderer/Adapter to advanced These really are advanced options that users shouldn't need to change normally, so moving them to advanced makes sense, and keeps them away from users who don't know what they're doing.
2016-01-25 05:55:01 -08:00
<number>0</number>
Fix/update forms for main and settings window - Had the wrong names set for the up/down widgets for sources/scenes - Updated the settings dialog and gave most of the widgets actual object names - Added code for the settings window. Settings window should now at least display.
2014-01-24 20:19:50 -08:00
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<widget class="QWidget" name="page">
<layout class="QHBoxLayout" name="horizontalLayout_2">
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item alignment="Qt::AlignTop">
Fix/update forms for main and settings window - Had the wrong names set for the up/down widgets for sources/scenes - Updated the settings dialog and gave most of the widgets actual object names - Added code for the settings window. Settings window should now at least display.
2014-01-24 20:19:50 -08:00
<widget class="QComboBox" name="fpsCommon">
<property name="currentText">
<string notr="true">30</string>
</property>
Finish the rest of the settings dialog code - Move over the last of the original settings dialog code to QT. It was actually a bit easier to write in the QT version. wxWidgets was definitely not ideal for that because the pages would fully create/destroy every time. - [Win32] Fix os_dlopen so that it only appends .dll if not present - [MacOS] Fix name dialog text edit widget issue (it would be better if we could just use the list widget for editing labels, will have to look in to that in the future) - Tweak the settings UI a bit more and make 30 FPS default - Add a macro to convert a QString to a UTF-8 const char * string - Rename build/plugins to build/obs-plugins - Remove the last of the wxWidgets code
2014-01-26 14:36:15 -08:00
<property name="currentIndex">
<number>3</number>
</property>
Fix/update forms for main and settings window - Had the wrong names set for the up/down widgets for sources/scenes - Updated the settings dialog and gave most of the widgets actual object names - Added code for the settings window. Settings window should now at least display.
2014-01-24 20:19:50 -08:00
<item>
<property name="text">
<string notr="true">10</string>
</property>
</item>
<item>
<property name="text">
<string notr="true">20</string>
</property>
</item>
<item>
<property name="text">
<string notr="true">29.97</string>
</property>
</item>
<item>
<property name="text">
<string notr="true">30</string>
</property>
</item>
<item>
<property name="text">
<string notr="true">48</string>
</property>
</item>
<item>
<property name="text">
<string notr="true">59.94</string>
</property>
</item>
<item>
<property name="text">
<string notr="true">60</string>
</property>
</item>
</widget>
</item>
</layout>
</widget>
<widget class="QWidget" name="page_3">
<layout class="QHBoxLayout" name="horizontalLayout_3">
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item alignment="Qt::AlignTop">
<widget class="QSpinBox" name="fpsInteger">
<property name="minimum">
<number>1</number>
</property>
<property name="maximum">
<number>120</number>
</property>
<property name="value">
<number>30</number>
</property>
</widget>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</item>
</layout>
</widget>
<widget class="QWidget" name="page_2">
<layout class="QFormLayout" name="formLayout_4">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<property name="fieldGrowthPolicy">
<enum>QFormLayout::ExpandingFieldsGrow</enum>
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<property name="labelAlignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item row="0" column="1">
Fix/update forms for main and settings window - Had the wrong names set for the up/down widgets for sources/scenes - Updated the settings dialog and gave most of the widgets actual object names - Added code for the settings window. Settings window should now at least display.
2014-01-24 20:19:50 -08:00
<widget class="QSpinBox" name="fpsNumerator">
<property name="minimum">
<number>1</number>
</property>
<property name="maximum">
<number>1000000</number>
</property>
<property name="value">
<number>30</number>
</property>
</widget>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</item>
<item row="1" column="1">
Fix/update forms for main and settings window - Had the wrong names set for the up/down widgets for sources/scenes - Updated the settings dialog and gave most of the widgets actual object names - Added code for the settings window. Settings window should now at least display.
2014-01-24 20:19:50 -08:00
<widget class="QSpinBox" name="fpsDenominator">
<property name="minimum">
<number>1</number>
</property>
<property name="maximum">
<number>1000000</number>
</property>
</widget>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</item>
<item row="0" column="0">
<widget class="QLabel" name="label_12">
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Settings.Video.Numerator</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
</widget>
</item>
<item row="1" column="0">
<widget class="QLabel" name="label_13">
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Settings.Video.Denominator</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
</widget>
</item>
</layout>
</widget>
</widget>
</item>
UI: Move Renderer/Adapter to advanced These really are advanced options that users shouldn't need to change normally, so moving them to advanced makes sense, and keeps them away from users who don't know what they're doing.
2016-01-25 05:55:01 -08:00
<item row="4" column="1">
Fix video reset and apply new video settings This allows the changing of bideo settings without having to completely reset all graphics data. Will recreate internal output/conversion buffers and such and reset the main preview.
2014-02-22 19:14:19 -08:00
<widget class="QLabel" name="videoMsg">
Finish the rest of the settings dialog code - Move over the last of the original settings dialog code to QT. It was actually a bit easier to write in the QT version. wxWidgets was definitely not ideal for that because the pages would fully create/destroy every time. - [Win32] Fix os_dlopen so that it only appends .dll if not present - [MacOS] Fix name dialog text edit widget issue (it would be better if we could just use the list widget for editing labels, will have to look in to that in the future) - Tweak the settings UI a bit more and make 30 FPS default - Add a macro to convert a QString to a UTF-8 const char * string - Rename build/plugins to build/obs-plugins - Remove the last of the wxWidgets code
2014-01-26 14:36:15 -08:00
<property name="sizePolicy">
<sizepolicy hsizetype="Preferred" vsizetype="Expanding">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="styleSheet">
<string notr="true">color: rgb(255, 0, 4);</string>
</property>
<property name="text">
<string notr="true"/>
</property>
Fix video reset and apply new video settings This allows the changing of bideo settings without having to completely reset all graphics data. Will recreate internal output/conversion buffers and such and reset the main preview.
2014-02-22 19:14:19 -08:00
<property name="wordWrap">
<bool>true</bool>
</property>
Finish the rest of the settings dialog code - Move over the last of the original settings dialog code to QT. It was actually a bit easier to write in the QT version. wxWidgets was definitely not ideal for that because the pages would fully create/destroy every time. - [Win32] Fix os_dlopen so that it only appends .dll if not present - [MacOS] Fix name dialog text edit widget issue (it would be better if we could just use the list widget for editing labels, will have to look in to that in the future) - Tweak the settings UI a bit more and make 30 FPS default - Add a macro to convert a QString to a UTF-8 const char * string - Rename build/plugins to build/obs-plugins - Remove the last of the wxWidgets code
2014-01-26 14:36:15 -08:00
</widget>
</item>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</layout>
</widget>
UI: Add hotkeys page in settings dialog
2014-11-01 13:50:36 -07:00
<widget class="QScrollArea" name="hotkeyPage">
<property name="widgetResizable">
<bool>true</bool>
</property>
<widget class="QWidget" name="hotkeyWidget">
UI: Add option to select recording format Add a listboxes to recording to allow changing file formats (allows mp4, mov, mkv, ts, flv)
2015-05-29 09:45:54 -07:00
<property name="geometry">
<rect>
<x>0</x>
<y>0</y>
<width>98</width>
<height>28</height>
</rect>
</property>
UI: Add hotkeys page in settings dialog
2014-11-01 13:50:36 -07:00
<layout class="QFormLayout" name="hotkeyLayout">
<property name="fieldGrowthPolicy">
<enum>QFormLayout::AllNonFixedFieldsGrow</enum>
</property>
<property name="labelAlignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
UI: Add option to select recording format Add a listboxes to recording to allow changing file formats (allows mp4, mov, mkv, ts, flv)
2015-05-29 09:45:54 -07:00
<property name="verticalSpacing">
<number>0</number>
</property>
UI: Add hotkeys page in settings dialog
2014-11-01 13:50:36 -07:00
</layout>
</widget>
</widget>
UI: Add 'Advanced' settings section Currently, this allows the setting of values such as: - Audio buffering time - Color format (still somewhat unsupported) - YUV color space (if a YUV format) = YUV color range (if a YUV format) More color formats will be added in the future, such as RGB and YUV 4:2:2 formats.
2015-02-11 12:55:06 -08:00
<widget class="QWidget" name="advancedPage">
<layout class="QHBoxLayout" name="horizontalLayout_11">
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item>
<widget class="QScrollArea" name="scrollArea">
<property name="frameShape">
<enum>QFrame::NoFrame</enum>
</property>
<property name="frameShadow">
<enum>QFrame::Plain</enum>
</property>
<property name="widgetResizable">
<bool>true</bool>
</property>
<widget class="QWidget" name="scrollAreaWidgetContents">
<property name="geometry">
<rect>
<x>0</x>
<y>0</y>
UI: Add support for QSV encoder to simple output
2016-04-18 00:56:51 -07:00
<width>559</width>
<height>563</height>
UI: Add 'Advanced' settings section Currently, this allows the setting of values such as: - Audio buffering time - Color format (still somewhat unsupported) - YUV color space (if a YUV format) = YUV color range (if a YUV format) More color formats will be added in the future, such as RGB and YUV 4:2:2 formats.
2015-02-11 12:55:06 -08:00
</rect>
</property>
<layout class="QVBoxLayout" name="verticalLayout_16">
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>9</number>
</property>
<item alignment="Qt::AlignTop">
<widget class="QWidget" name="widget_11" native="true">
<layout class="QVBoxLayout" name="verticalLayout_17">
<item>
<widget class="QGroupBox" name="advancedVideoContainer">
<property name="title">
<string>Basic.Settings.Video</string>
</property>
<layout class="QFormLayout" name="formLayout_14">
<property name="fieldGrowthPolicy">
<enum>QFormLayout::AllNonFixedFieldsGrow</enum>
</property>
<property name="labelAlignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
UI: Move Renderer/Adapter to advanced These really are advanced options that users shouldn't need to change normally, so moving them to advanced makes sense, and keeps them away from users who don't know what they're doing.
2016-01-25 05:55:01 -08:00
<item row="2" column="0">
UI: Add 'Advanced' settings section Currently, this allows the setting of values such as: - Audio buffering time - Color format (still somewhat unsupported) - YUV color space (if a YUV format) = YUV color range (if a YUV format) More color formats will be added in the future, such as RGB and YUV 4:2:2 formats.
2015-02-11 12:55:06 -08:00
<widget class="QLabel" name="label_30">
<property name="minimumSize">
<size>
UI: Implement theme selection option OBS will offer the user a list of themes which are .qss files inside data/obs-studio/themes. If no theme is found in the configuration, it loads the default theme for the system.
2015-02-16 23:45:34 -08:00
<width>0</width>
UI: Add 'Advanced' settings section Currently, this allows the setting of values such as: - Audio buffering time - Color format (still somewhat unsupported) - YUV color space (if a YUV format) = YUV color range (if a YUV format) More color formats will be added in the future, such as RGB and YUV 4:2:2 formats.
2015-02-11 12:55:06 -08:00
<height>0</height>
</size>
</property>
<property name="text">
<string>Basic.Settings.Advanced.Video.ColorFormat</string>
</property>
<property name="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>colorFormat</cstring>
</property>
UI: Add 'Advanced' settings section Currently, this allows the setting of values such as: - Audio buffering time - Color format (still somewhat unsupported) - YUV color space (if a YUV format) = YUV color range (if a YUV format) More color formats will be added in the future, such as RGB and YUV 4:2:2 formats.
2015-02-11 12:55:06 -08:00
</widget>
</item>
UI: Move Renderer/Adapter to advanced These really are advanced options that users shouldn't need to change normally, so moving them to advanced makes sense, and keeps them away from users who don't know what they're doing.
2016-01-25 05:55:01 -08:00
<item row="2" column="1">
UI: Add 'Advanced' settings section Currently, this allows the setting of values such as: - Audio buffering time - Color format (still somewhat unsupported) - YUV color space (if a YUV format) = YUV color range (if a YUV format) More color formats will be added in the future, such as RGB and YUV 4:2:2 formats.
2015-02-11 12:55:06 -08:00
<widget class="QComboBox" name="colorFormat">
<item>
<property name="text">
<string notr="true">NV12</string>
</property>
</item>
<item>
<property name="text">
<string notr="true">I420</string>
</property>
</item>
UI: Add YUV 4:4:4 format option
2015-04-17 02:46:48 -07:00
<item>
<property name="text">
<string>I444</string>
</property>
</item>
UI: Add 'Advanced' settings section Currently, this allows the setting of values such as: - Audio buffering time - Color format (still somewhat unsupported) - YUV color space (if a YUV format) = YUV color range (if a YUV format) More color formats will be added in the future, such as RGB and YUV 4:2:2 formats.
2015-02-11 12:55:06 -08:00
<item>
<property name="text">
<string notr="true">RGB</string>
</property>
</item>
</widget>
</item>
UI: Move Renderer/Adapter to advanced These really are advanced options that users shouldn't need to change normally, so moving them to advanced makes sense, and keeps them away from users who don't know what they're doing.
2016-01-25 05:55:01 -08:00
<item row="4" column="0">
UI: Add 'Advanced' settings section Currently, this allows the setting of values such as: - Audio buffering time - Color format (still somewhat unsupported) - YUV color space (if a YUV format) = YUV color range (if a YUV format) More color formats will be added in the future, such as RGB and YUV 4:2:2 formats.
2015-02-11 12:55:06 -08:00
<widget class="QLabel" name="label_34">
<property name="text">
<string>Basic.Settings.Advanced.Video.ColorRange</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>colorRange</cstring>
</property>
UI: Add 'Advanced' settings section Currently, this allows the setting of values such as: - Audio buffering time - Color format (still somewhat unsupported) - YUV color space (if a YUV format) = YUV color range (if a YUV format) More color formats will be added in the future, such as RGB and YUV 4:2:2 formats.
2015-02-11 12:55:06 -08:00
</widget>
</item>
UI: Move Renderer/Adapter to advanced These really are advanced options that users shouldn't need to change normally, so moving them to advanced makes sense, and keeps them away from users who don't know what they're doing.
2016-01-25 05:55:01 -08:00
<item row="4" column="1">
UI: Add 'Advanced' settings section Currently, this allows the setting of values such as: - Audio buffering time - Color format (still somewhat unsupported) - YUV color space (if a YUV format) = YUV color range (if a YUV format) More color formats will be added in the future, such as RGB and YUV 4:2:2 formats.
2015-02-11 12:55:06 -08:00
<widget class="QComboBox" name="colorRange"/>
</item>
UI: Move Renderer/Adapter to advanced These really are advanced options that users shouldn't need to change normally, so moving them to advanced makes sense, and keeps them away from users who don't know what they're doing.
2016-01-25 05:55:01 -08:00
<item row="3" column="0">
UI: Add 'Advanced' settings section Currently, this allows the setting of values such as: - Audio buffering time - Color format (still somewhat unsupported) - YUV color space (if a YUV format) = YUV color range (if a YUV format) More color formats will be added in the future, such as RGB and YUV 4:2:2 formats.
2015-02-11 12:55:06 -08:00
<widget class="QLabel" name="label_33">
<property name="text">
<string>Basic.Settings.Advanced.Video.ColorSpace</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>colorSpace</cstring>
</property>
UI: Add 'Advanced' settings section Currently, this allows the setting of values such as: - Audio buffering time - Color format (still somewhat unsupported) - YUV color space (if a YUV format) = YUV color range (if a YUV format) More color formats will be added in the future, such as RGB and YUV 4:2:2 formats.
2015-02-11 12:55:06 -08:00
</widget>
</item>
UI: Move Renderer/Adapter to advanced These really are advanced options that users shouldn't need to change normally, so moving them to advanced makes sense, and keeps them away from users who don't know what they're doing.
2016-01-25 05:55:01 -08:00
<item row="3" column="1">
UI: Add 'Advanced' settings section Currently, this allows the setting of values such as: - Audio buffering time - Color format (still somewhat unsupported) - YUV color space (if a YUV format) = YUV color range (if a YUV format) More color formats will be added in the future, such as RGB and YUV 4:2:2 formats.
2015-02-11 12:55:06 -08:00
<widget class="QComboBox" name="colorSpace">
<item>
<property name="text">
<string notr="true">709</string>
</property>
</item>
<item>
<property name="text">
<string notr="true">601</string>
</property>
</item>
</widget>
</item>
UI: Move Renderer/Adapter to advanced These really are advanced options that users shouldn't need to change normally, so moving them to advanced makes sense, and keeps them away from users who don't know what they're doing.
2016-01-25 05:55:01 -08:00
<item row="0" column="0">
UI: Hide renderer/adapter when not on windows Also hide adapter list if not using Direct3D.
2016-01-25 06:22:00 -08:00
<widget class="QLabel" name="rendererLabel">
UI: Move Renderer/Adapter to advanced These really are advanced options that users shouldn't need to change normally, so moving them to advanced makes sense, and keeps them away from users who don't know what they're doing.
2016-01-25 05:55:01 -08:00
<property name="text">
<string>Basic.Settings.Video.Renderer</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>renderer</cstring>
</property>
UI: Move Renderer/Adapter to advanced These really are advanced options that users shouldn't need to change normally, so moving them to advanced makes sense, and keeps them away from users who don't know what they're doing.
2016-01-25 05:55:01 -08:00
</widget>
</item>
<item row="0" column="1">
<widget class="QComboBox" name="renderer">
<property name="currentText">
<string notr="true"/>
</property>
</widget>
</item>
<item row="1" column="0">
UI: Hide renderer/adapter when not on windows Also hide adapter list if not using Direct3D.
2016-01-25 06:22:00 -08:00
<widget class="QLabel" name="adapterLabel">
UI: Move Renderer/Adapter to advanced These really are advanced options that users shouldn't need to change normally, so moving them to advanced makes sense, and keeps them away from users who don't know what they're doing.
2016-01-25 05:55:01 -08:00
<property name="text">
<string>Basic.Settings.Video.Adapter</string>
</property>
<property name="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>adapter</cstring>
</property>
UI: Move Renderer/Adapter to advanced These really are advanced options that users shouldn't need to change normally, so moving them to advanced makes sense, and keeps them away from users who don't know what they're doing.
2016-01-25 05:55:01 -08:00
</widget>
</item>
<item row="1" column="1">
<widget class="QComboBox" name="adapter">
<property name="enabled">
<bool>false</bool>
</property>
<property name="currentText">
<string notr="true"/>
</property>
</widget>
</item>
UI: Disable OSX V-Sync when program is open OSX has an annoying feature called "BeamSync", which on later versions of OSX is always on. For whatever reason, Apple devs decided to force this feature to always be on, so applications must always render with v-sync regardless of what they set their swap interval to. This issue would cause syncing to the vertical refresh for each additional active display, and wouldn't allow rendering above the current refresh rate. This caused major rendering stalls and prevented video frame timing from being accurate. This fixes the issue by using an undocumented set of functions to disable BeamSync. Note that because this is an undocumented method of working around the issue, its existence cannot be guaranteed. If the functions no longer exist for whatever reason, it will safely do nothing.
2016-01-25 17:09:59 -08:00
<item row="5" column="1">
<widget class="QCheckBox" name="disableOSXVSync">
<property name="text">
<string>DisableOSXVSync</string>
</property>
</widget>
</item>
<item row="6" column="1">
<widget class="QCheckBox" name="resetOSXVSync">
<property name="text">
<string>ResetOSXVSyncOnExit</string>
</property>
</widget>
</item>
UI: Add 'Advanced' settings section Currently, this allows the setting of values such as: - Audio buffering time - Color format (still somewhat unsupported) - YUV color space (if a YUV format) = YUV color range (if a YUV format) More color formats will be added in the future, such as RGB and YUV 4:2:2 formats.
2015-02-11 12:55:06 -08:00
</layout>
</widget>
</item>
UI: Add file formatting options for recording Allows the user to specify custom formatting for their recording file names with many formatting options, viewed via tooltip. The options have been added to the advanced settings section. Closes jp9000/obs-studio#507
2016-03-25 02:43:38 -07:00
<item>
<widget class="QGroupBox" name="groupBox_6">
<property name="title">
<string>Basic.Settings.Output.Adv.Recording</string>
</property>
<layout class="QFormLayout" name="formLayout_17">
<item row="0" column="0">
<widget class="QLabel" name="label_7">
<property name="text">
<string>Basic.Settings.Output.Adv.Recording.Filename</string>
</property>
</widget>
</item>
<item row="0" column="1">
<widget class="QLineEdit" name="filenameFormatting"/>
</item>
<item row="1" column="1">
<widget class="QCheckBox" name="overwriteIfExists">
<property name="text">
<string>Basic.Settings.Output.Adv.Recording.OverwriteIfExists</string>
</property>
</widget>
</item>
</layout>
</widget>
</item>
UI: Add stream delay options to advanced settings I added stream delay options to advanced settings not just because I feel it's an advanced option, but also to reduce clutter in the outputs section and its sub-sections, which already have far too many options as it is.
2015-09-06 16:12:03 -07:00
<item>
<widget class="QGroupBox" name="groupBox_5">
<property name="title">
<string>Basic.Settings.Advanced.StreamDelay</string>
</property>
<layout class="QFormLayout" name="formLayout_18">
<item row="0" column="1">
<widget class="QCheckBox" name="streamDelayEnable">
<property name="text">
<string>Enable</string>
</property>
<property name="checked">
<bool>true</bool>
</property>
</widget>
</item>
<item row="1" column="0">
<widget class="QLabel" name="label_56">
<property name="text">
<string>Basic.Settings.Advanced.StreamDelay.Duration</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>streamDelaySec</cstring>
</property>
UI: Add stream delay options to advanced settings I added stream delay options to advanced settings not just because I feel it's an advanced option, but also to reduce clutter in the outputs section and its sub-sections, which already have far too many options as it is.
2015-09-06 16:12:03 -07:00
</widget>
</item>
<item row="1" column="1">
<widget class="QWidget" name="widget_12" native="true">
<property name="enabled">
<bool>true</bool>
</property>
<layout class="QHBoxLayout" name="horizontalLayout_13">
<property name="spacing">
<number>5</number>
</property>
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item>
<widget class="QSpinBox" name="streamDelaySec">
<property name="enabled">
<bool>true</bool>
</property>
<property name="sizePolicy">
<sizepolicy hsizetype="Maximum" vsizetype="Fixed">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="minimumSize">
<size>
<width>80</width>
<height>0</height>
</size>
</property>
<property name="suffix">
<string notr="true">s</string>
</property>
<property name="minimum">
<number>1</number>
</property>
<property name="maximum">
<number>1800</number>
</property>
</widget>
</item>
<item>
<widget class="QLabel" name="streamDelayInfo">
<property name="text">
<string notr="true">Estimated RAM goes here</string>
</property>
</widget>
</item>
</layout>
</widget>
</item>
<item row="2" column="1">
<widget class="QCheckBox" name="streamDelayPreserve">
<property name="text">
<string>Basic.Settings.Advanced.StreamDelay.Preserve</string>
</property>
</widget>
</item>
</layout>
</widget>
</item>
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
<item>
<widget class="QGroupBox" name="groupBox_7">
<property name="title">
<string>Basic.Settings.Output.Reconnect</string>
</property>
<layout class="QFormLayout" name="formLayout_19">
<property name="fieldGrowthPolicy">
<enum>QFormLayout::AllNonFixedFieldsGrow</enum>
</property>
<item row="1" column="0">
<widget class="QLabel" name="label_17">
<property name="text">
<string>Basic.Settings.Output.RetryDelay</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>reconnectRetryDelay</cstring>
</property>
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
</widget>
</item>
<item row="0" column="1">
<widget class="QCheckBox" name="reconnectEnable">
<property name="text">
<string>Enable</string>
</property>
<property name="checked">
<bool>true</bool>
</property>
</widget>
</item>
<item row="1" column="1">
<widget class="QSpinBox" name="reconnectRetryDelay">
<property name="maximum">
<number>30</number>
</property>
</widget>
</item>
<item row="2" column="0">
<widget class="QLabel" name="label_22">
<property name="text">
<string>Basic.Settings.Output.MaxRetries</string>
</property>
UI: Add label/control buddy pairs for main windows
2016-02-21 11:19:26 -08:00
<property name="buddy">
<cstring>reconnectMaxRetries</cstring>
</property>
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
</widget>
</item>
<item row="2" column="1">
<widget class="QSpinBox" name="reconnectMaxRetries">
<property name="minimum">
<number>1</number>
</property>
<property name="maximum">
<number>10000</number>
</property>
</widget>
</item>
</layout>
</widget>
</item>
UI: Add 'Advanced' settings section Currently, this allows the setting of values such as: - Audio buffering time - Color format (still somewhat unsupported) - YUV color space (if a YUV format) = YUV color range (if a YUV format) More color formats will be added in the future, such as RGB and YUV 4:2:2 formats.
2015-02-11 12:55:06 -08:00
<item>
<widget class="QLabel" name="advancedMsg">
<property name="styleSheet">
<string notr="true">color: rgb(255, 0, 4);</string>
</property>
<property name="text">
<string notr="true"/>
</property>
UI: Add warning for non-NV12 color formats Non-NV12 video formats are primarily intended for recording. For streaming, if the libobs color format is not set to NV12, it's likely that the video frames will have to be converted to NV12, which will use extra CPU usage. Due to that fact, it's important to warn the user of that potential extra increased CPU usage that may be required when streaming.
2015-04-17 23:40:35 -07:00
<property name="wordWrap">
<bool>true</bool>
</property>
</widget>
</item>
<item>
<widget class="QLabel" name="advancedMsg2">
<property name="styleSheet">
<string notr="true">color: rgb(255, 0, 4);</string>
</property>
<property name="text">
<string notr="true"/>
</property>
<property name="wordWrap">
<bool>true</bool>
</property>
UI: Add 'Advanced' settings section Currently, this allows the setting of values such as: - Audio buffering time - Color format (still somewhat unsupported) - YUV color space (if a YUV format) = YUV color range (if a YUV format) More color formats will be added in the future, such as RGB and YUV 4:2:2 formats.
2015-02-11 12:55:06 -08:00
</widget>
</item>
</layout>
</widget>
</item>
</layout>
</widget>
</widget>
</item>
</layout>
</widget>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</widget>
</item>
</layout>
</item>
<item>
<widget class="QDialogButtonBox" name="buttonBox">
<property name="standardButtons">
<set>QDialogButtonBox::Apply|QDialogButtonBox::Cancel|QDialogButtonBox::Ok</set>
</property>
</widget>
</item>
</layout>
</widget>
<tabstops>
<tabstop>listWidget</tabstop>
<tabstop>buttonBox</tabstop>
<tabstop>language</tabstop>
</tabstops>
<resources>
<include location="obs.qrc"/>
</resources>
<connections>
<connection>
<sender>listWidget</sender>
<signal>currentRowChanged(int)</signal>
<receiver>settingsPages</receiver>
<slot>setCurrentIndex(int)</slot>
<hints>
<hint type="sourcelabel">
<x>75</x>
<y>35</y>
</hint>
<hint type="destinationlabel">
<x>199</x>
<y>50</y>
</hint>
</hints>
</connection>
<connection>
Fix/update forms for main and settings window - Had the wrong names set for the up/down widgets for sources/scenes - Updated the settings dialog and gave most of the widgets actual object names - Added code for the settings window. Settings window should now at least display.
2014-01-24 20:19:50 -08:00
<sender>fpsType</sender>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<signal>currentIndexChanged(int)</signal>
Finish the rest of the settings dialog code - Move over the last of the original settings dialog code to QT. It was actually a bit easier to write in the QT version. wxWidgets was definitely not ideal for that because the pages would fully create/destroy every time. - [Win32] Fix os_dlopen so that it only appends .dll if not present - [MacOS] Fix name dialog text edit widget issue (it would be better if we could just use the list widget for editing labels, will have to look in to that in the future) - Tweak the settings UI a bit more and make 30 FPS default - Add a macro to convert a QString to a UTF-8 const char * string - Rename build/plugins to build/obs-plugins - Remove the last of the wxWidgets code
2014-01-26 14:36:15 -08:00
<receiver>fpsTypes</receiver>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<slot>setCurrentIndex(int)</slot>
<hints>
<hint type="sourcelabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>159</x>
<y>34</y>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</hint>
<hint type="destinationlabel">
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<x>241</x>
<y>34</y>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</hint>
</hints>
</connection>
<connection>
<sender>outputMode</sender>
<signal>currentIndexChanged(int)</signal>
<receiver>outputModePages</receiver>
<slot>setCurrentIndex(int)</slot>
<hints>
<hint type="sourcelabel">
Add auto-reconnect settings
2014-07-03 18:07:33 -07:00
<x>586</x>
<y>38</y>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</hint>
<hint type="destinationlabel">
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
<x>250</x>
<y>39</y>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</hint>
</hints>
</connection>
Basic UI: Add advanced encoder settings
2014-08-25 07:48:51 -07:00
<connection>
<sender>simpleOutAdvanced</sender>
<signal>toggled(bool)</signal>
<receiver>simpleOutPreset</receiver>
<slot>setVisible(bool)</slot>
<hints>
<hint type="sourcelabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>875</x>
<y>360</y>
Basic UI: Add advanced encoder settings
2014-08-25 07:48:51 -07:00
</hint>
<hint type="destinationlabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>875</x>
<y>427</y>
Basic UI: Add advanced encoder settings
2014-08-25 07:48:51 -07:00
</hint>
</hints>
</connection>
<connection>
<sender>simpleOutAdvanced</sender>
<signal>toggled(bool)</signal>
<receiver>label_24</receiver>
<slot>setVisible(bool)</slot>
<hints>
<hint type="sourcelabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>875</x>
<y>360</y>
Basic UI: Add advanced encoder settings
2014-08-25 07:48:51 -07:00
</hint>
<hint type="destinationlabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>466</x>
<y>427</y>
Basic UI: Add advanced encoder settings
2014-08-25 07:48:51 -07:00
</hint>
</hints>
</connection>
<connection>
<sender>simpleOutAdvanced</sender>
<signal>toggled(bool)</signal>
UI: Rename 'Custom x264 Settings' Rename 'Custom x264 Settings' to 'Custom Encoder Settings', because it may be useful to use this for encoders other than x264
2015-01-18 06:29:24 -08:00
<receiver>simpleOutCustom</receiver>
Basic UI: Add advanced encoder settings
2014-08-25 07:48:51 -07:00
<slot>setVisible(bool)</slot>
<hints>
<hint type="sourcelabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>875</x>
<y>360</y>
Basic UI: Add advanced encoder settings
2014-08-25 07:48:51 -07:00
</hint>
<hint type="destinationlabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>875</x>
<y>503</y>
Basic UI: Add advanced encoder settings
2014-08-25 07:48:51 -07:00
</hint>
</hints>
</connection>
<connection>
<sender>simpleOutAdvanced</sender>
<signal>toggled(bool)</signal>
<receiver>label_23</receiver>
<slot>setVisible(bool)</slot>
<hints>
<hint type="sourcelabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>875</x>
<y>360</y>
Basic UI: Add advanced encoder settings
2014-08-25 07:48:51 -07:00
</hint>
<hint type="destinationlabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>466</x>
<y>503</y>
Basic UI: Add "Use Constant Bitrate" advanced option. It's better to use VBR for local recordings, so this option should be nice for people who want to do that.
2014-09-24 20:23:42 -07:00
</hint>
</hints>
</connection>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<connection>
<sender>advOutRecType</sender>
<signal>currentIndexChanged(int)</signal>
<receiver>stackedWidget</receiver>
<slot>setCurrentIndex(int)</slot>
<hints>
<hint type="sourcelabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>705</x>
<y>144</y>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</hint>
<hint type="destinationlabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>396</x>
<y>245</y>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</hint>
</hints>
</connection>
<connection>
<sender>advOutFFUseRescale</sender>
<signal>toggled(bool)</signal>
<receiver>advOutFFRescale</receiver>
<slot>setEnabled(bool)</slot>
<hints>
<hint type="sourcelabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>514</x>
<y>344</y>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</hint>
<hint type="destinationlabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>748</x>
<y>344</y>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</hint>
</hints>
</connection>
<connection>
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
<sender>advOutUseRescale</sender>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<signal>toggled(bool)</signal>
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
<receiver>advOutRescale</receiver>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<slot>setEnabled(bool)</slot>
<hints>
<hint type="sourcelabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>864</x>
<y>141</y>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</hint>
<hint type="destinationlabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>427</x>
<y>178</y>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</hint>
</hints>
</connection>
<connection>
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
<sender>advOutRecUseRescale</sender>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<signal>toggled(bool)</signal>
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
<receiver>advOutRecRescale</receiver>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<slot>setEnabled(bool)</slot>
<hints>
<hint type="sourcelabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>864</x>
<y>141</y>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</hint>
<hint type="destinationlabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>864</x>
<y>178</y>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</hint>
</hints>
</connection>
<connection>
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
<sender>advOutFFType</sender>
<signal>currentIndexChanged(int)</signal>
<receiver>stackedWidget_2</receiver>
<slot>setCurrentIndex(int)</slot>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<hints>
<hint type="sourcelabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>864</x>
<y>141</y>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</hint>
<hint type="destinationlabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>427</x>
<y>215</y>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</hint>
</hints>
</connection>
<connection>
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
<sender>streamDelayEnable</sender>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<signal>toggled(bool)</signal>
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
<receiver>label_56</receiver>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<slot>setEnabled(bool)</slot>
<hints>
<hint type="sourcelabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>864</x>
<y>141</y>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</hint>
<hint type="destinationlabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>864</x>
<y>215</y>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</hint>
</hints>
</connection>
<connection>
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
<sender>streamDelayEnable</sender>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<signal>toggled(bool)</signal>
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
<receiver>streamDelayPreserve</receiver>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<slot>setEnabled(bool)</slot>
<hints>
<hint type="sourcelabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>427</x>
<y>355</y>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</hint>
<hint type="destinationlabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>862</x>
<y>355</y>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</hint>
</hints>
</connection>
<connection>
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
<sender>streamDelayEnable</sender>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<signal>toggled(bool)</signal>
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
<receiver>widget_12</receiver>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<slot>setEnabled(bool)</slot>
<hints>
<hint type="sourcelabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>424</x>
<y>331</y>
UI: Set simple mode reconnect signal to toggled() clicked() is the wrong signal to use, it only activates on actual user click, not when the value is changed. toggle() activates whenever the value itself is changed.
2015-02-10 19:35:33 -08:00
</hint>
<hint type="destinationlabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>658</x>
<y>331</y>
UI: Set simple mode reconnect signal to toggled() clicked() is the wrong signal to use, it only activates on actual user click, not when the value is changed. toggle() activates whenever the value itself is changed.
2015-02-10 19:35:33 -08:00
</hint>
</hints>
</connection>
<connection>
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
<sender>reconnectEnable</sender>
UI: Set simple mode reconnect signal to toggled() clicked() is the wrong signal to use, it only activates on actual user click, not when the value is changed. toggle() activates whenever the value itself is changed.
2015-02-10 19:35:33 -08:00
<signal>toggled(bool)</signal>
<receiver>label_17</receiver>
<slot>setEnabled(bool)</slot>
<hints>
<hint type="sourcelabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>875</x>
<y>254</y>
UI: Set simple mode reconnect signal to toggled() clicked() is the wrong signal to use, it only activates on actual user click, not when the value is changed. toggle() activates whenever the value itself is changed.
2015-02-10 19:35:33 -08:00
</hint>
<hint type="destinationlabel">
UI: Allow generated filenames for FFmpeg output This changes the way the advanced output section's FFmpeg output settings work by allowing the user to select whether they want to output to a file or output to a URL, and makes it so file names are automatically generated like other recording outputs. If they choose to output to a file, it'll only require an output directory similarly to how other recording outputs work. They can select a directory to output to rather than being required to type in a full path and filename; the filename is automatically generated. The extension is also automatically retrieved from libff depending on the format selected. Otherwise if they have Output to URL selected, it'll show a simple edit box where they can type in the target URL.
2015-08-18 20:58:24 -07:00
<x>466</x>
<y>291</y>
UI: Set simple mode reconnect signal to toggled() clicked() is the wrong signal to use, it only activates on actual user click, not when the value is changed. toggle() activates whenever the value itself is changed.
2015-02-10 19:35:33 -08:00
</hint>
</hints>
</connection>
<connection>
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
<sender>reconnectEnable</sender>
UI: Set simple mode reconnect signal to toggled() clicked() is the wrong signal to use, it only activates on actual user click, not when the value is changed. toggle() activates whenever the value itself is changed.
2015-02-10 19:35:33 -08:00
<signal>toggled(bool)</signal>
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
<receiver>reconnectRetryDelay</receiver>
UI: Set simple mode reconnect signal to toggled() clicked() is the wrong signal to use, it only activates on actual user click, not when the value is changed. toggle() activates whenever the value itself is changed.
2015-02-10 19:35:33 -08:00
<slot>setEnabled(bool)</slot>
<hints>
<hint type="sourcelabel">
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
<x>516</x>
<y>411</y>
UI: Add stream delay options to advanced settings I added stream delay options to advanced settings not just because I feel it's an advanced option, but also to reduce clutter in the outputs section and its sub-sections, which already have far too many options as it is.
2015-09-06 16:12:03 -07:00
</hint>
<hint type="destinationlabel">
<x>250</x>
<y>92</y>
</hint>
</hints>
</connection>
<connection>
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
<sender>reconnectEnable</sender>
UI: Add stream delay options to advanced settings I added stream delay options to advanced settings not just because I feel it's an advanced option, but also to reduce clutter in the outputs section and its sub-sections, which already have far too many options as it is.
2015-09-06 16:12:03 -07:00
<signal>toggled(bool)</signal>
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
<receiver>label_22</receiver>
UI: Add stream delay options to advanced settings I added stream delay options to advanced settings not just because I feel it's an advanced option, but also to reduce clutter in the outputs section and its sub-sections, which already have far too many options as it is.
2015-09-06 16:12:03 -07:00
<slot>setEnabled(bool)</slot>
<hints>
<hint type="sourcelabel">
<x>533</x>
<y>273</y>
</hint>
<hint type="destinationlabel">
<x>449</x>
<y>301</y>
</hint>
</hints>
</connection>
<connection>
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
<sender>reconnectEnable</sender>
UI: Add stream delay options to advanced settings I added stream delay options to advanced settings not just because I feel it's an advanced option, but also to reduce clutter in the outputs section and its sub-sections, which already have far too many options as it is.
2015-09-06 16:12:03 -07:00
<signal>toggled(bool)</signal>
UI: Move reconnect options to advanced settings This is mostly just to remove the unnecessary clutter from the output sections. The reconnect settings are generally rarely modified by users as it is.
2015-09-10 19:10:40 -07:00
<receiver>reconnectMaxRetries</receiver>
UI: Add stream delay options to advanced settings I added stream delay options to advanced settings not just because I feel it's an advanced option, but also to reduce clutter in the outputs section and its sub-sections, which already have far too many options as it is.
2015-09-06 16:12:03 -07:00
<slot>setEnabled(bool)</slot>
<hints>
<hint type="sourcelabel">
UI: Add snap options to general settings section Allows the user to disable snapping all together or control the snap threshold.
2016-04-06 18:03:29 -07:00
<x>690</x>
<y>454</y>
</hint>
<hint type="destinationlabel">
<x>690</x>
<y>506</y>
</hint>
</hints>
</connection>
<connection>
<sender>snappingEnabled</sender>
<signal>toggled(bool)</signal>
<receiver>label_9</receiver>
<slot>setEnabled(bool)</slot>
<hints>
<hint type="sourcelabel">
<x>376</x>
<y>196</y>
</hint>
<hint type="destinationlabel">
<x>305</x>
<y>224</y>
</hint>
</hints>
</connection>
<connection>
<sender>snappingEnabled</sender>
<signal>toggled(bool)</signal>
<receiver>snapDistance</receiver>
<slot>setEnabled(bool)</slot>
<hints>
<hint type="sourcelabel">
<x>417</x>
<y>204</y>
</hint>
<hint type="destinationlabel">
<x>434</x>
<y>234</y>
</hint>
</hints>
</connection>
<connection>
<sender>snappingEnabled</sender>
<signal>toggled(bool)</signal>
<receiver>screenSnapping</receiver>
<slot>setEnabled(bool)</slot>
<hints>
<hint type="sourcelabel">
<x>476</x>
<y>202</y>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</hint>
UI: Add option to snap to edges of other sources Allows the user to snap sources to the edges of other sources, on by default. Closes jp9000/obs-studio#530
2016-04-06 18:13:56 -07:00
<hint type="destinationlabel">
<x>466</x>
<y>253</y>
</hint>
</hints>
</connection>
<connection>
<sender>snappingEnabled</sender>
<signal>toggled(bool)</signal>
<receiver>sourceSnapping</receiver>
<slot>setEnabled(bool)</slot>
<hints>
<hint type="sourcelabel">
<x>518</x>
<y>204</y>
</hint>
UI: Add option to snap to vertical/horizontal center Allows users to snap sources to the horizontal or vertical centers of the screen. Off by default. Closes jp9000/obs-studio#528
2016-04-06 18:10:39 -07:00
<hint type="destinationlabel">
<x>515</x>
<y>277</y>
</hint>
</hints>
</connection>
<connection>
<sender>snappingEnabled</sender>
<signal>toggled(bool)</signal>
<receiver>centerSnapping</receiver>
<slot>setEnabled(bool)</slot>
<hints>
<hint type="sourcelabel">
<x>557</x>
<y>207</y>
</hint>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
<hint type="destinationlabel">
UI: Add "Enforce streaming bitrate limits" setting Allows the user to disable streaming bitrate limits in simple output mode if they so choose. This option is enabled by default.
2016-04-10 03:10:36 -07:00
<x>866</x>
<y>306</y>
</hint>
</hints>
</connection>
<connection>
<sender>simpleOutAdvanced</sender>
<signal>toggled(bool)</signal>
<receiver>simpleOutEnforce</receiver>
<slot>setVisible(bool)</slot>
<hints>
<hint type="sourcelabel">
<x>484</x>
<y>147</y>
</hint>
<hint type="destinationlabel">
<x>483</x>
<y>170</y>
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
</hint>
</hints>
</connection>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</connections>
</ui>