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

[burek]

[00:00:42 CET] <deweydb> no?
[00:00:46 CET] <deweydb> trying now with that.
[00:00:48 CET] <deweydb> its hella slow
[00:00:58 CET] <deweydb> or maybe just hanging.
[00:01:02 CET] <deweydb> oh.. nope. just REALLY slow
[00:01:04 CET] <c_14> it's slow
[00:01:26 CET] <deweydb> ok now i have a param: "nb_read_frames": "2071" ?
[00:01:33 CET] <c_14> yep
[00:02:07 CET] <deweydb> heh this is going to change my whole design. lol. i was being lazy and calling that metadata command frequently without caching cause it was fast.
[00:02:28 CET] <deweydb> thanks for your help man!
[01:13:21 CET] <deweydb> c_14 if you're still around can you help me understand what i'm doing wrong here: http://pastebin.com/x1aDHw2g
[01:13:29 CET] <deweydb> i'm trying to extract some I frames from a video
[01:14:01 CET] <deweydb> i know that the video is roughly 70 seconds long, so a start time of 7.67 and a duration of 4seconds should be ok.
[01:14:10 CET] <deweydb> maybe this type of video doesn't have I frames?
[01:19:15 CET] <c_14> Not sure, never had that issue. You can check if there are any i-frames around that point with ffprobe -v quiet -show_entries frame=pict_type,pkt_pts_time -select_streams v -count_frames -of flat file | grep -B1 I
[01:19:38 CET] <deweydb> i have expanded the timeframe from -ss 0 -t 69
[01:19:43 CET] <deweydb> and still get 0 results
[01:19:57 CET] <deweydb> but i'll take a look at the whole file with ffprobe
[01:19:58 CET] <deweydb> sec
[01:21:26 CET] <deweydb> yeah, the command you just gave me gave me 0 results. is it possible for a video to have no I frames?
[01:22:15 CET] <c_14> yes and no; In your specific case, yes.
[01:22:56 CET] <c_14> If you want the video to be playable, it needs an i-frame somewhere (or intra-refresh or something) but you can cut a video so that the resulting file does not have any i-frames
[01:23:01 CET] <deweydb> file in question: https://usercontent.bid13.com/original_videos/v/t/vtCBJR6ekJjNs4JsgzgAFZSjOMFCtITIfYdD5pugzB4.MTS
[01:23:24 CET] <deweydb> it plays fine in VLC
[01:23:41 CET] <deweydb> not the greatest camera work, but otherwise, plays fine.
[01:24:22 CET] <c_14> just downloaded the file
[01:24:25 CET] <c_14> plenty of i-frames
[01:24:58 CET] <deweydb> you get results from that command?
[01:24:59 CET] <deweydb> ffprobe -v quiet -show_entries frame=pict_type,pkt_pts_time -select_streams v -count_frames -of flat /var/www/usercontent.bid13.com/original_videos/v/t/vtCBJR6ekJjNs4JsgzgAFZSjOMFCtITIfYdD5pugzB4.MTS | grep -B1 I
[01:26:18 CET] <c_14> yep
[01:26:26 CET] <c_14> And running the command in your pastebin also produces output
[01:26:34 CET] <deweydb> waaaaaat?
[01:26:35 CET] <c_14> (although it also prints the h264 warnings)
[01:26:39 CET] <deweydb> oh maybe ffmpeg version?
[01:26:44 CET] <c_14> could be
[01:26:53 CET] Action: c_14 is running git head from yesterday
[01:26:56 CET] <deweydb> ffmpeg version 2.8.6-1ubuntu2
[01:27:05 CET] <deweydb> im probably a bit out of date
[01:27:08 CET] <c_14> try a static build
[01:27:10 CET] <c_14> http://johnvansickle.com/ffmpeg/
[01:27:20 CET] <deweydb> i forget why, but i needed to compile
[01:27:25 CET] <deweydb> i think for opentype support
[01:27:41 CET] <deweydb> but let me try on my local and see if that makes a difference
[01:27:42 CET] <deweydb> super weird
[01:35:44 CET] <deweydb> yup, thsoe static builds get me I frames.
[01:35:46 CET] <deweydb> interesting.
[01:35:55 CET] <deweydb> but even latest from ubuntu repo does not.
[02:10:48 CET] <deweydb> is this guy: https://launchpad.net/~jonathonf/+archive/ubuntu/ffmpeg-3 in this channel?
[02:10:57 CET] <deweydb> can't for the life of me get this PPA to work
[02:11:08 CET] <deweydb> libavcodec-extra57 : Depends: libavutil55 (>= 7:3.2) but 7:3.2-0~16.04.york0 is to be installed
[03:46:16 CET] <Wiki61> I am trying to host a ts/udp stream on an html page, i have used ffmpeg in the past for simple stuff but am wondering if it would work for this project
[03:46:44 CET] <Wiki61> i am reading the wiki for streaming but not really seeing what I am looking for
[03:48:39 CET] <Wiki61> Or not even the html viewer, and just watch it with vlc
[07:59:39 CET] <k_sze[work]> wow
[07:59:49 CET] <k_sze[work]> there will be motion estimation in ffv1
[07:59:57 CET] <k_sze[work]> when is it landing in releases?
[08:00:15 CET] <k_sze[work]> Or is there a branch that I can play with?
[08:01:03 CET] <k_sze[work]> I wish the ffmpeg news page has links to the relevant branch or commit.
[08:02:45 CET] <k_sze[work]> It's a bit funny how the GSoC page implies that FFV1 is not competitive enough vs existing I+P frame lossless codecs.
[08:03:26 CET] <k_sze[work]> I think I have tested ffvhuff and huffyuv, both are horrible in terms of compression ratio, compared to ffv1.
[08:03:38 CET] <k_sze[work]> So I'm not sure where that claim comes from.
[08:03:54 CET] <k_sze[work]> libx264's lossless mode is also really bad.
[08:04:00 CET] <JEEB> yeah, those both are *very* simple while ffv1 is much less simple. what you'd generally be comparing ffv1 against would be libx264's lossless mode etc
[08:04:02 CET] <furq> x264 lossless seems pretty good
[08:04:16 CET] <furq> there are also plenty of other competitive lossless codecs
[08:04:46 CET] <JEEB> but in any case, ffv1 is nice, at least seems to be better than it was in late 2012/early 2013 when encoding was OK, but decoding was slow as hell
[08:05:07 CET] Action: JEEB decided to use ffv1 back then and then hit his head against the wall when trying to decode it
[08:05:26 CET] <JEEB> now it has multithreading and all that fancy stuff
[08:05:34 CET] <k_sze[work]> yes, it's fast now.
[08:05:35 CET] <furq> i remember x264 lossless being hopeless for decoding but it's better than ffv1 now
[08:05:48 CET] <k_sze[work]> We use it to archive some 16-bit grayscale stuff.
[08:06:08 CET] <JEEB> I don't remember x264 lossless ever being slow in decoding, like even in '07. the AVC decoder was always rather optimized so it never popped up
[08:06:19 CET] <furq> maybe it was just me
[08:06:38 CET] <JEEB> the primary thing was that people tended to forget to set shorter GOPs if they needed very quick seeking
[08:59:31 CET] <kerio> can x264 do grayscale?
[09:10:38 CET] <furq> doesn't look like it
[09:12:05 CET] <kerio> honestly lossless mjpeg2000 isn't even half bad
[09:15:09 CET] <flux> is it still patent-encumbered?
[09:15:33 CET] <flux> or is the lossless different from the normal jpeg2k
[09:20:28 CET] <kerio> idk
[09:20:50 CET] <kerio> matlab can write lossless mjpeg2000 tho :<
[09:21:15 CET] <kerio> which is good because every lossy compression option it has is ABSOLUTELY AWFUL
[11:19:28 CET] <nonex86> guys, does anyone expirienced using avformat_seek_file()? how stable is it? I noticed a problems with it on some container when seeking for keyframes
[11:20:38 CET] <nonex86> for example i am failed to seek on mpeg2 ps, mpeg2 video
[11:21:20 CET] <nonex86> also the function did not return any error, but i got some garbage when reading
[11:25:45 CET] <JEEB> those don't have an index
[11:26:04 CET] <JEEB> if you need "frame-exact" seeking you will have to utilize something like ffms2, which creates an index
[11:26:26 CET] <JEEB> so it goes through the thing once, indexes and then you can utilize its API to get the decoded images etc
[11:26:46 CET] <JEEB> will not help if you need the data before decoding, of course
[12:43:00 CET] <nonex86> JEEB: i see, i already build an index myself, but how can i be sure it works? For example, right now every mkv/h264 streams i tested works perfectly - no problems with seeking on keyframes. But will it work always on mkv/h264? avformat_seek_file() doesnt return an error on mpeg2 streams i have, but actually it doesnt work :(
[12:44:20 CET] <nonex86> so the question is can i use avformat_seek_file() on h264 in mkv and will it always work correctly
[13:04:50 CET] <JEEB> nonex86: if the files have correct timestamps and seek point flags it should work
[13:05:14 CET] <JEEB> if you already make an index then just use the byte-wise serking mode?
[13:05:29 CET] <JEEB> that way you can utilize your index :4
[13:05:49 CET] <nonex86> JEEB: well, indexing process can take some time i want avoid it if i can
[13:06:26 CET] <nonex86> JEEB: so, if avformat_seek_file() will work on keyframe basis i will not index the file
[13:07:05 CET] <nonex86> JEEB: but yes, you are right, after indexing process i can do byte-seeking
[13:19:14 CET] <nonex86> JEEB: btw, what about mp4 container? can i seek on it using keyframe seeking?
[15:10:13 CET] <furq> shouldn't -xerror quit after the first error
[15:10:26 CET] <furq> i'm getting hundreds of lines of error logs before it quits
[15:31:19 CET] <thebombzen> now out of curiosity, from the lossless codec discussion before, I've noticed that ffv1 is generally the best if I care more about archiving than about speed.
[15:32:06 CET] <furq> x264 lossless is much more competitive than i thought
[15:32:14 CET] <thebombzen> but I actually think that utvideo might be the best for realtime HD encoding. I think it's better than ffvhuff, though I've yet to do actual data collection.
[15:38:08 CET] <nonex86> JEEB, looks like mp4 is unable to do byte seaking :/ at least iformat has AVFMT_NO_BYTE_SEEK, now i am totally confused :/
[17:56:40 CET] <mykNCSA> Hello, is it possible to have ffmpeg capture the stream from a camera, transcode it to a different resolution and present it as a source for other applications to use?
[17:57:26 CET] <mykNCSA> I'm trying to use a BMD Intensity Pro card with Webex and my camera only outputs 1080i and Webex won't support anything above 720
[17:59:22 CET] <klaxa> like this? ffmpeg -f <format> -i <input> -s 1280x720 -c:v libx264 -preset veryfast -f <format> pipe:1
[18:00:24 CET] <klaxa> if your camera is v4l2 and your other application can read matroska it would be: ffmpeg -f v4l2 -i /dev/video0 -s 1280x720 -c:v libx264 -preset veryfast -f matroska pipe:1 | <program2> -
[18:00:55 CET] <klaxa> that is one possibility, i'm sure someone else can come up with something better
[18:01:27 CET] <sam> what is a reasonably polite delay before pinging ffmpeg-devel about a patch for a fix that got no answer or apparent attention?
[18:04:44 CET] <mykNCSA> Would pipe:1 work in Windows?  I'm thinking I'd need to use the dshow flag somehow
[18:15:18 CET] <furq> pipes work fine on windows
[18:16:25 CET] <kerio> mykNCSA: it won't show up as a camera tho
[18:19:55 CET] <mykNCSA> ok, thanks, so that's what I'm looking for, getting ffmpeg to transcode the capture from the Intensity Pro card, and present it as a different camera source so Webex can see it
[18:23:47 CET] <BtbN> ffmpeg does not act as dshow source.
[18:24:01 CET] <kerio> not with that attitude
[18:39:06 CET] <mykNCSA> ok, I've been looking at the decklink output device, I might be able to capture using dshow, transcode and output with decklink.  any thoughts?
[18:52:35 CET] <c_14> sam: 1-2 weeks or thereabouts
[19:17:13 CET] <ChocolateArmpits> Hi, I seemingly have an issue with directshow input. Ffmpeg it seems is unable to access pin 2 of the input that contains an interleaved video/audio dv stream. pin 1 contains only the video stream and that is useless to me. VLC and Graphedit handle both pins without problems.
[19:34:25 CET] <sam> c_14: thanks
[19:51:29 CET] <insp3ori0n> hey guys, is it possible to invert audio with ffmpeg? so when i would have a sine wave it would be phaseshhifted 90°
[19:52:22 CET] <DHE> insp3ori0n: https://ffmpeg.org/ffmpeg-filters.html#Examples-3   Does this help?
[19:53:43 CET] <insp3ori0n> that looks good!
[20:13:12 CET] <insp3ori0n> is there a way to process audio live? so mic input, through filter to output
[20:14:46 CET] <insp3ori0n> and output would be aux out for example
[20:26:55 CET] <dchana> hi, can ffmpeg do subtitles burn-in with .CAP files, for Japanese characters?
[20:27:09 CET] <dchana> the docs says it supports only .SRT and .ASS
[20:27:20 CET] <JEEB> give samples and support might come
[20:27:26 CET] <JEEB> + post them on the bug tracker
[20:27:55 CET] <JEEB> is that an official format or just ARIB B-24 stuff ripped or something?
[20:28:32 CET] <dchana> it's an official format
[20:28:41 CET] <dchana> Netflix has a guide for studios to create them
[20:28:42 CET] <dchana> https://drive.google.com/file/d/0B9DJydDVOVKKLTJpU3Qtei02NGxzZ0c0QUp6VXAwNUYzTnV3/view
[20:29:05 CET] <JEEB> oh shit
[20:29:10 CET] <JEEB> I might have seen that somewhere
[20:29:21 CET] <JEEB> probably someone posted something similar on #aegisub
[20:29:33 CET] <dchana> the tricky thing, imo, is that this format allows vertical characters displayed, and ruby
[20:29:44 CET] <dchana> smaller char on top and bottom of the normal subtitles
[20:30:15 CET] <JEEB> sure, it's a major PITA to try and do that in ASS for example, which IIRC is still our internal representation. Unless we have ruby support separately.
[20:30:29 CET] <JEEB> that said, that's closer to presentation than actually parsing it all
[20:30:55 CET] <JEEB> and most people would rather be interested in presentation than conversion into other formats... maybe?
[20:31:26 CET] <JEEB> dchana: anyways make an issue on the tracker for that if you really need it, and with what use case
[20:31:51 CET] <JEEB> as in, conversion or just hardsubbing (rendering on the video surface)
[20:32:02 CET] <dchana> just curious, how long does it take for a feature like this to get implemented by the team?
[20:32:30 CET] <JEEB> depends on if someone is actually interested in it
[20:32:38 CET] <dchana> and is there any opportunity that I can participate in doing it?
[20:32:41 CET] <JEEB> sure
[20:33:02 CET] <JEEB> if you can compile ffmpeg itself (simple ./configure and make to get a binary), you're ready to go
[20:33:19 CET] <JEEB> because 99%+ of all decoders are there by default within FFmpeg
[20:33:24 CET] <JEEB> and demuxers etc
[20:34:08 CET] <JEEB> and if you can get FFmpeg compiled and get the command line app done, you can join #ffmpeg-devel and poke people that you'd like to try and implement a  subtitle format
[20:34:42 CET] <JEEB> you need some understanding of C and capability of trying to read existing examples (although a lot of formats are just perversely insane)
[20:35:13 CET] <dchana> earlier I asked about using dbg in ffmpeg
[20:35:33 CET] <JEEB> don't know about dbg, but gdb I know :)
[20:35:34 CET] <dchana> ffmpeg codebase is large, it's hard to try something and debug on it, imo
[20:35:40 CET] <dchana> and compile takes 30 min every time
[20:35:51 CET] <dchana> gdb
[20:35:52 CET] <JEEB> uhh, why would you do a full compile every time?
[20:36:04 CET] <dchana> I don't want to if I don't have to
[20:36:06 CET] <JEEB> you usually have pre-compiled files and make will take care of only recompiling the things that are required
[20:36:11 CET] <furq> it shouldn't take that long unless your cpu is ancient
[20:36:12 CET] <JEEB> like, I compile FFmpeg once
[20:36:15 CET] <dchana> ok
[20:36:22 CET] <JEEB> then I change libavcodec/wutlol.c
[20:36:34 CET] <JEEB> even if I just do `touch libavcodec/wutlol.c`
[20:36:42 CET] <JEEB> it should only compile wutlol.c and its dependencies
[20:36:48 CET] <JEEB> when I run make again
[20:37:09 CET] <dchana> ic, and for debugging, is it all done on the command line?
[20:37:30 CET] <dchana> I recently did a ./configure and install on the linux subsystem on W10
[20:37:44 CET] <furq> it takes about 15 minutes for me to build 10-15 external libs and ffmpeg from scratch
[20:37:51 CET] <furq> on a cpu from 2009
[20:37:52 CET] <dchana> and I intend to use it for ffmpeg changes. Is there going to be a problem?
[20:38:05 CET] <JEEB> I have no idea how well the lunix subsystem for win10 works
[20:38:07 CET] <dchana> @furq, on a mac/linux?
[20:38:18 CET] <JEEB> on windows I never had it take 30min either
[20:38:19 CET] <furq> on debian, cross-compiling for windows
[20:38:25 CET] <furq> otherwise i wouldn't be building the libs myself
[20:38:27 CET] <JEEB> even though fork() is slow as hell
[20:39:01 CET] <dchana> @furq, on debian you can build the executables that run on windows/
[20:39:09 CET] <furq> yes?
[20:39:15 CET] <JEEB> on any lunix as long as you have a cross-compiler :P
[20:39:20 CET] <JEEB> search for mingw-w64
[20:39:35 CET] <JEEB> with the ubuntu thing on win10 `apt search mingw-w64`
[20:39:57 CET] <furq> i should probably see if apt is acceptably fast now
[20:40:08 CET] Action: JEEB has no idea
[20:40:18 CET] <furq> last time i tested it it was much slower than using apt-(get|cache)
[20:40:18 CET] <JEEB> I always built with msys2+nev's mingw-w64 toolchain on windows
[20:40:22 CET] <JEEB> funky
[20:40:23 CET] <furq> but that might have been prerelease
[20:41:02 CET] <dchana> @jeeb you build ffmpeg on windows?
[20:41:13 CET] <JEEB> yes, I have done that too :P
[20:41:19 CET] <JEEB> both on mingw-w64 as well as MSVC
[20:41:43 CET] <dchana> are you getting the 15min compile time?
[20:41:58 CET] <JEEB> let me time my basic compile
[20:42:08 CET] <JEEB> because it never was slow enough for me to really matter
[20:42:30 CET] <furq> if you're not running make -j then that would probably explain it
[20:42:37 CET] <dchana> I assume all dev will enable debug symbols when compiling right?
[20:42:39 CET] <furq> that 15 minute compile is with make -j6
[20:42:47 CET] <JEEB> granted, it is slower than on actual *nix because of fork() but yunno :P
[20:42:51 CET] <furq> for ffmpeg alone it's probably about 10 minutes
[20:43:00 CET] <furq> and yeah i doubt msys' slow fork is a significant bottleneck
[20:43:21 CET] <JEEB> well I often just leave -j out because windows file locks can be funky
[20:43:40 CET] <furq> yeah i found it to be less hassle to just fire up a vm
[20:44:33 CET] <and_die> to install static ffmpeg do i just copy the binaries to /usr/local/bin/ ? Do I need to do anything so it doesn't conflict with the one I already have in /usr/bin ?
[20:44:47 CET] <furq> the ones in /usr/bin will usually take precedence
[20:45:12 CET] <and_die> furq: those are system package, I thought about removing them but a bunch of stuff depends on em
[20:45:12 CET] <furq> if you want to invoke it as /usr/local/bin/ffmpeg then it makes no difference
[20:45:16 CET] <dchana> @furq, linux VM and build ffmpeg there?
[20:45:24 CET] <furq> yeah
[20:45:29 CET] <furq> and_die: what distro is that
[20:45:47 CET] <and_die> furq: linux mint (not entirely sure if it's based on debian or ubuntu anymore)
[20:45:53 CET] <furq> that shouldn't matter then
[20:46:06 CET] <dchana> another funny story for me, I used hyper-V to start a VM, and I can never get it full-screen to run ubuntu
[20:46:10 CET] <dchana> and that turned me off
[20:46:31 CET] <furq> if you have other packages which depend on libavcodec etc then you can remove ffmpeg without the libs being flagged for removal
[20:46:34 CET] <JEEB> it's not like you need the GUI
[20:46:38 CET] <and_die> i mean do i have to invoke it as /usr/bin/local/ffmpeg every time tho? or make an alias? I thought there was some way to manage multiple versions or something
[20:46:45 CET] <furq> and if anything depends on /usr/bin/ffmpeg then you should uninstall it for being garbage
[20:46:55 CET] <JEEB> and_die: better to just install it somewhere and specifically specify the binary
[20:46:57 CET] <furq> i guess you can manage it with update-alternatives
[20:47:10 CET] <furq> but yeah you should be able to uninstall the ffmpeg package without breaking anything
[20:47:11 CET] <JEEB> ok, `configure` finished in real    1m52.045s
[20:47:27 CET] <JEEB> now timing make without any parameters
[20:47:28 CET] <furq> debian's ffmpeg packaging is smart enough to handle that
[20:47:33 CET] <furq> unlike some other distros i could name
[20:48:23 CET] <and_die> hmm. packaging hurts my brain. I think I'll just make an alias
[20:48:57 CET] <ben218> hi, i have a question about using libfdk_aac for transcoding FLAC
[20:49:17 CET] <dchana> does enabling libx264 add to configure time?
[20:49:27 CET] <furq> it'll add to build time
[20:49:27 CET] <dchana> but I probably don't need that for subtitles right
[20:49:33 CET] <furq> it shouldn't add anything significant to configure time
[20:49:51 CET] <ben218> no matter what options i pass, it seems like mediainfo sees the files as constant bitrate instead of variable
[20:50:15 CET] <JEEB> ben218: time to see what on earth it utilizes to find that info out :P
[20:50:32 CET] <JEEB> mediainfo can often interpret fields in "interesting" ways
[20:50:46 CET] <JEEB> but yes, if you specify a bit rate fdk-aac will probably try to do CBR
[20:51:03 CET] <JEEB> you have to utilize something a la -q:a to set it to a specific quantizer
[20:51:03 CET] <ben218> that's what i'm curious about, if the files are truely CBR or VBR
[20:51:38 CET] <ben218> i'm not specifying a bitrate, i'm using -vbr
[20:51:51 CET] <ben218> that's what i read here https://trac.ffmpeg.org/wiki/Encode/AAC
[20:51:54 CET] <JEEB> I've no idea what that does
[20:51:59 CET] <furq> they're vbr
[20:52:08 CET] <furq> i just tested with -vbr 5 and mediainfo claims they're constant
[20:52:14 CET] <furq> s/they're/it's/
[20:52:21 CET] <furq> fb2k reports it correctly
[20:52:34 CET] <JEEB> welcome to mediainfo, to know what exactly it means with something you have to actually learn what it interprets in some way :P
[20:52:54 CET] <ben218> thanks furq, wanted to verify i wasn't doing something wrong
[20:53:03 CET] <ben218> thanks JEEB also
[20:53:41 CET] <JEEB> ben218: just for the reference, mediainfo rather often seems to take information from <some field> in a file and output it in some way or another. thus you always need to double-check what mediainfo outputs
[20:53:45 CET] <furq> ffprobe reports the same value for bit_rate and max_bit_rate even though the bitrate spikes higher than that
[20:53:50 CET] <furq> so i'm guessing that's got something to do with it
[20:54:07 CET] <andai> looks like my shell prefers /usr/local/bin, yay!
[20:54:08 CET] <JEEB> I've no idea how it could have probed that
[20:54:22 CET] <JEEB> unless it went through the sizes of all audio frames
[20:56:11 CET] <JEEB> although I guess the movenc muxer might be writing the bit rate into a field which is then read as bit rate and maxrate
[20:56:21 CET] <JEEB> enjoy boxdumping
[20:57:33 CET] <furq> i get a different value for format:bit_rate
[20:58:36 CET] <andai> is AAC not in the static build? oh dang
[20:58:47 CET] <furq> fdk is nonfree
[20:58:59 CET] <JEEB> but the internal one is completely OK for LC-AAC
[20:59:13 CET] <JEEB> also nonfree in this context is "you can build it locally but you cannot distribute a binary mixing the two"
[20:59:17 CET] <furq> is the internal encoder any good for vbr
[20:59:27 CET] <JEEB> it should be at this point methinks?
[20:59:29 CET] <furq> i remember someone commenting that it wasn't a while back
[20:59:35 CET] <andai> JEEB: oh i see so it's not a philosophical thing, it's a legal thing
[20:59:37 CET] <furq> but that might have been before 3.0 was out
[20:59:57 CET] <furq> andai: https://github.com/mstorsjo/fdk-aac/blob/master/NOTICE#L51-L58
[21:00:01 CET] <furq> that clause is gpl incompatible
[21:00:30 CET] <andai> So.. my understanding is the best video codec is x265 and the best audio is opus. But they don't go together in mp4, i need to use MKV instead?
[21:00:44 CET] <JEEB> dchana: ok, without any parameters to the build it actually goes close to 15min
[21:00:44 CET] <ben218> last i heard fdk_aac was prefered  over the other aac encoders in ffmpeg
[21:00:45 CET] <JEEB> real    12m38.328s
[21:00:46 CET] <andai> context: phone storage full,  shrinking my media
[21:00:47 CET] <JEEB> for the build
[21:00:52 CET] <furq> for a given definition of best
[21:01:08 CET] <furq> x265 is probably a bad choice for your phone
[21:01:17 CET] <furq> unless it has a hardware hevc decoder
[21:01:30 CET] <JEEB> ben218: that has changed, the internal is now usable as well. unless you need HE-AAC that is.
[21:01:38 CET] <deweydb> guys, has "ffmpeg concat" changed in some way from 2.x to 3.x ?
[21:01:49 CET] <furq> fdk is preferred but the internal encoder is pretty good
[21:01:53 CET] <deweydb> is there a changelog
[21:01:54 CET] <JEEB> HE-AAC being "let's trade quality to get quite low bit rates (read: <64kbps"
[21:02:03 CET] <furq> much better than the old external aac libs
[21:02:14 CET] <JEEB> deweydb: which one of the umpteen ways of doing concat that only work for a single limited use case?
[21:02:25 CET] <JEEB> we have a filter, we have a protocol, we have a demuxer...
[21:02:47 CET] <andai> furq: not good for my phone you mean will use cpu instead of hardware decoders, impacting battery life?
[21:02:48 CET] <deweydb> demuxer, using a txt file as input.
[21:02:56 CET] <furq> andai: right
[21:03:02 CET] <deweydb> ffmpeg -f concat -i %s -c copy %s
[21:03:11 CET] <deweydb> where the first %s is the text file containing the clips
[21:03:12 CET] <andai> furq: on that note, do you have any idea of hardware level audio codec support
[21:03:17 CET] <furq> also if you actually want to save space with x265 then be prepared for 5fps encoding
[21:03:18 CET] <deweydb> and the second %s is my output target
[21:03:22 CET] <andai> furq: like i remember decoding ogg on the old ipods would eat through the battery
[21:03:48 CET] <andai> furq: yeah it's mostly powerpoint presentations with audio
[21:03:51 CET] <furq> if you use fast settings with x265 then it's no better than x264
[21:04:26 CET] <furq> x264 should already do very well on mostly-static content
[21:04:48 CET] <furq> and yeah i have no idea about hardware audio decoder support
[21:04:56 CET] <andai> i guess i'll just make x264 + opus mkvs then? :)
[21:05:05 CET] <furq> but you'd need very good ears to notice the difference between opus and aac at the same bitrate
[21:05:09 CET] <furq> so you might as well stick with aac
[21:05:29 CET] <furq> i imagine that's more likely to be accelerated
[21:05:52 CET] <andai> good point i should do some tests to see if it's worth it! except I'll be biased towards opus haha
[21:06:04 CET] <furq> if you're going for super-low bitrates then opus will probably be better
[21:06:11 CET] <furq> at 128k you won't be able to notice
[21:06:14 CET] <furq> especially not coming out of a phone
[21:06:59 CET] <andai> furq: ye exactly they're already 128k but they were recorded over skype so it's mostly wasted bw
[21:08:06 CET] <furq> that's like 60MB/hour
[21:08:15 CET] <furq> it's probably not worth reencoding them to save half that
[21:08:25 CET] <deweydb> http://paste.ubuntu.com/23408385/
[21:08:29 CET] <furq> it's your phone though
[21:08:39 CET] <deweydb> what does that even mean " Non-monotonous DTS in output stream 0:0; previous: 45568, current: 45056; changing to 45569. This may result in incorrect timestamps in the output file. " ?
[21:08:40 CET] <andai> i got about 13gb of em
[21:08:48 CET] <furq> i just mean the audio
[21:08:59 CET] <andai> yeah... haha
[21:09:03 CET] <furq> if the video is straight out of skype then it's probably some godawful waste of space
[21:10:05 CET] <furq> deweydb: you can normally ignore that unless you get playback issues
[21:10:07 CET] <ben218> so a lot of my source files are 24/96, is there a need to resample when going to aac?
[21:10:09 CET] <andai> yeah i got like 10gb mp3s that i could slash at least in half, and a few gb of video that's more about the message than the aesthetic
[21:10:12 CET] <deweydb> i have issues
[21:10:22 CET] <deweydb> started after upgrading ffmpeg
[21:10:27 CET] <deweydb> i was still on 2.8.x
[21:10:34 CET] <deweydb> and i'm on 3.1.5 now
[21:10:43 CET] <ben218> or is it ok to leave sampling as is?
[21:10:45 CET] <deweydb> (the newest version i could get via a PPA on ubuntu)
[21:11:45 CET] <furq> ben218: it shouldn't make much difference
[21:12:04 CET] <ben218> thanks furq
[21:14:54 CET] <deweydb> furq: i'm combining 9 clips. and every second clip is missing in the output, and instead the video just locks up at that moment for 1 second.
[21:20:42 CET] <deweydb> here is the first 4 clips metadata:
[21:20:44 CET] <deweydb> http://paste.ubuntu.com/23408421/
[21:20:52 CET] <deweydb> http://paste.ubuntu.com/23408422/
[21:21:01 CET] <deweydb> http://paste.ubuntu.com/23408423/
[21:21:11 CET] <deweydb> http://paste.ubuntu.com/23408424/
[21:21:53 CET] <deweydb> the second and 4th clip are the ones that don't "get included" to the output.
[21:22:00 CET] <deweydb> is it because they both have zero b frames?
[21:37:02 CET] <deweydb> just noticed the inputs are also different in bitrate and profile.  which is strange because all parts are encoded using: -c:v libx264 -preset ultrafast
[21:49:18 CET] <andai> i made a little comparison spectrogram of Daft Punk - Around The World at 8kbps in MP3 and Opus
[21:49:19 CET] <andai> http://i.imgur.com/SwdXotu.png
[21:50:04 CET] <deweydb> what kind of a madman encodes music at 8kbps?
[21:50:53 CET] <andai> deweydb: 8 year old me trying to fit music on a 32mb mp3 player
[21:51:22 CET] <Kuukunen> for daft punk it might kinda fit tho!
[21:51:49 CET] <andai> friend: "this sounds like shit!" me: "but i know what it's *meant* to sound like!"
[21:52:21 CET] <andai> we've come pretty far with the codecs in 20 years
[21:52:34 CET] <andai> Kuukunen: heavily compressed eh
[21:54:35 CET] <Kuukunen> yea it's kinda funny how you don't really need as much quality for songs you already know :P
[21:55:23 CET] <Kuukunen> kinda like how you can enjoy songs you know in a noisy environment from low quality speakers, but if you try to listen to something you don't know it sounds like a mess
[21:55:27 CET] <deweydb> i could not disagree more.
[21:55:45 CET] <Kuukunen> disagree then! :P
[21:55:56 CET] <deweydb> whenever i hear a song i know well, on sub par setup, speakers, or quality. it really makes my ears bleed.
[21:56:09 CET] <deweydb> but i guess i'm spoiled listening to music all day on my Genelecs
[21:56:25 CET] <Kuukunen> *genelecs*
[21:57:47 CET] <llogan> exspensive
[21:57:56 CET] <Kuukunen> deweydb: but anyway, that's a bit of a different effect
[22:00:19 CET] <Kuukunen> it's like... "I have a mental image of how this should sound like, therefore I can tell when it doesn't sound correct" vs. "I have a mental image of how this should sound like, I know very well it doesn't sound right, but what I can hear reminds me of the mental image and I can enjoy that"
[22:06:43 CET] <bencoh> I hardly enjoy (real) music in really noisy/poor quality environment if I already "know" it, partly because then I'll probably miss half of it
[22:07:29 CET] <bencoh> (you know, the sounds/instruments that you barely hear in poor conditions)
[22:09:46 CET] <bencoh> on the other hand I'm quite fine with, say, recorded live in a relatively lower quality as long as it features improvisation, for instance
[22:11:35 CET] <llogan> Kenny G
[22:17:54 CET] <deweydb> anyone familiar with ffmpeg concat demuxer?
[22:17:55 CET] <deweydb> https://www.ffmpeg.org/ffmpeg-formats.html#concat-1
[22:18:10 CET] <andrey_utkin_> deweydb, yes
[22:18:14 CET] <deweydb> the documentation says "All files must have the same streams (same codecs, same time base, etc.)."
[22:18:21 CET] <andrey_utkin_> so
[22:18:25 CET] <deweydb> i have ensured that the same codec, and time base
[22:18:32 CET] <deweydb> but the files have different bitrates
[22:18:34 CET] <deweydb> does this matter?
[22:18:45 CET] <andrey_utkin_> depends
[22:18:50 CET] <deweydb> also they have a different profile.
[22:19:03 CET] <deweydb> the strange part is i have generated them all using the same flags: -c:v libx264 -preset ultrafast
[22:19:08 CET] <andrey_utkin_> with mp4 files you are running into a lot of issues if you join non-uniform files
[22:19:32 CET] <andrey_utkin_> different profile is a show stopper
[22:19:44 CET] <andrey_utkin_> you can't say it's same flags
[22:19:58 CET] <deweydb> some have profile "High"
[22:20:00 CET] <andrey_utkin_> think of different h264 profiles as of different codecs
[22:20:04 CET] <deweydb> others have profile "constrained baseline"
[22:20:35 CET] <deweydb> for the constrained baseline ones, what flags do i need to add to force to High profile?
[22:21:24 CET] <andrey_utkin_> -profile high ?
[22:21:44 CET] <andrey_utkin_> are you joining mp4 files or what?
[22:21:48 CET] <deweydb> yes
[22:22:24 CET] <deweydb> the strange part is my script was working fine on ffmpeg 2.8, but i upgraded to 3.1 yesterday, and it broke the concat/demux part
[22:22:40 CET] <andrey_utkin_> you may be safe only if you reencode them all with exactly same ffmpeg command
[22:22:40 CET] <deweydb> literally have changed nothing else. but maybe 3.1 is stricter about concat
[22:22:42 CET] <thebigmac> Hi. I'm trying to compile ffmpeg on centos and I'm getting this error: "libavcodec/libopusenc.c: In function libopus_encode_init: libavcodec/libopusenc.c:337:9: error: implicit declaration of function opus_multistream_surround_encoder_create [-Werror=implicit-function-declaration]          enc = opus_multistream_surround_encoder_create("  any ideas?
[22:23:17 CET] <andrey_utkin_> deweydb, in them all i mean ALL, not just part of them which are in e.g. Baseline
[22:23:32 CET] <andrey_utkin_> all your files which you want to merge must be reencoded the same way
[22:23:40 CET] <BtbN> thebigmac, if you installed libopus from the centos repo, there's a good chance it's simply too old.
[22:24:09 CET] <andrey_utkin_> also make sure to add -x264opts stitchable=1 if you do constant quality (CRF mode) or 2-pass encoding
[22:24:36 CET] <thebigmac> BtbN, that sounds like the issue. Is there another repo to install it from?
[22:24:57 CET] <andrey_utkin_> mp4+h264 joining without reencoding is a mess )
[22:26:15 CET] <furq> thebigmac: https://www.johnvansickle.com/ffmpeg/
[22:27:04 CET] <deweydb> andrey_utkin_: yeah, but re-encoding is super slow, and i'm building all these clips beforhand, so i just need to figure out how to build them right in the first place.
[22:27:09 CET] <deweydb> im trying with -profile high now
[22:27:21 CET] <deweydb> failing that i will try the -x264opts
[22:27:28 CET] <furq> you might want to use mpegts
[22:28:16 CET] <andrey_utkin_> yeah mpegts is good for joining, but it depends on stream consumers if mpegts is suitable
[22:28:29 CET] <furq> i mean for the clips, not the output
[22:28:36 CET] <andrey_utkin_> deweydb, what's your application?
[22:28:51 CET] <andrey_utkin_> who plays the joined file?
[22:29:00 CET] <deweydb> it gets uploaded to youtube.
[22:29:07 CET] <deweydb> https://bid13.com
[22:31:25 CET] <deweydb> andrey_utkin_: well thats weird, even with -profile high, it still used "Constrained Baseline"
[22:32:02 CET] <furq> -profile just restricts the features you can use
[22:32:08 CET] <andrey_utkin_> youtube doesn't support mpegts as input :)
[22:32:18 CET] <furq> if you're using preset ultrafast then you probably aren't using any features outside of baseline
[22:32:36 CET] <furq> andrey_utkin_: really?
[22:32:53 CET] <deweydb> i honestly don't care what the preset is, the video quality we get sent is is always crap. i just want it to render as quickly as possible. thats the bigger issue.
[22:32:55 CET] <andrey_utkin_> https://support.google.com/youtube/troubleshooter/2888402?hl=en-GB furq
[22:33:23 CET] <furq> i'll have to test that
[22:35:30 CET] <andrey_utkin_> deweydb, well ok, even with what you say (and furq confirms) all you need is uniformness of your files. reencode all parts with same command and they most probably will concat finely
[22:35:36 CET] <furq> https://www.youtube.com/watch?v=urkwEF1uoxg
[22:35:46 CET] <furq> unsurprisingly, google's support page is wrong
[22:36:02 CET] <furq> this is the first time this has ever happened
[22:36:51 CET] <andrey_utkin_> furq, try something with TS discontinuity and size/format change in the middle :)
[22:37:20 CET] <andrey_utkin_> that's what would help deweydb :)
[22:37:22 CET] <furq> i'm pretty sure youtube are just using ffmpeg circa 2011
[22:37:29 CET] <furq> so if that dealt with it then youtube ought to be able to
[22:37:42 CET] <kerio> furq: supports lossless h264 tho ;o
[22:37:50 CET] <kerio> do we really need anything else
[22:38:43 CET] <andrey_utkin_> i've learnt today that amazon elastic transcoder is basically ffmpeg 3.x & libx264 v148 :)
[22:39:49 CET] <kerio> i distinctly remember being able to send ZMBV to youtube
[22:40:02 CET] <furq> it might be newer than 2011
[22:40:13 CET] <furq> all i remember is that it predates the hevc encoder
[22:40:17 CET] <furq> s/enc/dec/
[22:40:55 CET] <furq> which put a bit of a dent in my theory that they were taking a stand against hevc to help push vp9
[23:02:37 CET] <deweydb> furq / andrey_utkin_ thank you for your help. i you were correct, there was one place in my code that i was missing to enforce the codec.   i was taking a slice of a video with something like: ffmpeg -ss %.2f -t %.2f -i in.mp4 out.mp4
[23:02:49 CET] <deweydb> and somehow this was changing the profile.
[23:03:00 CET] <deweydb> even though the input video was already the correct profile
[23:03:47 CET] <furq> that'll reencode with the default settings
[23:10:45 CET] <deweydb> is there a "cut" command that just simply cuts that section of video, without re-encoding?
[23:10:54 CET] <JEEB> -c copy
[23:11:48 CET] <deweydb> thanks
[23:13:21 CET] <furq> you probably won't be able to get accurate cuts with -c copy
[23:15:55 CET] <utack> shouldn't jpeg2000 be super fast to decode? this thing is slow as hell for me https://media.xiph.org/video/derf/meridian/MERIDIAN_SHR_C_EN-XX_US-NR_51_LTRT_UHD_20160909_OV/
[23:16:00 CET] <utack> 6fps slow
[23:23:47 CET] <pzich> hoping someone here can confirm: MP4s don't have any sort of "poster frame" metadata (either an image file or specifying a particular frame to show), right? that's a product of the player/previewer itself, or is available in other formats (e.g. MOV)
[23:23:50 CET] <deweydb> what would be the best choice of codec for enlarging a video without losing a ton of quality?
[23:24:40 CET] <llogan> utack: a 89G sized files can conceivably take a long time
[23:25:53 CET] <llogan> deweydb: an appropriate scaling algorithm is probably more important. but why upscale?
[23:26:12 CET] <utack> llogan certainly, but it seemed slow low for a jpeg2000 codec
[23:28:00 CET] <TD-Linux> utack, same here. it's really high bitrate jpeg2000 and not very fast.
[23:28:13 CET] <utack> ok. interesting
[23:28:17 CET] <TD-Linux> should scale reasonably if you have a bazillion cores
[23:28:27 CET] <llogan> libopenjpeg may be faster
[23:28:27 CET] <utack> so it does not compress well, and it isn't fast either. seems like THE codec of choice
[23:28:41 CET] <TD-Linux> I suspect ffmpeg's decoder may not be well loved
[23:28:59 CET] <TD-Linux> I am hoping to get a lossless version at some point, which I will transcode to something more reasonable
[23:30:34 CET] <utack> please let me know when that is the case
[00:00:00 CET] --- Tue Nov  1 2016