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

[burek]

[01:49:34 CET] <JamJams> libavcodec question, getting some memory leaks. I'm decoding then if a condition is met I duplicate the frame using av_buffersrc_add_frame_flags(buffersrc_ctx, av_frame_clone(newframe), AV_BUFFERSRC_FLAG_KEEP_REF); but when I do that the memory is leaked for the duplicated frame.
[01:49:45 CET] <JamJams> How should I go about duplicating frames so that it doesn't leak memory?
[02:03:18 CET] <_Vi> Is there any use of this hack for amateurs of static linking: https://github.com/vi/FFmpeg/commit/a554d6451e041ec6cb3297830e94903d64368cad . Shall I try to make a proper patch?
[02:05:08 CET] <J_Darnley> People with small, vary small disk space?
[02:06:01 CET] <J_Darnley> If you want to submit a patch then you are welcome to
[02:06:13 CET] <_Vi> J_Darnley, People that does not like unnecessary duplication. One can include FFmpeg as a tool, not as a library and when you want both to convert files and to analyze them, it's better to have both ffmpeg and ffprobe.
[02:06:41 CET] <J_Darnley> Just explain why and your reasoning.
[02:07:06 CET] <_Vi> J_Darnley, I mean does patch that adds such mode (although less invasively) have a change to be accepted?
[02:07:17 CET] <J_Darnley> No idea, sorry
[02:48:41 CET] <fundies> whats the difference between colorprim and transfer in x265?
[04:27:16 CET] <jookiyaya> i want to able to use shine mp3 encoder
[04:28:40 CET] <grublet> fundies: colorprim is the color primaries, transfer is the transfer coefficients
[04:33:51 CET] <fundies> :/
[04:51:52 CET] <svnpenn> If I use "-ss", "-t" and "-c copy", the duration is reduced, but not the reported duration. This happens with "-ss -t -i", "-ss -i -t" and "-i -ss -t"
[06:27:58 CET] <fundies> why ffmpeg only using ~ 1/2 my cpu?
[07:59:34 CET] <flux> fundies, by cpu do you mean one or more cores?
[09:48:25 CET] <Fyr> guys, when using DXVA2 I experience low speed in contrast to the option -hwaccel dxva2 off.
[09:49:03 CET] <Fyr> how to get a speed gain when using hardware acceleration?
[11:24:31 CET] <ku1dne> Hello, is there any advantage at all to using bitrates that are divisible by 8 (for example 1536 instead of 1500) for video encoding with x264?
[11:34:27 CET] <furq> no
[12:40:35 CET] <_Vi> ku1dne, If you want some advantage but don't need strict bitrate, you can use alternative modes like -crf or use two-pass encoding.
[13:36:24 CET] <Fyr> is it possible to make cube rotation with ffmpeg like KDE effect?
[13:36:36 CET] <Fyr> first introduced in compiz
[13:40:55 CET] <J_Darnley> Cube rotation?  Do you have an example of what you want to see?
[13:41:12 CET] <J_Darnley> I can think of perspective which might dowhat you want.
[13:41:17 CET] <Fyr> yes, KDE effect.
[13:41:25 CET] <J_Darnley> I don't know what that is.
[13:41:30 CET] <ubitux> the compiz thing?
[13:42:21 CET] <Fyr> http://www.youtube.com/watch?v=4QokOwvPxrE
[13:43:13 CET] <Fyr> http://www.youtube.com/watch?v=4417_9UjuqQ
[13:43:21 CET] <Fyr> the last one is shorter.
[13:43:40 CET] <J_Darnley> Fuck you youtube and your overlays and your geo restrictions
[13:44:44 CET] <Fyr> I would give you the link to VK video, but you won't be happy about it too. =)
[13:44:48 CET] <J_Darnley> No
[13:44:54 CET] <J_Darnley> ffmpeg cannot do that
[13:45:08 CET] <J_Darnley> What would you want shown on the other faces anyway?
[13:45:18 CET] <furq> another video, presumably
[13:45:30 CET] <Fyr> right
[13:45:33 CET] <Fyr> or the same thing or a screenshot.
[13:46:02 CET] <Fyr> sometimes blackscreen is good too.
[13:47:42 CET] <furq> https://www.youtube.com/watch?v=y3YcsAOttO0&t=3m02s
[13:47:45 CET] <furq> ffmpeg has got some catching up to do
[13:48:45 CET] <Fyr> agreed
[13:48:46 CET] <J_Darnley> I doubt people want an aliased effect
[13:48:55 CET] <J_Darnley> they would bitch about the quality
[13:49:55 CET] <Fyr> they won't.
[14:15:20 CET] <Filarius> Hello, how do I can ask ffmpeg to retry connection if it found 404 error while trying to get source from link ?
[14:24:08 CET] <JEEB> Filarius: no way to do that within FFmpeg, I mean it goes backwards from any usual use case. You should build your own thing that re-starts FFmpeg or the libraries if you're using them in case you need to probe for input all the time
[14:26:11 CET] <Filarius> okay, thanks
[14:42:50 CET] <AlexQ> Hi. How to slow down a matroska video with h.264 content without reencoding video? (Slow down from "PAL progressive" (25 FPS) to "NTSC progressive" (23.976 FPS)? Can I just force ffmpeg to think that the input video is 23.976 FPS? And I also want to replace the original audio with a soundtrack from another file (which is 23.976 FPS)
[14:44:05 CET] <AlexQ> As the soundtrack in PAL version is dubbing only, unfortunately
[14:47:22 CET] <flux> alexq, this seems relevant to your question: https://trac.ffmpeg.org/wiki/How%20to%20speed%20up%20/%20slow%20down%20a%20video - or are you asking if the change could cause issues?
[14:48:55 CET] <AlexQ> Thanks, flux. Is that possible without reencoding the video?
[14:52:13 CET] <AlexQ> I thought that maybe it is just as simple as changing the FPS metadata in the Matroska file, but there are also these PTS for each frame I believe which need to be changed as well (these are in the H.264 stream itself, right?)
[14:53:44 CET] <AlexQ> Found something like that, flux: http://ffmpeg.org/pipermail/ffmpeg-user/2014-May/021673.html
[15:01:23 CET] <flux> alexq, ah sorry, I sort of assumed the examples wouldn't re-encode anything
[15:02:22 CET] <flux> and yes, H.264 stream has presentation time stamp and decoding time stamp
[15:06:43 CET] <AlexQ> so what happens when I change the framerate metadata in a video file, but without changing presentation and decoding time stamps?
[15:07:11 CET] <JEEB> most containers don't have a notion of "frame rate" really
[15:07:22 CET] <JEEB> and if they have it's completely cosmetic
[15:07:29 CET] <JEEB> I think AVI was the last thing that only had a frame rate
[15:07:42 CET] <JEEB> (well there are probably mangled non-generic things as well)
[15:07:54 CET] <AlexQ> http://forum.doom9.org/showthread.php?t=173107 - someone reports to have succeeded with mp4box, but the problem is quite different. I just can't believe it is impossible to do such a conversion without reencoding
[15:08:07 CET] <JEEB> what are you trying to do?
[15:08:22 CET] <JEEB> most containers have a per-stream or global timebase, and then every stream has their own timestamps for each "sample"
[15:08:50 CET] <flux> it certainly is possible, but if there's a tool to do it is another matter
[15:09:03 CET] <JEEB> if you are trying to change the rate of a clip I recommend extracting the video track and remuxing it with L-SMASH's muxer and specifying the rate you want
[15:09:23 CET] <JEEB> because the pts video filter requires re-encoding and -r doesn't work
[15:10:05 CET] <JEEB> muxer -i input.264?fps=24000/1001 -o output_at_24000_1001_fps.mp4
[15:10:29 CET] <JEEB> and you can mux in the audio track at the same time if you have it around
[15:10:39 CET] <AlexQ> Replace original soundtrack from a 25 FPS video with a soundtrack from a 23.976 FPS video. Thought it would make much more sense just to change to slow the 25 FPS video down rather that tempo up the audio from 23.976.
[15:10:51 CET] <JEEB> yeah
[15:10:56 CET] <JEEB> because that way you don't have to re-encode either
[15:10:57 CET] <JEEB> so yeah
[15:11:15 CET] <JEEB> ffmpeg -i initial_input -c copy out.264
[15:12:13 CET] <JEEB> muxer -i out.264?fps=24000/1001 -i your_audio (if the audio is in raw bit stream, otherwise you use ffmpeg or L-SMASH's remuxer) -o out_with_new_rate.mp4
[15:14:33 CET] <JEEB> and yes, "23.976" is really 24000/1001
[15:16:21 CET] <AlexQ> So I should extract that audio to an aac raw stream (as that's the format I believe), right? From the 23.976 FPS file? And what "muxer" program is that? I got lost. I am using Ubuntu, what package should I install? Or if there is no package in the official repo, should I use some ppa or (least preferably) compile something, or maybe get a .deb or a pre-compiled tarball
[15:16:22 CET] <AlexQ> ?
[15:17:00 CET] <JEEB> nah, the video thing is what matters for now
[15:17:16 CET] <JEEB> just in case you had the other audio track as a raw bit stream you'd be using that
[15:17:38 CET] <JEEB> you extract the video track like in the first command to raw "Annex B" AVC/H.264
[15:17:56 CET] <JEEB> then you use L-SMASH's muxer to mux it with a different frame rate
[15:18:19 CET] <JEEB> not sure l-smash has any official packaging
[15:18:33 CET] <JEEB> thankfully, building it is rather easy https://github.com/l-smash/l-smash
[15:19:02 CET] <JEEB> after configure and make you should have the tools under cli
[15:19:13 CET] <JEEB> including muxer
[15:20:01 CET] <JEEB> then you should be able to mux the AVC/H.264 track into mp4 with it with the new rate
[15:20:13 CET] <JEEB> after that it's pretty simple to stick the audio track to it with whatever you want, really
[15:20:20 CET] <JEEB> f.ex. ffmpeg
[15:21:10 CET] <JEEB> but yeah, we can look into the audio side after you've confirmed that you've gotten the video done :)
[15:21:45 CET] <AlexQ> Indeed, no need for any libs or anything for L-SMASH's muxer
[15:21:51 CET] <AlexQ> installed
[15:22:43 CET] <AlexQ> extracting h264...
[15:23:59 CET] <JEEB> yeah, it's kind of unfortunate that retiming tracks isn't working well with ffmpeg cli. I guess you could do it with the library, but there's no way to do it through the ffmpeg cli
[15:26:12 CET] <JEEB> but since I've got L-SMASH and I can live with some unfortunate data duplication for a moment, I'm fine with taking that route for now
[15:27:16 CET] <AlexQ> So in that ffmpeg -i initial_input -c copy out.264 ffmpeg knows I want to copy vid only by guessing the output format from the output file extension? Cool
[15:28:40 CET] <JEEB> yeah, because the output format guessed by the extension can't contain anything else
[15:29:09 CET] <JEEB> if it could, it would copy what it could or even error out due to the output container not supporting some video/audio/subtitle format
[15:29:10 CET] <AlexQ> and if I use -c option it specifies the codec for all streams?
[15:29:17 CET] <JEEB> yup
[15:30:43 CET] <AlexQ> So I should remux that raw stream to .mp4, not .mkv now? With muxer? I don't care, whatever is safer. In your example you had mp4
[15:32:43 CET] <AlexQ> muxing to 24000/1001 FPS mpeg4 container then
[15:34:03 CET] <JEEB> L-SMASH is a thing that is specifically made to correctly implement the video/audio/timed text specific parts of MPEG-4 container
[15:34:09 CET] <JEEB> you can later change that to matroska if you require
[15:35:00 CET] <JEEB> one of the good sides of the MPEG-4 container is that it can deliver your timestamps as specific as you want, so as a source it's probably one of the best ways to do it
[15:35:38 CET] <JEEB> mpeg-ts has a global timebase of 90000, and matroska is usually limited to millisecond precision
[15:36:30 CET] <AlexQ> Wow, it was using a lot of RAM, almost 2 gigs. Dunno what
[15:36:36 CET] <AlexQ> but it crashed, unfortunately
[15:36:45 CET] <JEEB> huh
[15:37:13 CET] <JEEB> would be great to see how that happened, but unfortunately can't really do it without a sample
[15:37:13 CET] <AlexQ> first it displayed "MP4 muxing mode" and started using HDD and memory heavily (CPU not as much intensely)
[15:37:28 CET] <AlexQ> and then I got
[15:37:29 CET] <AlexQ> "[importer: Error]: failed to find the matched importer.
[15:37:30 CET] <AlexQ> Error: failed to open input file.
[15:37:30 CET] <AlexQ> Error: failed to open input files.    "
[15:37:56 CET] <JEEB> can I get a full command line and terminal output in a pastebin-like?
[15:38:03 CET] <AlexQ> ffmpeg exported with no errors
[15:38:17 CET] <JEEB> also if possible it'd be nice to get the sample if you can share that (even if in private)
[15:38:27 CET] <JEEB> would be nice to debug if it happens to me, too
[15:38:42 CET] <AlexQ> How can I check if the 264 file plays correctly?
[15:38:54 CET] <JEEB> ffmpeg -i file.264 -f null -
[15:39:06 CET] <JEEB> it will say something about bad timestamps with the null muxer, but that's OK
[15:39:16 CET] <JEEB> because null muxer will just throw things into the void anyways
[15:39:37 CET] <JEEB> (it will decode the thing and throw it out)
[15:42:21 CET] <AlexQ> should I update to ffmpeg 3.0 as well? I have 2.7.6 from Ubuntu 14.10 repo
[15:42:59 CET] <JEEB> the versions aren't much, in general if possible you should be following the master branch as long as FATE looks green
[15:43:11 CET] <JEEB> FATE = http://fatebeta.ffmpeg.org/
[15:43:37 CET] <JEEB> but yes, in general the newer the better
[15:44:31 CET] <AlexQ> 15.10* obviously
[15:50:43 CET] <AlexQ> http://paste.ubuntu.com/15307781/
[15:51:03 CET] <AlexQ> that decode-testing of the extracted video
[15:52:10 CET] <JEEB> ooh-kay
[15:52:13 CET] <JEEB> now that looks fun
[15:52:18 CET] <JEEB> no wonder you get issues
[15:52:45 CET] <JEEB> it's as if there's no parameter sets
[15:53:02 CET] <JEEB> which contain that little stuff like picture size and parameters for compression etc
[15:53:51 CET] <JEEB> you might want to git clone ffmpeg (git://git.videolan.org/ffmpeg.git) and compile without any options. if you aren't going to re-encode, that should bring you up to snuff with a basic binary
[15:54:01 CET] <JEEB> no need to install it, just use from the build dir
[15:54:19 CET] <JEEB> you will probably have to have yasm installed but that should be it
[15:54:40 CET] <JEEB> then try extracting the video track once again with that
[15:55:14 CET] <AlexQ> but the vid plays well in VLC, I mean the original matroska file with audio. Maybe I should try to null-decode the whole original Matroska file with the ffmpeg I have? And enable verbose mode as well?
[15:55:51 CET] <JEEB> nah, focus on updating FFmpeg and see what happens when you extract the video with that
[15:56:00 CET] <JEEB> (when you try to decode that)
[15:58:24 CET] <AlexQ> okay, already running raw decode on the original vid file with -loglevel debug
[15:58:28 CET] <AlexQ> I already got something like
[15:58:36 CET] <AlexQ> [null @ 0x2699e40] Encoder did not produce proper pts, making some up.
[15:58:43 CET] <JEEB> that's what I said is OK
[15:58:50 CET] <AlexQ> okay
[15:59:05 CET] <JEEB> it's because the null muxer is basically void
[15:59:18 CET] <JEEB> throws everything out so various fields aren't filled
[15:59:31 CET] <AlexQ> but that is the original Matroska file. Okay
[16:00:07 CET] <JEEB> anyways, I wouldn't focus on the matroska file but rather what happens when you extract the video stream from it with the latest FFmpeg
[16:02:15 CET] <Filarius> Hello, how to fix recording from livestream, seems some livestream have lag on start on video/audio syncronization. Logs http://pastebin.com/pUGbbfRf and video http://rghost.ru/7N6Bz42RS  down load video - online player have another lag. I tryed to upload to Youtube, and somehow it fix it - lag changes to no audio for 50-90 ms
[16:03:17 CET] <AlexQ> okay, I'll compile it later. I just wanted to decode the whole Matroska file to check if it isn't corrupted, as I haven't watched it yet
[16:03:32 CET] <AlexQ> will be back later! Thank's JEEB!
[16:03:42 CET] <JEEB> even if it is later, parameter sets are required from the beginning
[16:04:06 CET] <Filarius> I have same lag after re-encoding record
[16:04:28 CET] <JEEB> so if it properly starts decoding, it got those from somewhere :P
[16:06:59 CET] <AlexQ> :D
[16:07:13 CET] <AlexQ> JEEB: Maybe that will be of some interest for you: http://paste.ubuntu.com/15307964/
[16:07:31 CET] <AlexQ> didn't let it run all the way, have it stopped for the moment
[16:07:45 CET] <JEEB> AlexQ: aka it got the parameters just fine
[16:07:59 CET] <AlexQ> as you can see, my machine isn't a speed demon :D
[16:08:56 CET] <JEEB> so yeah, build a standard configuration FFmpeg from master (just ./configure) and run that from the directory you built it in and see what comes out when you try to extract the track with it
[16:10:50 CET] <AlexQ> 50 tbc - does that mean it is a raw recoding from a PAL HDTV source?
[16:11:48 CET] <JEEB> don't read into those values too much
[16:12:18 CET] <JEEB> I don't even remember which bits of data ffmpeg cli uses to come out with them :)
[16:12:29 CET] <JEEB> tbn is the matroska timebase at least
[16:12:45 CET] <JEEB> millisecond precision so one second is 1k ticks
[16:12:58 CET] <AlexQ> Okay, I'll be back later, with the newest ffmpeg master
[16:13:01 CET] <JEEB> ok
[16:13:03 CET] <AlexQ> Thanks very much!
[16:13:15 CET] <JEEB> np
[17:52:35 CET] <AlexQ> JEEB: Compiling, takes a while...
[17:53:44 CET] <JEEB> yeah, although you can `make -jX` where X is the amount of cores you have or so
[17:54:00 CET] <JEEB> FFmpeg does have a few files :)
[17:55:02 CET] <furq> AlexQ: http://johnvansickle.com/ffmpeg/
[17:55:46 CET] <JEEB> furq: he doesn't need anything fancy so better to just keep him compiling if he's already doing it :P
[17:56:51 CET] <AlexQ> good to know, JEEB. Pity I had no idea that it doesn't do it in parallel automatically, it uses only one core indeed
[17:57:31 CET] <furq> if you cancel make and rerun it with -jn it should pick up where it left off
[17:58:11 CET] <AlexQ> furq: Just Ctrl+C?
[17:58:14 CET] <JEEB> yeah
[18:06:04 CET] <AlexQ> I decided to install it after compiling, so I first removed ffmpeg package from Ubuntu
[18:06:07 CET] <AlexQ> done make install
[18:06:24 CET] <AlexQ> but now when I type ffmpeg I get /usr/bin/ffmpeg: no such file or directory
[18:06:30 CET] <AlexQ> what's up?
[18:06:35 CET] <furq> it'll probably be in /usr/local/bin
[18:06:39 CET] <furq> although that should really be on your PATH
[18:07:29 CET] <AlexQ> apparently it isn't, as there is ffmpeg there indeed
[18:07:40 CET] <AlexQ> how should I add it to PATH?
[18:08:00 CET] <AlexQ> uum
[18:08:01 CET] <JEEB> yeah, that's why I said just use it from the build dir :P
[18:08:03 CET] <AlexQ> it is in PATH
[18:08:04 CET] <furq> "/usr/bin/ffmpeg: no such file or directory" isn't the right error message for it not being on your path
[18:08:12 CET] <JEEB> you'll have to reload or whatever
[18:08:21 CET] <furq> i guess something else on your PATH is pointing to /usr/bin/ffmpeg
[18:08:21 CET] <JEEB> because the shell has already once picked which ffmpeg it will run
[18:08:21 CET] <AlexQ> is it some cache issue or what?
[18:08:25 CET] <JEEB> yes
[18:08:42 CET] <JEEB> rehash or reload
[18:08:44 CET] <JEEB> whichever it was
[18:09:05 CET] <furq> hash -r
[18:09:12 CET] <AlexQ> just closed the vterm window and opened again and it worked :D
[18:09:16 CET] <furq> yeah that'll do it
[18:10:23 CET] <JEEB> anyways, check if the latest FFmpeg extracts the AVC track properly (by trying to decode it afterwards)
[18:11:39 CET] <AlexQ> doing just that
[18:11:58 CET] <AlexQ> BTW. Could I pipe ffmpeg with muxer?
[18:12:14 CET] <AlexQ> for the future, I'll have a few more files to convert like that
[18:12:39 CET] <JEEB> I don't remember how well muxer takes in AVC from stdin, so feel free to try
[18:12:44 CET] <JEEB> if it works, great
[18:12:55 CET] <JEEB> if not, I can look into it when I have time
[18:13:33 CET] <AlexQ> BTW2. So muxer can't demux mkv, but it could mp4, or it can only mux raw streams?
[18:13:53 CET] <JEEB> it can only mux raw streams into ISOBMFF derivatives
[18:14:09 CET] <JEEB> remuxer can remux streams from ISOBMFF derivatives into ISOBFMM derivatives
[18:14:20 CET] <JEEB> L-SMASH is a purely ISOBMFF-specific project
[18:14:35 CET] <JEEB> you can then remux that ISOBMFF into matroska or whatever you want
[18:17:06 CET] <AlexQ> That's the demux log, if want to have a look: http://paste.ubuntu.com/15309676/
[18:17:12 CET] <AlexQ> running null decode...
[18:20:28 CET] <AlexQ> failed :(
[18:21:28 CET] <AlexQ> http://paste.ubuntu.com/15309791/
[18:23:38 CET] <AlexQ> So that means any remuxing of that source file would file? E.g. if I decided to tempo up the audio file from the other source to 25 fps?
[18:24:39 CET] <AlexQ> fail*
[18:24:40 CET] <JEEB> nah, it just means that the demuxing failed
[18:25:30 CET] <AlexQ> so how can e.g. VLC play the source file when demuxing fails even with the newest ffmpeg?
[18:25:53 CET] <JEEB> ok, I said it wrong
[18:26:00 CET] <JEEB> the writing of the raw Annex B fails :P
[18:26:02 CET] <JEEB> demuxing works
[18:26:13 CET] <JEEB> otherwise you would've not been able to decode the source
[18:26:27 CET] <JEEB> ffmpeg -i input.mkv -bsf:v h264_mp4toannexb -c copy out.264
[18:26:28 CET] <JEEB> try this
[18:26:31 CET] <JEEB> just in case
[18:26:39 CET] <JEEB> it should put that BSF there by default
[18:26:43 CET] <JEEB> but just in case
[18:26:54 CET] <Paranoialmaniac> ffmpeg h264 bsf is broken. apply this patch https://github.com/VFR-maniac/ffmpeg/commit/172fe56b1a4a063ff2feb14d3394129eb155b40d
[18:27:39 CET] <JEEB> a wild VFR Maniac appears
[18:27:50 CET] Action: Paranoialmaniac hides
[18:28:33 CET] <JEEB> not sure if that is the reason for the parameter sets not being found, though... but sure, looks like a valid fix for too short start codes
[18:28:43 CET] <JEEB> because it looked like it didn't use the BSF at all
[18:30:51 CET] <JEEB> AlexQ: anyways try with the BSF inserted there (-bsf:v h264_mp4toannexb)
[18:31:02 CET] <JEEB> if that still fails, try V-maniac's patch
[18:31:05 CET] <AlexQ> before trying to apply the patch? Okay
[18:31:23 CET] <bencoh> hmm, is this bug in ffmpeg bugtracker?
[18:32:01 CET] <JEEB> no idea, it looked useful so I poked the -devel channel with the patch
[18:32:30 CET] <JEEB> not sure if he has already posted it on -devel ML
[18:33:01 CET] <JEEB> seems like not
[18:33:28 CET] <bencoh> can
[18:33:29 CET] <Paranoialmaniac> i didnt since i have planed to post on libav-devel :P
[18:33:33 CET] <bencoh> cant find it either :)
[18:33:39 CET] <bencoh> Paranoialmaniac: ah
[18:33:39 CET] <JEEB> ok
[18:33:51 CET] <JEEB> and then it would flow to ffmpeg through the merges
[18:34:31 CET] <JEEB> but since it's a few months old... I guess you wouldn't mind at this point unless you're actually going to post it :) also I think Libav just started reworking the BSF API together with related FFmpeg folk
[18:34:34 CET] <bencoh> looks like the kind of bug I might have encountered months ago without knowing why
[18:35:02 CET] <JEEB> (seems like Libav is becoming the kettle where breaking changes are first introduced)
[18:35:40 CET] <JEEB> (although I guess it's nothing new since elenril kind of started such way of improving things a few years back)
[18:36:44 CET] <Paranoialmaniac> i dont have time to rewrite the patch for libav recently :P i guess the patch cant be applied cleanly
[18:36:53 CET] <JEEB> yeah
[18:37:22 CET] <JEEB> I had a similar issue with some of my patches that I've still not posted on the ML
[18:37:50 CET] <bencoh> which reminds me I still have a ffmpeg/libssh patch lying around
[18:38:10 CET] <bencoh> and I need help regarding libssh caching ... forgot about that too
[18:38:23 CET] <bencoh> (caching/read-ahead)
[18:41:52 CET] <AlexQ> Demux log with that option added: http://paste.ubuntu.com/15310043/
[18:42:26 CET] <JEEB> alright, now see if you can decode that extracted track
[18:45:16 CET] <AlexQ> seems to be decoding, 5 mins already decoded with no errors. Guess that means it works then?
[18:45:25 CET] <JEEB> most probably yes
[18:45:41 CET] <AlexQ> So now back to muxer...
[18:47:51 CET] <AlexQ> Decode log, if you were interested for debug purposes or sth: http://paste.ubuntu.com/15310151/
[18:48:17 CET] <JEEB> not really, just shows that the extraction worked :)
[19:00:18 CET] <AlexQ> JEEB: http://paste.ubuntu.com/15310342/ :(
[19:02:03 CET] <AlexQ> VLC can't play that 264 file either. Not even a single frame displayed, and "[h264 @ 0x7f943d239f20] mmco: unref short failure" in the terminal output
[19:02:28 CET] <JEEB> VLC is quite different and most probably using a different version
[19:02:38 CET] <JEEB> aanyways
[19:03:00 CET] <AlexQ> So I don't even know if the .264 file is correct or not
[19:03:14 CET] <JEEB> ooh-kay.. now try with the patch (in the FFmpeg source dir `git remote add vmani https://github.com/VFR-maniac/ffmpeg.git` `git fetch vmani` `git cherry-pick 172fe56b1a4a063ff2feb14d3394129eb155b40d`)
[19:03:43 CET] <JEEB> haven't tried it myself yet, but by chance it could match as-is
[19:03:59 CET] <JEEB> and then run make and it should rebuild the related components
[19:14:45 CET] <AlexQ> These two files were compiled after make "CC	libavcodec/h264_mp4toannexb_bsf.o AR	libavcodec/libavcodec.a", guess that means the patch worked, right?
[19:15:20 CET] <JEEB> if the patch worked git successfully cherry-picked the patch
[19:15:28 CET] <JEEB> it should have told you that the cherry-pick failed otherwise
[19:18:38 CET] <AlexQ> JEEB: Extracting after make and make install. MD5'ed previous .264 to check if they will differ in any way
[19:18:51 CET] <JEEB> ok
[19:24:13 CET] <AlexQ> JEEB: Guess I should let ffmpeg test decode run through the whole file this time?
[19:24:19 CET] <JEEB> nah
[19:24:28 CET] <JEEB> just make sure it *can* start decoding it
[19:24:59 CET] <AlexQ> well, it could before patching, but muxer couldn't. So try muxer now then?
[19:25:25 CET] <JEEB> sure
[19:25:58 CET] <AlexQ> md5sums differ, so the patch apparently influenced the output file
[19:26:31 CET] <JEEB> yeah, it made the start codes longer for parameter sets
[19:27:49 CET] <JEEB> you can either have 0x00 00 01 or 0x00 00 00 01 , and it seems like that bit stream filter in FFmpeg wasn't properly making four byte start codes for parameter sets, even though the specification says they should be at least 4 bytes long
[19:28:01 CET] <AlexQ> Yes, the file is slightly larger as well
[19:28:39 CET] <AlexQ> 2050729719 to 2050731491 bytes
[19:33:31 CET] <AlexQ> [H.264: Info]: Analyzing stream as H.264
[19:33:36 CET] <AlexQ> maybe it'll work then
[19:33:44 CET] <JEEB> looks good
[19:34:14 CET] <rainabba> I'm learning my way around capture from a DeckLink 4K Pro. When I attempt UHD60 capture and copy to avi, I get an "input buffer overflow" Anyone familiar with this? How do I enlarge that buffer or what does it indicate?
[19:36:11 CET] <AlexQ> and in the meantime, what approach should I take when trying to synchronize with the new soundtrack when muxing?
[19:37:12 CET] <JEEB> ffmpeg -i your_mp4.mp4 -i your_mkv_video_with_audio.mkv -map 0:v -map 0:a -c copy out.your_extension_of_liking
[19:37:28 CET] <JEEB> maps the video track(s) from the first input file, and the audio track(s) from the second
[19:37:36 CET] <JEEB> which disables automatic track selection
[19:38:42 CET] <AlexQ> and what about sync?
[19:38:47 CET] <maco1717> hi where can i find the irc logs for this channel?
[19:39:45 CET] <JEEB> AlexQ: you should be able to check that after that
[19:39:56 CET] <AlexQ> it is very likely that some shift will be required. Can you sync without reencoding audio?
[19:40:02 CET] <JEEB> yeah
[19:40:31 CET] <JEEB> you can extract a part of the audio track only first, making sure it has the parts you need only
[19:40:42 CET] <JEEB> and then mux that together with the video
[19:43:57 CET] <AlexQ> Importing stage finally
[19:46:35 CET] <rainabba> maco1717: There isn't a universal answer to that as the various servers may/may-not maintain logs. If you check the server you're using and find that organization on the web, you may find logs they maintain.
[19:47:22 CET] <furq> maco1717: http://ffmpeg.gusari.org/irclogs/
[19:47:35 CET] <rainabba> nice :)
[19:48:15 CET] <rainabba> furq: That a server provider or maintained by the ffmpeg project?
[19:48:33 CET] <furq> server provider?
[19:48:43 CET] <rainabba> IRC server
[19:48:45 CET] <furq> oh
[19:49:02 CET] <furq> i don't think any irc servers keep channel logs
[19:49:14 CET] <furq> especially not on a network the size of freenode
[19:49:48 CET] <furq> i assume those logs are provided by someone who has a logging bot in here
[19:50:00 CET] <AlexQ> JEEB: So in other words, you mean I should mux a few minutes first, then sync audio with e.g. VLC and that apply that shift when muxing the whole thing?
[19:50:10 CET] <rainabba> That was my expectation. Been some years but I recall back in the day there were some logging systems, but they weren't part of the IRC network itself and didn't cover all channels; just ones they were setup for. Might have even been efnet (been a while).
[19:51:21 CET] <furq> i assume they just use regular clients (or bots)
[19:51:43 CET] <furq> maybe some services packages can do it
[19:52:02 CET] <rainabba> Can anyone link me to any info about the buffer referred to in my "Input buffer overflow" issue? I can't find anything other than about -bufsize and -rtbufsize which I think are unrelated.
[19:52:46 CET] <rainabba> Only found a couple results on Google that even look like a match and they have no useful replies (one mentiones Queue depth, but I have single input).
[19:54:43 CET] <AlexQ> JEEB: Wow, that process takes ages. Is it really that computationally expensive, or is muxer just really slow for that kind of tasks?
[19:54:59 CET] <rainabba> Unrelated, If I'm encoding h.264 (using x264) and pushing to Wowza, am I better off using mpegts udp:// or flv rtmp://  (if there's even a "better")?
[19:57:40 CET] <basisbit> according to https://www.ffmpeg.org/doxygen/2.8/group__libsws.html#gae531c9754c9205d90ad6800015046d74 calling sws_scale from code should not have changed from ffmpeg 2.8 to 3.0 from what I can see. for some reason now after switching to ffmpeg 3.0 I get an exception in swscale-4!sws_getCachedContext. any idea what changes in ffmpeg 3 could have caused that or are there any known issues? (most likely the issue is on my side but I can't find what causes this)
[20:00:00 CET] <jkqxz> rainabba:  You'll need to offer more information than that, such as complete log output.  (The string "input buffer overflow" does not appear anywhere in the ffmpeg source, so your problem might well be some other component.)
[20:00:29 CET] <furq> rainabba: depends if you want to use formats which are unsupported by flv
[20:00:36 CET] <furq> s/formats/codecs/
[20:03:42 CET] <AlexQ> JEEB: Muxing completed! Finally :D Let's check if it plays in VLC
[20:04:42 CET] <rainabba> furg: Ahh. Could be decklink source then perhaps? Mabye time for me to start compiling myself :/  I'll turn out output and pastebin it. As for the Woqza question. The source will be the decklink and I'm looking at using Wowza (also considering bitcodin and Elemental Cloud) to handle the transcoding where it will become h.264/ts/HLS. This will be real-time and with a decent pipe behind it (Some
[20:04:42 CET] <rainabba> pretty noteworthy sponsors at a VERY large music festival)
[20:07:10 CET] <rainabba> Heh, that was easier than I expected, "[decklink @ 0000020dcfdeca00] Decklink input buffer overrun!"  Might also explain why there's so little info out there. I'm guessing there aren't a lot of people doing UHD60 capture on a Decklink card using ffmpeg. :)
[20:08:18 CET] <furq> rainabba: fwiw if you've not already paid for wowza then https://github.com/arut/nginx-rtmp-module will do hls
[20:08:31 CET] <rainabba> Even on debug there's not much more to be found. Happens when the filesize is betweten ~600MB and ~1.4GB
[20:12:11 CET] <rainabba> furq: I have, but that's trivial only $60/mo/server and we only need 1 server per stream at worse) compared to what we're doing so it wouldn't stop me :) Checking that out now. Thank you. For additional information, we're using CloudFront as CDN (Amazon is a direct sponsor) so it's really the transcoding thats primary.
[20:21:18 CET] <rainabba> Hmm. Even with 1080p60, I'm hitting that input buffer error, just way further in.
[20:23:53 CET] <bencoh> hmm, I've worked with the decklink cards (for the upipe project), and to be honest I never ever thought of using it through ffmpeg
[20:25:04 CET] <bencoh> I guess most people use it in some appliance/proprietary software or VLC (for live applications at least)
[20:25:31 CET] <rainabba> As best I can tell, this is the project providing decklink support to ffmpeg, but that error doesn't show at all: https://github.com/henriklied/decklink-ffmpeg  same for the project it branched from: https://github.com/lu-zero/bmdtools
[20:26:21 CET] <rainabba> bencoh: Hmm. VLC for the capture/push to next step in the pipe?
[20:26:51 CET] <bencoh> rainabba: you'd need to encode, and VLC isn't really good at live low-latency encoding
[20:27:04 CET] <bencoh> but that'd be the idea yeah
[20:27:05 CET] <rainabba> I'm basically looking to build an appliance that would handle capture, [stitching for 360,] encoding, then push to a transcoder.
[20:27:13 CET] <bencoh> or have a look at upipe if you're into writing code
[20:27:55 CET] <rainabba> bencoh: I'm not too concerned with latency. We're looking at minimum 18 seconds thanks to HLS alone and from what I've seen the latency most people are concerned about is in the order of ms (telecommunications).
[20:27:56 CET] <bencoh> (I wont advertise for proprietary appliance here but the guys behind upipe might have what you're looking for)
[20:28:11 CET] <bencoh> ah, HLS, right. you definitely dont care about latency :D
[20:28:15 CET] <rainabba> bencoh: Thanks. Not familiar so I'll check it out.
[20:29:06 CET] <Mavrik> Yeah, you should expect latency in terms of seconds not ms
[20:29:56 CET] <bencoh> you can reach ~140ms latency with decklink input + h264 intra-refresh/zerolatency settings
[20:30:13 CET] <bencoh> (and around 40mbps output stream iirc)
[20:30:29 CET] <rainabba> Anyone in the Phoenix area and interested in helping with this? We're a poor startup, but for the right skills, it wouldn't have to be pro-bono :)   Me: https://www.linkedin.com/in/rainabba   Project: https://vantage.tv   No real expectations, but I've seen stranger coincidences along the way.
[20:30:33 CET] <Mavrik> Yeah, and then iPhone player buffers 5 seconds :P
[20:30:50 CET] <bencoh> Mavrik: yeah, HLS kills it all :)
[20:30:55 CET] <Mavrik> Just don't want him to have unrealistic expectations on what players do :)
[20:31:43 CET] <rainabba> We're delivering between 1.7Mbps and 28Mbps depending on the source, and device (iPhone chokes arond 12Mbps where my Note4 and Nexus 6P will take 40Mbps without an issue, but start to overheat from GPU (VR environment) after a couple minutes.
[20:36:07 CET] <Mavrik> Hmm, that seems like it could be problematic for playback
[20:36:17 CET] <Mavrik> Getting a 28Mbps wifi connection on a phone is not really common.
[20:36:26 CET] <Mavrik> Check if your users have that.
[20:37:26 CET] <rainabba> Mavrik: Hence HLS adaptive :)
[20:38:24 CET] <rainabba> I can sustain 150Mbps at home but many will be lucky if they can sustain an average close enough to 3Mbps to be able to stream without buffering. We go as high as we do because 1) We can 2) We are already kicking everyone's ass in the field and want to continue that pattern :)
[20:40:37 CET] <rainabba> bencoh: You were referring to https://github.com/cmassiot/upipe ?
[20:43:19 CET] <bencoh> rainabba: yup
[20:43:42 CET] <Zeranoe> Does the location of -threads 1 matter when forcing FFmpeg to use a single core? Before or after the -i that is
[20:44:07 CET] <JEEB> yes
[20:44:10 CET] <JEEB> decoding vs encoding
[20:44:26 CET] <Zeranoe> thought so
[20:52:31 CET] <rainabba> It appears that my output .mp4 isn't written to until ffmpeg is stopped (vs the file growing as encoding happens). Is that the case? Expected? I'd expect that to cause RAM usage to increase over time and I'd think it would make more sense to write as it goes. There a flag that controls that or am I seeing this all wrong to begin with?
[20:53:02 CET] <BtbN> mp4 is useless until the final header is written at the end anway
[20:53:31 CET] <JEEB> or if you use fragments
[20:56:40 CET] <Mavrik> yep, mp4 is not a streamable format really.
[20:56:55 CET] <Mavrik> rainabba, don't use mp4 as a format to pass data from encoder to streaming server.
[20:59:12 CET] <rainabba> Mavrik: See my question above about pushing to Wowza? I'm doing this right now to figure out my capture, cropping and understand encoding load mostly. Ideally, the transocder in my flow will be independant and handle it, but I need to figure out the best format for that intermediate transfer and admittedly, I'm very new to ffmpeg and anything outside of camera formats and h.264. I'm considering
[20:59:12 CET] <rainabba> ffmpeg, Wowza and Elemental Cloud (in that order right now).
[21:00:18 CET] <Mavrik> We used ffmpeg that muxed H264/AAC into MPEG-TS and passed it to wowza over UDP
[21:00:31 CET] <Mavrik> wowza then remuxed that into MP4 and other crap required for output
[21:00:36 CET] <rainabba> cropdetect is only really meant to work on a rectangular image right? I've got a spherical image with lots of black on the sides and would love to auto-detect (different lens shims mean that sphere can be >20px in either direction on the horizontal).
[21:01:04 CET] <Mavrik> No idea about cropdetect :/
[21:01:11 CET] <Mavrik> It's not an online algorithm at all afaik.
[21:01:40 CET] <rainabba> Mavrik: Other than using FLV/RTMP, that's what I've done so far. MPEGTS is advantageous though? Can you explain why?
[21:01:52 CET] <Mavrik> It's a muxing format built for streaming.
[21:02:18 CET] <Mavrik> Which MP4 and FLV aren't (they have global headers at start of file without which you cannot playback content. MPEG-TS retransmits that)
[21:02:23 CET] <rainabba> I assume I should focus on ensuring GOP matches what I intend to use for the HLS TS chunks?
[21:02:30 CET] <Mavrik> RTMP is a very chatty protocol that requires two-way communication.
[21:02:40 CET] <rainabba> Mavrik: Good info. Thank you.
[21:02:52 CET] <Mavrik> MPEG-TS does have a bit more of the overhead though (it's about 100kbit/s I think)
[21:03:06 CET] <Mavrik> But it's good enough for DVB-everything, ATSC and IPTVs ;)
[21:03:14 CET] <Mavrik> HLS uses it as it's underlying container as well.
[21:03:14 CET] <rainabba> We're likely sending > 8Mbps on the low-end so that's fine with me.
[21:03:24 CET] <Mavrik> Wowza will remux it anyway.
[21:03:48 CET] <rainabba> Referring to the GOP question?
[21:03:53 CET] <rainabba> "remux it anyway"
[21:04:01 CET] <rainabba> Or just in general?
[21:04:02 CET] <Mavrik> No, you can't fix GOP by remuxing :)
[21:04:03 CET] <bencoh> dont they have decklink support (wowza)?
[21:04:09 CET] <bencoh> I thought they did
[21:04:14 CET] <Mavrik> Since GOP is a property of the video stream / encode.
[21:04:27 CET] <Mavrik> And yeah, afaik you must make sure you have an IDR frame when your chunk starts.
[21:04:36 CET] <bencoh> yeah, you do
[21:04:48 CET] <Mavrik> And some non-iOS devices choke on HLS if the chunks aren't equal over several qualities.
[21:04:48 CET] <rainabba> bencoh: To my knowledge, Wowza has zero capture ability natively.
[21:04:50 CET] <bencoh> especially since the RFC draft has been superseeded by apple doc
[21:05:03 CET] <bencoh> https://developer.apple.com/library/tvos/documentation/General/Reference/HLSAuthoringSpec/Requirements.html#//apple_ref/doc/uid/TP40016596-CH2-SW1
[21:06:20 CET] <JEEB> Mavrik: funny enough I haven't noticed that in any of the stuff I've poked. I could just be lucky, but there's stuff that has been running with mismatched GOPs for years
[21:06:35 CET] <JEEB> what mostly is an issue with mismatched GOPs are the streaming servers
[21:06:42 CET] <JEEB> those are usually really dumb regarding those things
[21:06:47 CET] <Mavrik> Asbis STBs and some old Androids with Vivino or what that DRM crap is were sensitive.
[21:07:40 CET] <JEEB> oh, STBs. I've only dealt with actual TV sets and mobiles so far. Actual DRM vendors' SDKs are a separate world of pain, yes.
[21:07:40 CET] <Mavrik> Granted, not really relevant for everyone :)
[21:08:03 CET] <JEEB> and TVs often, too. Thankfully the mobile space at least here seems to be relatively good
[21:08:15 CET] <bencoh> *cough*good*cough*
[21:08:19 CET] <bencoh> (sorry)
[21:08:22 CET] <Mavrik> Also Windows Phones.
[21:08:26 CET] <Mavrik> Fuck those :)
[21:08:38 CET] <JEEB> but yeah, DRM vendors' demuxing is very bad often
[21:08:49 CET] <JEEB> and then the streaming servers that handle the DRM :P
[21:08:57 CET] <JEEB> E_CANNOT_STAB_ENOUGH
[21:09:04 CET] <bencoh> they're all mostly shit, but some shit works better than others :p
[21:09:08 CET] <JEEB> yeah
[21:09:58 CET] <JEEB> and because everyone else just dumbs their transcodes down they don't get an incentive to really improve unless someone puts some heat under them. I tried but no idea how successfully :P
[21:23:15 CET] <rainabba> Generally speaking, is there a good way to "split/duplicate" a stream? For example, if I wanted to use VLC to monitor locally and also push mpegts/udp to another server?
[21:23:51 CET] <rainabba> Definitely think it's time to start compiling myself. Just found unsharp with opencl support :)
[21:26:58 CET] <bencoh> rainabba: mpegts+multicat?
[21:27:12 CET] <bencoh> multicast*
[21:27:22 CET] <bencoh> but you prolly want to have a look at "multicat" too :p
[21:27:56 CET] <bencoh> (multicast on lo works quite well)
[21:35:25 CET] <nadermx> I have multiple instances of ffmpeg running at a time but when more than a few source urls with large input streams  it only converts each of them for about 15 minutes worth and then cuts out.  I thought the buffer was set large by default?
[21:36:01 CET] <nadermx> I have a many instances of ffmpeg running at a time*
[21:37:20 CET] <nadermx> would I have to pass a buffer size sufficiently large for each input stream?
[21:43:37 CET] Action: rainabba just had a "moment" with ffmpeg that isn't appropriate for children
[21:44:13 CET] <J_Darnley> Please don't abuse the software in that manner.
[21:44:21 CET] <rainabba> Capture, upscale, unsharp, crop and encoding without even really taxing CPU and I don't even have OpenCL support yet. This single command does what it's taken us 3 devices costing more than $75k to do previously :)
[21:44:24 CET] <J_Darnley> Some of us have to work with it
[21:44:25 CET] <J_Darnley> :)
[21:44:39 CET] <rainabba> J_Darnley: I will clean the mess and hug you all :)
[21:45:10 CET] <rainabba> ... after I setup my build environment so I can get opencl support and ensure my decklink support is as updated as possible (damn input buffer overflow).
[21:45:18 CET] <rainabba> Not looking forward to this
[21:45:25 CET] <bencoh> underflow*?
[21:45:50 CET] <rainabba> Overrun: "[decklink @ 000001aab97acc00] Decklink input buffer overrun!"
[21:45:54 CET] <bencoh> ah
[21:46:12 CET] <bencoh> hmm btw, can't this come from a clock drift of some kind?
[21:46:32 CET] <bencoh> and/or your input not being 60hz while you think it is?
[21:46:51 CET] <rainabba> Seems the harder I push ffmpeg, the quicker it happens (UHD almost instantly, 1080p60 with fast encoding and no filters, just keeps going. Move to medium encoding preset and add filters and it takes a bit)
[21:46:53 CET] <bencoh> (30000/1001 interlaced for instance)
[21:47:20 CET] <bencoh> (or the other way around, it being real interlaced 60hz while you're waiting for 30000/1001)
[21:47:34 CET] <rainabba> Input is definitely 1080p59.94 and I'm using "DeckLink 4K Pro at 12" though the /1000 vs /1001 isn't clear to me so maybe I'm off there?
[21:48:02 CET] <bencoh> 60000/1001 == 59.94 :)
[21:48:09 CET] <bencoh> so nevermind
[21:49:35 CET] <rainabba> That was my suspicion. Kinda wish I'd been wrong and that's all it was :)
[21:49:37 CET] <maco1717> hi, im trying to output to a window "a command" that takes to streams and overlays them sort of picture in picture, I have managed to do the PIP to record to a file, ive looked around and apprently the way to put this to a windows would be namepipe to ffplay? this is the command
[21:49:46 CET] <maco1717>  ./ffmpeg -i 'rtsp://' -i 'rtsp://' -filter_complex "[1]scale=iw/2:ih/2 [pip]; [0][pip] overlay_w-10:10" pipe:1 ¦ ./ffplay -i pipe:1
[21:51:00 CET] <maco1717> i get unable to find a suitable output format for pipe:1 pipe:1: invalid argument pipe:: invalid data found when procesin input
[21:56:46 CET] <rainabba> Looks like the lower my speed is, the quicker I hit that input buffer error.
[21:57:10 CET] <JEEB> since it's a realtime capture thing, not surprising
[21:58:28 CET] <JEEB> you should try -q:v 0 -preset ultrafast for initial lossless capture if you can't handle it with whatever you would be doing otherwise
[21:58:47 CET] <JEEB> (lossless is the only case where you should be using -q:v with any sane video encoder)
[21:59:12 CET] <rainabba> bencoh: "mpegts+multicast" Can I source that multicast to another ffmpeg instance? (Admittedly, I didn't Google first)
[22:01:05 CET] <rainabba> JEEB: Where would I take that from there? Also, can I control the buffer being used to buy myself a little margin of error (in some cases, speed is between .9 and 1.1)? The other thing I'm wondering about is why I'd go below speed 1.0x when I've got plenty of CPU, RAM and Disk IO to spare (this machine is a beast and I'm never going over 75% total CPU)
[22:01:39 CET] <JEEB> you have a bottleneck somewhere along the way?
[22:01:51 CET] <rainabba> I'm doing 1080p60, Preset Medium, high422 just fine until I add the unsharp.
[22:01:56 CET] <JEEB> I'd say it's not the encoder if you're using libx264 that's properl built
[22:02:22 CET] <JEEB> well yeah, I bet your filtering/possible colorspace conversions take a toll
[22:02:52 CET] <JEEB> you should check with -v debug what kind of stuff it does and try to pinpoint where your bottleneck is
[22:02:54 CET] <rainabba> Also bm_v210 on source so maybe I ease that and the profile up a bit?
[22:03:25 CET] <JEEB> so yeah, you are at the very least doing a colorspace conversion to planar 4:2:2 from that
[22:03:37 CET] <JEEB> then you are throwing that into some filter
[22:03:46 CET] <bencoh> rainabba: the great thing about multicast is you can have multiple receivers on the same host ;)
[22:03:47 CET] <JEEB> then you are passing that to the encode
[22:06:07 CET] <rainabba> I think something is off because main and high throw "[libx264 @ 000001f2e2dc7fa0] Error setting profile main" and "[libx264 @ 000001f2e2dc7fa0] Error setting profile high", but high422 works.
[22:06:20 CET] <JEEB> those profiles don't support 4:2:2
[22:06:25 CET] <rainabba> Ahh
[22:07:13 CET] <rainabba> 4:2:0 only or something else entirely?
[22:07:23 CET] <JEEB> 4:2:0 only for those, yes
[22:07:37 CET] <JEEB> you don't really have to specify a profile unless you specifically want to
[22:07:48 CET] <JEEB> libx264 should select one depending on your input and parameters
[22:07:52 CET] <rainabba> Okay
[22:08:17 CET] <JEEB> usually it's in cases where you're doing 4:2:0 and want to limit the encoder specifically to some profile
[22:08:21 CET] <rainabba> Should I stick with bm_v210 for input from decklink or omit and go with 422 (think that's the default)?
[22:08:38 CET] <rainabba> ... or is that entirely a quality question?
[22:08:40 CET] <JEEB> v210 is the packed 4:2:2 format
[22:09:08 CET] <JEEB> I think it might handled as a video format instead of a colorspace
[22:10:27 CET] <rainabba> "If set to @option{true}, video is captured in 10 bit v210 instead of uyvy422. Not all Blackmagic devices support this option."
[22:10:34 CET] <rainabba> That clarify?
[22:10:45 CET] <JEEB> ok, so they support two forms of packed 4:2:2
[22:11:16 CET] <JEEB> actually not sure which is more optimal with a straight thing to libx264
[22:11:31 CET] <JEEB> you would probably want to bench stuff in a very simple manner
[22:11:47 CET] <JEEB> (and making sure how much implicit filtering goes on with -v debug)
[22:11:50 CET] <rainabba> Okay. Thanks. How about that buffer question; giving myself some safety margin when speed isn't consistently > 1.0x?
[22:12:05 CET] <JEEB> probably quite specific to your capture card where the buffer is
[22:12:33 CET] <JEEB> if it's set in libav<whatever that thing is in> or in your actual system/driver
[22:13:16 CET] <rainabba> "Clipping frame in rate conversion by 0.000053"  Because I'm capturing 59.94 and encoding 60? Can I encode with x264 in 59.94?
[22:13:32 CET] <JEEB> of course
[22:13:38 CET] <JEEB> it's not frame rate based anyways
[22:13:43 CET] <JEEB> it takes in input timestamps :P
[22:13:53 CET] <JEEB> https://github.com/FFmpeg/FFmpeg/blob/master/libavdevice/decklink_dec.cpp#L114
[22:14:03 CET] <JEEB> seems like the 1GiB limit is set there if that's what you're getting
[22:14:37 CET] <rainabba> That's what I thought but I've never seen 59.94 as an option. Googling now. Not seeing anything else with -v debug that looks interesting (aside from a cur_dts message that I think doesn't matter).
[22:14:47 CET] <JEEB> uhh
[22:14:53 CET] <JEEB> why would it be a special option?
[22:15:11 CET] <JEEB> I mean, you get input timestamps and in 99%+ of all cases you just want those timestamps to be used
[22:15:16 CET] <rainabba> JEEB: I bet it is, but then it wouldn't matter with mpegts (vs mp4) right?
[22:15:24 CET] <JEEB> !?
[22:15:40 CET] <JEEB> I don't get what you're basing your assumptions on
[22:16:04 CET] <rainabba> I'm not specifying -r right now so I'd think that the 59.94 would just pass through, yet I'm seeing those messages so I need to do something to maintain 59.94 right?
[22:16:22 CET] <rainabba> The 1GB assumption is based on anetedotal evidence :)
[22:16:34 CET] <rainabba> Nothing more
[22:16:49 CET] <JEEB> if you are not specifying -r then no frame rate conversions should happen
[22:16:58 CET] <JEEB> unless some filter in your chain requires one
[22:17:08 CET] <rainabba> Hmm.
[22:17:18 CET] <JEEB> or that message does not mean what you think it does
[22:17:33 CET] <JEEB> i have no idea what part of FFmpeg output it
[22:17:46 CET] <JEEB> since you cut off the part that says which component output the message
[22:18:30 CET] <JEEB> anyways, -v debug always tells you the whole story regarding any filter chains that were done. of course it also spams you with a whole lot of messages because it enables that log level with everything :P
[22:18:40 CET] <rainabba> That's the whole line. No prefix.
[22:18:59 CET] <JEEB> no [COMPONENT at MEMORY]?
[22:19:16 CET] <rainabba> not that I can see. Happy to share more log.
[22:19:49 CET] <JEEB> please just share your command line and terminal output in a pastebin-like :P
[22:20:22 CET] <JEEB> Most messages that come from inside FFmpeg's libraries come in the form of: [ogg @ 02cd6a60] Page at 3550503 is missing granule
[22:20:40 CET] <rainabba> http://pastebin.com/WCUr3fE3
[22:21:00 CET] <bencoh> rainabba: you should be able use with uyvy, unless your decklink card is exotic
[22:21:29 CET] <bencoh> (all my SDI/composite cards worked with uyvy)
[22:21:47 CET] <bencoh> (afaicr)
[22:22:37 CET] <rainabba> bencoh: That's effectively 422 no? How do I specify that?
[22:23:12 CET] <bencoh> I've never ever used this ffmpeg-decklink patch, you know :p
[22:23:19 CET] <rainabba> :)
[22:23:23 CET] <rainabba> Me either
[22:23:36 CET] <JEEB> ok, so v210 is handled as a "decoder" which then converts to yuv422p10le as its "output", and then for unsharp it gets converted to yuv422p
[22:23:38 CET] <bencoh> I've only used decklink cards with VLC and through the libDecklink API ;p
[22:23:54 CET] <bencoh> s/and/or/
[22:23:59 CET] <JEEB> so that explains why the unsharp makes it slower
[22:24:05 CET] <JEEB> not only are you adding filtering
[22:24:15 CET] <JEEB> but you are also adding another format conversion
[22:24:23 CET] <bencoh> is that kierank's v210 decoder?
[22:24:35 CET] <JEEB> not fully sure, but I'd guess so?
[22:25:21 CET] <JEEB> actually no
[22:25:35 CET] <JEEB> the copyrights on the file are mini and baptiste
[22:26:12 CET] <JEEB> kierank did add V210 SIMD tho
[22:26:38 CET] <bencoh> ah, I prolly only had the optim in mind
[22:26:57 CET] <rainabba> [Without v210], this hits 35-40% CPU and 1.1-1.2x speed: ./ffmpeg -f decklink -i 'DeckLink 4K Pro at 12' -vf "crop=1412:1080:254:0, unsharp=luma_msize_x=5:luma_msize_y=5:luma_amount=1.5" -vcodec libx264 -preset:v fast -level 4.2 1080p60_fast_unsharp.mp4
[22:27:01 CET] <bencoh> (I think he wrote a full decoder at some point though, but maybe he never merged it)
[22:27:22 CET] <JEEB> probably for his own project?
[22:27:24 CET] <JEEB> no idea
[22:27:27 CET] <rainabba> While this uses ~25% CPU: ./ffmpeg -f decklink -i 'DeckLink 4K Pro at 12' -vf "crop=1412:1080:254:0" -vcodec libx264 -preset:v fast -level 4.2 1080p60_fast.mp4
[22:27:31 CET] <bencoh> maybe yeah
[22:27:43 CET] <rainabba> So the unsharp is still heavy. To be expected?
[22:27:51 CET] <JEEB> yes, random filters are heavy
[22:27:55 CET] <rainabba> k
[22:28:00 CET] <JEEB> do not use them unless you specifically need them
[22:28:08 CET] <JEEB> minimize the bottlenecks between input and encoding
[22:28:11 CET] <bencoh> rainabba: do you really need unsharp?
[22:28:23 CET] <JEEB> after that your problems will become encoder and output I/O :P
[22:28:25 CET] <bencoh> (I know "sharp" content can be pretty tough to encode, but...)
[22:28:38 CET] <rainabba> For our application, it's a significant improvement. More valuable that 20% increase in bandwidth or resolution.
[22:29:30 CET] <JEEB> but yeah, without v210 you should now see that it should only be unpacking the 4:2:2
[22:29:37 CET] <JEEB> not doing bit depth conversions (hopefully)
[22:29:45 CET] <rainabba> Any chance you were at Lollapalooze or Austin City Limits last year and visited the Samsung Activation? We were the ones streaming VR for them :)  I'm off to Auckland NZ for the 1st Auckland City Limits in less than a week and come back to Coachella next.
[22:29:46 CET] <JEEB> when you look at the filter chain
[22:31:02 CET] <rainabba> Tryin to read those now to check
[22:31:36 CET] <rainabba> This covers it? " Stream #0:1, 1, 1/1000000: Video: rawvideo, 1 reference frame (UYVY / 0x59565955), uyvy422, 1920x1080, 1001/60000, -10 kb/s, 59.94 tbr, 1000k tbn, 59.94 tbc"
[22:31:46 CET] <JEEB> that tells you the input
[22:31:55 CET] <bencoh> do filters all run in the same thread or is there some threading/queueing support in libavfilter nowadays?
[22:32:05 CET] <JEEB> I have no idea, libavfilter is a damn mess
[22:32:23 CET] <bencoh> I was under that impression too last time I had to deal with it
[22:32:54 CET] <bencoh> but having queues between threaded filters might help in his case
[22:33:04 CET] <JEEB> yeah
[22:33:42 CET] <JEEB> rainabba: what you want to read into is the stuff after the parameter parsing by libavfilter (the Parsed_crop and Parsed_whatever)
[22:33:43 CET] <rainabba> JEEB: That shows "yuv422p" now instead of "yuv422p10le" so that confirms right, or is there something more specific to the filter I should look for?
[22:34:03 CET] <JEEB> after that it should be listing the filter graph iti builds for you
[22:34:06 CET] <JEEB> within libavfilter
[22:34:42 CET] <JEEB> rainabba: that just means you're getting 8bit YCbCr instead of 10bit, which can be better off if the conversions or filters for it are quirecker
[22:34:44 CET] <rainabba> This? [auto-inserted scaler 0 @ 000002745c52dba0] w:1412 h:1080 fmt:yuv422p10le sar:0/1 -> w:1412 h:1080 fmt:yuv422p sar:0/1 flags:0x4
[22:35:12 CET] <JEEB> that means that the filter chain decided to convert to 8bit from 10bit at some point, yes
[22:35:14 CET] <bencoh> hmm
[22:35:50 CET] <rainabba> JEEB: That's the most significant log entry in light of the conversion you pointed out?
[22:35:55 CET] <bencoh> why would you still have fmt:yuv422p10le in the chain?
[22:36:06 CET] <bencoh> if you moved to uyvy?
[22:36:16 CET] <JEEB> he probably was looking at an old log?
[22:36:20 CET] <rainabba> yep
[22:36:58 CET] <rainabba> Here's the new one: http://pastebin.com/gBvVpZZE
[22:38:18 CET] <rainabba> Okay, between my want to play with opencl, NVENC and QSV along with that buffer (potentially), I need another build (for windows). Can you guys recommend one? If not, best compiling guide you can suggest?
[22:38:57 CET] <rainabba> For that matter, is the opinion still that NVENC and QSV produce garbage in light of the benefits or have them improved?
[22:42:23 CET] <JEEB> compiling with msys2's mingw-w64 environment should be relatively easy
[22:42:34 CET] <JEEB> so I recommend that over random builds
[22:42:48 CET] <rainabba> ty
[22:42:49 CET] <JEEB> not to mention that you usually only need a couple of dependencies
[22:43:14 CET] <JEEB> the GPU-based ASIC things are only good if you absolutely can't handle stuff otherwise
[22:43:27 CET] <JEEB> or if you are just not giving a darn about quality and have way underpowered CPUs
[22:43:41 CET] <JEEB> (at which point I am not sure if you have stuck your money into the wrong place)
[22:44:08 CET] <JEEB> opencl can be "fun" because you have to take into mention that data has to be pushed onto the GPU and then put back
[22:44:13 CET] <JEEB> keep that in mind
[22:44:24 CET] <JEEB> latency n' all
[22:44:27 CET] <rainabba> I need https://msys2.github.io/ and http://mingw-w64.org/doku.php then code and in theory, nothing more? (have 3 version of VS installed already)
[22:44:44 CET] <JEEB> msys2 should already package 32bit and 64bit mingw-w64 packaged
[22:45:02 CET] <JEEB> so installing the toolchains from its package management is most probably going to be the path of least resistance
[22:45:34 CET] <rainabba> So just install msys2 and use it to provide any other dependencies for the toolchain?
[22:45:57 CET] <JEEB> I am not sure about that, but you should be able to grab yasm and basic building tools with it
[22:46:07 CET] <bencoh> you can have a look at win-builds.org too
[22:46:11 CET] <rainabba> JEEB: What about pure CPU vs QSV, same conclusion?
[22:46:19 CET] <JEEB> pretty much
[22:47:03 CET] <rainabba> bencoh: That instead of msys2?
[22:48:00 CET] <bencoh> if you feel the need for some "easy" windows buildenv installation on linux
[22:48:25 CET] <rainabba> I'm live-streaming 1080p60 with unsharp right now at 60% CPU so that's not too bad. Might not hold up to the UHD stuff though so I don't think even an 8-core would make me feel safe. Other CPU considerations that might buy me more capacity? Not afraid to invest in CPU if that's the way to go.
[22:48:37 CET] <rainabba> bencoh: Ahh
[22:48:54 CET] <rainabba> I'd prefer to build on Windows, but that's good to know.
[22:50:08 CET] <bencoh> are those real 8cores, or hyperthreading?
[22:50:15 CET] <rainabba> Hmm. Getting a couple rows of macro-blocks that are freaking out :/
[22:50:40 CET] <rainabba> bencoh: I've got a real 6-core now and can get 8. Is hyperthreading any good with encoding?
[22:50:53 CET] <bencoh> absolutely not :)
[22:51:34 CET] <rainabba> Figured :)
[22:51:53 CET] <rainabba> Does it make things worse, or just not help?
[22:52:06 CET] <bencoh> YMMV
[22:52:20 CET] <rainabba> gotcha
[22:52:53 CET] <bencoh> in my case it helped a bit with other processes running on the server
[22:53:48 CET] <rainabba> The unsharp filter supports opencl when it's enabled, that should help (offloading to opencl) right?
[22:59:11 CET] <JEEB> not necessarily
[22:59:15 CET] <JEEB> opencl is not a magic bullet
[22:59:22 CET] <JEEB> as I noted, it has its latencies etc
[22:59:35 CET] <JEEB> also I wouldn't be surprised if the opencl filters were just POCs
[23:00:27 CET] <JEEB> also I definitely recommend looking at your bottlenecks before thinking of more cores
[23:00:41 CET] <JEEB> more cores don't help jack shit if you can't utilize them
[23:04:52 CET] <rainabba> I've got HT on right now (with a real 6-core) and have the load down to around 40%. I'm under the impression that x264 will use more threads if they're there which would bring the load down more (allowing perhaps a 2nd stream of the same). No?
[23:05:38 CET] <JEEB> I think at this point libx264 is the least of your issues, esp. if you're doing thread-per-picture threading instead of slice-based threading
[23:06:28 CET] <JEEB> that can utilize your stuff pretty well up until I think 80 samples in height? I really don't remember the threading limitations in libx264 with picture-based threads
[23:06:31 CET] <rainabba> Trying to figure out the "splitting" idea with UDP, but I think I'm missing a networking concept here. If I use: "-f mpegts -muxrate 12000k udp://192.168.10.10:5501?pkt_size=1316C", then I should be able to hit the same address on that machine as an input to then push to another machine, or do transcodes and such right?
[23:07:31 CET] <bencoh> when in auto threads mode x264 spawns a number of threads based on the number of cpu threads available
[23:07:41 CET] <JEEB> yes
[23:07:45 CET] <bencoh> enabling HT would roughly double that value
[23:07:46 CET] <JEEB> *3/2
[23:07:52 CET] <JEEB> is the algo
[23:08:07 CET] <bencoh> but as JEEB said it's not your issue right now
[23:08:08 CET] <JEEB> for logical cores (as opposed to physical)
[23:08:14 CET] <jookiyaya> does ffmpeg still has:  libfdk_aac, libvo_aacenc
[23:08:32 CET] <JEEB> I think vo_aacenc was removed as it's way worse than the libavcodec one by now
[23:08:45 CET] <jookiyaya> what is libavcodec
[23:08:59 CET] <jookiyaya> according to ffempg it has  aac, libfaac, libfdk_aac, libvo_aacenc
[23:09:01 CET] <rainabba> JEEB: Okay. That's a bit over my head still. You mentioned bottlenecks before cores. Based on that log, can you suggest more I can do to identify/reduce bottlenecks? I assume you don't mean RAM/IO (which shouldn't be an issue right now with my 32GB DDR4, Quad-Channel and Samsung Pro 950 nvme)
[23:09:02 CET] <JEEB> the library in FFmpeg that handles video/audio/subtitle encoding and decoding
[23:09:17 CET] <JEEB> jookiyaya: it's the "aac" one
[23:09:27 CET] <JEEB> that's ffaac which is the libavcodec internal one
[23:09:41 CET] <JEEB> vo_aacenc was removed lately due to the reasons I mentioned
[23:09:56 CET] <JEEB> fdk_aacenc can still be used, but it's probably only useful if you require HE-AAC
[23:09:57 CET] <jookiyaya> you just gave me 2 different answers
[23:10:19 CET] <JEEB> no, I did not
[23:10:26 CET] <JEEB> I am just detailing my replies :P
[23:10:43 CET] <bencoh> jookiyaya: ffac == default aac, libfaac is a wrapper around the FAAC project
[23:10:58 CET] <JEEB> which was also removed I think
[23:10:59 CET] <JEEB> lately
[23:11:12 CET] <JEEB> because only the internal one and the fdk_aac one are worth using at this point
[23:11:16 CET] <jookiyaya> is libavcodec = libfaac  ?
[23:11:19 CET] <JEEB> no
[23:11:35 CET] <JEEB> libavcodec is a part of FFmpeg that contains video/audio/subtitle decoders and encoders (and their wrappers)
[23:12:23 CET] <JEEB> the "lib" somethings are libavcodec things that use a separate library in the background, otherwise it's a thing that is internal to libavcodec and doesn't require 3rd party libraries to work
[23:12:50 CET] <jookiyaya> okay let's start over; how many different aac encoder is in ffmpeg now?
[23:13:29 CET] <bencoh> git pull && find libavcodec -iname "*aac*" ? :)
[23:13:48 CET] <ethe> two, the native one and libfdk-aac
[23:13:48 CET] <bencoh> but JEEB pretty much answered your question now
[23:13:52 CET] <jookiyaya> C:\> git pull && find libavcodec -iname "*aac*"
[23:13:52 CET] <jookiyaya> 'git' is not recognized as an internal or external command,
[23:13:52 CET] <jookiyaya> operable program or batch file.
[23:14:02 CET] <JEEB> in FFmpeg itself without 3rd party libraries there's one
[23:14:05 CET] <bencoh> ah, windows, nevermind :p
[23:14:11 CET] <JEEB> there is also one that is based on 3rd party library, fdk-aac
[23:14:14 CET] <JEEB> as I noted
[23:14:44 CET] <jookiyaya> i thought ffmpeg removed fdk-aac
[23:14:49 CET] <jookiyaya> due to licensing issue
[23:15:00 CET] <JEEB> no, it just made it usable only if you made your binary non-distributable
[23:15:19 CET] <rainabba> I'm seeing nasty artifacts that stick around for a while (until motion occurs?). What might that be about?
[23:15:59 CET] <JEEB> the license incompatibility means that you cannot distribute the binary and have both licenses be OK
[23:16:00 CET] <ethe> jookiyaya: there are patents in the code, but libfdk-aac is released as open source
[23:16:09 CET] <JEEB> the patents have nothing to do with it
[23:16:40 CET] <JEEB> it's with the license specifically noting that you have to do some things to be able to distribute binaries, among other things
[23:16:59 CET] <JEEB> FFmpeg has never cared about patents as such, otherwise we would not have DCA or Dolby formats' decoders
[23:17:07 CET] <ethe> "The license states that the library may only be distributed as authorized by patent licenses"
[23:17:18 CET] <JEEB> yes, that is a *license* issue
[23:17:26 CET] <JEEB> not a *patent* issue
[23:17:27 CET] <ethe> yeah, my bad
[23:17:29 CET] <JEEB> two different things
[23:17:37 CET] <jookiyaya> i don't fdk anymore when i do   ffmpeg.exe -encoders
[23:17:49 CET] <JEEB> that's because you built without it
[23:18:02 CET] <jookiyaya> i didn't do anything
[23:18:19 CET] <JEEB> if it's a random binary from somewhere near a road then it most probably is built without it
[23:18:29 CET] <JEEB> because building with fdk-aac makes the binary non-distributable, as I said
[23:18:36 CET] <JEEB> you have to set --enable-nonfree
[23:18:45 CET] <JEEB> (and have the fdk-aac libraries around when building)
[23:19:18 CET] <JEEB> that said, if you are using a new enough FFmpeg and don't need HE-AAC you can just use the internal aac encoder
[23:19:38 CET] <JEEB> fdk-aac's main good point at this point is HE-AAC support, which the intenral encoder doesn't yet support
[23:19:55 CET] <jookiyaya> internal aac encoder =  aac  or faac ?
[23:20:18 CET] <JEEB> internal stuff is often called ffSOMETHING, but fSOMETHING is a different thing
[23:20:41 CET] <rainabba> Reducing GOP makes the issues go away much more quickly so it seems like bad B frames somehow.
[23:20:44 CET] <JEEB> faac is another library that also was found to be non-distributable
[23:20:57 CET] <jookiyaya> jeeb since when
[23:21:18 CET] <JEEB> I think it was found that it was using reference code licensed under a non-compatible license in around 2011 or so?
[23:21:24 CET] <jookiyaya> i see
[23:21:27 CET] <JEEB> after which it was put under --enable-nonfree
[23:21:50 CET] <jookiyaya> so ffmpeg removed 3 aac encoders   libvo_aacenc, fdk and faac
[23:21:55 CET] <JEEB> uhh, no
[23:22:04 CET] <JEEB> at most only vo_aacnenc and faac were removed
[23:22:14 CET] <JEEB> all of those three are wrappers around 3rd party libraries
[23:22:41 CET] <JEEB> (also libaacplus was also removed because fdk-aac supports HE-AAC well enough)
[23:22:47 CET] <JEEB> (and both are nonfree)
[23:23:52 CET] <JEEB> so now you can build FFmpeg with the following AAC encoders: internal (ffaac, shows up as just 'aac'), and libfdk_aac (requires the 3rd party library and --enable-nonfree, making that FFmpeg build[4~ nondistributable)
[23:24:15 CET] <jookiyaya> i see
[23:24:55 CET] <jookiyaya> so you cannot include faac anymore even if you build it yourself with --enable-nonfree
[23:25:15 CET] <JEEB> no, it is now worse than both fdk-aac and the internal aac encoder anyways
[23:25:19 CET] <JEEB> so there is no reason to have it
[23:25:26 CET] <JEEB> same with vo_aacenc and libaacplus
[23:25:43 CET] <jookiyaya> i see
[23:25:48 CET] <JEEB> if there is an alternative that does things better, why leave the worse things in there :P
[23:26:11 CET] <JEEB> if you are only going to be encoding LC-AAC then you are fine with just the internal one
[23:26:18 CET] <JEEB> since it's much better than it used to be
[23:26:38 CET] <jookiyaya> according to ffmpeg site:  libopus > libvorbis >= libfdk_aac > aac > libmp3lame >= libfaac >= eac3/ac3 > libtwolame > vorbis > mp2 > wmav2/wmav1
[23:26:56 CET] <JEEB> that is rather random
[23:27:02 CET] <jookiyaya> sorry
[23:27:03 CET] <furq> is anyone else getting a sense of déjà vu
[23:27:12 CET] <jookiyaya> they didn't include  libvo_aacenc  in that ranking list
[23:27:23 CET] <JEEB> because it's stereo only and shit
[23:27:35 CET] <JEEB> even before the major improvements the internal one was better off
[23:27:56 CET] <JEEB> it was only taken in because it was interesting at the time it was pushed to android
[23:28:03 CET] <JEEB> but google also noticed it was shit
[23:28:09 CET] <JEEB> so it was there only for less than a year I think
[23:28:13 CET] <jookiyaya> what does google use now then
[23:28:13 CET] <JEEB> replaced by fdk-aac
[23:28:58 CET] <JEEB> anyways, I've now noted a couple of times under which cases you want fdk-aac
[23:29:07 CET] <jookiyaya> if libopus is so great, how come nobody uses it
[23:29:08 CET] <JEEB> which is if you want HE-AAC encoding
[23:29:28 CET] <jookiyaya> i see
[23:29:43 CET] <jookiyaya> and when does someone wants to use he-aac encoding method?
[23:29:51 CET] <JEEB> when you want to go under 64kbps
[23:29:58 CET] <jookiyaya> i see
[23:30:20 CET] <AlexQ> 64 per channel or per 2 channels?
[23:30:29 CET] <JEEB> for stereo
[23:30:32 CET] <jookiyaya> alexq good question
[23:31:37 CET] <JEEB> but really, you should know if you are doing encoding like that :P
[23:31:44 CET] <JEEB> base your ffmpeg build on your requirements
[23:31:45 CET] <jookiyaya> i am surprised that ffmpeg support wma?  i thought wma is closed
[23:32:03 CET] <JEEB> that encoder is shit, but exists because someone cared to implement it
[23:32:11 CET] <JEEB> it's still shit because nobody really cares
[23:32:35 CET] <jookiyaya> but how did they manage to include closed source encoder
[23:32:40 CET] <JEEB> they didn't
[23:32:49 CET] <JEEB> they looked at how the format works by looking at references
[23:32:56 CET] <JEEB> and implemented accordingly
[23:33:05 CET] <jookiyaya> so it's not even real
[23:33:22 CET] <JEEB> as long as it creates the format it is "real"
[23:33:26 CET] <JEEB> or decodes it correctly
[23:33:34 CET] <JEEB> that's as real as it gets
[23:33:40 CET] <jookiyaya> ok
[23:34:05 CET] <jookiyaya> what do you think about the author putting opus as #1
[23:34:13 CET] <jookiyaya> is that bias?
[23:34:41 CET] <JEEB> it's a random list. opus is really good and if you can use it with lossy encoding, you should
[23:34:51 CET] <JEEB> if you can't due to hw decoding etc
[23:34:57 CET] <JEEB> then that's a limitation of your use case
[23:35:12 CET] <JEEB> there's a reason why European Broadcasting Union got opus standardized in broadcast
[23:35:20 CET] <jookiyaya> i have yet to seen a single opus encoded file
[23:35:34 CET] <jookiyaya> jeeb how recent?
[23:35:35 CET] <furq> do you not use youtube
[23:35:45 CET] <jookiyaya> furq huh?
[23:35:53 CET] <jookiyaya> i use youtube
[23:35:56 CET] <JEEB> youtube has pretty much all of its stuff available as opus
[23:36:00 CET] <furq> then you've heard plenty of opus encoded files
[23:36:07 CET] <jookiyaya> i see
[23:36:16 CET] <JEEB> you get fed either avc+aac or vp8+vorbis or vp9+opus
[23:36:33 CET] <JEEB> dpeending on the profile and other things
[23:36:33 CET] <jookiyaya> why no  avc+opus
[23:36:45 CET] <JEEB> because they don't mish-mash them for whatever reason, ask them rather than us :P
[23:36:47 CET] <bencoh> because google bought on2
[23:36:53 CET] <bencoh> :>
[23:37:15 CET] <jookiyaya> bencoh i see, but didn't know vp and opus came as package
[23:37:29 CET] <jookiyaya> i thought they are 2 competely different
[23:37:36 CET] <furq> because webm can't contain avc and mp4 can't contain opus
[23:37:44 CET] <furq> not that it particularly matters now that they're serving ts over dash
[23:37:54 CET] <furq> but they still serve mp4 or webm over http to non-dash clients
[23:37:55 CET] <JEEB> yeah, but they are not limited to that due to using MSE for higher profiles anyways
[23:37:58 CET] <jookiyaya> does flv container support opus?
[23:38:02 CET] <furq> no
[23:38:14 CET] <jookiyaya> then how are they able to use opus
[23:38:16 CET] <JEEB> flv is completely adobe-specific and even adobe has given up on it
[23:38:21 CET] <furq> because they don't use flv?
[23:38:25 CET] <JEEB> 'tube hasn't used FLV for a while
[23:38:28 CET] <furq> because it's not 2008
[23:38:41 CET] <JEEB> go check what profiles youtube-dl lists for you
[23:38:46 CET] <JEEB> when you post a random link into it
[23:38:59 CET] <jookiyaya> if you cannot use flv or mp4  then what can you use opus with
[23:39:21 CET] <JEEB> mpeg-ts, matroska, OGG and raw bit streams as far as I know.
[23:39:25 CET] <JEEB> mp4 is coming
[23:39:27 CET] <furq> you forgot webm
[23:39:33 CET] <JEEB> webm is a matroska subset
[23:39:38 CET] <jookiyaya> webm = container ?
[23:39:40 CET] <JEEB> so it is included there
[23:39:58 CET] <jookiyaya> i have never seen  videofilename.webm
[23:40:27 CET] <furq> well then you must look harder
[23:40:38 CET] <JEEB> the most popular user of such specific files is 4chan, but without seeing the file names youtube is probably the biggest user
[23:41:08 CET] <furq> yeah that's really going to sell him on using it
[23:41:18 CET] <JEEB> I don't give a flying fuck
[23:41:29 CET] <JEEB> if he can't use it due to device limitations he wouldn't use it anyways
[23:42:26 CET] <furq> well this is at least the third run at this exact conversation
[23:42:36 CET] <furq> although to be fair we have at least made it past "why can't i use fdk" this time
[23:42:50 CET] <jookiyaya> i tried to download  webm youtube site:   it saves as  .flv
[23:43:11 CET] <JEEB> then it saves it like that no matter what the data is
[23:43:21 CET] <jookiyaya> it should save as .webm
[23:43:31 CET] <furq> are you downloading it from l33tkrewyoutubeconvert.ru or something
[23:43:31 CET] <jookiyaya> i am confused
[23:43:40 CET] <JEEB> just use youtube-dl to list the profiles for fuck's sake https://rg3.github.io/youtube-dl/download.html
[23:43:48 CET] <JEEB> that should tell you all the available video and audio profiles
[23:44:02 CET] <furq> the only flv format still available on youtube is h.263 and mp3
[23:44:08 CET] <jookiyaya> somebody from firefox  gave me a click thing to convert  youtube video to webm  javascript:if(!location.hash)location.href=location.href+'&webm=1&html5=1';else{location.href=location.href.substr(0,(location.href.length-location.hash.length))+'&webm=1&html5=1'+location.hash}
[23:44:14 CET] <jookiyaya> #firefox
[23:44:54 CET] <furq> well then it's shit
[23:44:59 CET] <furq> otherwise it wouldn't be saving flv
[23:45:24 CET] <JEEB> I don't give a fuck if it was jesus who gave you enlightenment, right now the least retarded tool for looking at what youtube can serve you is youtube-dl
[23:46:13 CET] <JEEB> youtube-dl -F "your-url"
[23:46:16 CET] <JEEB> lists all formats
[23:46:32 CET] <jookiyaya> i see
[23:47:18 CET] <furq> even if that bookmarklet works then i assume it'll download the http webm which is vp8+vorbis anyway
[23:47:20 CET] <JEEB> example http://up-cat.net/p/39f8900f
[23:47:43 CET] <jookiyaya> furq how did you know it was bookmarklet
[23:48:24 CET] <JEEB> not sure if it discerns the opus/vorbis correctly or this video just didn't hit youtube's random decision algorithms regarding opus
[23:49:03 CET] <jookiyaya> so many different format show up when i use that command
[23:49:19 CET] <jookiyaya> even 3gp
[23:49:20 CET] <JEEB> http://up-cat.net/p/68a1219d
[23:49:32 CET] <JEEB> yes, it lists literally everything youtube can offer :P
[23:49:43 CET] <JEEB> they have all kinds of weird crap for very old mobile devices and such
[23:49:44 CET] <furq> did you just trick me into clicking on a totalbiscuit video
[23:49:46 CET] <furq> that's pretty low
[23:49:53 CET] <JEEB> that one had opus
[23:50:25 CET] <jookiyaya> wow google must think opus is better than aac
[23:50:40 CET] <JEEB> fuck if I know
[23:50:42 CET] <jookiyaya> too bad mp4 container doesn't support it
[23:50:53 CET] <JEEB> well I know it's being worked upon
[23:51:05 CET] <JEEB> although even if it is standardized you still have to have things implement it
[23:51:25 CET] <JEEB> https://vfrmaniac.fushizen.eu/contents/opus_in_isobmff.html
[23:51:29 CET] <JEEB> this is the draft
[23:51:29 CET] <jookiyaya> or why don't they just make mkv the standard
[23:51:51 CET] <JEEB> they are trying to standardize that one, but it's a crapshoot that never had a specification for the past 12 years
[23:52:11 CET] <JEEB> if ISOBMFF is fucked, then Matroska is even more fucked
[23:52:34 CET] <jookiyaya> what is isobmff ?
[23:52:40 CET] <JEEB> what you call mp4
[23:52:51 CET] <JEEB> ISO Base Media File Format
[23:53:15 CET] <jookiyaya> ok
[23:54:01 CET] <jookiyaya> google is pushing for vp9  but  h265 is better
[23:54:26 CET] <furq> better how
[23:54:51 CET] <jookiyaya> smaller size for equal quality
[23:56:37 CET] <galex-713> Hi, I heard ffmpeg and libavconv merged again ^^ how did it happen?
[23:56:50 CET] <J_Darnley> That's news to me
[23:57:28 CET] <furq> i heard that elvis is still alive and he works at burger lord
[23:57:38 CET] <galex-713> ?
[23:59:12 CET] <jookiyaya> galex-713 what is libavconv ?
[00:00:00 CET] --- Mon Mar  7 2016