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

[burek]

[00:00:12 CET] <JEEB> *-profile:v baseline
[01:12:18 CET] <kinkinkijkin> does ffmpeg no longer provide libav.so.57 ?
[01:12:48 CET] <JEEB> API version got bumped
[01:12:56 CET] <kinkinkijkin> hmmm
[01:13:01 CET] <JEEB> also it's libavcodec most likely :P
[01:13:13 CET] <JEEB> no idea what libav.so is :P
[01:13:14 CET] <kinkinkijkin> ah yes I forgot the codec part
[01:13:38 CET] <kinkinkijkin> anyways obs still builds against .57, regardless of if I build manually, so I've been having some issues
[01:13:48 CET] <kinkinkijkin> know if the arch packages is updated to the api bump yet?
[01:13:59 CET] <kinkinkijkin> might go back to the non-git version but I noticed the version bumped
[01:14:27 CET] <JEEB> any project building against FFmpeg should be building against the non-versioned lib
[01:14:36 CET] <JEEB> and then that would be symlinked to some version during build time
[01:14:50 CET] <JEEB> so if it was built with a newer git version like you say it wouldn't matter
[01:14:55 CET] <kinkinkijkin> hmmm
[01:14:57 CET] <kinkinkijkin> strange issue then
[01:15:16 CET] <JEEB> if the issue is that you're taking in random binaries of OBS then that's a problem of course
[01:15:19 CET] <JEEB> :P
[01:15:29 CET] <kinkinkijkin> no, I'm building my own
[01:16:06 CET] <kinkinkijkin> I've rebuilt ffmpeg manually, would you really think I'd be dumb enough to take in random binaries off the web?
[01:16:24 CET] <JEEB> well if things don't work that's the first possibility
[01:16:26 CET] <JEEB> and not saying random
[01:16:33 CET] <JEEB> just that it might be a distro package or whatever
[01:16:40 CET] <kinkinkijkin> hmm
[01:16:57 CET] <kinkinkijkin> ABS package didn't work, neither did the git aur package, for rebuilding obs
[01:59:09 CET] <rajkosto> JEEB, do you know how to explicitly use dxva2/d3d11va to decode h264 ? it has something to do with setting the appropriate pixfmt
[02:03:40 CET] <jkqxz> rajkosto:  Look at the hw_decode example.
[02:04:29 CET] <rajkosto> oooh when did this get made
[02:10:33 CET] <rajkosto> this is too recent, not available in my version
[02:13:14 CET] <jkqxz> Upgrade?
[02:13:31 CET] <jkqxz> Making it work in older versions is ... not fun.
[02:13:42 CET] <rajkosto> cant, the null packet flush is not working in newer versions
[02:19:55 CET] <JEEB> :D
[02:20:13 CET] <JEEB> it really sounds like the simplest way to go about is to implement the "don't reorder" feature in the h264 decoder :P
[02:20:25 CET] <rajkosto> i want to try dxva why you hate
[02:20:32 CET] <JEEB> I don't
[02:20:43 CET] <JEEB> I have a commit in d3d11va for christ's sake
[02:20:43 CET] <rajkosto> its not "dont reorder", its "dynamically adjust how many frames to delay output"
[02:20:43 CET] <JEEB> :D
[02:21:18 CET] <JEEB> hmm, I wonder how complex the rule set for that would be
[02:21:28 CET] <JEEB> and it would still not fix your issue with the other API?
[02:21:35 CET] <JEEB> unless you give it a good kick and change it
[02:21:45 CET] <rajkosto> how change binary compatibility
[02:23:29 CET] <JEEB> what on earth are you thinking about :P
[02:24:02 CET] <rajkosto> ill try the hw_decode sample with new version, which one should i clone
[02:24:47 CET] <JEEB> http://fate.ffmpeg.org/
[02:24:50 CET] <JEEB> check your OS/compiler
[02:25:01 CET] <JEEB> if it passes as usual, just use latest HEAD
[02:25:33 CET] <rajkosto> nice non working windows
[02:25:43 CET] <JEEB> ?
[02:26:08 CET] <JEEB> both mingw boxes from less than 2 h ago build
[02:26:10 CET] <rajkosto> all the msvc are error compiling
[02:26:25 CET] <JEEB> oh, so that I guess what jamrial was fixing 8)
[02:26:32 CET] <JEEB> he had some patches on the ML for that
[02:26:59 CET] <rajkosto> this why i dont change versions unless absolutely necessary
[02:27:09 CET] <JEEB> this is pretty rare :P
[02:27:14 CET] <JEEB> and you always have FATE
[02:27:25 CET] <JEEB> any real breakage gets found out rather quickly
[02:27:48 CET] <JEEB> I mean, build or test breaking stuff
[02:27:54 CET] <rajkosto> how do i find the last one that works
[02:28:39 CET] <jkqxz> Are you actually using MSVC?
[02:28:43 CET] <rajkosto> of course
[02:29:05 CET] <JEEB> 3701d49 was the one that broke it
[02:29:08 CET] <JEEB> so the one before that
[02:30:15 CET] <JEEB> I guess abf669479c0098ab5eb184a167e57a70aabb942b ?
[02:30:30 CET] <JEEB> which is before the atomic removals
[02:31:22 CET] <rajkosto> should i just use 3.4 ?
[02:31:59 CET] <JEEB> you can also do that if you want, do note that things can or not be in any better state :P
[02:32:11 CET] <JEEB> things are after all actively fixed in master, but not many people look at releases
[02:32:17 CET] <JEEB> just so you know
[02:32:22 CET] <rajkosto> releases should at least build on all compilers
[02:32:35 CET] <JEEB> """all"""
[02:32:43 CET] <JEEB> that is a rather wide range
[02:34:31 CET] <JEEB> and any breakage tested by FATE generally gets fixed quickly as I said - and fixes accidentally breaking compilation on relase branches can happen just as well, although less likely in general because of less changes in general. that said I'm not sure if anyone looks too much at FATE when branching off. not that I know the release procedure
[03:30:39 CET] <rajkosto> must i override get_format to use hw decode ? seems that just setting pix_fmt doesnt do it
[03:54:25 CET] <rajkosto> seems like it, and now im getting no frames out
[10:36:52 CET] <kiranbsravi> "java(1128,0x700003430000) malloc: *** error for object 0x7fafa4068a00: pointer being freed was not allocated" error message is thrown upon calling av_write_trailer() in libavformat library while closing the file. I am using libavformat to mux two audio and video streams into a webm file.
[10:40:56 CET] <Fig1024> seems like invalid pointer, maybe some modules were freed prior to your call
[11:01:43 CET] <kiranbsravi> but i haven't freed any modules before calling av_write_trailer()
[11:05:51 CET] <Fig1024> that pointer value is too large to be real, so it's definitely invalid. That memory was overwritten by something, which typically happens when pointer references freed memory. Or when some buffer overrun type of bug happens
[14:28:22 CET] <rajkosto> JEEB, seems like its nothing to do with b-frames, there's always 2-frame latency in h264dec somehow
[14:28:54 CET] <JEEB> have you checked the SPS?
[14:29:07 CET] <JEEB> and/or added debug logging to h264dec
[14:29:19 CET] <rajkosto> whats the ffprobe for that on annex-b file
[14:29:45 CET] <JEEB> I remember someone made a bsf for this stuff with nice logging but I don't remember how it's usable
[14:30:03 CET] <JEEB> I think it might be simpler to do the av_log addition to h264dec
[14:30:33 CET] <JEEB> so you can change the spots where teh delay would be set in the decoder to add av_log logging
[14:30:56 CET] <JEEB> anyways, $dayjob
[14:31:47 CET] <bencoh> rajkosto: how many threads do you have?
[14:31:54 CET] <bencoh> decoding threads that is
[14:32:21 CET] <rajkosto> i even tried setting thread_count = 1, thread_type = 0 (or SLICE), delay = 0
[14:33:14 CET] <bencoh> I (not so) vaguely remember avcdec adding a latency of one frame per thread
[14:33:28 CET] <rajkosto> it should, if you use FRAME threading
[14:33:33 CET] <rajkosto> SLICE/no threading shouldnt
[14:33:48 CET] <bencoh> ah, missed the slice, mybad
[14:35:50 CET] <rajkosto> ctx->delay never changes from my set 0
[14:35:53 CET] <rajkosto> yet the delay is 2
[14:39:50 CET] <dradakovic_> Has anyone ever tried to output FFMPEG streams to DCM or monitored them with a probe? I input the HTTP radio and output it as UDP multicast. When i monitor this stream on probe i can see a massive IAT (Inter Arrival Time of Frames). I would like to lower that time so that DCM has no problems accepting my multicast.
[14:40:07 CET] <dradakovic_> I hope someone has any clue what i mean :)
[14:40:33 CET] <dradakovic_> I do that for a HTTP radio
[14:44:02 CET] <rajkosto> bencoh, on the first avcodec_receive_frame it doesnt even try to decode anything, it fails after get_pkt returns a negative value
[14:46:56 CET] <rajkosto> ff_bsf_get_packet returns EAGAIN, pretty sure i gave it plenty of nals already
[14:47:33 CET] <rajkosto> yep it has 190939 bytes yet its not enough
[14:49:37 CET] <bencoh> "plenty of nals" you do feed it with complete encoded frames, right?
[14:49:43 CET] <rajkosto> yep
[14:50:18 CET] <rajkosto> i eat nals until the picture_num is different in the NAL or whatever, thats a complete frame
[14:50:26 CET] <rajkosto> then i send those in one go as an avpacket
[14:53:17 CET] <rajkosto> theyre in annex-b, ofc
[15:01:36 CET] <rajkosto> ok so its because inside avcodec_send_packet it consumes it immediately  if (!avci->buffer_frame->buf[0])
[15:19:59 CET] <rajkosto> i do get here on the first frame av_log(h->avctx, AV_LOG_DEBUG, "no picture %s\n", out_of_order ? "ooo" : "");
[15:28:29 CET] <Bear10> Has anyone used the nginx-rtmp-module and managed to create a dynamic push endpoint to restream to a desired rtmp?
[15:28:47 CET] <rajkosto> yes
[15:29:30 CET] <Bear10> rajkosto: how did you go about it? since the on_push redirect doesn't support domains and on the server config level I'm unsure how or if it's even possible to introduce dynamic push directives
[15:32:15 CET] <rajkosto> push rtmp://targetserver:1935/targetappname live=1 'flashVer=Nginx pushin to ya';
[15:34:22 CET] <Bear10_> rajkosto: ah ok that's not the same thing i was looking for, it's more like "push $somVar", so i've tried you're approach as well like rtmp://localhost:1935/myapp and then in the myapp configuration having a on_publish do a callback and do a 301 or 302 redirect to facebook for example, but per the documentation it doesn't support hostnames just ips
[15:34:26 CET] <Bear10_> so I have no idea how to resolve that bit
[15:34:49 CET] <rajkosto> you never said the target server needs to be dynamic, no clue then
[15:35:27 CET] <Bear10> thanks for the help, maybe someone else knows :)
[15:35:47 CET] <rajkosto> you can always hack it with exec
[15:35:53 CET] <rajkosto> and just spawn a ffmpeg
[15:38:19 CET] <Bear10> yeah i tried with exec as well but we ran into the same issue where i couldn't put the dynamic endpoint in the config, so i'm thinking i need to do a custom script that launches the ffmpeg in it
[15:38:38 CET] <Bear10> but hey as long as i'm not the onlyone thinking it, means it's probably the easiest approach without modifying modules
[15:38:55 CET] <rajkosto> its better to not look into the code of nginx-rtmp
[15:39:10 CET] <Bear10> hahaha
[15:39:54 CET] <Bear10> thanks rajkosto, gotta run to the vet now, cat's sick but if someone is around please feel free to drop some pointers if there's another solution
[15:40:12 CET] <rajkosto> you realise nginx-rtmp has nothing to do with ffmpeg yea ?
[15:40:30 CET] <Bear10> yeah but it was recommended to me in here, and wasn't sure where else to ask
[15:46:50 CET] <dradakovic_> Guys how much would you set -muxrate if your output was libmp3lame with 256kb bitrate?
[15:48:38 CET] <BtbN> I wouldn't set it at all?
[15:52:47 CET] <dradakovic_> Ok. When i set it, it fixed my graphs on the probe i am monitoring. But in the logs i am getting dts < pcr, TS is invalid
[15:57:04 CET] <DHE> that's an mpegts (format) option, not an MP3 (codec) option
[15:57:43 CET] <DHE> if you're getting that error with a -muxrate set, it means it's probably too low a setting
[15:57:57 CET] <dradakovic_> Ok. But i am indeed streaming output on mpegts
[15:58:11 CET] <dradakovic_> so input is http, converting it to mp3 and streaming it to mpegts
[15:58:20 CET] <dradakovic_> I w ill try a higher number
[15:59:06 CET] <DHE> mpegts has rather high overhead. I would start with 10% on top of the audio bitrate and see how that goes
[15:59:14 CET] <DHE> I'm assuming no video here
[15:59:32 CET] <dradakovic_> you assume right. There is no video
[16:00:02 CET] <dradakovic_> That means if my audio bitrate is 256k, you would start with 25,6k muxrate?
[16:00:10 CET] <TheRock> "No codec could be found for 'vc1'"
[16:00:15 CET] <TheRock> Can you tell me which decoder is required?
[16:00:24 CET] <dradakovic_> sorry missunderstood. I know what you mean
[16:00:31 CET] <TheRock> --enable-decoder=..vc1?
[16:01:38 CET] <JEEB> have a separate ffmpeg.c around to which you can throw `./ffmpeg -decoders |grep -i "vc1"`
[16:01:43 CET] <JEEB> so you don't have to keep asking the channel
[16:01:44 CET] <JEEB> :P
[16:02:04 CET] <TheRock> I have sepcified vc1
[16:02:07 CET] <TheRock> but it doesn't work
[16:02:10 CET] <TheRock> that's why i ask
[16:02:28 CET] <JEEB> do you have the parsers etc also for it if you need to demux it?
[16:03:00 CET] <TheRock> yes i added vc1 in --enable-parser and --enable-demuxer
[16:11:04 CET] <DHE> <dradakovic_> That means if my audio bitrate is 256k, you would start with 25,6k muxrate?  # no, muxrate = 256k * 1.1
[16:11:08 CET] <DHE> that working for you?
[17:23:42 CET] <alexpigment> any idea what's keeping VCE encoder integration from happening?
[17:25:08 CET] <alexpigment> it looks like there was an ongoing thread on the mailing list, but the last message is from october 31
[17:25:40 CET] <Cracki> does it work?
[17:29:37 CET] <alexpigment> not sure. i've tried building ffmpeg with the patch on the mailing list, but I couldn't find a vce/amf encoder in the resultant build
[17:29:44 CET] <alexpigment> it's possible I did something wrong though
[17:30:52 CET] <alexpigment> looking at the mailing list again, it looks like there's some sort of discussion about the lack of an AMD header, so the encoder is off in a default build
[17:30:59 CET] <alexpigment> that's a bit over my head
[17:35:07 CET] <Cracki> amd should just throw its people at it
[17:35:47 CET] <Cracki> I'd very much like to see ffmpeg support recent hw encode of amd processors
[17:36:17 CET] <Cracki> (wait, gpus, right? I had the wikipedia open just minutes ago)
[17:36:32 CET] <alexpigment> gpus, yes
[17:36:50 CET] <alexpigment> although a decent amount of AMD's CPUs have GPUs built in
[17:36:56 CET] <Cracki> so it's similar to nvidia's nvenc, eh?
[17:36:59 CET] <alexpigment> right
[17:37:24 CET] <jkqxz> alexpigment:  Install headers from <https://github.com/GPUOpen-LibrariesAndSDKs/AMF/tree/master/amf/public/include> in an AMF directory somewhere in the standard include path.  Run configure (it's autodetected).
[17:37:26 CET] <Cracki> I like hw encode support :) my 2012 desktop has none (xeon e3 v1, gtx 560)
[17:37:31 CET] <alexpigment> and i don't really have a horse in the race, it's just important that for any modern system (within reason), there should be a hardware encoder available
[17:37:51 CET] <alexpigment> jkqxz: thank you very much, i'll try that out today
[17:38:41 CET] <jkqxz> (Hopefully AMD will make the header installation a bit nicer.)
[17:38:59 CET] <alexpigment> i'm still reading through this thread (which I didn't see until today) about the AMD headers
[17:39:24 CET] <alexpigment> i'm not sure (yet) why anyone would want to leave out headers for AMD, or to remove headers for Nvidia
[17:39:37 CET] <jkqxz> It's very silly.  Including the AMD header is absurd because there is a sensible upstream.
[17:39:41 CET] <alexpigment> this seems like a weird absolutist position that really only makes it annoying for the end user
[17:40:12 CET] <alexpigment> jkqxz: do you mind explaining that in layman's terms?
[17:41:30 CET] <jkqxz> Why would anyone want headers to be included?  It makes all maintenance harder - you can't build with different versions, if there is ever an incompatible change then you have to choose one side or the other, distributions can't fix the version to match everything else in them.
[17:42:03 CET] <alexpigment> "can't build with different versions" = ?
[17:42:07 CET] <alexpigment> different versions of what?
[17:42:37 CET] <jkqxz> The headers or driver.  If bundled headers were updated, the user is probably required to update the driver as well.
[17:43:07 CET] <alexpigment> jkqxz: with hardware encoding, updating drivers has kind of been the norm for quite a while
[17:43:19 CET] <jkqxz> This is exactly what you don't want having done proper testing of a driver for your setup.
[17:43:31 CET] <jkqxz> Only for Nvidia, which forces it on everyone.
[17:43:32 CET] <alexpigment> at any rate, I really appreciate that I didn't have to do anything out of the way to build with Nvidia hardware acceleration
[17:44:03 CET] <alexpigment> what does nvidia force?
[17:44:07 CET] <jkqxz> Would you like the libx264 headers to be included as well?
[17:44:17 CET] <jkqxz> That would be "more convenient" too, wouldn't it?
[17:44:58 CET] <alexpigment> honestly, i'll fully admit ignorance on all of this. I don't know what a header does or doesn't do, and I didn't know libx264 headers weren't included
[17:45:07 CET] <alexpigment> i just know it's very easy to build with x264
[17:45:56 CET] <jkqxz> Because the headers are open and included by all distributions.  AMD headers are open, if they package them properly then it will be easy to have them everywhere.
[17:52:14 CET] <Hinton> Hello, can i get help here for ffmpeg?
[17:55:39 CET] <alexpigment> Hinton: generally, you just come in and ask a question
[17:55:56 CET] <Hinton> ah okay
[17:56:28 CET] <Hinton> i have found ffmpeg while finding a solution to play audible books on my xubuntu
[17:57:00 CET] <Hinton> i can play them with the proper key (aka. 4bytes of security), but if i convert them, they are silent
[17:57:05 CET] <Hinton> any idea why?
[17:58:01 CET] <Hinton>  ffmpeg -loglevel error -stats -activation_bytes "${auth_code}" -i "${path}" -vn  -vol 256 was the command
[18:00:47 CET] <alexpigment> personally, I have no clue. I assume that command works fine on other non-audiobook sources, right?
[18:01:35 CET] <alexpigment> Anyway, this gets into a weird territory re: DRM/copyright
[18:01:49 CET] <alexpigment> but ultimately, if you can play something, you can record it
[18:04:05 CET] <Hinton> oh my god
[18:04:10 CET] <Hinton> that was sooo stupid
[18:05:11 CET] <Hinton> it converts just right, it was muted. i've tested it on two different players, and vlc was set to a different sound output, which was not turnet on
[18:05:17 CET] <Hinton> *turned
[18:05:34 CET] <alexpigment> well there you go :)
[18:06:18 CET] <alexpigment> if it makes you feel any better, I kept trying to figure out why certain videos were quieter or louder in Windows Media Player. turns out there are all this Dolby Digital specific settings that I never knew about
[18:07:01 CET] <Hinton> yeah :D its ALWAYS the user ;) but thanks nonetheless :D it was your tip with the non encrypted file, which made me realize that maybe, just maybe some settings were wrong ^^
[18:16:56 CET] <rajkosto> the reference decoder is able to give me the frames immediately, no 2 frame delay like ffmpeg does
[18:17:44 CET] <rajkosto> and they are in order unlike old ffmpeg with null packets
[18:19:33 CET] <alexpigment> Hinton: no worries. glad you got it figured it out
[18:23:39 CET] <kinkinkijkin> trying to figure out how to pipe to ffmpeg in C# using a really obscure audio backend
[19:10:47 CET] <TheRock> Is .wmv basedo n h263?
[19:11:49 CET] <alexpigment> wmv is several different codecs
[19:12:00 CET] <alexpigment> wmv7 and 8 are based on h263 though
[19:12:02 CET] <TheRock> hm, the problem is
[19:12:06 CET] <TheRock> i build ffmpeg from SRC
[19:12:08 CET] <alexpigment> wmv9 and vc-1 aren't
[19:12:21 CET] <TheRock> and i'd like to know what i must specify for wmv series
[19:12:28 CET] <TheRock> i have now VC1 in demuxer, decoder, parser
[19:12:40 CET] <TheRock> but the other wmv can't be played, one wmv works
[19:12:42 CET] <TheRock> though without sound
[19:12:48 CET] <sfan5> probably helpful: https://en.wikipedia.org/wiki/Windows_Media_Video#Versions
[19:13:38 CET] <alexpigment> TheRock: look at ffmpeg -codecs
[19:14:14 CET] <alexpigment> look for wmv1, wmv2, and wmv3
[19:14:25 CET] <TheRock> i see, that's more helpful
[19:14:31 CET] <alexpigment> i realize it's confusing, but wmv1 = windows media video 7
[19:14:37 CET] <alexpigment> wmv2 = windows media video 8
[19:14:43 CET] <alexpigment> wmv3 = windows media video 9
[19:14:51 CET] <TheRock> sounds like it wmv sucks
[19:15:05 CET] <alexpigment> eh, wmv9/vc-1 was a pretty good format
[19:15:17 CET] <alexpigment> it just doesn't have the broadest support
[19:16:14 CET] <alexpigment> up until windows started integrating H.264 support into Windows Media Player, WMV9/VC-1 was actually a very good option for a format that would play with certainty and have a good compression ratio
[19:16:26 CET] <TheRock> I see
[19:16:41 CET] <TheRock> but i remember that i had to install some codecs on windows 10
[19:16:47 CET] <TheRock> to play an mp4
[19:16:58 CET] <TheRock> K-Lite codec pack
[19:17:09 CET] <alexpigment> that had to have been unrelated to H.264
[19:17:32 CET] <TheRock> isn't mp4 h264?
[19:17:33 CET] <alexpigment> also, K-Like is a good way to screw up the codec associations on your system. i'd highly recommend against installing codec packs
[19:17:41 CET] <alexpigment> TheRock: not always
[19:18:05 CET] <alexpigment> but Windows 10 should have had out-of-the-box support for any of the video codecs within a standard MPEG-4 file
[19:18:16 CET] <alexpigment> i'd guess that either it was an audio format or something else
[19:18:51 CET] <alexpigment> what Windows 10 doesn't have is a built-in MPEG-2 codec. those cheap bastards dropped support in Windows 8, thereby killing native DVD support for a lot of people
[19:19:49 CET] <TheRock> lol
[19:19:59 CET] <TheRock> that's when you would need k-lite codec pack then?
[19:20:34 CET] <alexpigment> i can't think of a scenario where I would ever let K-lite be installed on my system
[19:20:54 CET] <alexpigment> but still, there were other ways around it, especially if you have the Pro version of Windows
[19:21:53 CET] <alexpigment> of course, there are players with built-in codecs that are another option, but the hardware accelerated playback, deinterlacing, and upscaling of Windows Media Player is hard to beat
[19:22:28 CET] <TheRock> yeah, it's optimized for windows
[19:22:30 CET] <alexpigment> anyway, I use Windows 7, so I don't have to deal with any of this first-hand
[19:24:02 CET] <TheRock> there are so many codecs
[19:24:11 CET] <TheRock> the best is probably to built all inside the app
[19:24:22 CET] <TheRock> but the size of my app grows pretty hard
[19:24:38 CET] <TheRock> Now, i'm at 5mb after all codecs 15-20
[19:26:52 CET] <alexpigment> TheRock - yeah, there are definitely a lot of codecs out there
[19:27:14 CET] <alexpigment> but for video codecs, I think you could support the vast majority with only 6-8 codecs
[19:28:46 CET] <alexpigment> and right as I said that, I started counting them in my head, and it's probably more than 6-8 :)
[19:34:08 CET] <TheRock> ./configure --disable-everything --extra-version=QtAV --disable-debug --enable-static --disable-shared --enable-runtime-cpudetect --toolchain=msvc --extra-ldexeflags='-SUBSYSTEM:CONSOLE,5.01' --enable-avresample enable-decoder= wavpack,wmav1,wmav2,wmv1,wmv2,wmv3,mpeg1video,mpeg2video,mpeg4,avi,wma,ogg,wmv,vp8,vp9,opus,vorbis,vc1,mpegvideo,flv,mp3,aac,h264,mpeg2video,mpeg4,asf,swf,mov,wav
[19:34:08 CET] <TheRock> --enable-demuxer=wavpack,wmav1,wmav2,wmv1,wmv2,wmv3,mpeg1video,mpeg2video,mpeg4,wmv,ogg,vc1,m4v,flv,mp3,aac,avi,h264,matroska,pcm_s16le,mov,m4v,rawvideo,wav,mpegvideo,wma,asf,swf,vp8,vp9 --enable-parser=wavpack,wmav1,wmav2,wmv1,wmv2,wmv3,mpeg1video,mpeg2video,mpeg4,ogg,wmv,flv,vc1,vp8,vp9,vorbis,opus,aac,h264,mpeg4video,mpegaudio,mpegvideo,wma,asf,swf,avi,mov,wav --disable-programs --enable-p
[19:34:08 CET] <TheRock> rotocol=file
[19:34:19 CET] <TheRock> I hope this will include now all popular
[19:34:27 CET] <TheRock> i added it for security to parser, demuxer as well
[19:34:35 CET] <TheRock> invalid commands should be ignored
[19:35:54 CET] <alexpigment> well, i can understand explicitly limiting it out, but H.265/HEVC is becoming pretty common
[19:36:15 CET] <TheRock> Is h265 supported?
[19:36:19 CET] <sfan5> >wavpack
[19:36:22 CET] <sfan5> people use that?
[19:36:30 CET] <alexpigment> then there's something like DV, which admittedly has fallen out of use, but was a huge standard for a long time
[19:36:33 CET] <TheRock> i don't know, sounds like its used for .wav files ?
[19:36:51 CET] <sfan5> .wav files usually contain pcm_s16le
[19:36:57 CET] <sfan5> wavpack is yet another codec to compress those
[19:36:59 CET] <alexpigment> yes, h265 is supported
[19:37:23 CET] <TheRock> ah, ok. Gonna remove it then
[19:38:31 CET] <TheRock> alexpigment: is HEVC a different codec?
[19:38:34 CET] <TheRock> or is it enough to add h265
[19:38:43 CET] <alexpigment> it's the same codec
[19:38:46 CET] <TheRock> --enable-decoder=h265
[19:39:18 CET] <alexpigment> all modern video formats have two names, just to mess with people ;)
[19:39:29 CET] <alexpigment> at least two
[19:39:53 CET] <alexpigment> AVC = H.264 = MPEG-4 Part 10
[19:40:15 CET] <alexpigment> HEVC = H.265 = MPEG-H Part 2
[19:40:32 CET] <alexpigment> admittedly, i've never seen anyone say MPEG-H Part 2
[19:42:20 CET] <JEEB> I have, but it's as little used as MPEG-4 Part 10 ;)
[19:42:28 CET] <JEEB> AVC/HEVC are just simpler to write
[19:43:12 CET] <alexpigment> well, with the former, at least H.264 was more commonly used and recognized by the masses (as much as the masses will ever recognize a codec)
[19:43:29 CET] <alexpigment> with H.265 / HEVC, I still don't know what to call it to make the most people understand it
[19:43:45 CET] <alexpigment> it *feels* like HEVC is more prevalent
[19:44:06 CET] <rajkosto> just use AV1 instead :P
[19:44:23 CET] <alexpigment> rajkosto: buy me a card that has hardware support for it, and it's a deal
[19:44:33 CET] <alexpigment> (and also buy a phone that has support for it. thanks ;))
[19:44:41 CET] <kepstin> the name 'av1' is annoying too, because 'av' sounds like 'audio/visual', but it's only a video codec :)
[19:44:48 CET] <alexpigment> oh and lastly, i'm going to need a tv with native support
[19:45:35 CET] <kepstin> (the 'a' is actually supposed to be for 'AOMedia' - 'Alliance for Open Media')
[19:45:49 CET] <TheRock> i added h265
[19:45:53 CET] <TheRock> (ffmpeg 3.4 src)
[19:46:03 CET] <TheRock> but it doesn't appear in the configuration overview
[19:46:14 CET] <flydev> Hi guys, the last ffmpeg compile guide for Ubuntu 16 is broken
[19:46:14 CET] <flydev>  libx265.so.147: cannot open shared object file: No such file or directory
[19:46:22 CET] <TheRock> is there --enable-gpl required?
[19:46:33 CET] <TheRock> I just use it for decoding
[19:46:34 CET] <alexpigment> TheRock: most likely
[19:46:40 CET] <flydev> Already have dozens of Ubuntu 14 hosts with older version compiling and running fine, this one also seems to compile everything fine, but it does not run at all
[19:46:40 CET] <flydev> And can't really figure out why x265 lib is missing when x265 compiles fine
[19:46:42 CET] <sfan5> gpl is required for decoders? o.O
[19:46:47 CET] <alexpigment> as I said earlier, i can understand why someone wouldn't include it
[19:46:48 CET] <TheRock> usually not
[19:46:56 CET] <TheRock> but h265 is not recgonized somehow
[19:47:08 CET] <TheRock> --enable-deocders=h265,h264,h263
[19:47:11 CET] <kepstin> the decoder's called hevc, not h265
[19:47:16 CET] <jkqxz> flydev:  You forgot to run ldconfig after installing a new version?
[19:47:19 CET] <TheRock> oh, ok
[19:47:30 CET] <TheRock> because the previous version was called just 'h264'
[19:47:38 CET] <rajkosto> deocders :P
[19:48:05 CET] <TheRock> yah, just typed that :P. its correct in my build
[19:48:45 CET] <flydev> jkqxz this is on a fresh install of ubuntu 16
[19:48:57 CET] <flydev> following this guide: https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu
[19:50:00 CET] <jkqxz> Well, the install is definitely polluted somehow if it can't find a shared library like that.
[19:50:43 CET] <jkqxz> Since that message implies it was available at link time but not at run time.
[19:50:56 CET] <kepstin> flydev: did you build your own libx265 or just use the distro one (libx265-dev)?
[19:51:19 CET] <jkqxz> (Not having run ldconfig to link SONAMEs being the most obvious way to achieve that.)
[19:51:24 CET] <flydev> or the doc is not reflected to apply for vanilla installs? tried 3 machines, and few VPS'es, tried building my own and the distro one
[19:51:30 CET] <kepstin> this could happen if you built it yourself and had the distro one installed at the same time, and have linking errors
[19:52:42 CET] <flydev> i have the distro one removed by apt-get remove --purge lib265-dev and recompiling my own - no luck
[19:53:56 CET] <kepstin> that removes the dev headers, did you also remove the lib? should be libx265-79 on xenial
[19:54:24 CET] <flydev> how can I get rid of the whole lib? via the commandline that is
[19:54:33 CET] <kepstin> apt-get remove libx265-79
[19:55:43 CET] <kepstin> but if you have other stuff depending on it, that'll remove a lot of things
[19:55:51 CET] <TheRock> Looks like the wmv* codecs add hw accelerators to my build. Could i use --disable-hwaccels to use only software rendering?
[19:56:05 CET] <TheRock> or are they mandatory
[19:56:25 CET] <kepstin> TheRock: unless you explicitly use the hw decoders, ffmpeg will decode in software by default. But feel free to build without them to save space
[19:57:08 CET] <flydev> Package 'libx265-79' is not installed, so not removed .... huh, something is very wrong here...... okay, doing reinstall (again), atleast it's a VPS and it will be quick
[19:57:44 CET] <kepstin> ok, so something's going wrong manually installing libx265 then :/
[19:58:05 CET] <kepstin> it would be helpful to see more context of the failing link command
[19:59:44 CET] <kepstin> i wonder if the issue is that libx265 has changed how they install stuff at some point, so their pkg-config file is broken or something.
[19:59:52 CET] <flydev> yeah, it gets stuck at [ 86%] Building CXX object common/CMakeFiles/common.dir/deblock.cpp.o and failing to allocate memory.... okay, trying with 8 GB RAM..
[20:01:42 CET] <flydev> okay, new take - 16 vCPU, 8 GB RAM, this time i'm not joking, fingers crossed
[20:02:01 CET] <flydev> and doing makes with -j16 if that's of any impotance
[20:02:52 CET] <kepstin> well, reducing the -j will make it use less ram...
[20:04:02 CET] <flydev> I don't have problems with that, it's just that last builds ran and compiled fine with Ubuntu 14 on 2GB RAM
[20:04:19 CET] <flydev> okay, this time no RAM errors, it's compiling the ffmpeg
[20:04:21 CET] <kepstin> newer gcc versions use more ram
[20:04:31 CET] <kepstin> flydev: once you have libx265 installed, can you pastbin the output of these two commands:
[20:04:56 CET] <kepstin> cat ~/ffmpeg_build/lib/pkgconfig/x265.pc ; ls -l ~/ffmpeg_build/lib/libx265*
[20:06:16 CET] <flydev> https://pastebin.com/LtZHZ8GT
[20:06:40 CET] <kepstin> that all looks good
[20:06:48 CET] <flydev> nah, still broken
[20:06:57 CET] <flydev> https://pastebin.com/YAUK7MwE
[20:07:48 CET] <kepstin> ok, that shouldn't be happening, the ffmpeg commands on that page are supposed to build a static ffmpeg
[20:07:51 CET] <flydev> stuff like  : command not found scare me a lot, that's from the compile log, shall i go back to vanilla again?
[20:07:58 CET] <kepstin> it shouldn't be trying to load the .so at all
[20:08:10 CET] <kepstin> are you sure you copied the 'configure' line correctly?
[20:08:57 CET] <flydev> yes, it's a copy/paste from the https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu page, nothing is changed
[20:09:58 CET] <kepstin> that makes no sense; everything's set up to do the static build correctly there :/
[20:10:27 CET] <furq> have you run make clean on ffmpeg after removing the apt libx265
[20:10:53 CET] <flydev> only thing I do add is --enable-openssl like so: https://pastebin.com/Wd7Df5nn
[20:11:46 CET] <flydev> and I have the libssl-dev and openssl installed
[20:11:56 CET] <flydev> okay, will try make clean, just in case
[20:13:14 CET] <flydev> did it, compiling
[20:15:43 CET] <flydev> still broken
[20:20:26 CET] <kepstin> huh, interesting. this set of commands breaks when building x264 on newer ubuntu versions (17.10) because th compiler enables PIC by default there.
[20:20:45 CET] <kepstin> i think? or something weird.
[20:21:14 CET] <kepstin> owell, on 17.10 you get a new enough ffmpeg that there's no much reason to bother building one unless you want something bleeding edge or nonfree
[20:21:52 CET] <flydev> nonfree and openssl ;)
[20:22:19 CET] <flydev> and it must be on a LTS OS
[20:25:25 CET] <kepstin> alright, i see the problem. at some point the x265 cmake must have changed the option used to disable the shared lib build
[20:25:38 CET] <kepstin> it installed the shared lib even though that was supposed to be turned off
[20:26:07 CET] <kepstin> you can probably work around this by just doing `rm ~/ffmpeg_build/lib/libx265.so*` before building ffmpeg
[20:31:44 CET] <flydev> did this, and a make clean in ffmpeg
[20:34:30 CET] <kepstin> huh, weird, it worked for me; only built & installed the static lib like it was supposed to.
[20:35:27 CET] <kepstin> i dunno what went wrong for you with the libx265 build :/
[20:36:02 CET] <kepstin> oh, the timestamps on your 'ls' show the story
[20:36:42 CET] <kepstin> looks like you built it on dec 1, something went wrong (copy/paste error on cmake command maybe?) then rebuilt it correctly on dec 4 but the old lib was left there
[20:36:59 CET] <flydev> running compile after make clean on ffmpeg and rm ~/ffmpeg_build/lib/libx265.so and because I did a reboot it's with 1 CPU core doing the compile which will take a while
[20:37:40 CET] <kepstin> starting again on a fresh machine would have fixed it, or deleting the bin and ffmpeg_build directories :/
[20:38:40 CET] <flydev> https://pastebin.com/Z8bDBKQW
[20:46:03 CET] <flydev> and it's a success!
[20:46:10 CET] <flydev> root at enc7-bg:~/ffmpeg_sources/ffmpeg# /root/bin/ffmpeg ffmpeg version N-89387-gd67c1dd Copyright (c) 2000-2017 the FFmpeg developers   built with gcc 5.4.0 (Ubuntu 5.4.0-6ubuntu1~16.04.5) 20160609
[20:46:53 CET] <flydev> Okay, so I need to edit the script to compile from source and do rm ~/ffmpeg_build/lib/libx265.so* + make clean before building ffmpeg?
[21:12:05 CET] <TheRock> External libraries:
[21:12:05 CET] <TheRock> schannel                xlib
[21:12:11 CET] <TheRock> what's this for?
[21:12:15 CET] <TheRock> and can it be disabled?
[21:14:50 CET] <alexpigment> i think schannel is for old TLS support
[21:14:58 CET] <alexpigment> you can do --disable-schannel i believe
[21:16:03 CET] <alexpigment> i suppose you could try --disable-xlib too, but I'm not sure what that does
[21:17:21 CET] <therage3> ok, so
[21:17:30 CET] <TheRock> both, got accepted. reconfiguring now. thx
[21:17:46 CET] <TheRock> i will see, if it still runs afterwards ;)
[21:17:56 CET] <therage3> if CRF for x264 is unchanged, but preset is moved around, the quality of the image stays the same, just the file size that changes, right?
[21:18:51 CET] <BtbN> depends
[21:18:57 CET] <alexpigment> therage3: I had this understanding as well, but I believe I've heard that the quality changes too
[21:19:00 CET] <BtbN> slower presets also enable more features
[21:19:01 CET] <alexpigment> which is confusing
[21:19:04 CET] <therage3> uh
[21:19:05 CET] <therage3> wat
[21:19:10 CET] <BtbN> which might result in better quality
[21:19:10 CET] <therage3> ok, this is confusing as hell, now
[21:19:40 CET] <BtbN> If you set x264 to ultrafast, it will output constained baseline
[21:19:44 CET] <alexpigment> therage3: it's most likely because quality is based on the feature set, so you can't guarantee a 1:1 quality level when using different features
[21:19:46 CET] <BtbN> Which obviously results in worse quality
[21:19:49 CET] <therage3> BtbN, alexpigment, i always thought the quality itself doesn't change, like how a png or flac's compression level changes but the image or the sound is identical otherwise
[21:19:52 CET] <kepstin> therage3: in general, the meaning of a particular crf value depends on a bunch of other x264 options, and changing the preset changes some of those options.
[21:20:03 CET] <therage3> kepstin: i see, so that's the reason then
[21:20:10 CET] <therage3> the crf changes some stuff under the hood!
[21:20:11 CET] <therage3> that explains it
[21:20:18 CET] <BtbN> no it doesn't
[21:20:19 CET] <kepstin> no, the preset changes some stuff
[21:20:20 CET] <BtbN> the preset does
[21:20:21 CET] <alexpigment> therage3: no, the preset changes things under the hood
[21:20:25 CET] <therage3> er
[21:20:28 CET] <therage3> yes, sorry
[21:20:30 CET] <therage3> the preset*
[21:20:31 CET] <BtbN> It's a preset, as the name might suggest
[21:20:38 CET] <BtbN> a pre-set set of options
[21:20:43 CET] <therage3> ahh interesting
[21:21:05 CET] <BtbN> Nobody wants to touch all the multiple dozens of options it has
[21:21:09 CET] <kepstin> basically, the x264 preset system was introduced because people kept copy/pasting bad x264 option lists off of forums and wikis
[21:21:21 CET] <kepstin> so the devs decided to pick some good ones and put them into presets
[21:21:22 CET] <therage3> so the names "slower", "placebo", etc. are just "user friendly" things so that people just think of it in terms of speed
[21:21:28 CET] <therage3> and not what actually changes under the hood
[21:21:40 CET] <alexpigment> right
[21:22:25 CET] <therage3> the problem then of course is that hiding the technical details gives people this misconception
[21:22:34 CET] <therage3> the misconception that i addressed myself personally
[21:22:47 CET] <therage3> and now know better
[21:23:24 CET] <alexpigment> this does bring up a good question though: are the CRF values assigned with the respect to the preset? in other words, is there any code to make CRF 20 look close to each other for both veryfast and slow?
[21:23:49 CET] <kepstin> alexpigment: the crf values have no intrinsic meaning, there actually an internal part of the two-pass rate control mechanism
[21:24:11 CET] <therage3> so whenever you use crf, internally ffmpeg does a two-pass thing?
[21:24:20 CET] <alexpigment> therage3: well, i think it does pass 1
[21:24:26 CET] <therage3> ...
[21:24:29 CET] <kepstin> when you do crf, x264 effectively does only the 2nd pass of a two-pass encode
[21:24:33 CET] <therage3> ^
[21:24:40 CET] <therage3> that's what i meant, alexpigment
[21:24:55 CET] <therage3> why is ffmpeg so complicated
[21:24:59 CET] <therage3> none of this is online anywhere
[21:25:08 CET] <kepstin> we haven't even gotten into ffmpeg stuff, this is all libx264 ;)
[21:25:27 CET] <therage3> everyone just blurts out that presets only change speed of encoding and the size, and if crf is the same, image quality is the same
[21:25:54 CET] <therage3> thank God IRC exists
[21:26:13 CET] <kepstin> i mean, quality will generally be *close*, as long as you're not comparing ultrafast and veryslow or something like that
[21:26:23 CET] <kepstin> but it won't be the same.
[21:26:29 CET] <therage3> great, now my ocd is going to kick in
[21:26:37 CET] <therage3> why did i have to learn about this ._.
[21:27:06 CET] <kepstin> the rule of thumb for using x264 is "pick the slowest preset you can handle, then pick a crf that gives you the quality you want"
[21:27:15 CET] <therage3> yeah, that sounds good
[21:27:22 CET] <therage3> also, one more thing... i keep reading conflicting information
[21:27:24 CET] <kepstin> the downside is that doing a fast test encode won't give you a completely accurate idea of quality.
[21:27:26 CET] <alexpigment> I use medium CRF 18 on most things fwiw
[21:27:39 CET] <therage3> is crf 0 lossless in the true sense of that word?
[21:27:47 CET] <alexpigment> because hard drives are cheap and my time is valuable
[21:27:48 CET] <therage3> because here's the issue
[21:27:57 CET] <alexpigment> therage3: yes
[21:28:03 CET] <kepstin> therage3: with 8bit x264 yes, with 10bit, no. Use the "-qp 0" option instead which is lossless in both.
[21:28:04 CET] <therage3> crf 0 is one thing, but depending on preset, that then changes, right?
[21:28:26 CET] <alexpigment> kepstin: there you go screwing up my understanding of the universe again ;)
[21:28:37 CET] <therage3> my brain just exploded a second time again today
[21:28:52 CET] <alexpigment> crf 0 will be lossless for 8-bit (apparently) at any preset, but the file size will change depending on the preset
[21:28:54 CET] <therage3> then again i see yup420 or whatever on most of my stuff which i think is 8-bit
[21:29:18 CET] <alexpigment> yuv420p is different than the depth
[21:29:31 CET] <alexpigment> 4:2:0 is chroma subsampling
[21:29:33 CET] <kepstin> note that using -qp 0 or -crf 0 (on 8-bit) triggers a separate lossless mode, and it doesn't follow the normal crf pattern really
[21:29:35 CET] <alexpigment> 8-bit is the bit depth
[21:29:43 CET] <therage3> ahhhh i see kepstin
[21:29:54 CET] <therage3> that explains why it's truly lossless regardless of preset then
[21:29:57 CET] <kepstin> both options do exactly the same thing
[21:30:06 CET] <alexpigment> crf 0 will also change your profile to yuv444pp i believe
[21:30:44 CET] <alexpigment> which, for compatibility reasons, can be problematic. then again, a crf 0 video is likely to be problematic for playback anyway due to the bitrate
[21:30:51 CET] <kepstin> you can still encode yuv420p in lossless, but the h264 profile with be one that requires the decoder support 4:4:4 modes
[21:30:52 CET] <therage3> yeah i know
[21:30:53 CET] <therage3> i figured
[21:31:02 CET] <therage3> i just asked out of curiosity
[21:31:40 CET] <therage3> i guess unlike png and flac, there's nothing that takes a DVD or a BluRay and compresses it losslessly yielding a smaller filesize, to my knowledge
[21:31:51 CET] <therage3> because my experiments with crf 0 was GINORMOUS file
[21:32:00 CET] <kepstin> therage3: that's impossible, because DVD and Bluray are already encoded with a lossy codec
[21:32:05 CET] <therage3> right i see
[21:32:14 CET] <alexpigment> most modern formats are optimized to the point where you couldn't save much anyway at lossless quality
[21:32:38 CET] <kepstin> I mean, you can re-encode a DVD to a way smaller file with no *visible* loss using x264
[21:32:38 CET] <alexpigment> modern codecs are usually only better at "looking better" while being lossy
[21:32:52 CET] <alexpigment> lossless encoding doesn't have much to optimize
[21:33:33 CET] <kepstin> but using a lossless codec to re-encode a lossy source makes no sense, because the lossless codec has to carefully and perfectly reproduce all the artifacts added by the original lossless codec.
[21:33:38 CET] <alexpigment> unlike PNG and FLAC, which were based on very old compression standards
[21:33:50 CET] <alexpigment> rather, they were improvements on old standards
[21:33:54 CET] <therage3> kepstin: i guess what i meant is, lossless with respect to the master one possesses (in this case, a DVD or a Blueray), but yeah i understand
[21:33:57 CET] <alexpigment> (BMP and WAV)
[21:34:06 CET] <jfmcarreira> heyy guys. I am using the following code to read stream using libav: http://dpaste.com/1HAP5PQ
[21:34:09 CET] <kepstin> (I mean, it might be useful as a temp file if you're doing multi-step edits to avoid more generation loss than necessary)
[21:34:11 CET] <therage3> like, we don't have the 16mm film elements from the studio, of course
[21:34:28 CET] <jfmcarreira> However the function av_read_frame is always returning EOF error
[21:36:37 CET] <alexpigment> therage3: one other thing to keep in mind about CRF is that you need to choose based on the resolution of the original media. you notice the lack of quality more on SD sources, presumably because the pixels are going to be bigger when you fullscreen
[21:37:02 CET] <alexpigment> so you might be able to get away with CRF 22 or something on an HD video, but CRF 22 is getting into that "too lossy" territory for SD content
[21:37:21 CET] <therage3> alexpigment: yes, precisely. this is evident on the cartoon we were discussing some days ago, from which i still cannot eliminate that pesky hard telecine
[21:37:31 CET] <therage3> i just use a filter for it in the media player :D
[21:38:17 CET] <alexpigment> yeah, fortunately, cartoons compress well
[21:38:25 CET] <therage3> there's a problem though
[21:38:32 CET] <alexpigment> you can just set the CRF to something really low (like 14-16) and just leave it
[21:38:36 CET] <therage3> the compressed lossy version apparently throws the filter off
[21:38:43 CET] <therage3> and it doesn't eliminate it that well
[21:39:02 CET] <alexpigment> i can understand how that would happen
[21:39:23 CET] <alexpigment> if you are trying to match fields and you have more compression artifacts in one field compared to the matching other field, then it might not see them as the same
[21:39:29 CET] <therage3> exactly
[21:39:53 CET] <alexpigment> having said that, I never really have that problem with detelecine on lossy sources
[21:39:54 CET] <therage3> but when i play back the uncompressed mkv, which is just a stream copy from the dvd mpeg2 stream, it does it flawlessly
[21:39:58 CET] <alexpigment> i've never tried to use fieldmatch though
[21:40:05 CET] <therage3> well, note that i did use crf 22
[21:40:12 CET] <therage3> so i may need to use lower values and then test
[21:40:30 CET] <alexpigment> yeah, I have no idea of the sensitivity of the filter
[21:40:49 CET] <therage3> i asked in #videolan and nobody knew
[21:40:54 CET] <therage3> (it's VLC's IVTC filter)
[21:42:09 CET] <alexpigment> out of curiosity, did you use interlaced encoding when you tried CRF 22?
[21:42:19 CET] <alexpigment> the source would have been interlaced
[21:42:34 CET] <therage3> let me copy the command i used
[21:42:43 CET] <alexpigment> but you have to expliclitly specify interlaced when encoding with x264
[21:43:17 CET] <therage3> ffmpeg -i input -c:v libx264 -preset slower -crf 22 -c:a copy output
[21:43:20 CET] <alexpigment> ah
[21:43:22 CET] <alexpigment> yeah
[21:43:35 CET] <therage3> just a standard x264 call with an audio stream copy
[21:43:39 CET] <alexpigment> -x264-params +ildct+ilme
[21:43:39 CET] <therage3> nothing fancy
[21:43:50 CET] <alexpigment> er
[21:43:52 CET] <alexpigment> sorry
[21:43:53 CET] <therage3> what?
[21:44:00 CET] <alexpigment> -flags +ildct+ilme
[21:44:21 CET] <alexpigment> add that to your command
[21:44:24 CET] <therage3> i don't know what that is. are those parameters to pass to the encoder?
[21:44:28 CET] <therage3> what do they do?
[21:44:43 CET] <alexpigment> they basically make sure that your output is interlaced
[21:44:58 CET] <alexpigment> an IVTC filter probably assumes that your content is interlaced
[21:45:06 CET] Action: therage3 raises an eyebrow
[21:45:15 CET] <alexpigment> i mean true telecined content *is* interlaced
[21:45:25 CET] <therage3> why did i ever get involved in video encoding, this is so complicated lol
[21:45:40 CET] <alexpigment> therage3: yep
[21:46:12 CET] <alexpigment> there's a lot of job security in knowing the complexities though :)
[21:46:55 CET] <therage3> here's my confusion though ... when you say "true telecined content *is* interlaced", you don't mean all frames, right? just in a set pattern, some of them, and some are progressive
[21:47:23 CET] <alexpigment> MPEG-2 is either interlaced or progressive
[21:47:30 CET] <alexpigment> there's no hybrid mode to my knowledge
[21:47:56 CET] <alexpigment> whereas x264 has MBAFF, which is a hybrid progressive/interlaced thing
[21:48:03 CET] <therage3> so even if actual visible frames may appear progressive, the actual stream is either interlaced or progressive
[21:48:09 CET] <therage3> and if some are interlaced, the whole stream is
[21:48:28 CET] <alexpigment> well, I suppose there could be a change midstream or something
[21:48:37 CET] <therage3> jesus christ
[21:48:41 CET] <alexpigment> but in general, it's not actively switching between the two
[21:49:01 CET] <therage3> (i'm not frustrated at you, it's just that this is all so complicated :D)
[21:49:08 CET] <alexpigment> just assume that if you have something telecined, it's interlaced
[21:49:21 CET] <alexpigment> it's been converted from ~24p to 30i
[21:49:38 CET] <therage3> right, from the studio 16mm film elements to broadcast
[21:49:45 CET] <therage3> or 35mm, w/e
[21:49:51 CET] <alexpigment> yeah
[21:50:13 CET] <alexpigment> anyway, let me know if adding that stuff above makes the player do the correct ivtc
[21:50:14 CET] <therage3> (this is a show that aired from 1993 to 1995, so yeah, that's likely it)
[21:50:26 CET] <therage3> i see, well, after this encode i'll add those flags and let you know. do i keep crf at 22?
[21:50:55 CET] <alexpigment> sure. although i'd personally go lower, but that's up to you
[21:51:29 CET] <therage3> yeah, i may do that for an actual rip that i use, but now i wanted to see if this helps the IVTC filter in picking up interlaced frames
[21:51:39 CET] <alexpigment> yeah, the crf doesn't matter for this test
[21:51:46 CET] <alexpigment> *shouldn't* matter for this test
[21:52:45 CET] <therage3> yeah
[21:52:59 CET] <therage3> another thing that messed with my head something bad was the SAR and the DAR
[21:53:06 CET] <alexpigment> haha, yeah
[21:53:30 CET] <alexpigment> anytime I have to fix aspect ratio stuff in handbrake, I'm like "uhhh... ?"
[21:53:30 CET] <therage3> the display resolution is apparently 720 x 480... so far so good. but whenever i uploaded it to YouTube, for whatever reason, it would be 640 x 480
[21:53:37 CET] <alexpigment> oh
[21:53:40 CET] <alexpigment> yeah, that's dvd for you
[21:53:53 CET] <therage3> apparently YouTube actually looks at the file's DAR and SAR and uses _that_
[21:53:53 CET] <alexpigment> dvd is always 720x480 for ntsc
[21:54:13 CET] <alexpigment> but the dislay aspect is 640x480 for 4x3 (it horizontally compresses the source)
[21:54:18 CET] <therage3> yes, lol
[21:54:29 CET] <alexpigment> or it's ~853x480 for 16x9
[21:54:38 CET] <alexpigment> and it stretches the original width
[21:54:55 CET] <alexpigment> so when youtube is making it 640x480, it's doing the right thing
[21:55:29 CET] <therage3> yeah
[22:02:54 CET] <therage3> alexpigment: OK, encoding now
[22:03:29 CET] <therage3> ffmpeg -i input -c:v libx264 -preset slower -crf 22 -flags +ildct+ilme -c:a copy output
[22:03:32 CET] <therage3> this is the command i used
[22:06:12 CET] <alexpigment> yeah, that should be fine
[22:07:00 CET] <alexpigment> i've been one of those flags isn't needed (maybe ilme?) for x264, but I just use that across the board with various encoders, and it doesn't hurt anything
[22:07:21 CET] <alexpigment> mpeg2video i think requires both
[22:07:39 CET] <alexpigment> anyway, the point being is that what you have is good
[22:08:48 CET] <therage3> nice
[22:09:05 CET] Action: therage3 sits back and waits for this mobile i5 to finish encoding .)
[22:09:06 CET] <therage3> :)
[22:25:15 CET] <rajkosto> :( cant seem to get rid of the implicit 2 frame buffer on h264 decode
[22:26:39 CET] <BtbN> Have you tried using the new API?
[22:26:49 CET] <rajkosto> yes
[22:26:58 CET] <rajkosto> i dont understand what buffer_frame is for in send_packet
[22:27:14 CET] <rajkosto> thats one of the frames that delays it
[22:27:49 CET] <BtbN> buffer_frame in send_packet?
[22:28:40 CET] <rajkosto> bceause it eats the first decode result, receive_frame afterwards returns EAGAIN as the packet buffer is empty (was eaten to fillup buffer_frame)
[22:29:15 CET] <BtbN> What code are you even looking at?
[22:29:38 CET] <rajkosto> https://images.sshnuke.net/2017-12-04_22-29-35.png
[22:29:49 CET] <BtbN> That's a screenshot
[22:29:51 CET] <BtbN> of code
[22:30:01 CET] <rajkosto> thats what im looking at ?
[22:30:06 CET] <rajkosto> its avcodec_send_packet, the "new" interface
[22:30:20 CET] <BtbN> Where in the codebase is it? In the h264 decoder?
[22:30:25 CET] <rajkosto> decode.c
[22:31:23 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/decode.c;h=3f5b086f7e4fb6a91385fcb56608bebcdb3b8cc9;hb=HEAD
[22:31:24 CET] <rajkosto> nevermind, it doesnt eat it, receive_frame will fetch from it if its full
[22:31:44 CET] <rajkosto> but its not full in my case, even when i gave it enough nals for an IDR slice
[22:32:07 CET] <JEEB> have you checked if the decoder just doesn't /always/ block according to the limit in SPS?
[22:32:17 CET] <rajkosto> how
[22:34:05 CET] <JEEB> http://up-cat.net/p/1c0e32af
[22:34:20 CET] <JEEB> not too many places where has_b_frames is used with H.264 :P
[22:57:51 CET] <rajkosto> JEEB, yes but i still have no clue how internally the ffmpeg decoder buffering works
[23:22:34 CET] <therage3> alexpigment: this is an interesting turn of events
[23:23:24 CET] <alexpigment> therage3: in the sense that the ivtc now works?
[23:23:56 CET] <therage3> alexpigment: i just ran the original DVD vob file (to ensure i'm using the original) through MediaInfo, and apparently this thinks it's "Interlaced" and not "2:3 pulldown" or whatever it calls telecine
[23:24:08 CET] <alexpigment> yeah, that's normal
[23:24:10 CET] <alexpigment> it *is* interlaced
[23:24:19 CET] <therage3> o.o
[23:24:20 CET] <alexpigment> and the pulldown is not a flag
[23:24:49 CET] <alexpigment> at least in this case
[23:24:55 CET] <alexpigment> that's why it's a "hard telecine"
[23:25:18 CET] <therage3> ... so the actual video itself is burned, as is, telecined, onto the dvd
[23:25:30 CET] <therage3> and not brought up to 30fps with a flag
[23:25:30 CET] <alexpigment> https://en.wikipedia.org/wiki/Telecine#2:3_pulldown
[23:25:33 CET] <alexpigment> yeah
[23:25:45 CET] <alexpigment> i mean, i can't tell for sure without seeing it, but most likely that is the case
[23:25:51 CET] <therage3> jesus christ it's like i'm getting a master's degree in video processing <.<
[23:25:55 CET] <alexpigment> haha
[23:26:20 CET] <sfan5> don't worry there's more
[23:26:27 CET] <therage3> i bet, sfan5
[23:27:19 CET] <alexpigment> but the thing is that the fields are all there and the patterns can be detected to reconstruct a true 24p (or 23.976p) source
[23:28:29 CET] <therage3> yeah, i see, and the trick is to use a filter that's intelligent enough to detect those and bring the framerate down after duplicate decimation and combination
[23:28:36 CET] <alexpigment> yep
[23:28:37 CET] <therage3> that's the part where i'm struggling
[23:29:28 CET] <alexpigment> well, have you tried handbrake?
[23:29:41 CET] <alexpigment> i've always had good luck with their detelecine filter
[23:29:57 CET] <alexpigment> just set it to "default", then I manually set the frame rate to 23.976
[23:30:16 CET] <alexpigment> not sure if that'll be different than what ffmpeg does, but it's generally always worked for me
[23:31:04 CET] <therage3> uhm yeah
[23:31:20 CET] <therage3> the problem with handbrake is that it uh, like, what does it do with the aspect rations and the border cropping
[23:31:23 CET] <therage3> it has a mind of its own
[23:31:27 CET] <therage3> i want it to leave that stuff alone
[23:31:33 CET] <alexpigment> yeah, that's pretty easy to do
[23:31:40 CET] <therage3> how o.o
[23:31:43 CET] <alexpigment> manual crop and set each side to 0
[23:31:52 CET] Action: therage3 opens Handbrake o.o
[23:31:54 CET] <therage3> hold on
[23:32:01 CET] <alexpigment> then turn anamorphic to automatic
[23:32:46 CET] <therage3> i see
[23:33:14 CET] <therage3> "then I manually set the frame rate to 23.976" OH
[23:33:16 CET] <therage3> i see
[23:33:23 CET] <therage3> that's the part i wasn't doing in Handbrake
[23:33:36 CET] <alexpigment> well, i think there's an auto mode for the frame rate
[23:33:38 CET] <therage3> i thought the detelecine filter would get rid of the duplicates itself
[23:33:41 CET] <alexpigment> but i generally set it explicitly
[23:34:03 CET] <alexpigment> maybe it's because i don't trust the wording of "same as source"
[23:34:09 CET] <alexpigment> the source is 30
[23:34:10 CET] <alexpigment> so
[23:34:13 CET] <alexpigment> ....?
[23:34:30 CET] <alexpigment> because of that wording, i've always explicitly set the frame rate
[23:34:49 CET] <therage3> it's also confusing, if it's a soft telecine maybe it reads the flag and adjusts it, if it's hard, it uses 30
[23:34:53 CET] <therage3> go figure
[23:34:57 CET] <alexpigment> maybe so
[23:35:07 CET] <alexpigment> i so rarely deal with soft telecined content, that I'll admit ignorance on that
[23:35:15 CET] <alexpigment> almost everything i deal with is hard telecined
[23:35:27 CET] <therage3> goddamn i wish the TV broadcast industry and Hollywood had the same standards
[23:35:30 CET] <therage3> this is so annoying
[23:36:40 CET] <alexpigment> well, if hollywood ruled all, then you'd never see anything above 24fps
[23:36:48 CET] <alexpigment> and that would be a sad jerky world ;)
[23:37:00 CET] <therage3> frankly, after this headache, i may be ok with tat
[23:37:01 CET] <therage3> that*
[23:37:08 CET] <therage3> it'd spare me having to learn this stuff
[23:37:16 CET] <alexpigment> therage3: this is all making you stronger
[23:37:19 CET] <alexpigment> you're like the hulk now
[23:37:21 CET] <therage3> i hope so
[23:39:31 CET] <therage3> alexpigment: anyway in handbrake, modulus is 2? and leave width and height as is?
[23:39:47 CET] <alexpigment> modulus 2 is fine
[23:40:07 CET] <therage3> i see
[23:40:10 CET] <alexpigment> assuming your crop is set to 0 on all sides, then make sure the height is 480
[23:40:19 CET] <alexpigment> it doesn't update that number dynamically for some reason
[23:40:24 CET] <alexpigment> or not in my experience at least
[23:41:16 CET] <therage3> i see
[23:42:06 CET] <therage3> alexpigment: are detelecine and deinterlace supposed to be used together?
[23:42:10 CET] <alexpigment> no
[23:42:12 CET] <alexpigment> one or the other
[23:42:23 CET] <alexpigment> just use detelecine
[23:42:33 CET] <therage3> right, i see....... i was wondering what detelecine even did if it didn't switch off deinterlae
[23:42:41 CET] <alexpigment> it does, actually
[23:42:47 CET] <alexpigment> it's just that it does it in a different way
[23:43:05 CET] <alexpigment> deinterlace only looks at the two fields when creating progressive frames
[23:43:19 CET] <alexpigment> detelecine looks at the bigger pattern and combines fields from different frames
[23:43:33 CET] <alexpigment> you use them in different contexts
[23:43:35 CET] <therage3> right, i see
[23:47:03 CET] <therage3> all right, outputting this video at 23.976 fps with the detelecine thing
[23:47:06 CET] <therage3> let's see how it does
[23:47:11 CET] <alexpigment> cool
[23:47:18 CET] <alexpigment> btw, you can do "preview" to test it out
[23:47:26 CET] <alexpigment> just so you don't waste a lot of time on something that doesn't work
[23:47:29 CET] <alexpigment> or that isn't optimal
[23:47:32 CET] <alexpigment> *optimal
[23:47:48 CET] <alexpigment> (weird, i thought i typo'd but i didn't)
[23:53:29 CET] <therage3> alexpigment: handbrake is being annoying again :) for some reason it insists on changing the resolution... on the original, 720x480 is both the resolution and the display resolution
[23:53:41 CET] <therage3> now the resolution is 720x482 for whatever reason
[23:54:06 CET] <alexpigment> ok, then set the anamorphic to "Loose"
[23:54:10 CET] <alexpigment> set the height to 480
[23:54:19 CET] <alexpigment> the width should stay at 720
[23:54:23 CET] <therage3> ... uh
[23:54:26 CET] <alexpigment> even when you switch back and forth between tabs
[23:54:34 CET] <therage3> i set it to loose and the Height field became grayed out
[23:54:47 CET] <alexpigment> ok, but the width is 720, right?
[23:54:51 CET] <therage3> yes
[23:54:54 CET] <alexpigment> you're fine then
[23:55:05 CET] <alexpigment> see, handbrake is by default catered to 'dumb' progressive video
[23:55:06 CET] <therage3> phew
[23:55:16 CET] <alexpigment> and by that i mean that it takes out anything that might confuse a player
[23:55:19 CET] <alexpigment> like interlacing
[23:55:22 CET] <alexpigment> or like aspect ratio
[23:55:25 CET] <alexpigment> etc
[23:55:39 CET] <therage3> this is what i mean when i say Handbrake annoyed me
[23:55:39 CET] <therage3> like, it has a mind of its own
[23:55:43 CET] <alexpigment> right
[23:55:49 CET] <alexpigment> if you make a preset, it'll stick usually
[23:55:57 CET] <therage3> i see
[23:56:00 CET] <alexpigment> although different sources can still cause it to rescan or certain values
[23:56:18 CET] <alexpigment> it's not the best program in the world, but I have some things I record regularly and process in batches
[23:56:36 CET] <alexpigment> and handbrake makes that process pretty easy while giving me access to additional command line options for x264
[23:56:50 CET] <therage3> yeah so i see
[23:57:03 CET] <therage3> don't get me wrong, the program is good if you know its quirks and how to tame it
[23:57:07 CET] <alexpigment> like i always specify the gop at the same length as the frame rate in the "extra options" field
[23:57:27 CET] <alexpigment> therage3: precisely. and i guarantee you that most people don't know its quirks or how to use it
[23:57:30 CET] <therage3> but how one is supposed to figure out that to get it to stop randomly making up its own resolutions, one has to hunt for "Anamorphic" and set it to "Loose", well...
[23:57:33 CET] <therage3> it's not trivial
[23:57:37 CET] <alexpigment> but it does make some assumptions that are probably best for most users
[23:57:53 CET] <alexpigment> well, the thing is, you're trying to get it to stick to the source resolution
[23:57:56 CET] <alexpigment> most people aren't
[23:57:58 CET] <therage3> yes
[23:58:30 CET] <alexpigment> it's a 4:3 dvd, so they assume that you want to encode at 640x480 so that the player doesn't have to stretch it to that resolution anyway
[23:58:38 CET] <alexpigment> and honestly, that's a perfectly fine assumption
[23:59:14 CET] Action: therage3 raises an eyebrow
[23:59:18 CET] <therage3> it's doing what YouTube does
[23:59:19 CET] <therage3> i see
[00:00:00 CET] --- Tue Dec  5 2017