HaikuArchives / ffmpegGUI

GUI for FFmpeg
MIT License
23 stars 10 forks source link

Add codec copy options for audio and video #85

Closed andimachovec closed 1 year ago

andimachovec commented 1 year ago

implements #66

andimachovec commented 1 year ago

@humdingerb : I didn't update the en.catkeys file because I wasn't sure if you are happy with the text in the menu. I opted for the term codec copy because it is used by ffmpeg. Feel free to change it if you come up with something more human sounding :-) But if you do so it also has to be changed in ffguiwin::BuildLine()

humdingerb commented 1 year ago

I don't think we're quite there yet. Choosing "copy from source" -- I'd go with "1:1 copy", because it's not just the same codec as the source, but all settings of video and/or audio -- should disable all audio and video options. "-vcodec | -acodec copy" really does a 1:1 copy without de-/encoding; no changes in bitrate, framerate, resolution, cropping.

Those checkboxes and their spinners/menus/etc. should be disabled when "1:1 copy" is chosen and their parameters shouldn't appear in the commandline. Their state should be saved and restored when choosing a "non-copy" audio/video format.

andimachovec commented 1 year ago

Fair enough, I'll change it and append it to this PR.

andimachovec commented 1 year ago

@humdingerb : I've updated the PR with fixes to the various toggle methods and buildline to handle all the option dependencies coming with 1:1 copy correctly. At least I hope so, please do test :-) After writing all this enabling and disabling code, something about the structure of our GUI design here came to my attention. Let's say I want to only extract the audio from a video file. With the current design (and 1:1 copy as the default) I have to first select a video codec and only then I can proceed to disable video entirely. My solution would be to keep the video container (or file format as it is named in our GUI) with the output file as it is now and move the video and audio codec dropdowns to their respective boxes, right below the "enable xxx" checkboxes. What do you think? Could be implemented as part of this PR or a separate one afterwards of course.