Re: [Debconf-video] One proposal about debconf16 videos
On Tue, Jul 26, 2016 at 08:40:20AM -0500, Carl Karsten wrote:
>
>
> On Tue, Jul 26, 2016 at 2:01 AM, Wouter Verhelst <w@uter.be> 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
Reply to: