[Ffmpeg-devel-irc] ffmpeg.log.20160709

[burek]

[00:22:45 CEST] <corw> Hi to all
[00:23:50 CEST] <corw> I'd like to find, in a movie, where there are changes in audio level, e.g. when a dialog starts
[00:24:40 CEST] <Kadigan> corw: if Your goal is to normalize the volume, there are playback plugins to do that, and You can easily roll Your own based on reported playback volume alone.
[00:25:24 CEST] <corw> Kadigan: my goal is to sync subtitles
[00:25:45 CEST] <Kadigan> Ah. How would You recognize speech as opposed to, say, loud noises?
[00:26:38 CEST] <Kadigan> Unless You could specify "general area" pointers where the text "should be", and then use this audio analysis to sync them up "almost perfectly".
[00:28:25 CEST] <corw> Kadigan: yes that's a problem, but I need to determine the delay of a srt file
[00:28:44 CEST] <Kadigan> The delay of ALL subtitles in the file?
[00:28:57 CEST] <Kadigan> (ie. the subtitle offset)
[00:30:05 CEST] <Kadigan> Please take a look at http://subshifter.bitsnbites.eu/ <-- You can use this tool to recalculate all SRT subtitle points based on a constant shift (eg. all subtitles 2s late)
[00:30:17 CEST] <corw> Kadigan: well I suppose that if I know the delay that I must use for one dialog (-subdelay in mencoder) that will be the same for the other dialogs
[00:30:29 CEST] <Kadigan> You can also use that tool to correct for overall length.
[00:30:40 CEST] <Kadigan> As for determining this - does this have to be automatic?
[00:32:13 CEST] <Kadigan> If it does, You may have to learn to implement VAD (Voice Activity Detection), which is non-trivial.
[00:32:29 CEST] <corw> Kadigan: what I'd like to determine is the "2s" of your example
[00:32:38 CEST] <Kadigan> Yes, I understand. Does it have to be automatic?
[00:33:02 CEST] <corw> Kadigan: I don't need a complete automatic process,
[00:33:42 CEST] <Kadigan> Then perhaps You can determine that by hand?
[00:33:57 CEST] <Kadigan> ie. manually, by watching, listening and calculating the difference.
[00:34:37 CEST] <corw> Kadigan: I did that in the past, but it's annoying and imprecise
[00:35:33 CEST] <Kadigan> I do not know how to help You. This detection You're looking for would provide You with MANY false-positives, so Your "manual" precision would still be better.
[00:39:01 CEST] <corw> Kadigan: I'd like something like showwaves but with a text output, every frame, like ffprobe
[00:39:41 CEST] <Kadigan> I'm sorry, I do not know how to help You.
[00:39:59 CEST] <corw> Kadigan: thx anyway
[01:03:35 CEST] <ZarfMouse> I'm curious what the etiquette on editing the wiki is? I see that anyone can edit it and I'd like to add info about compiling in libspeex support because that was missing from the compile guide I used: https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu
[01:03:50 CEST] <ZarfMouse> Would it ruffle any feathers if I edited that page to add that info in the same format as the other codecs?
[01:08:34 CEST] <CFS-MP3> I'll never understand people who ask a question and leave just because one person in the channel says I can't help you
[01:08:44 CEST] <CFS-MP3> I could have helped corw...
[01:09:09 CEST] <Kadigan> Can You explain Your solution? I'm curious.
[01:09:21 CEST] <Kadigan> (and yeah, I didn't say it was impossible)
[01:44:24 CEST] <dystopia> ffmpeg has started hanging since the last zeranoe builds
[01:44:35 CEST] <dystopia> had 3 hangs up now, can't close command window
[01:44:43 CEST] <dystopia> have to end the process in task manager :|
[02:34:36 CEST] <CFS-MP3> Kadigan sorry, just read that. I'm the developer of CCExtractor (an open source subtitle tool)... it's quite a niche tool I guess, but it's got some advanced users
[02:35:27 CEST] <CFS-MP3> the linguist department at UCLA spent a lot of time on correcting transcript delays in news casts (where delays are always present since there's someone actually typing audio)
[02:35:52 CEST] <CFS-MP3> they do have close to perfect lip sync already
[02:36:03 CEST] <Kadigan> Yeah, makes sense. I mean, there should be SOME delay due to conversion and buffering... real-time isn't really real-time is it.
[02:36:25 CEST] <Kadigan> That should allow for a short gap (a few seconds maybe) to insert stuff into the stream at the last minute, resyncing it.
[02:37:24 CEST] <CFS-MP3> if you enable captions in the news you'll see that the text appears a few seconds after the audio (which itself is live, of course minus buffering and transmissions, but those also apply to the captions themselves so for practical purposes they cancel each other out)
[02:38:12 CEST] <CFS-MP3> anyway, at UCLA and other universities they store all the news from lots of TV stations... and they bother sync'ing text and audio for their archives
[02:38:40 CEST] <Kadigan> I can't really relate, for three reasons: a) I don't live in the US, so I don't know about news CC, b) even if I did, I threw my TV out the window, and c) I mostly deal with production of planned/programmed stuff that's never real-time. :)
[02:38:56 CEST] <CFS-MP3> a couple of PHDs spent their summer last year (for google summer of code) on that
[02:39:04 CEST] <Kadigan> CFS-MP3: "and they bother" -- that's a good thing, actually.
[02:39:50 CEST] <luc4> Hello! After switching to ffmpeg 3 I started to get this http://pastebin.com/W1uZfGbU when trying to build my application. Any idea why?
[02:40:31 CEST] <Kadigan> luc4: it looks as though You need to update Your dependency headers...?
[02:41:21 CEST] <luc4> Kadigan: mmh& do you mean Im building my app on the new version while still using the old headers?
[02:42:21 CEST] <Kadigan> Either that, or using old libs w/ new headers. It's the linker (ld) that's borking out.
[02:42:56 CEST] <luc4> Kadigan: mmh& no, I dont think so. The headers are new and the libs was just built.
[02:45:06 CEST] <Kadigan> Google so far only notes one other(?) user having this issue, Wanghong Lin.
[02:45:26 CEST] <luc4> Kadigan: yes, but it seems to fail building ffmpeg.
[02:45:38 CEST] <luc4> Kadigan: my build succeeds, it is my app that wont link.
[02:46:04 CEST] <luc4> Kadigan: I suspect the build is wrong: nm reports ff_put_vc1_chroma_mc8_neon to be undefined.
[02:46:24 CEST] <luc4> Kadigan: question is: why isnt that defined in the library?
[02:47:57 CEST] <Kadigan> Okay, my natural knee-jerk reaction is to explicitly verify that my env isn't doing some weird caching, and that I didn't in fact copy any headers/references for editing purposes.
[02:48:23 CEST] <Kadigan> Failing that, it's possible the latest is borked (it happens). I am unable to help You, then.
[02:49:11 CEST] <luc4> Kadigan: Im not sure I understand sorry.
[02:49:30 CEST] <luc4> Kadigan: the symbol results undefined. Is that normal?
[02:49:51 CEST] <Kadigan> I honestly don't know.
[02:50:06 CEST] <furq> http://www.ffmpeg.org/doxygen/trunk/vc1dsp__init__neon_8c_source.html
[02:50:11 CEST] <furq> i'm not going to lie, i have no idea what's going on here
[02:50:22 CEST] <furq> but that hasn't changed since 2.x
[02:51:50 CEST] <luc4> furq: I only see a declaration there.
[02:52:05 CEST] <furq> it doesn't show up anywhere else on doxygen
[02:52:23 CEST] <furq> maybe it's being defined by a macro somewhere
[02:52:32 CEST] <luc4> furq: even grep wont find it.
[02:52:54 CEST] <furq> you could maybe work around it by building ffmpeg with --disable-decoder=vc1
[02:53:04 CEST] <furq> assuming you don't need a vc1 decoder obviously
[02:53:15 CEST] <luc4> furq: in fact I dont probably need it.
[02:53:24 CEST] <luc4> furq: but& this is weird...
[02:53:49 CEST] <furq> if you're sure there's nothing wrong with your build environment then maybe report it as a bug
[02:53:53 CEST] <luc4> furq: the same configure line has been working for months/years, so something must have changed...
[02:54:38 CEST] <furq> is this happening with 3.1 or with git master
[02:54:46 CEST] <luc4> furq: my build env is very complex, and my configure line is pretty long, so it is likely something is wrong& however that symbol occurs only there according to grep and the definition is missing...
[02:55:19 CEST] <luc4> furq: I dont know, Im using 3.1 tag
[02:55:46 CEST] <Kadigan> luc4 You may want to search globally for ff_pub_vc1_chroma_mc followed by a number.
[02:56:02 CEST] <Kadigan> This thing gets assigned by overload, if I'm not mistaken, and it's calculated on the fly.
[02:56:18 CEST] <Kadigan> (which makes me believe it may also be DEFINED on-the-fly)
[02:56:32 CEST] <Kadigan> put*
[02:56:32 CEST] <luc4> Kadigan: likely, I see something like that below
[02:56:46 CEST] <luc4> Kadigan: and also 2.8 reports exactly the same occurrences.
[02:56:57 CEST] <luc4> Kadigan: and 2.8 was working properly
[02:57:15 CEST] <Kadigan> It may also be that some dependency was moved out of ffmpeg.
[02:57:39 CEST] <Kadigan> Unfortunately, I do not have the knowledge to dig any deeper.
[02:57:44 CEST] <Kadigan> I can't help more, sorry.
[02:57:53 CEST] <furq> does ffmpeg compile or is it just your app which won't link
[02:58:01 CEST] <luc4> Kadigan: it happened in the past that some symbol was moved to some encoder/decoder that I was disabling. The result was pretty similar.
[02:58:24 CEST] <luc4> furq: ffmpeg is ok, the symbol is undefined in the static lib and my app wont link
[03:01:02 CEST] <furq> http://vpaste.net/X6Tru
[03:01:17 CEST] <furq> that's from 3.1.1
[03:02:03 CEST] <Kadigan> Okay, one final thought: can that be an export YOU need to define as per the API? ie. a user-side function?
[03:02:20 CEST] <luc4> furq: yes, that is problem probably
[03:02:29 CEST] <Kadigan> Never used those, but I know they exist... Though typically they are also explicitly assigned by the developer and there are defaults in place as well... Usually...
[03:02:30 CEST] <luc4> furq: I only have two undefined
[03:03:01 CEST] <luc4> Kadigan: the neon optimized functions?
[03:03:26 CEST] <luc4> Kadigan: I should define those functions while my app may not even use vc1?
[03:03:38 CEST] <furq> http://vpaste.net/olic3
[03:03:41 CEST] <furq> in case that helps
[03:03:57 CEST] <Kadigan> I have no idea. But in case You are compiling against vc1, You may have to.
[03:04:01 CEST] <luc4> furq: unfortuantely my configure line is veeery long
[03:04:06 CEST] <furq> yeah
[03:04:18 CEST] <Kadigan> A stop-gap would be to disable vc1...
[03:05:11 CEST] <luc4> Kadigan: Ill disable vc1 but I strongly suspect those symbols were moved in a place that I disabled in my configure line.
[03:05:28 CEST] <Kadigan> It's possible. Do You absolutely need the latest ffmpeg?
[03:05:59 CEST] <luc4> Kadigan: Im bumping to keep up to date with updates.
[03:06:41 CEST] <Kadigan> What I would do would be: I would revert to previous ffmpeg and keep asking on the forum/on IRC.
[03:06:41 CEST] <luc4> Kadigan: so, yes, to accomplish my test I need that. But this task is not strictly needed actually.
[03:07:03 CEST] <furq> time for a good old-fashioned configure binary search
[03:07:51 CEST] <furq> or yeah just disable vc1
[03:08:04 CEST] <luc4> lets disable vc1
[03:08:09 CEST] <luc4> and see what happens
[03:08:13 CEST] <luc4> thanks for the suggestion
[06:36:33 CEST] <Prelude2004c> hey guys.. good evening... Stream #0:0: Video: rawvideo (UYVY / 0x59565955), uyvy422, 720x486, 59.94 fps, 59.94 tbr, 60k tbn, 60k tbc .. That is my input... trying go use NVENC to convert it but... it keeps saying [nvenc @ 0x11aade0] No NVENC capable devices found
[06:36:43 CEST] <Prelude2004c> does this mean that my input pixel format is not supported or something
[06:36:47 CEST] <Prelude2004c> anything i can do to try and fix it ?
[07:53:31 CEST] <Prelude2004c> hey guys.. anyone know where i can find seanbright ?
[11:46:39 CEST] <luc4> Hello! Already asked this hours ago but Im still unable to solve. Im updating ffmpeg to 3.1 in my application and Im now getting this error: http://pastebin.com/W1uZfGbU. My assumption is that my configure line is disabling something that prevents the introduction of this symbol. Anyone who knows what I should enable to have it defined?
[11:54:34 CEST] <furq> luc4: what's your configure line
[11:57:04 CEST] <luc4> furq: http://pastebin.com/zz0c9wBx
[11:58:28 CEST] <luc4> furq: removing vc1 does not seem to help
[12:01:02 CEST] <luc4> furq: this is pretty weird: http://pastebin.com/Sjhw28zk
[12:01:41 CEST] <furq> fwiw it looks like those symbols are defined in libavcodec/arm/h264cmc_neon.S
[12:02:04 CEST] <furq> i don't see any reason why that wouldn't be working though
[12:02:30 CEST] <luc4> furq: Im wondering why those symbols get defined since I disabled vc1...
[12:04:49 CEST] <furq> did you run make distclean before rebuilding
[12:05:06 CEST] <luc4> furq: I completely removed the directory, including the sources.
[12:05:13 CEST] <furq> fun
[12:05:39 CEST] <luc4> furq: my scripts clones the repo, configures and builds. I do this every time.
[12:08:40 CEST] <furq> oh nice
[12:08:53 CEST] <furq> i just rebuilt with --disable-decoder=vc1 and now ffmpeg fails to link
[12:12:45 CEST] <ubitux> you know you can --disable-everything and then enable just what you need?
[12:13:30 CEST] <ubitux> also, --enable-pthreads --enable-armv5te --enable-neon --enable-armv6t2 --enable-armv6 looks unecessary at best
[12:13:37 CEST] <furq> and --arch=armv7a
[12:15:33 CEST] <aditsu> hi, I want to add a fade out effect to a clip; if I do it directly, it works, but since it has to reencode the whole thing, the quality is affected a bit
[12:15:51 CEST] <aditsu> I tried to cut it, apply the fade only to the end part and the concat
[12:16:23 CEST] <aditsu> but then it said "Non-monotonous DTS in output stream", and the end part is all black
[12:16:48 CEST] <aditsu> I meant "the*n* concat"
[12:17:01 CEST] <BtbN> you have to encode with compatible codec parameters if you want to concat without re-encoding.
[12:17:25 CEST] <BtbN> so, same resolution, same codec obviously, same profile, level, and probably some other stuff
[12:17:30 CEST] <aditsu> the clip is mp4 with h264 and aac; I reencoded video with libx264
[12:18:05 CEST] <aditsu> I'm not sure what additional parameters it needs to be compatible
[12:19:19 CEST] <luc4> ubitux, furq: I prefer to keep the configure line like it is because it comes from another software and I integrate the changes. I keep the changes to a minimum.
[12:19:32 CEST] <luc4> unless there is something wrong of course
[12:19:43 CEST] <aditsu> (reencoded the fading part, that is)
[12:20:01 CEST] <BtbN> Also, try using mpeg-ts instead of mp4 for concating.
[12:21:57 CEST] <aditsu> I used "-f concat"
[12:22:39 CEST] <furq> well yeah
[12:22:45 CEST] <furq> http://vpaste.net/vIP4R
[12:22:52 CEST] <furq> that happens while linking ffmpeg_g
[12:22:58 CEST] <furq> so i guess there's a bug somewhere
[12:23:41 CEST] <luc4> furq: yes that is what I found online. But not happening with my configure line.
[12:24:01 CEST] <luc4> furq: very weird
[12:24:05 CEST] <furq> not happening?
[12:24:28 CEST] <luc4> furq: no, ffmpeg libraries are properly built. It is my app that fails linking.
[12:24:32 CEST] <furq> oh
[12:24:35 CEST] <luc4> properly"
[12:24:41 CEST] <furq> your configure line has --disable-programs
[12:24:43 CEST] <luc4> in the sense that the symbol is missing
[12:25:04 CEST] <furq> it's failing when it tries to link ffmpeg_g, which you're not doing
[12:25:31 CEST] <luc4> furq: yes, you are right
[12:25:38 CEST] <luc4> furq: this is explained
[12:26:51 CEST] <furq> let me try it with git master
[12:28:52 CEST] <luc4> furq: so this problem is exactly the same of that message online
[12:29:17 CEST] <furq> well it works fine for me without --disable-decoder=vc1
[12:29:30 CEST] <furq> but it seems like the same thing is causing both those issues
[12:31:44 CEST] <furq> yeah, same thing with git master
[12:38:58 CEST] <luc4> furq: Ill try again cause it keeps failing here. I probably did something wrong.
[12:47:54 CEST] <furq> luc4: fwiw it works with --disable-decoder=vc1 --disable-demuxer=vc1 --disable-muxer=vc1 --disable-parser=vc1
[12:49:46 CEST] <luc4> furq: is it also a muxer?
[12:49:54 CEST] <furq> apparently
[12:50:42 CEST] <luc4> furq: so the problem is probably that I need the muxers and demuxers but I dont need the decoder, as I have hardware decoder for vc1
[12:51:32 CEST] <furq> were you always building with --disable-decoder=vc1
[12:53:45 CEST] <luc4> furq: actually no: https://github.com/carlonluca/pi/blob/master/piomxtextures_tools/compile_ffmpeg.sh
[12:54:00 CEST] <luc4> furq: I disabled when I saw the errors
[15:46:43 CEST] <dystopia> anyone else having random crashes with latest ffmpeg?
[15:48:19 CEST] <JEEB> is FATE red?
[15:48:34 CEST] <JEEB> http://fatebeta.ffmpeg.org/
[15:59:20 CEST] <Navion> Does anyone know of a utility that can take an AAC stream and convert it to MP3? I have a streaming server out in the net and I want to send a single stream to it and be able to encode streams for AAC and MP3.
[16:01:47 CEST] <dystopia> besweet can do it
[16:06:06 CEST] <Navion> dystopia: Do you know where the home page is for besweet?
[16:09:20 CEST] <JEEB> uhh
[16:09:24 CEST] <JEEB> besweet, sure is something old
[16:09:55 CEST] <JEEB> Navion: you can do that just fine with FFmpeg as well, just build with LAME for mp3 encoding
[16:10:30 CEST] <JEEB> ffmpeg -i that_aac_stream.aac -c:a liblamemp3 (I think that's how it's called) <further parameters> out.mp3
[16:15:23 CEST] <Navion> So I need to send an Icecast encoded AAC stream to <something> at the remote server site, transcode it to MP3 and send both the AAC and MP3 encoded streams to an Icecast server. I can't do this as a file conversion. It's got to be something like pipes.
[16:15:50 CEST] <JEEB> well icecast is HTTP input for ffmpeg, no?
[16:16:03 CEST] <JEEB> then you push that to a streaming server as MP3 bit stream
[16:16:16 CEST] <JEEB> you can do HTTP input and HTTP post output towards a streaming server
[16:16:23 CEST] <JEEB> why not the same icecast for example?
[16:17:07 CEST] <JEEB> also please do not send private messages to me unless you especially have a reason for it (specifically relating to me)
[16:18:19 CEST] <Kadigan_KSB> (for the record, it's libmp3lame IIRC)
[16:18:46 CEST] <Navion> Jeeb: Sorry I misread something. I thought you had sent me a private message and I was replying but upon further close inspection it was just tagged to me. Sorry.
[16:23:19 CEST] <Navion> Right now I have a stream encoder at the radio station that makes an AAC and an MP3 stream and sends it to the streaming server. We're changing server locations and the new guys only want a single incoming stream. They're fine with whatever outgoing streams we want. I've actually got a couple different service software instances on the same computer that I need to feed. Add to that, I'm not a streaming wizard.
[16:26:17 CEST] <Navion> Will ffmpeg do transrate as well as transcode? I wanna send a really good AAC stream and step the rate down at the server for mobile devices.
[16:42:07 CEST] <Zelmo> Hi. I have problems with ffmpeg. I have a m3u8 link which contains lots of .vtt files. I use ffmpeg.exe -v 9 -loglevel 99 -sub_charenc CP1252 -i "link" "episode.srt" --> but this doesnt use the right charset... å-æ-ø is not showing correctly , and there is a few "duplicates"... the duplicates are fine, but is there a way to make it rip right charset?
[16:44:58 CEST] <obelisk29> [pcm_s24be @ 0x2afcf80] Invalid PCM packet, data has size 32 but at least a size of 48 was expected
[16:44:58 CEST] <obelisk29> Error while decoding stream #0:0: Invalid data found when processing input
[16:45:35 CEST] <obelisk29> Is there anyway to have ffmpeg continue processing the file? even though that occured?
[16:47:56 CEST] <obelisk29_> Sorry I got disconnected if anybody responded
[20:46:28 CEST] <obelisk29> When I try to mux h264 and flac together into a .mov file I get this error "Using MS style audio codec tag, the file may be unplayable!" any idea on howto solve?
[20:46:39 CEST] <obelisk29> alac works fine though.
[20:49:44 CEST] <BtbN> mp4 does not support flac i guess
[20:52:04 CEST] <obelisk29> its .mov
[20:52:49 CEST] <obelisk29> I would have guessed someone would have used h264 and flac together..
[20:52:52 CEST] <obelisk29> so puzzling
[20:53:16 CEST] <BtbN> same thing.
[20:53:51 CEST] <c_14> mov supports alac and mpeg4-als
[20:53:57 CEST] <c_14> And maybe pcm
[20:55:11 CEST] <obelisk29> which container supports flac and h264?
[20:56:27 CEST] <BtbN> mkv I'd guess
[20:56:41 CEST] <BtbN> I'm quite sure I heard about flac in mkv before.
[20:56:55 CEST] <obelisk29> mkv supports almost anything i think
[20:57:12 CEST] <obelisk29> unfortunately premiere doesn't support mkv =(
[20:57:22 CEST] <BtbN> Does it support flac?
[20:57:27 CEST] <obelisk29> yes
[20:57:31 CEST] <BtbN> In which container?
[20:57:41 CEST] <obelisk29> cant find that out
[20:58:09 CEST] <BtbN> Have you tried using mp4 instead of mov? It's essentialy the same thing, just with diffrent restrictions.
[20:58:36 CEST] <obelisk29> yes it doesnt work
[20:59:13 CEST] <obelisk29> wont even encode, mov will encode but wont play audio stream
[21:00:18 CEST] <BtbN> Wikipedia lists FLAC as supported in "QuickTime", which seems to mean mov
[21:01:11 CEST] <obelisk29> Yes I saw that, which gave me hope. ffmpeg does encode it it just puts the wrong style audio tag on it. Thats why I thought there may be an easy fix.
[21:02:07 CEST] <JEEB> if you are going to be loading it into an editor then just use raw PCM instead of FLAC
[21:02:26 CEST] <JEEB> for lossless video just use ut video and install the VFW component on your editing machine
[21:02:29 CEST] <BtbN> flac in mov should indeed work. Are you using latest ffmpeg master?
[21:02:49 CEST] <JEEB> flac in mov sounds like something that nothing supports except for libavformat :P
[21:02:57 CEST] <JEEB> unless you have a custom QT component for it
[21:03:02 CEST] <ritsuka> you need a third party plugin to play flac in QT
[21:03:08 CEST] <JEEB> ^this
[21:03:09 CEST] <obelisk29> source audio is pcm and it works i was just trying to get a little more compression but still have it lossless
[21:03:19 CEST] <ritsuka> there was a xiph qt plugin some years ago, I don't know if it still exists
[21:03:21 CEST] <JEEB> then don't use AVC because no editor supports lossless AVC
[21:03:36 CEST] <JEEB> video wise that is
[21:04:14 CEST] <JEEB> just give up on the miniscule savings you get from lossless audio compression and getting all those incompatibilities
[21:04:34 CEST] <JEEB> for stereo it's like 1.5mbps?
[21:04:40 CEST] <JEEB> 16bit 48kHz
[21:04:43 CEST] <obelisk29> 2308kbps
[21:04:55 CEST] <obelisk29> 24 bit pcm
[21:05:01 CEST] <JEEB> yeah, 24bit is bigger of course
[21:05:34 CEST] <JEEB> but still, that's still probably at least 1/10 of the video bit rate
[21:05:39 CEST] <JEEB> if it's lossless
[21:06:01 CEST] <obelisk29> i just have a LOT of really long HD captures in prores so any savings make a big difference
[21:06:36 CEST] <obelisk29> 3.8 gb vs 2.2 gb of audio on one file
[21:06:48 CEST] <JEEB> well, then you would have to give up on using that file as source for editing as-is
[21:06:52 CEST] <JEEB> which is a bigger thing for you?
[21:07:58 CEST] <obelisk29> I just run the storage machine and try to keep our editors happy =)
[21:08:23 CEST] <JEEB> well then you don't want to make them decode the audio every time they grab the file for editing, right?
[21:08:31 CEST] <obelisk29> Yes
[21:08:41 CEST] <JEEB> just buy more disks then :/
[21:08:53 CEST] <JEEB> no payware editor supports what you want to do
[21:09:03 CEST] <JEEB> (ffv1 or lossless AVC with FLAC or so)
[21:09:12 CEST] <obelisk29> h.264 works fine in premiere, are you saying flac or alac would have to be processed.
[21:09:22 CEST] <JEEB> yes, *lossy* AVC works
[21:09:25 CEST] <JEEB> lossless doesn't
[21:09:27 CEST] <obelisk29> yes
[21:09:30 CEST] <obelisk29> its lossy
[21:09:46 CEST] <obelisk29> 216 gb on average down to 30
[21:10:07 CEST] <JEEB> so you are effectively making it pretty much impossible to make a re-edit of something
[21:10:34 CEST] <obelisk29> No they are telling me they can edit just fine on that
[21:10:35 CEST] <JEEB> depends on your CRF value but you're basically scrapping out information. not like prores is lossless to begin with of course, but it has lulzy bit rates
[21:10:51 CEST] <JEEB> well yes they can, but depending on how much you compress that stuff is worse than the source
[21:10:56 CEST] <JEEB> I just want you to understand that
[21:11:00 CEST] <obelisk29> They are just using the eye test of course
[21:11:07 CEST] <obelisk29> I understand
[21:11:34 CEST] <obelisk29> The goal is to edit off prores then once they're done convert to h264 for archival
[21:11:35 CEST] <JEEB> also I think QT used to have issues with AVC quantizer going under some value like 4 or so
[21:11:53 CEST] <obelisk29> and on the offchance they do need to edit something I guess they will take the quality hit
[21:11:57 CEST] <JEEB> yes
[21:12:08 CEST] <JEEB> EU is trying to standardize ffv1+flac in matroska for archival
[21:12:15 CEST] <JEEB> I wonder if the corps will implement that
[21:12:16 CEST] <JEEB> lol
[21:13:05 CEST] <obelisk29> I've done screenshot comparison testing and it's pretty darn good. Do you know of any software video quality testers?
[21:13:13 CEST] <obelisk29> That would be awesome if they did
[21:13:32 CEST] <JEEB> no, eyes are still the best thing around. what were your settings for x264?
[21:13:47 CEST] <JEEB> with computers you can just get some sort of values like PSNR or SSIM etc
[21:14:04 CEST] <JEEB> those aren't always the same as visual quality
[21:14:24 CEST] <JEEB> although I guess if you have high enough limits those could be utilized
[21:14:47 CEST] <JEEB> PSNR for example is very easy to get good scores with by just blurring the result
[21:15:02 CEST] <obelisk29> -vcodec libx264 -crf 19 -preset slow \
[21:15:02 CEST] <obelisk29>                 -x264opts colorprim=bt709:transfer=bt709:colormatrix=bt709:fullrange=off \
[21:15:02 CEST] <obelisk29>                 -map 0:0 -map_metadata -1 \
[21:15:02 CEST] <obelisk29>                 ../cache/h264_video.mov
[21:17:41 CEST] <obelisk29> I still can't understand why premiere doesn't support mkv
[21:18:16 CEST] <JEEB> because it's a crazy nonstandard format. the EU people are having "real fun" trying to standardize the mess
[21:18:37 CEST] <JEEB> + since no enterprise used it for editing purposes
[21:18:58 CEST] <obelisk29> I guess when you support anything, anything goes...
[21:20:33 CEST] <JEEB> well it doesn't support anything any more than any other container. just that it doesn't have a clear thing on where things are defined
[21:21:07 CEST] <JEEB> I'm pretty sure my write-up on HEVC isn't anywhere else than the mailing list f.ex.
[21:21:09 CEST] <obelisk29> I'm also trying out hevc as an archive format. I'm currently encoding a file right now so our editors can test it. Any thoughts on that?
[21:21:11 CEST] <JEEB> https://lists.matroska.org/pipermail/matroska-devel/2013-September/004567.html
[21:21:24 CEST] <obelisk29> I know it uses a lot more cpu.
[21:21:27 CEST] <JEEB> obelisk29: not useful for your use case really and the encoders can be funky
[21:21:34 CEST] <JEEB> + slower to decode
[21:21:59 CEST] <JEEB> for archival I'd be using the stuff in lossless mode anyways, so ffv1 and x264 (and ut video for editing machines) would be my picks
[21:22:14 CEST] <obelisk29> maybe in the future then
[21:23:11 CEST] <obelisk29> how is mac support for ffv1 and ut video?
[21:23:36 CEST] <JEEB> ut video has a component from the original author
[21:23:38 CEST] <obelisk29> mac premiere specifically
[21:23:47 CEST] <JEEB> for QT which then most editors use
[21:24:12 CEST] <JEEB> thus it has become the lossless thing I see most people using for video editors on win/mac
[21:24:25 CEST] <obelisk29> I would have to find out if our capture software can output that.
[21:25:20 CEST] <JEEB> of course it's an editing format so compression ratios aren't exactly excellent
[21:25:26 CEST] <JEEB> but that's not what it was meant for
[21:25:35 CEST] <JEEB> it's a simple, fast lossless format
[21:26:05 CEST] <obelisk29> They are using movierecorder 3 to capture all the footage
[21:26:35 CEST] <obelisk29> is it worse compression then prores?
[21:26:46 CEST] <obelisk29> or no compression lol
[21:26:54 CEST] <JEEB> no compression is of course bigger
[21:27:09 CEST] <JEEB> it's got simple median prediction and then huffman coding
[21:27:28 CEST] <JEEB> size difference between it and prores depends, prores is pretty much slightly changed JPEG
[21:27:32 CEST] <JEEB> and of course lossy
[21:31:43 CEST] <obelisk29> movierecorder doesn't support it. It does have a codec listed us uncompressed which I'm not sure what that would be.
[21:32:18 CEST] <JEEB> it looks like yer standard QT using thing so I would guess it supports it if you install the QT component
[21:32:39 CEST] <obelisk29> I'll definitely try.
[21:32:40 CEST] <JEEB> uncompressed is either uncompressed YCbCr or RGB, the usual stuff
[21:32:57 CEST] <JEEB> for some reason enterprises only know lossless that is uncompressed
[21:34:01 CEST] <obelisk29> We have a 1080i 59.94 input format, if I capture that uncompressed could ffmpeg deinterlace lossless into a 1080p 29.97?
[21:34:05 CEST] <obelisk29> Or am I offbase?
[21:35:39 CEST] <JEEB> well compressed or uncompressed as long as it's hinted correctly you can deinterlace those fields into frames, yes
[21:36:45 CEST] <obelisk29> is it better to make that framerate stepdown for the deinterlacing or is keeping it at 59.94 going to produce the same result?
[21:37:15 CEST] <JEEB> depends on the content
[21:37:48 CEST] <JEEB> for actual interlaced content with actual separate fields in the fields the best results are gained from having each field become a frame after deinterlacing
[21:38:13 CEST] <JEEB> for progressive content coded interlaced you have stuff like field matching and possibly decimation
[21:41:16 CEST] <JEEB> usually deinterlacing that halves the rate is used to save resources on the encoding side that comes after that (unless it's actually progressive content coded interlaced)
[21:41:16 CEST] <obelisk29> gotcha, So I would have to make sure the capture machine is recording true interlaced not half-converting to progressive right?
[21:41:30 CEST] <JEEB> nah, you just have to know what sort of input you've got
[21:42:14 CEST] <JEEB> and if your input can actually be progressive in general that's almost always a better deal
[21:42:49 CEST] <obelisk29> Scan type                   : Interlaced
[21:42:49 CEST] <obelisk29> Original scan type          : Progressive
[21:42:49 CEST] <obelisk29> Scan type, store method     : Interleaved fields
[21:42:49 CEST] <obelisk29> Scan order                  : Top Field First
[21:43:11 CEST] <obelisk29> That's an example capture
[21:43:17 CEST] <JEEB> that doesn't really say anything about the actual content coded in there
[21:43:38 CEST] <obelisk29> How would I find that out?
[21:43:45 CEST] <JEEB> video formats generally only contain info on how something is coded, they don't take note on what is being coded
[21:44:00 CEST] <JEEB> by actually checking the video field by field
[21:44:06 CEST] <JEEB> short points here and there
[21:44:31 CEST] <JEEB> you can use avisynth or vapoursynth for that, among other things. although I think players such as mpv can in theory do that, too if you give them the correct filter chain
[21:44:57 CEST] <obelisk29> thx
[21:49:19 CEST] <obelisk29> http://avisynth.nl/index.php/Interlace_detection
[21:49:33 CEST] <obelisk29> Am I one the right track? I've never used avisynth
[21:49:46 CEST] <JEEB> no, don't try to do automagics
[21:49:51 CEST] <JEEB> that doesn't work with interlacism
[21:50:14 CEST] <JEEB> just load the thing up in avs or vapoursynth and do separatefields() in AvsPmod or vapoursynth editor
[21:50:31 CEST] <JEEB> then seek to a piece of motion
[21:50:43 CEST] <JEEB> and see if you get every field its own image, or two fields that form an image
[21:51:03 CEST] <JEEB> if it's the latter then you start seeing if there's a pattern of 1-2-3-4-5 or 1-2-3-4-4
[21:51:15 CEST] <JEEB> latter having one duplicate image
[21:51:43 CEST] <JEEB> which is usually used when coding 24/1.001 Hz content into 30/1.001Hz
[21:51:53 CEST] <JEEB> due to broadcast or whatever limitations
[21:52:06 CEST] <JEEB> after that you should have an idea of what you're dealing with
[21:52:18 CEST] <JEEB> and can apply required filters
[21:53:15 CEST] <zeeo> hello people
[21:53:31 CEST] <zeeo> i've got a problem encoding to vp8
[21:54:00 CEST] <zeeo> ffmpg seems to ignore my -crf option
[21:54:29 CEST] <JEEB> how FFmpeg maps the -crf option is different between libvpx and libx264
[21:54:40 CEST] <JEEB> also vp8 has special limits
[21:54:49 CEST] <JEEB> like requiring you to set a bit rate even though you're using CRF
[21:54:59 CEST] <JEEB> libvpx with vp9 doesn't require that
[21:55:00 CEST] <zeeo> i'm clueless. i get those ~256k default bitrate all the time
[21:55:46 CEST] <zeeo> oh. the bitrate requirement could be it. gonna check.
[21:57:10 CEST] <JEEB> but as I noted, even though FFmpeg decided to map the -crf command to something in libvpx that doesn't mean it's the same as crf with other encoders :)
[21:57:23 CEST] <JEEB> so don't expect similar results
[21:58:32 CEST] <zeeo> sure
[21:58:38 CEST] <zeeo> i can just set -b:v really high then, right?
[21:58:53 CEST] <JEEB> I would guess so, I only checked the libvpx wrapper code and WTF'd :P
[21:58:54 CEST] <zeeo> it seems to work.
[21:59:16 CEST] <JEEB> because I wondered why the heck official examples at google used both bit rate and "crf" at the same time
[21:59:30 CEST] <iongion> is there a way to mux multiple aac + h264 streams to a mp4 file and stream the bytes immediately as they get produced ? I mean, I do not want moov atom at the begging, I just want the fastest way to produce mp4 files without ffmpeg having to travel back and forth to construct the moov atom
[21:59:55 CEST] <zeeo> stupid requirement. also, i didn't get that from --help or manpage or all the webpages i checked.
[22:00:20 CEST] <c_14> zeeo: https://trac.ffmpeg.org/wiki/Encode/VP8
[22:00:55 CEST] <c_14> iongion: fragmented moov, check all the fragment_ flags in the manpage (most clients won't support fragmented moov though)
[22:01:30 CEST] <JEEB> I actually wonder how many things wouldn't support fragmented stuff now
[22:01:39 CEST] <JEEB> because DASH support pretty much requires it
[22:02:03 CEST] <JEEB> it doesn't but it means that if something supports DASH it's highly likely it supports fragmented ISOBMFF
[22:02:12 CEST] <iongion> c_14: but can it be placed last and thus removing the need for fragmented ?
[22:02:22 CEST] <JEEB> that's the default
[22:02:26 CEST] <JEEB> but you can't play the file right away
[22:02:32 CEST] <JEEB> because the moov isn't there
[22:02:40 CEST] <JEEB> since the file isn't finished yet :P
[22:02:40 CEST] <zeeo> c_14: been there. the following paragraph in there made me stumble:
[22:02:49 CEST] <zeeo> "If neither -b:v nor -crf are set, the encoder will use a low default bitrate and your result will probably look very bad. Always supply one of these optionsideally both."
[22:03:19 CEST] <iongion> but when I try to have ffmpeg mux and redirect output to a named pipe so I can pick bytes up with python, it complains that muxer dont support non-seekable output
[22:03:22 CEST] <c_14> They both have internal defaults, but they're very low.
[22:03:26 CEST] <JEEB> yeah, google changed how that option worked between vp8 and vp9 so for vp8 you need both and vp9 is separate :)
[22:03:42 CEST] <iongion> I do not want to play it, just to export it as fast as possible
[22:03:59 CEST] <JEEB> iongion: you're not using the faststart movflag, right?
[22:04:13 CEST] <zeeo> JEEB: from a quick look it seemed to be the same story for libvpx-vp9 for me...
[22:04:14 CEST] <JEEB> because otherwise it should be just leaving the moov in the back
[22:04:28 CEST] <JEEB> zeeo: that doesn't require the bit rate as far as I remember from the libavcodec wrapper
[22:04:52 CEST] <iongion> but then why does it complain that it cannot redirect output to a named pipe ? the muxer does not need to travel in the default case
[22:05:19 CEST] <JEEB> dunno, could be something within the mov/ISOBMFF muxer otherwise that wants seeking
[22:05:40 CEST] <JEEB> not moov in that case then, but something else where the thing is seemingly using seek
[22:06:02 CEST] <JEEB> the feature set I use with the muxer seems to be OK, though
[22:06:09 CEST] <JEEB> but I'm using fragments
[22:07:42 CEST] <ChocolateArmpits> iongion: use mpegts as muxer ?
[22:07:59 CEST] <iongion> yes
[22:08:49 CEST] <iongion> but then the file is not an mp4
[22:09:03 CEST] <DHE> mp4 must be written t a real file on disk. it is not stream-friendly at generation time
[22:09:23 CEST] <JEEB> uhh, then why am I being able to output to HTTP :P
[22:09:33 CEST] <DHE> really?
[22:09:35 CEST] <JEEB> I mean, ISOBMFF has limitations but seriously please don't say things that aren't true
[22:09:36 CEST] <ChocolateArmpits> You can do -f nut too, that will never complain
[22:10:00 CEST] <JEEB> DHE: yes really, I use it currently to produce stuff against other stuff
[22:10:01 CEST] <DHE> I thought the moov atom still needed to be updated...
[22:10:42 CEST] <JEEB> well, in my case it's fragmented but it's still ISOBMFF. and in theory you should be able to write ISOBMFF even without fragmentation A=>B
[22:10:43 CEST] <zeeo> well, no, doesn't seem to work at all. it only respects the -b:v option, it seems.
[22:10:53 CEST] <JEEB> zeeo: crf with libvpx is weird
[22:11:00 CEST] <JEEB> esp. with vp8
[22:11:10 CEST] <JEEB> also rate control in libvpx is notoriously bad, at least with vp9
[22:12:10 CEST] <JEEB> DHE: that said it seems like there could be an issue with the current movenc.c when not using fragments
[22:12:28 CEST] <JEEB> at least according to that guy saying that it complains when writing to a non-seekable output
[22:16:31 CEST] <zeeo> i get several megabits/sec with -crf 63 for a 400p video...
[22:16:50 CEST] <zeeo> unusable.
[22:17:13 CEST] <JEEB> it probably uses the bit rate more than the CRF then :P
[22:37:52 CEST] <obelisk29> JEEB ok so I separated the fields into vapoursynth, I'm not sure how to tell if every field has its own image or not and there is no discernible pattern in frames it's like 1 frame then next is duplicate then new frame then duplicate then new frame then duplicate but half of it is shearing then new frame newframe
[22:37:55 CEST] <obelisk29> so confused
[22:38:16 CEST] <JEEB> just get some actual movement going
[22:38:25 CEST] <JEEB> as in, seek to a place where there's movement
[22:38:46 CEST] <JEEB> then after you've separated the fields you seek through it and see whether the fields are part of a single picture that's in two
[22:38:54 CEST] <JEEB> or if every field is its own picture
[22:38:58 CEST] <JEEB> it should be pretty obvious
[22:39:12 CEST] <obelisk29> the whole thing has motion
[22:40:04 CEST] <JEEB> then it should be simple to see which of those two cases is true :P
[22:40:26 CEST] <obelisk29> every frame is taking up the upper portion of the window
[22:40:29 CEST] <obelisk29> its halved
[22:40:33 CEST] <obelisk29> and fps has doubled
[22:41:00 CEST] <obelisk29> 1920x540
[22:41:01 CEST] <JEEB> yes, since a field is half the height of a frame (has every second line)
[22:41:22 CEST] <JEEB> actual interlaced content has those fields be taken at different times which should be obvious when you seek through them
[22:41:47 CEST] <JEEB> so you have clearly two different images between two fields in actual interlaced content that has movement
[22:42:02 CEST] <obelisk29> yes
[22:42:29 CEST] <obelisk29> except when they are exact duplicate copies
[22:42:41 CEST] <obelisk29> which is very often when i step through frame by frame
[22:42:59 CEST] <JEEB> that only happens when there's no movement or when there's telecine going on
[22:43:30 CEST] <JEEB> so if you start having stuff like same image but one line up/down kind of effect that means that it seems like progressive images are being encoded as interlaced
[22:43:50 CEST] <JEEB> instead of having two completely different images between two fields
[22:45:01 CEST] <obelisk29> whats the best case for converting to 1080p from 1080i 59.94?
[22:45:11 CEST] <obelisk29> straight interlacing
[22:45:23 CEST] <obelisk29> so every frame is half the other one?
[22:45:38 CEST] <obelisk29> So it can combine them perfectly into one frame?
[22:46:07 CEST] <JEEB> yes, that's called telecine, where you code two parts of a single progressive image into two fields
[22:46:22 CEST] <JEEB> then you fieldmatch those together instead of doing dumb deinterlacing
[22:46:37 CEST] <JEEB> that's why it's important to look at your stuff instead of just applying a deinterlacer ;)
[22:47:02 CEST] <zeeo> 2-pass encoding seems to be unavoidable for reasonable control over target bitrate with vp8/9 if you don't want to nail it to cbr
[22:47:21 CEST] <JEEB> zeeo: and expect issues with the rate control anyways
[22:47:34 CEST] <JEEB> 'tube has o9k wrappers around it to make it work for them
[22:48:35 CEST] <JEEB> I just hope that with the AM1 project some people will care to fix it
[22:48:41 CEST] <JEEB> or was it AV1
[22:48:41 CEST] <obelisk29> Thx so much for your help
[22:48:57 CEST] <JEEB> obelisk29: anyways for progressive content you just want to keep it progressive all the way :P
[22:49:05 CEST] <JEEB> instead of making it interlaced at some point
[22:49:08 CEST] <JEEB> less of a headache
[22:49:37 CEST] <obelisk29> Yes half our cameras can only output 1080i =)
[22:49:45 CEST] <obelisk29> Waiting for them to upgrade
[22:50:12 CEST] <ChocolateArmpits> They should output 25p too as that's per standard
[22:50:57 CEST] <ChocolateArmpits> or 30p if you're in the States
[22:51:09 CEST] <Navion> Jeeb: Do you know where I can find people that have used Liquidsoap? It seems like a streaming transcoder is part of that package.
[22:51:10 CEST] <obelisk29> I was about to say isn't that a pal format?
[22:51:18 CEST] <obelisk29> ;)
[22:51:28 CEST] <JEEB> Navion: no idea whatsoever :P
[22:51:42 CEST] <Navion> Jeeb: Pooh!
[22:51:45 CEST] <JEEB> Navion: also if you had that question about audio rate change, yes FFmpeg can do that too
[22:51:54 CEST] <JEEB> ffmpeg cli has -ar for that
[22:51:59 CEST] <JEEB> -ar 22050 etc
[22:54:24 CEST] <Navion> Jeeb: I think Liquidsoap probably uses ffmpeg to do the work but they have built all the shimware to get a stream and re-stream it. Easier than writing a bunch of stuff from scratch.
[22:54:58 CEST] <JEEB> ok, I can't say anything about 3rd party solutions
[00:00:00 CEST] --- Sun Jul 10 2016