Up in front, thank you so much for investing serious thoughts and time into the stuff, really appreciated.
knk wrote: ↑Thu Oct 03, 2024 2:22 pm
Pressure is what makes life on earth possible!
Very valid point and very well expressed. My big sister always says "the earth without art is just eh" but your point is much more valid than hers
knk wrote: ↑Thu Oct 03, 2024 2:22 pm
VU meter seems to be a bit faded in the player...maybe it can be fixed in the player config file, will check.
Might i ask what is the offset for you?
I started by trying to keep mpv parameters in the mpv.conf but it turned out quickly that we have to insert/change filters depending on source file, so the filter chain is now calculated on server side, source_code/node_components/player.js. For me and @momocampo, the AV sync was always about 5-6 frames off, so i decided add a rule like "if there is audio, then insert asetpts=PTS-0.24/TB"
For my xdcamhd sources and youtube stuff it seems to be about +- 1 frame now.
knk wrote: ↑Thu Oct 03, 2024 2:22 pm
Now for the down part, it doesn't seem to be compatible with my previous "major" workflows.
The concat feature "stitch" tag has a big differences from the previous version.
Very sorry for not being fully backwards compatible here, but i needed to stop "misusing" s_source and fill it with some simple string instead of complex data structures.
This should go into the future documenation:
When add the stitch functionality to your workflow (webui_stitch in wf_description), in the past, we just populated s_source with a JSON array of files. But this did lead to bad behaviour everywhere so we changed that:
The current behaviour is:
- for backward compatibility you can set s_source at start of your job to %webui_a_source%. This contains a plain JSON array of files without any in/out points, just filenames (as it was before, so this should work for your workflows)
- a complex JSON object with in/out points and similar stuff is populated into %webui_o_source%, this is what the example workflows use
knk wrote: ↑Thu Oct 03, 2024 2:22 pm
It still doesn't seem to show the "current name" that it is transcoding, nor does it seem to allow a custom "main job" name for people to be able to identify their job in the monitor window.
I've tested the example workflows and the "for each" branch of transcoding always provides the name of the 1st file in the submited list.
1) naming the "main job" is currently done with the first source file. I'll think about how we could connect a webui_variable with s_source to change this.
2) "for each" not changing the source name is something we discussed already internally, a topic for @admin for sure. Lots of stuff to do in that area (like re-parsing s_source)
3) exactly, instead of submitting a json array into s_source, i changed it now to submit the first source file name into s_source.
knk wrote: ↑Thu Oct 03, 2024 2:22 pm
Also there seems to be a constrain in the global number of input files, since the command line seems to big holding UNC paths, etc.
That should not be the case, there should be no "builtin" point where we hand over the full list of files on a commandline. E.g. ffmpeg gets a ffconcat list from text file.
I hope you can give some example how to reproduce that, this has high priority. Is it like i just need to submit hundreds of files to one of my example workflows?
