On Tue, Jul 26, 2016 at 08:40:20AM -0500, Carl Karsten wrote: > > > On Tue, Jul 26, 2016 at 2:01 AM, Wouter Verhelst <[email protected]> wrote: > > On Thu, Jul 14, 2016 at 12:07:44PM +0200, Wouter Verhelst wrote: > > I don't mind. > > > > However, the easiest way is probably to hack up things so that > > generating a webm file creates a low-res version by default, and then > > setting everything back to "encode" again. > > > Assuming they are all in the same state (like 12/done) > > python enc.py --ready-state=12 > > That will find the 12's, encode, bump them to 13.
Yeah, that's one way of doing it. What I was planning was to just run some raw SQL on the database, setting all dc16 talks back to encode with no further changes. Something like "UPDATE main_episode SET state = 2 WHERE state = 12 AND eventid = 4" should work, if my memory of your data scheme is correct... > For the future, I should make this easier. veyepar already supports multiple > encodes, but currently each needs it's on extension (the use case is: an mp4 > for youtube and a webm for download) > > What is the typical way of naming the larger/smaller files? In past years, we had "high" and "low" directories, which would contain files with the same name, but different resolutions. Since we've already released at high resolution in the "standard" directory, and since people already link to those files, it might not be a good idea to move those files around anymore. > On a similar note, there are 3 more things that could us a bunch of R&D: > > 1. 2 pass encoding > 2. Audio normalization > 3. encode script hook. > > > 1. 2 pass - > > This should be easy. I have code that should work, but: > # 2 pass causes no video track, so dumping this. > https://github.com/CarlFK/veyepar/blob/master/dj/scripts/enc.py#L453-L460 That's not very good :-) I have no clue how to do two-pass encoding with melt, so I converted your melt command line into producing DV output (which causes it to just copy the video rather than transcode it) and then do a two-pass video encode with gstreamer. It's a hack, but it works -- except for menzies 12, where we do one-pass transcode with melt. Not sure how to fix that for next year, yet. > 2. Audio normalization needs looking at. It "works for me" but that may be > because my source is good enough and whatever is or isn't happening doesn't > matter. result: I haven't put much effort into this in over a year. If > someone can dig into this and figure out A) is there a problem and if so, some > examples and of course patches! > > Here is what currently drives it: > > https://github.com/CarlFK/veyepar/blob/master/dj/scripts/template.mlt#L177-L182 > > Maybe <property name="program">-23.0</property> is wrong? > https://www.mltframework.org/bin/view/MLT/FilterLoudness > "This filter requires two passes." Hmmm.. That looks like a problem. Yeah. The first pass checks audio levels and peaks etc, the second pass adjusts audio levels. The good news is that audio takes far less CPU than video. Both passes added together usually take no more than a few seconds to run on most modern hardware. > template.mlt is a functioning ShotCut project file. If you put the input files > in place (this will generate them) > https://github.com/CarlFK/veyepar/blob/master/dj/scripts/run_tests.py#L112-L179 > > There is code that uses template.mlt to create each_talk_slug.mlt which gets > passed to this webm encode line: > https://github.com/CarlFK/veyepar/blob/master/dj/scripts/enc.py#L405-L417 You really really really want to use bs1770gain. BS.1770 is an ITU standard on loudness. The intricate details of that standard are extremely complicated (it turns out that it's very difficult to define what exactly it means for something to be "loud"), but the good news is that the author of bs1770gain understands those intricate details, and you can just call it on any media file with '-a' (for "automatically do the right thing") and '-o' (for "output here"), and it generates a second version of the same file in the directory you pass it with -o, which contains the same audio at appropriate loudness. The result of all that is that you have a video file which, if you play it back on a TV set, will sound "just right" to people who've already set their TV to a correct value. Even if you don't do multi-pass video, you should in theory be able to just call bs1770gain on the output of your video transcoding, which will DTRT on your stuff. > 3. I should add back in the hook that lets people do their own encode > commands > without modifying enc.py. I had this years ago, but for some reason commented > it out. > > script hook: > https://github.com/CarlFK/veyepar/blob/master/dj/scripts/enc.py#L528-L533 > > But if 1 and 2 get addressed, then no need for it and it can linger on in > limbo. It's always nice to have such hooks. You have your opinion, but I have mine, and maybe we disagree on what the best way to encode is. Having the ability to customize encoding is always nice. -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12 _______________________________________________ Debconf-video mailing list [email protected] http://lists.debconf.org/mailman/listinfo/debconf-video
