Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

February 2018

1 participants
56 discussions

ffmpeg-devel.log.20180202
by burek 03 Feb '18

03 Feb '18

[00:20:37 CET] <cone-276> ffmpeg 03Michael Niedermayer 07master:0a2560a9775b: avcodec/exr: Fix memleaks in decode_header() [00:20:38 CET] <cone-276> ffmpeg 03Michael Niedermayer 07master:b1bef755f617: avcodec/aacsbr_fixed: Fix overflows in rounding in sbr_hf_assemble() [00:20:39 CET] <cone-276> ffmpeg 03Xiaohan Wang 07master:caaa40d2c67b: configure: Remove carriage return ('\r') in Windows CC_IDENT [01:29:19 CET] <mypopydev> @jkqxz Hi [01:30:03 CET] <mypopydev> Can you help to review https://patchwork.ffmpeg.org/patch/7439/, tks [08:25:39 CET] <blackelement> Does the rawvideo format contain anything other than standard YUV420P in the output file? I'm seeing usual data and then things get weird pretty quick [08:28:04 CET] <blackelement> Specifically 3330 and 0d0a hex repeating [09:54:22 CET] <kierank> It seems Chrome Embedded Framework lets you build ffmpeg and strip the licence flags [10:13:46 CET] <atomnuker> license flags? [10:14:09 CET] <kierank> the configure string and the string telling you what FFmpeg's licence is [10:22:59 CET] <atomnuker> nasty, but I guess they needed the space [10:23:25 CET] <atomnuker> you can still just look up the symbols and figure out if it has any GPL ones [10:25:56 CET] <atomnuker> or if they strip off everything you can still try to find the flac x86 asm instructions [10:59:30 CET] <kierank> atomnuker: the binary is 55MB [10:59:32 CET] <kierank> they don't need the space [11:42:41 CET] <wm4> <kierank> It seems Chrome Embedded Framework lets you build ffmpeg and strip the licence flags <-for what purpose? [11:42:55 CET] <wm4> because that makes you immediately think of supporting intentional license violations [11:43:00 CET] <wm4> which would be Not Nice [11:56:27 CET] <chouquette> Hello there, if some of you are at FOSDEM and would like to join the VideoLAN community dinner on Saturday evening, please get in touch with me :) (hugo(a)videolan.org) [12:47:20 CET] <wm4> qsv sure has some horrible ifdeffery for a single vendor portable lib [12:47:29 CET] <wm4> the libavcodec wrapper I mean [14:48:48 CET] <jamrial_> michaelni: can you upload the sample attached in "fate: add id3v2 test" ? [14:49:21 CET] <jamrial_> maybe rename it to id3v2_priv.mp3 since id3v2-test.mp3 is too generic, and the test is for the PRIV tag [14:53:11 CET] <wm4> yeah with _priv it'd probably be better [15:12:33 CET] <jamrial_> nevcairiel: do you mind if i push the ffprobe patch for coded_w/h? it's local, simple, and really innocuous, and will be gone in a year or two alongside avstream.codec [15:13:05 CET] <michaelni> jamrial_, you can upload it yourself, ive just created an account and you should have permissions to upload samples [15:51:34 CET] <SortaCore> er, latest ffmpeg doesn't have codec names before the hwaccels? [16:10:38 CET] <wm4> so I guess I'll push my id3 and rtsp changes soon [16:11:08 CET] <SortaCore> does rtsp have a useful timeout now? [16:11:09 CET] <wm4> for id3 I suspect that there are some files around that expect pre-patch semantics, but didn't find any [16:11:12 CET] <wm4> no [16:11:15 CET] <SortaCore> rats [16:11:27 CET] <wm4> well it does, just the option name is different [16:11:34 CET] <wm4> which will be fixed in 2 years [16:11:44 CET] <wm4> unless one of the bikeshedders go ahead and implement what they wanted [16:12:01 CET] <SortaCore> now that's a term I'm not familiar with [16:12:24 CET] <SortaCore> heh [16:18:43 CET] <cone-268> ffmpeg 03Richard Shaffer 07master:4be6307cbf81: fate: add id3v2 test [16:37:13 CET] <cone-268> ffmpeg 03Calvin Walton 07master:108958e43df0: librsvgdec: Fix frame clearing code [16:37:31 CET] <atomnuker> kepstin: pushed, thanks [16:37:46 CET] <kepstin> atomnuker: cheers! [17:05:23 CET] <Chloe> atomnuker: how would you like me to credit you? Based on an idea from a previous patch by atomnuker or smth? [17:05:48 CET] <atomnuker> yeah, just put a line in the description [17:06:40 CET] <atomnuker> also you technically you finished the patch so "Based on an unfinished patch by atomnuker" is more accurate [17:08:32 CET] <wm4> when will git have support for multiple author fields [17:11:56 CET] <Chloe> atomnuker: thanks, Ill add it in :) [17:16:24 CET] <atomnuker> wm4: when starts using a better sha version and does a 3way <everything> by default [17:25:42 CET] <Chloe> adding in author renames would be nice too [17:27:46 CET] <atomnuker> author renames? like authors changing names? [17:28:08 CET] <atomnuker> or emails? I'd like that [17:31:16 CET] <Chloe> atomnuker: both, but mostly authors changing names [17:38:20 CET] <wm4> he's probably referencing the x264 incident [17:38:43 CET] <atomnuker> well you don't have to change your name if you're wise like ^^^ is [17:39:41 CET] <Chloe> atomnuker: it's more difficult if you dont have forethought like wm4 [17:43:04 CET] <Chloe> atomnuker: also people change their names often, it seems kind of silly to not have a way to do it [17:44:13 CET] <Chloe> wm4: I have no idea what that is [17:48:16 CET] <atomnuker> Chloe: project leader of x264 changed his name/email and rewrote the git history [17:49:01 CET] <wm4> he didn't just change name, he changed his gender [17:49:27 CET] <wm4> and I think it wasn't officially explained or something, they just force pushed it, rewriting years or history [18:43:47 CET] <Chloe> michaelni: yes I did build out of tree [18:52:27 CET] <Chloe> michaelni: did you try a distclean first? [19:24:55 CET] <michaelni> Chloe, let me retry [19:27:12 CET] <SortaCore> what happened to all the hwaccels on master? [19:28:37 CET] <wm4> SortaCore: nothing? [19:29:27 CET] <SortaCore> h264_qsv, h264_cuvid and h264_nvenc hwaccels are gone [19:29:33 CET] <SortaCore> although I see a h264_nvdec [19:29:56 CET] <wm4> I doubt nvenc ever had a hwaccel, because it's an encoder [19:30:14 CET] <wm4> the cuvid/qsv hwaccels are gone because they were just dummy which are not required anymore [19:30:26 CET] <wm4> the actual hardware accelerated decoders are still there [19:30:46 CET] <SortaCore> so if you're using one decoder and one encoder with nvenc, what's the process now? [19:31:02 CET] <SortaCore> nvdec hwaccel for src, then create derived dxva2 for destination? [19:31:57 CET] <wm4> exactly the same as before [19:32:26 CET] <wm4> if you can use nvdec that's generally better than cuvid (IMO), although it lacks deint/scaling [19:33:45 CET] <michaelni> Chloe, "mkdir new-dir && cd new-dir && ../configure && make -j12" reproduces the issue with the first patch on top of caaa40d2c67b1f4ebde368c859647af6f42f394a [19:34:08 CET] <michaelni> "make distclean" isnt meaningfull as the build directory is empty [19:40:18 CET] <atomnuker> kierank: this is horrible, its friday night, and brussels is pretty much dead, no kebab shops nearby, no italian restaurants, only very fancy places open with 0 people in them [19:40:21 CET] <michaelni> Chloe, running make distclean in the parent directory seems to fix it but that really shouldnt be [19:40:50 CET] <Chloe> I think I forgot to add the directories to the _list.c includes [19:41:00 CET] <kierank> Do you want to come to "gist" with us? [19:41:08 CET] <atomnuker> sandwiches in supermarkets are what's left and even then there's no more than a few, and even then I've never noticed how everything in brussels is turboexpensive [19:41:40 CET] <wm4> heh how can it possibly be so dead if it's not even 8 PM? [19:41:43 CET] <atomnuker> 5 euro for 100 grams of chocolate which would go for no more than 1.5 quids [19:41:45 CET] <kierank> atomnuker: we are going to "gist" [19:43:01 CET] <kierank> I have no idea what it is [19:43:22 CET] <atomnuker> too late, had an unusual tuna sandwich for which I managed to aquire a taste for and my hotel is near ULB (for now, I'm going to the novotel after fosdem) [20:00:23 CET] <Chloe> jamrial_: Should I add a rename for bsf to the next iteration of the set? [20:00:30 CET] <Chloe> (with deprecation ofc) [20:01:22 CET] <jamrial_> I have no real opinion about it. But I'd rather stop seeing two separate and conflicting sets doing the same thing in different ways, to be honest [20:01:31 CET] <jamrial_> it's duplicate work [20:01:59 CET] <Chloe> I dont know what prompted the other set tbh [20:03:23 CET] <Chloe> the other set also only fixes half the issue, and doesnt allow for changing how codecs are stored in the future without another API change. With my changes you could theoretically reintroduce a registration API and keep the same iteration APIs without having to play with linked lists (since they're opaque) [20:11:08 CET] <Chloe> what. why am I being told *why* I made a particular change [20:22:30 CET] <nevcairiel> jamrial_: its fine to push that, i guess, i still think its a bit silly, but not going to block it [20:24:21 CET] <jamrial_> ok [20:40:37 CET] <peloverde> Anyone in contact with the homebrew ffmpeg maintainers? A few of their defaults look interesting. [20:41:35 CET] <Chloe> peloverde: you can fairly easily create an issue on their github page if you think they should be change [20:41:47 CET] <cone-386> ffmpeg 03Zhong Li 07master:19b1d905b88d: ffprobe: Initialize coded_width/height [20:44:42 CET] <Chloe> michaelni: I've updated the set, out of tree builds should just work now [20:44:57 CET] <Chloe> also bsf api name patch added [21:51:52 CET] <cone-386> ffmpeg 03James Almer 07master:94eb5505ad7b: ffprobe: remove usage of deprecation warning removal pragmas [22:26:18 CET] <atomnuker> wm4: going to push the id3 and rstp stuff? [22:31:17 CET] <wm4> needs some adjustment, so tomorrow [00:00:00 CET] --- Sat Feb 3 2018

1 0

ffmpeg.log.20180202
by burek 03 Feb '18

03 Feb '18

[00:13:34 CET] <alexpigment> bonk: static implies that there is audio [00:14:42 CET] <alexpigment> unless, of course, you've got static in your speakers when you just generally turn up the audio [02:26:52 CET] <damarusama> can I make a video darker trough ffmpg? [02:53:38 CET] <leewdch> is it possible to encode a video, stop to encode if size limit is reached and apply a fade out to the audio at the end? maybe using 2-pass? [02:53:57 CET] <leewdch> oterhwise I need to make a bash script for this [05:08:02 CET] <mkdir> yooo [05:08:10 CET] <mkdir> I need to find a good .wav library [05:14:33 CET] <mkdir> Yo [05:14:34 CET] <mkdir> Johnjay [05:14:52 CET] <Johnjay> hey [05:14:52 CET] <Johnjay> sup [05:15:05 CET] <Johnjay> i think i met you in another channel mkdir but i don't see it now [05:17:34 CET] <mkdir> Yeah [05:17:44 CET] <mkdir> Possibly audacity? [05:21:28 CET] <Johnjay> hmm maybe [05:21:36 CET] <Johnjay> i'm not using ffmpeg much these days though [05:21:47 CET] <Johnjay> i had to do a fade in effect on a mp3 file but that's about it [05:22:33 CET] <mkdir> Ah I see [05:22:42 CET] <mkdir> I need to find a good .wav library [05:23:02 CET] <mkdir> Do you know of any good places to find sample .wav sound files [05:23:26 CET] <mkdir> english words would be beneficial [05:23:33 CET] <mkdir> It could have also been in ##C [05:25:27 CET] <brettdong> ffmpeg: common/cpu.c:251: x264_cpu_detect: Assertion `!(cpu&(X264_CPU_SSSE3|X264_CPU_SSE4))' failed. [05:25:36 CET] <brettdong> I'm running ffmpeg in a qemu vm, how can I do? [07:19:11 CET] <butts> hi [10:35:41 CET] <TheoTheo> I am trying to wrap my head around how filters work using the libavfilter library in C code. Does anyone know of a good guide or can / wants to help me understand? [10:51:02 CET] <JEEB> TheoTheo: did you look under doc/examples? [10:51:09 CET] <JEEB> there should be at least one or two filtering examples [11:03:21 CET] <TheoTheo> Hi JEEB, i did look at the filter_audio and filtering_audio example, but i still don't quite get it [11:03:56 CET] <TheoTheo> I would like to crossfade two streams [11:06:55 CET] <TheoTheo> I know how to get the right filter by using avfilter_get_by_name("crossfade"), but i don't understand how filters are applied to my stream / frames [11:15:15 CET] <Uzzi> I've restored video files from android phone. I cannot play videos. mp4 demux error: cannot create chunks index [12:17:36 CET] <kr> Hi, I am using libavformat to mux rtp video stream (vp8) to webm. I am not getting how to set pts and dts values in AVPacket. Can i set rtp timestamp itself as pts or dts or do i need to do any other calculation ? [12:51:14 CET] <JEEB> kr: usually the input format sets the AVPacket pts/dts values and you might only have to re-scale them to the output time base [12:52:27 CET] <JEEB> kr: if you don't have those values set, then you will either have to fix the rtp protocol/demuxer, or poke the values yourself [13:08:44 CET] <kr> by "re-scale them to output timebase" you mean, stream timebase or codec timebase? [13:10:02 CET] <JEEB> AVPacket should be in the input stream time base, and you need most likely to scale it to the output stream time base [13:10:17 CET] <JEEB> decoder's output would be in the decoder's time base [13:15:09 CET] <kr> pardon me for my naivity, but what do u mean by decoder here. I am not using any decoder here. I am recieving already vp8 encoded rtp live stream at a port on my system. i am assembling the stream frame wise. then initializing a AVPacket and setting its buffer to the assembled frame byte array. [13:15:33 CET] <JEEB> yes [13:15:46 CET] <JEEB> but you asked "codec time base" and that is generally the time base for the decoder or encoder [13:16:04 CET] <JEEB> AVPackets are in stream time base that they are for [13:16:33 CET] <JEEB> and then filter graph outputs have time bases as well :P [13:16:59 CET] <kr> sorry i meant codec context timebase or stream timebase [13:17:10 CET] <JEEB> codec context is for a decoder anyways [13:17:26 CET] <JEEB> stream time base is the stream's time base and AVPackets' pts/dts is in that [13:18:33 CET] <kr> So, how do i calculate that for my particular case ? do i have to use the rtp timestamps that i get or any other way ? [13:19:39 CET] <JEEB> as I said in the very beginning that the RTP protocol/demuxer should give you DTS/PTS and the time base. if it doesn't then that protocol/container within that protocol doesn't have such things and you have to make them up? [13:19:55 CET] <JEEB> (or you fix the RTP protocol / whatever demuxer is getting used) [13:22:41 CET] <JEEB> raw streams might not have PTS/DTS set, so you either implment giving them timestamps in the raw format "demuxer", or you fix them after-the-fact [13:24:48 CET] <kr> there is no container inside rtp. it's a realtime transfer protocol, which only transfers audio video frames in packetized way. [13:26:08 CET] <JEEB> I've seen MPEG-TS within RTP [13:26:12 CET] <JEEB> which is why I noted [13:26:25 CET] <JEEB> and yes, with raw streams the "raw XXX" demuxer gets used after the protocol [13:26:52 CET] <JEEB> (unless the protocol itself just passes the packets to a parser and skips "demuxers" altogether) [13:27:05 CET] <kr> by "raw format demuxer" you mean rawvideo demuxer ? that video stream is not raw video. it is already vp8 encoded stream. [13:27:11 CET] <JEEB> no [13:27:19 CET] <JEEB> h264 demuxer is one of them [13:27:34 CET] <JEEB> or possibly the parser [13:27:39 CET] <JEEB> one of those two [13:27:42 CET] <JEEB> 32 [13:49:59 CET] <kr> yes the protocol passes the packets to my custom parser, where i parse the rtp packets and get frame wise data. This data i am trying to mux into a webm file, but not sure how to set timestamps. [13:53:33 CET] <kr> is there a way to achieve this i.e without passing the live stream input to any demuxer, directly writing to file. Because my stream is already vp8 encoded which shud have no problem with webm container. [14:16:44 CET] <boingboing> ok chat, heres my issue: I have a command that is constantly fetching video into video.mp4. I then want to stream that to my devices. but, when I call another ffmpeg command to read from the mp4, it says it's invalid, and it doesnt work until i stop streaming from the camera first [14:17:06 CET] <boingboing> whats the best way to make it constantly stream from the camera to the hard drive, and from the hard drive to my phone only when i want to [14:17:19 CET] <boingboing> I dont need to store the file on the hard drive [14:18:06 CET] <JEEB> nginx-rtmp with hls/dash output? [14:21:06 CET] <boingboing> doesn't that seem a bit much though? there has to be a way I can just stream to a file and then stream from that file [14:21:50 CET] <klaxa> don't use mp4 [14:22:09 CET] <klaxa> mkv supports reading partial files, maybe try that instead [14:22:21 CET] <JEEB> matroska or mpegts, yes [14:22:30 CET] <klaxa> doing it the way you do will definitely fill up your harddrive though [14:22:37 CET] <klaxa> in the long term [14:22:38 CET] <JEEB> but nginx-rtmp would output what phones and web clients like [14:22:54 CET] <JEEB> and not fill the hfd [14:22:58 CET] <JEEB> *hdd [14:23:37 CET] <boingboing> ill try the mkv [14:24:01 CET] <boingboing> is there a way to have it auto delete video from say, 2 seconds behind current, then my hard drive wont fill up? [14:24:41 CET] <JEEB> with the hls muxer maybe [14:25:00 CET] <JEEB> since it has an option for how many segnents to keep [14:51:41 CET] <furq> the hls muxer will be fine for that but you'll end up with way more than two seconds of latency [15:58:35 CET] <Nacht> Anyone know why sometimes you have MPEGTS files who indicate that they have an adaptationfield, yet the Length is set to 0 ? [16:35:32 CET] <DHE> Nacht: due to the fixed size frames of mpegts, adaptation fields of varying lengths are sometimes used to simulate a frame of smaller size. a field size of 0 still consumes the 1 byte for the field size itself, resulting in a payload of 183 bytes instead of 184. [16:41:34 CET] <mkdir> Hi [16:41:35 CET] <mkdir> There [16:41:39 CET] <mkdir> It's mkdir [16:41:42 CET] <mkdir> say it just like that [16:41:50 CET] <mkdir> okay is there good text to speech software? [16:43:51 CET] <Nacht> rmdir [16:44:34 CET] <kepstin> mkdir: there's lots, but less so if you're limiting yourself to open-source options (also, this is kinda out of scope for ffmpeg) [16:45:07 CET] <mkdir> oh sorry [16:45:08 CET] <mkdir> yeah [16:45:18 CET] <mkdir> I just want one that can convert to .wav [16:45:27 CET] <mkdir> or saves as a .wav [17:24:50 CET] <vidaoptics> Hi guys, I have an exotic question - how can I make ffmpeg stream audio and video from udp (multicast) to Icecast server, with no transcoding? doing .... -f mp3 icecast://source:password@ip:port/mount will stream only audio when input is udp, but when input is another http source from icecast with video - it works.... [17:26:01 CET] <furq> it works with -f mp3? [17:27:51 CET] <vidaoptics> yes, but only when input stream is http://some-server:port/stream.ts [17:28:37 CET] <furq> i have no idea what it would even be sending as the video stream if you're outputting mp3 [17:29:03 CET] <furq> that doesn't seem like something that should work at all [17:29:06 CET] <vidaoptics> if stream is udp://239.0.0.1:1234 then ffmpeg fails with many errors [17:29:28 CET] <furq> pastebin the full command line and output for both cases [17:34:00 CET] <vidaoptics> failire: https://pastebin.com/5nCYqCMg [17:35:01 CET] <kepstin> oh, right, 'mp3' takes a video stream because it can attach a picture as cover art [17:35:01 CET] <mkdir> furq [17:35:06 CET] <mkdir> what's good with you? [17:35:19 CET] <furq> kepstin: i get that but surely that wouldn't actually work as far as watching it goes [17:35:27 CET] <kepstin> definitely not, yeah [17:36:35 CET] <furq> i'm going to guess the working stream is mjpeg or something [17:37:19 CET] <kepstin> I believe icecast can do theora+vorbis in ogg and vp8+vorbis in webm [17:37:22 CET] <kepstin> in terms of video [17:37:27 CET] <furq> officially, yeah [17:37:37 CET] <furq> iirc other stuff works but it's not officially supported [17:38:00 CET] <furq> you've always been able to stream mp3 but it's never been officially supported [17:38:03 CET] <vidaoptics> all stuff works fine, mpeg-ts is ok and mpeg-ps also fine [17:38:12 CET] <kepstin> hmm, they list mp3 in the docs now [17:38:12 CET] <furq> vidaoptics: use -f mpegts instead of -f mp3 then [17:38:22 CET] <furq> mp3 doesn't support video streams [17:38:33 CET] <vidaoptics> this is upd multicast stream from a TV channel in some area but we can't get it out via udp proxy due to network conditions... [17:38:36 CET] <furq> so i'm still not entirely sure how that worked at all [17:39:04 CET] <furq> either it was just writing one mjpeg frame as cover art and it wasn't actually sending video, or something tremendously hacky was happening [17:39:16 CET] <furq> like ffmpeg just decided to write the entire mjpeg stream as cover art and this was somehow working [17:39:37 CET] <vidaoptics> *I am an idiot* ... -f mpegts worked.... [17:40:04 CET] <furq> can you actually watch that [17:40:30 CET] <furq> icecast will accept a lot of stuff and just forward it unmodified, but it's not actually guaranteed that anything will play it [17:40:58 CET] <furq> if mpegts actually works then that's pretty interesting as far as streaming stuff goes [17:41:07 CET] <furq> probably less hassle to get that up and running than nginx-rtmp [17:41:33 CET] <kepstin> well, the nice thing about mpegts is that forwarding it unmodified is all you really need to do, stuff will just sync up with it eventually. [17:42:02 CET] <furq> yeah i guess if anything will work over icecast then mpegts is most likely [17:42:10 CET] <furq> i know there were issues with flv because it doesn't send the right mime-type [17:42:29 CET] <vidaoptics> furq - it plays fine, no problem on STB's [17:42:35 CET] <furq> neat [17:42:44 CET] <furq> i take it it just acts like a regular mpegts over http stream [17:42:47 CET] <kepstin> i know it has extra code for webm and ogg containers to basically remux per connected client. [17:43:04 CET] <furq> i'll have to mess around with that later and see if i can get anything useful out of it [17:44:07 CET] <vidaoptics> nope, you can't - it's a bad story, STB's do not like it at all :( [17:44:27 CET] <vidaoptics> and in h264 you can get good stream anyway [17:44:37 CET] <furq> STBs don't like what [17:44:53 CET] <furq> if you meant webm then i didn't mean that, i already knew it could stream webm [17:57:39 CET] <jfmcarreira> Heyy guys [17:58:10 CET] <jfmcarreira> I am trying to read input stream using ffmpeg. is it possible that I convert the decoded frame to a different pixel format? [17:59:49 CET] <JEEB> yes, avfilter [18:18:50 CET] <mkdir> yo [18:54:07 CET] <furq> so i guess mpegts over icecast sort of works except mpv will just bail out before starting the stream most of the time [20:15:11 CET] <SortaCore> what's the equivalent to "--disable-doc --disable-encoders --disable-decoders --disable-filters --disable-demuxers --disable-muxers --disable-protocols --disable-parsers --disable-hwaccels --disable-bsfs --disable-indevs --disable-outdevs" [20:15:53 CET] <kepstin> SortaCore: just not compiling ffmpeg at all should be approximately equivalent to that [20:16:24 CET] <SortaCore> lol [20:16:29 CET] <SortaCore> *saves time* [20:16:38 CET] <SortaCore> nah, I mean before I manually enable all the ones I need [20:20:13 CET] <c_14> --disable-everything [20:20:22 CET] <c_14> eh, you still need --disable-doc [20:20:44 CET] <c_14> but everything covers encoders/decoders/hwaccells/muxers/demuxers/parsers/bsfs/protocols/devices/filters [20:21:34 CET] <c_14> and you'll probably want --disable-autodetect [20:31:12 CET] <SortaCore> what does autodetect do? [20:31:53 CET] <c_14> configure auto-enables certain "system" libraries [20:32:02 CET] <c_14> that just disables the autodetection in configure [20:35:13 CET] <SortaCore> so not related to cpu features? [20:37:23 CET] <c_14> nope [20:39:30 CET] <furq> there's also --disable-all but that will more or less not build anything that you don't manually enable [20:39:35 CET] <furq> including things like libavcodec and ffmpeg [20:41:56 CET] <DHE> --disable-everything will build the libraries but with no codecs, formats and filters. makes them useless but they'll build and follow the APIs [20:59:45 CET] <SortaCore> --enable-hwaccel="h264_nvdec" does nothing (with --disable-autodetect or not) [21:00:40 CET] <SortaCore> hmm [21:00:51 CET] <SortaCore> nah, it's disable-autodetect that kills all the hwaccels [21:04:16 CET] <c_14> check your config.log [21:04:25 CET] <c_14> might need zlib or something like that that's normally autodetected [21:05:03 CET] <c_14> wait, --enable-nvdec [21:05:06 CET] <c_14> did you pass that? [21:05:11 CET] <c_14> because that's normally autodetected [21:05:14 CET] <SortaCore> ah, nope [21:05:42 CET] <SortaCore> but it didn't have any of them, and I passed hwa "h264_nvdec,h264_d3d11va2,h264_dxva2,mpeg4_nvdec"" [21:08:09 CET] <SortaCore> hm, probably --disable-dxva2=no [21:10:19 CET] <c_14> just --enable-dxva2? [22:03:42 CET] <furq> SortaCore: aren't those decoders, not hwaccels [23:01:00 CET] <ddubya> can I make hardware decoder priority above software one, e.g. I have an app that opens h264 codec, can it default to h264_cuvid ? [23:04:38 CET] <BtbN> if you write your code that way, sure [23:11:32 CET] <ddubya> was hoping for some hacky environment override :-) [23:11:50 CET] <BtbN> they are entirely separate decoders [23:12:40 CET] <ddubya> well yeah, but there could be priority [23:13:27 CET] <BtbN> you select a specific decoder via the API [23:13:30 CET] <BtbN> not a generic codec [23:13:41 CET] <BtbN> so any priority logic you will have to do yourself [23:19:47 CET] <ddubya> If I'm using hardware codec context->threads should be fixed to 1 right? [23:20:05 CET] <BtbN> at least h264_cuvid does not care [23:20:33 CET] <ddubya> well just in case [23:30:17 CET] <Cu5tosLimen> hi [23:30:24 CET] <Cu5tosLimen> so I have some really poorly made avis [23:31:51 CET] <hojuruku> ddubya: i know how to do it in gstreamer, it involves source code patching. ffmpeg probably is the same - how does ffmpeg choose what decoders / hwaccell to use if any? [23:32:33 CET] <ddubya> hojuruku, must be selected manually when opening codec [23:32:54 CET] <ddubya> defaults to the non-prefixed version, e.g. "h264" instead of "h264_cuvid" [23:33:05 CET] <ddubya> prefixed/suffixed [23:33:43 CET] <hojuruku> yeah gstreamer uses priorities [23:33:55 CET] <hojuruku> you don't patch your app's source you patch your gstreamer plugin's priority setting :) [23:34:08 CET] <hojuruku> that's what I did to make openmax beat vaapi [23:40:36 CET] <kerio> Cu5tosLimen: it's porn, isn't it [23:40:50 CET] <Cu5tosLimen> kerio, I would never ;) [23:41:09 CET] <Cu5tosLimen> so I'm trying to cut parts from these avis using timecodes recorded with somplayer [23:41:52 CET] <Cu5tosLimen> using ffmpeg -i in.avi -ss 01:32:13.663 -to 01:32:38.000 -c copy out.avi for example [23:42:03 CET] <Cu5tosLimen> but the time codes from smplayer does not match ffmpeg timecodes [23:42:35 CET] <Cu5tosLimen> so inevitably I find the frame that ffmpeg starts at - get same frame from smplayer and work out delta and then adjust timecodes with this delta [23:42:40 CET] <Cu5tosLimen> how can I get past this? [23:43:03 CET] <kerio> use mpv :^) [23:43:14 CET] <Cu5tosLimen> smplayer is running mpv [23:43:19 CET] <kerio> is 01:32:13.663 a keyframe? [23:43:29 CET] <Cu5tosLimen> no but the differences are huge [23:43:32 CET] <Cu5tosLimen> like 2 mins or so [23:43:51 CET] <Cu5tosLimen> for one avi it was datetime.timedelta(0, 204, 411000) [23:44:01 CET] <Cu5tosLimen> for other it was datetime.timedelta(0, 88, 400000) [23:44:08 CET] <Cu5tosLimen> I record timecodes by taking screenshots [23:44:20 CET] <Cu5tosLimen> with this format specifier: cap_%F_%P_%02n [23:45:17 CET] <kerio> something something -vsync passthrough? [23:45:29 CET] <Cu5tosLimen> for smplayer? [23:45:34 CET] <kerio> no, for ffmpeg [23:45:43 CET] <Cu5tosLimen> no those are all the options I use [23:45:45 CET] <kerio> but idk [23:45:57 CET] <Cu5tosLimen> or are you saying I should try -vsync passthrough? [23:46:05 CET] <kerio> yep [23:46:09 CET] <kerio> or the other -vsync options idk [23:46:19 CET] <Cu5tosLimen> ok thanks will try that for next one [23:46:21 CET] <kerio> are these vfr or cfr videos? [23:47:45 CET] <Cu5tosLimen> https://bpaste.net/raw/5559fd8d5422 [23:47:48 CET] <Cu5tosLimen> not sure how to tell [23:47:53 CET] <Cu5tosLimen> that is mediainfo dump [23:48:09 CET] <Cu5tosLimen> they use AVC codec [23:50:45 CET] <Cu5tosLimen> this is ffmpeg output: http://termbin.com/1utc [23:51:05 CET] <Cu5tosLimen> Stream #0:1[0x100]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(tv, progressive), 640x480 [SAR 1:1 DAR 4:3], 30 fps, 30 tbr, 90k tbn, 60 tbc [23:51:46 CET] <Cu5tosLimen> cfr = constant frame rate and vfr = variable frame rate I assume? [23:51:50 CET] <Cu5tosLimen> I guess it is cfr [00:00:00 CET] --- Sat Feb 3 2018

1 0

ffmpeg-devel.log.20180201
by burek 02 Feb '18

02 Feb '18

[00:03:35 CET] <jdarnley> lol, nice [00:31:16 CET] <philipl> Zeranoe: frame it and hang it on the wall. [00:47:27 CET] <SortaCore> I note h264_nvenc doesn't list the praised yuvj420p as supported altho it does like yuv420p [00:53:51 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:812e06cc8296: avcodec/dirac_dwt: Fix multiple overflows in 9/7 lifting [00:53:51 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:dc4ef664ab38: avformat/mov: Fix DoS in read_tfra() [00:53:51 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:fa6559830930: avformat/asfdec: Fix DoS in asf_build_simple_index() [00:53:51 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:18e1ef489ab1: avcodec/diracdec: Fix overflow in DC computation [00:53:51 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:f51fc65d66e1: avcodec/hevcdsp_template: Fix undefined shift in put_hevc_pel_bi_w_pixels [00:53:51 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:a93bbd8aa32a: avcodec/jpeg2000dsp: Fix multiple integer overflows in ict_int() [00:53:51 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:fd0b42344a7a: avcodec/pngdec: Clean up on av_frame_ref() failure [00:53:52 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:a2d129a841f5: avcodec/svq3: Fix overflow in svq3_add_idct_c() [00:53:53 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:104d36647cc2: avcodec/ffv1dec: Fix integer overflow in read_quant_table() [00:53:54 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:ed5d0bc237f9: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_FIDELITYi*() [00:53:55 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:a0f854b5ffbd: avcodec/takdec: Fix integer overflows in decode_subframe() [00:53:56 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:66fd3de40ab0: avcodec/proresdec2: Check bits in DECODE_CODEWORD(), fixes invalid shift [00:53:57 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:13d16a7b9963: avcodec/takdec: Fix integer overflow in decode_lpc() [00:53:58 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:6d03495c7054: avcodec/jpeg2000: Check that codsty->log2_prec_widths/heights has been initialized [00:53:59 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:c665a9343889: avcodec/hevcdsp_template: Fix undefined shift [00:54:00 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:df66540dd505: avcodec/proresdec2: SKIP_BITS() does not work with len=32 [00:54:01 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:1ad7bbfd210d: avcodec/aacdec_template: Clear tns present flag on error [00:54:02 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:39291059134a: avcodec/truemotion2: Fix integer overflows in tm2_high_chroma() [00:54:03 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:fd21cec8a9e7: avcodec/mpeg4videodec: Use 64 bit intermediates for sprite delta [00:54:04 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:0d9baa6d16cc: avcodec/mpeg_er: Clear mcsel in mpeg_er_decode_mb() [00:54:05 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:23ea9f91c033: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_53iL0() [00:54:06 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:f62201d550a3: avcodec/ffv1dec: Fix out of array read in slice counting [00:54:07 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:c9298f5d0253: avcodec/pafvideo: Check for bitstream end in decode_0() [00:54:08 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:c48262d85738: avcodec/snowdec: Check mv_scale [00:54:09 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:3fc5451f4016: avcodec/jpeglsdec: Check ilv for being a supported value [00:54:10 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:9ba9c5a16f47: avcodec/jpeglsdec: Check for end of bitstream in ls_decode_line() [00:54:11 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:9ef0472b265a: avcodec/aacdec_fixed: Fix integer overflow in predict() [00:54:12 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:9d4ad2dbfdc7: avcodec/aacdec_fixed: Fix integer overflow in apply_dependent_coupling_fixed() [00:54:13 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:35c1e95b41e9: avcodec/xan: Improve overlapping check [00:54:14 CET] <cone-098> ffmpeg 03Luca Barbato 07release/2.8:907a704c9f6c: avformat: Free the internal codec context at the end [00:54:15 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:1376beb658d3: avcodec/xan: Check for bitstream end in xan_huffman_decode() [00:54:16 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:b75eb7f8d55d: avcodec/h264idct_template: Fix integer overflows in ff_h264_idct8_add() [00:54:17 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:92eff6b829bd: avcodec/aacsbr_fixed: Fix division by zero in sbr_gain_calc() [00:54:18 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:fd1854647bdb: avutil/softfloat: Add FLOAT_MIN [00:54:19 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:efe9439caa25: avcodec/sbrdsp_fixed: Fix integer overflow in shift in sbr_hf_g_filt_c() [00:54:20 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:d8fb143546da: avcodec/cngdec: Fix integer clipping [00:54:21 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:7de06077c9fb: avcodec/snowdec: Fix integer overflow in header parsing [00:54:22 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:cd01fc76c406: avcodec/mdct_*: Fix integer overflow in addition in RESCALE() [00:54:23 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:b0c2e6e2d240: avcodec/aacdec_fixed: Fix undefined shift [00:54:24 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:0a9e416a19c0: avcodec/x86/mpegvideodsp: Fix signedness bug in need_emu [00:54:25 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:0af4a5b180d4: avcodec/h264dec: Fix potential array overread [00:54:26 CET] <cone-098> ffmpeg 03Fredrik Hubinette 07release/2.8:c11ac27f49f7: avformat/mov: Check size of STSC allocation [00:54:27 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:7d6319e5e658: avcodec/snowdec: Check intra block dc differences. [00:54:28 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:20d6a6fa5ace: avcodec/snowdec: Check for remaining bitstream in decode_blocks() [00:54:29 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:ee54354fcd8e: avcodec/wmv2dec: Check end of bitstream in parse_mb_skip() and ff_wmv2_decode_mb() [00:54:30 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:813d7f497233: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_DD137iL0() [00:54:31 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:90ad2798ae71: avcodec/zmbv: Check that the buffer is large enough for mvec [00:54:32 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:4e5351940fe6: avcodec/mlpdsp: Fix undefined shift ff_mlp_pack_output() [00:54:33 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:107606260c4c: avcodec/hevcdsp_template: Fix invalid shift in put_hevc_epel_bi_w_v() [00:54:34 CET] <cone-098> ffmpeg 03Jacob Trimble 07release/2.8:514bdaafb439: avformat/mov: Propagate errors in mov_switch_root. [00:54:35 CET] <cone-098> ffmpeg 03Dale Curtis 07release/2.8:78782ca62d69: Fix undefined shift on assumed 8-bit input. [00:54:36 CET] <cone-098> ffmpeg 03Dale Curtis 07release/2.8:ee13d847a49c: Close ogg stream upon error when using AV_EF_EXPLODE. [00:54:37 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:ea24e70a6a41: avcodec/mpeg4videodec: Check also for negative versions in the validity check [00:54:38 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:74d467baa4a3: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_FIDELITYi* [00:54:39 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:32a92a7a9b43: avcodec/kgv1dec: Check that there is enough input for maximum RLE compression [00:54:40 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:6011422a5415: avcodec/mlpdsp: Fix signed integer overflow, 2nd try [00:54:41 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:2f7cced9bbe2: avcodec/hevcdsp_template: Fix undefined shift in put_hevc_epel_bi_w_h() [00:54:42 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:cf32c814ed1f: avcodec/j2kenc: Fix out of array access in encode_cblk() [00:54:43 CET] <cone-098> ffmpeg 03Dale Curtis 07release/2.8:2543475730b9: avformat/utils: Prevent undefined shift with wrap_bits > 64. [00:54:44 CET] <cone-098> ffmpeg 03Dale Curtis 07release/2.8:1bc4e743f561: avcodec/vorbis: 1 << 31 > int32_t::max(), so use 1u << 31 instead. [00:54:45 CET] <cone-098> ffmpeg 03Dale Curtis 07release/2.8:8bea0c307dee: Don't manipulate duration when it's AV_NOPTS_VALUE. [00:54:46 CET] <cone-098> ffmpeg 03Dale Curtis 07release/2.8:9166e6abd6c6: avcodec/vorbis: Fix another 1 << 31 > int32_t::max() with 1u. [00:54:47 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:2bffe4613ecb: avcodec/dirac_dwt: Fix integer overflows in COMPOSE_DAUB97* [00:54:48 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:f4cce67dca66: avcodec/amrwbdec: Fix division by 0 in voice_factor() [00:54:49 CET] <cone-098> ffmpeg 03Jun Zhao 07release/2.8:15df68bf5059: avfilter/formats: fix wrong function name in error message [00:54:50 CET] <cone-098> ffmpeg 03Kelly Ledford 07release/2.8:b6731e87c85d: libavfilter/af_dcshift.c: Fixed repeated spelling error [00:54:51 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:d1af42e4b26e: avcodec/hevcdsp_template: Fix undefined shift in put_hevc_qpel_bi_w_hv() [00:54:52 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:f75e2cb05946: avcodec/hevc_sei: Fix integer overflows in decode_nal_sei_message() [00:54:53 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:4eb24ae083bc: avcodec/hevc_cabac: Fix integer overflow in ff_hevc_cu_qp_delta_abs() [00:54:54 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:d0967e3faf4d: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_DD97iH0() and COMPOSE_DD137iL0() [00:54:55 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:789157fdde3d: avcodec/hevcdsp_template.c: Fix undefined shift in FUNC(dequant) [00:54:56 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:59e3f49ef0f3: avcodec/flacdec: avoid undefined shift [00:54:57 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:aae8ea9c186e: avcodec/hevcdsp_template: Fix Invalid shifts in put_hevc_qpel_bi_w_h() and put_hevc_qpel_bi_w_w() [00:54:58 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:2a53778676d0: avcodec/flacdec: Fix overflow in multiplication in decode_subframe_fixed() [00:54:59 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:0abf465dc561: avcodec/exr: Check buf_size more completely [00:55:00 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:761362fffb86: avcodec/h264_slice: Do not attempt to render into frames already output [00:55:01 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:a15c056f5ca9: avcodec/jpeg2000dsp: Fix integer overflows in ict_int() [00:55:02 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:c860d5326f56: avcodec/opus_parser: Check payload_len in parse_opus_ts_header() [00:55:03 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:c65c4c475975: avcodec/diracdec: Fix integer overflow with quant [00:55:04 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:2885e45eb467: avcodec/dirac_dwt: Fix overflows in COMPOSE_HAARiH0/COMPOSE_HAARiL0 [00:55:05 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:82fb8dc076f7: avcodec/h264addpx_template: Fixes integer overflows [00:55:06 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:74aeeb223a13: avcodec/arm/sbrdsp_neon: Use a free register instead of putting 2 things in one [00:55:07 CET] <cone-098> ffmpeg 03Carl Eugen Hoyos 07release/2.8:10ed2f197201: configure: bump year [00:55:08 CET] <cone-098> ffmpeg 03Nikolas Bowe 07release/2.8:5971f1941b39: avformat/matroskadec: Fix float-cast-overflow undefined behavior in matroska_parse_tracks() [00:55:09 CET] <cone-098> ffmpeg 03Nikolas Bowe 07release/2.8:3e499537a46f: avformat/lrcdec: Fix memory leak in lrc_read_header() [00:55:10 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:b51f1f5a1911: avcodec/ac3dec_fixed: Fix integer overflow in scale_coefs() [00:55:11 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:0036b62c9911: avcodec/ulti: Check number of blocks at init [00:55:12 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:b9948d52756a: avcodec/snowdec: Fix integer overflow before htaps check [00:55:13 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:25f7121c7b98: avcodec/truemotion2: Fix integer overflow in TM2_RECALC_BLOCK() [00:55:14 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:193b6df3572f: avcodec/hevc_cabac: Move prefix check in coeff_abs_level_remaining_decode() down [00:55:15 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:c1f7b2b6e18a: avcodec/mjpegdec: Fix integer overflow in DC dequantization [00:55:16 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:c740f585a183: avcodec/hevc_cabac: Check prefix so as to avoid invalid shifts in coeff_abs_level_remaining_decode() [00:55:17 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:ed06873b7b2d: avfilter/vf_transpose: Fix used plane count. [00:55:18 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:54a7d3efc436: avcodec/mpeg4videodec: Check mb_num also against 0 [00:55:19 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:f606a943d31a: avcodec/get_bits: Document the return code of get_vlc2() [00:55:20 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:b6a7dd174ab3: avcodec/mpeg4videodec: Avoid possibly aliasing violating casts [00:55:21 CET] <cone-098> ffmpeg 03Aman Gupta 07release/2.8:b40576a9a436: avcodec/hevc_ps: extract one SPS fields required for hvcC construction [00:55:22 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:4abdd6535628: avcodec/hevc_ps: Check log2_sao_offset_scale_* [00:55:23 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:a0c366b1f57c: avcodec/indeo5: Do not leave frame_type set to an invalid value [00:55:24 CET] <cone-098> ffmpeg 03Michael Niedermayer 07release/2.8:172edcf3baa7: Update for 2.8.14 [02:36:23 CET] <cone-098> ffmpeg 03Luca Barbato 07release/2.8:7a30e6448c25: x264: Support version 153 [02:36:24 CET] <cone-098> ffmpeg 03James Almer 07release/2.8:c95d343ae170: changelog: update with previous commit [02:40:42 CET] <cone-098> ffmpeg 03James Almer 07release/2.4:1cae2f002d4e: avcodec/libx264: fix usage of AVComponentDescriptor depth field [03:58:13 CET] <cone-098> ffmpeg 03Steven Liu 07master:27fe8930e0b9: avfilter: add comments for duplicate line [03:58:14 CET] <cone-098> ffmpeg 03Steven Liu 07master:44f343067455: avformat/http: add referer option into http [03:58:15 CET] <cone-098> ffmpeg 03Steven Liu 07master:b1af0e23a3b6: avformat/hls: store referer message in HLS http request [18:00:55 CET] <kepstin> atomnuker: you wrote the librsvg decoder, right? Any chance you could take a quick look at https://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/224761.html ? it fixes an issue someone was running into in #ffmpeg yesterday. [18:06:27 CET] <atomnuker> done [18:14:02 CET] <durandal_1707> where is vulkan filter? [18:25:27 CET] <kierank> durandal_1707: going to fosdem? [18:26:29 CET] <durandal_1707> kierank: no, im going to mars with flamethrower :/ [18:27:36 CET] <atomnuker> durandal_1707: on my github, was trying to figure out why DRM didn't work as expected, waiting for mesa to tell me whether they have a bug or not [19:28:46 CET] <kepstin> atomnuker: send out an updated patch, thanks for the feedback. [00:00:00 CET] --- Fri Feb 2 2018

1 0

ffmpeg.log.20180201
by burek 02 Feb '18

02 Feb '18

[00:00:46 CET] <linux50> I am stumped... I am trying to capture a rtsp stream from my foscam camera and re-stream it using ffserver. Am I allowed to paste my ffmpeg command here? [00:01:31 CET] <furq> probably pastebin it [00:01:40 CET] <furq> but the advice you'll get will most likely be "don't use ffserver" [00:02:02 CET] <linux50> well... my issue is that ffmpeg is not capturing the stream to begin with [00:02:10 CET] <linux50> so Im still behind the curve ball there [00:02:24 CET] <BtbN> keep in mind that ffserver is dead and nobody has any useful experience with it. [00:02:40 CET] <BtbN> So help there will be limited, mostly a bunch of people telling you not to use it. So, don't use it. [00:02:42 CET] <furq> does it work if you output to a file instead of ffserver [00:03:20 CET] <linux50> im not sure [00:03:31 CET] <linux50> forgive my ignorance [00:10:18 CET] <linux50> https://pastebin.com/GBpiaHxM [00:10:25 CET] <linux50> can anyone please take a look [00:11:18 CET] <linux50> on the bottom... Text is red and underlined with a message "Unkown Encoder 'libx264' [00:11:31 CET] <furq> configuration: --enable-libvpx [00:11:34 CET] <furq> uhh [00:11:58 CET] <furq> did you build this yourself [00:12:18 CET] <furq> if not then go and yell at whoever did build it [00:12:29 CET] <linux50> no... like a noob... i tried different commands [00:12:32 CET] <linux50> this has never worked [00:12:38 CET] <linux50> so... im the only one to blame [00:12:43 CET] <furq> well yeah that build doesn't have x264 [00:12:47 CET] <linux50> this is for learning purposes [00:12:50 CET] <furq> or very much of anything really [00:13:05 CET] <linux50> when you say build [00:13:10 CET] <linux50> are you referring to how it was compiled [00:13:11 CET] <linux50> ? [00:13:12 CET] <furq> yes [00:14:30 CET] <linux50> im at the documentation page of ffmpeg.org [00:14:43 CET] <linux50> is there a HowTo? [00:14:54 CET] <furq> how to what [00:14:54 CET] <linux50> on how to compile with the appropiate features? [00:15:11 CET] <furq> there are compilation guides on the wiki [00:15:12 CET] <furq> but really [00:15:15 CET] <furq> https://www.johnvansickle.com/ffmpeg/ [00:15:18 CET] <furq> just use that [00:16:31 CET] <linux50> thank you [00:16:33 CET] <linux50> i will try that out [00:17:51 CET] <linux50> one last thing... how were you able to see that it had no features? [00:23:59 CET] <furq> where it says "configuration: --enable-libvpx" [00:24:44 CET] <furq> http://vpaste.net/lcMNO [00:24:47 CET] <furq> as opposed to something like this [00:37:14 CET] <linux50> furq: http://vpaste.net/ijIHK [00:37:49 CET] <linux50> okay [00:37:58 CET] <linux50> i think i have resolved that issue, right? [01:04:22 CET] <geuis> furq: was the librsvg wrapper yours? [01:05:00 CET] <atomnuker> no, I wrote it [01:05:14 CET] <atomnuker> bugs? [01:06:57 CET] <geuis> cool wrapper. [01:07:01 CET] <geuis> question about fonts [01:07:48 CET] <geuis> the original svg includes a path to a local font file for text. shows up in other svg viewing apps but isn't being used by ffmpeg [01:07:55 CET] <geuis> wonder if you had any insights [01:08:56 CET] <ddubya> svg is plaintext right? You can find and replace the fonts [01:09:27 CET] <atomnuker> geuis: never heard of such, but libcairo should handle it [01:09:38 CET] <geuis> yup plaintext. not sure what you mean by find and replace though [01:10:16 CET] <ddubya> replace the font with another one that you have [01:10:33 CET] <ddubya> maybe the font substitution doesn't work for some reason [01:11:05 CET] <geuis> the font file is local to the directory where ffmpeg is working. The svgs all reference it [01:11:31 CET] <ddubya> oic [01:12:23 CET] <ddubya> well if you can't install the font, perhaps you can add the directory to font search path [01:12:36 CET] <ddubya> no idea how [01:12:42 CET] <geuis> hmm [01:15:45 CET] <ddubya> or maybe use a fully qualified path in the svg [01:15:55 CET] <ddubya> might need file:// prefix on it [01:32:41 CET] <kepstin> geuis: what format is the external font file? [01:35:24 CET] <geuis> ttg [01:35:26 CET] <geuis> ttf [01:35:52 CET] <kepstin> ttf? I suspect the most reliable way is to just install the font and use it by name then, rather than listing a file. [01:38:24 CET] <geuis> hmm just install it to debian and reference by name? [01:38:42 CET] <kepstin> yeah, using css font-family: "Font Name" or whatever [01:39:09 CET] <geuis> ddubya: tried the file:// path, no luck [01:39:13 CET] <kepstin> I don't think rsvg has any support for loading fonts from files at all [01:39:45 CET] <geuis> what about how fontfile is referenced in drawtext? [01:40:18 CET] <geuis> looked briefly through the docs but not sure if fontfile works outside of drawtext [01:40:54 CET] <kepstin> drawtext is completely independent from the librsvg "decoder" (svg renderer) [01:42:32 CET] <kepstin> it looks like librsvg internally just passes the font-family from the svg to pango, which attempts to load that from the system fonts [01:42:41 CET] <kepstin> they explicitly don't support svg fonts [01:49:44 CET] <linux50> Hi Everyone... What streaming server (besides ffserver) do you recommend? Also... Why should I not use ffserver? [02:02:02 CET] <kepstin> linux50: you shouldn't use ffserver because nobody is gonna be able to help you if you have problems with ffserver. [02:02:45 CET] <kepstin> as for a streaming server, that depends entirely on what's gonna be playing the stream. [02:07:14 CET] <SortaCore> copying from m3u8, is it meant to keep selecting new URLs? [02:07:51 CET] <SortaCore> it goes from bla(n).ts to bla(n+1).ts [02:09:53 CET] <SortaCore> on the computer doing screen recording, it keeps pausing for buffering [03:02:55 CET] <SortaCore> correct answer: yea, it seems like new URLs make no difference [03:54:54 CET] <karen__> You still around JEEB? [04:22:35 CET] <doug___> hi! is there any filter to track faces in the video? [04:23:03 CET] <thebombzen> libavfilter doesn't have any native facial recognition algorithms [04:23:31 CET] <thebombzen> You'd have to find something more specialized to do that [04:24:04 CET] <doug___> ok thanks thebombzen! [04:24:33 CET] <thebombzen> doug___: it is worth noting that it has a video stabalizer plugin with vid.stab [04:24:40 CET] <thebombzen> that might make it easier to track faces with other software [04:24:50 CET] <linux50> hi everyone... What stream (re-broadcast) server do you recommend [04:24:51 CET] <thebombzen> since the background will not move as much [04:25:22 CET] <thebombzen> linux50: the most common recommendation is to use nginx as an HTTP streaming server [04:25:27 CET] <linux50> I have my foscam ip cameras as my source using h.264 and AAC [04:25:32 CET] <linux50> oh interesting [04:25:33 CET] <linux50> okay [04:25:36 CET] <linux50> ill check that out [04:25:39 CET] <linux50> just curious [04:25:43 CET] <linux50> why nginx [04:25:44 CET] <linux50> ? [04:25:50 CET] <thebombzen> it's a generic http server (like apache) that needs a module to do it [04:26:02 CET] <linux50> can it be done in apache? [04:26:02 CET] <thebombzen> this is for HLS or Dash. for rtmp* you'd need something else [04:26:14 CET] <thebombzen> I believe it's easier to do it in nginx, but perhaps it can be done in apache? I don't know. [04:26:17 CET] <doug___> thebombzen: thank you. You've been most helpful [04:26:21 CET] <thebombzen> :) [04:26:37 CET] <linux50> for rtmp is there a recommendation [04:26:43 CET] <linux50> or should I re-encode it with ffmpeg? [04:26:54 CET] <thebombzen> I'd avoid re-encoding if possible, but it might be unavoidable [04:27:03 CET] <thebombzen> since if the bitrate is too high for streaming you can't stream it [04:27:23 CET] <thebombzen> I have no idea what to use as an rtmp streaming server, sorry. [04:27:54 CET] <linux50> okay [04:28:03 CET] <linux50> ffmpeg can transcode right? [04:28:11 CET] <thebombzen> yes, absolutely [04:28:18 CET] <thebombzen> also upon googling apparently nginx-rtmp exists [04:28:19 CET] <linux50> thats what "-f mpeg4" would mean? [04:28:38 CET] <thebombzen> no, you wouldn't use "-f mpeg4" cause that would mean "mux to the mpeg4 container format" which doesn't exist [04:28:56 CET] <linux50> what would be ideal then? [04:28:56 CET] <thebombzen> transcoding is decoding and re-encoding [04:29:09 CET] <thebombzen> Ideally you wouldn't be transcoding, and just streamcopy [04:29:16 CET] <thebombzen> but upon googling I found nginx-rtmp: http://nginx-rtmp.blogspot.com/ [04:29:23 CET] <thebombzen> check it out, if you'd ike to stream over rtmp [04:29:35 CET] <thebombzen> it also does HLS and Dash though if that fits your needs better [04:29:56 CET] <linux50> okay... So i continue to be on square 1 [04:30:33 CET] <linux50> so my objective is to put all my home cameras onto a internal webpage at home that my raspberry pi (which is connected to my TV) can present on my TV [04:30:55 CET] <linux50> so am I going about it the wrong way? [04:32:59 CET] <thebombzen> if you're looking for some sort of CCTV-like system, the best way to do that is probably to just not do a webpage [04:33:23 CET] <thebombzen> have all the cameras go directly to the rasperry pi, which will then on-the-fly just tile the videos together and put it on your TV [04:33:53 CET] <thebombzen> you don't need to do a webpage rendered in the browser if you're not interacting with the videos, just displaying them. [04:54:45 CET] <linux50> thebombzen: can ffmpeg send the stream to nginx as well as save to an output file? [04:54:51 CET] <thebombzen> Yes [04:55:00 CET] <linux50> how would that format look like [04:55:19 CET] <linux50> do I specify the file the the destination url [04:55:19 CET] <linux50> ? [04:55:38 CET] <linux50> do I specify the file then the destination url? [04:55:43 CET] <linux50> sorry for the typo* [04:56:06 CET] <kazuma_> output it as hls/m3u8 in a dir nginx monitors [04:56:24 CET] <kazuma_> then access the m3u8 from a browser or device [04:59:28 CET] <kazuma_> https://pastebin.com/1cM2CCga might be useful for you linux50, my script to do it in windows, the recordings are stored locally as .ts + encoded on the fly and streamed to wherever via nginx [05:03:58 CET] <linux50> thank you [05:04:01 CET] <linux50> i will review [05:04:47 CET] <linux50> what is the -ss? [05:09:28 CET] <kazuma_> -ss in ffmpeg specifies video start time, so in that script i get the current runtime of the active recording with media info for loop and set it as %duration% [05:09:56 CET] <kazuma_> so then when i start encoding for the live stream, it starts from where the recoring is at, instead of from the beggining of the recording file [05:10:43 CET] <linux50> does that mean you have 1 giant file? [05:10:49 CET] <linux50> with all your recording? [05:11:08 CET] <kazuma_> yeah, i have the recording writing to disk [05:11:30 CET] <kazuma_> then jump into it at %current_time% to stream from [05:12:57 CET] <linux50> i wrote my own script using openRTSP that would break the recording into 5 minute increments [05:13:18 CET] <linux50> and then organize the videos by hour then day, then month, etc... [05:13:47 CET] <linux50> so If i needed to go back and review i could quickly move through it in 5 minute increments [05:14:49 CET] <kazuma_> good idea [05:15:01 CET] <linux50> but its in bash [05:15:10 CET] <linux50> i dont mind passing it down to you guys [05:15:14 CET] <linux50> via pastebin or something [05:15:36 CET] <linux50> i personally didnt like it because I wanted to re-broadcast it [05:15:40 CET] <linux50> and I dont think it does that [05:15:53 CET] <linux50> but... [05:16:00 CET] <linux50> if I can get the nginx to work [05:16:17 CET] <linux50> ill have the script pull the stream from nginx (if possible) and record the video for me [09:13:16 CET] <bloobloo> found a bug from ffmpeg? https://pastebin.com/YXksPJaC [09:14:18 CET] <bloobloo> "-i default" works but "-i hw:3,0" doesn't, the "arecord -l" shows there is the 3,0 device [09:16:50 CET] <bloobloo> many people were using "-f alsa" and suggested that command, i guess that works with "-f alsa" but not with "-f pulse" [09:28:53 CET] <furq> bloobloo: what's the output of pactl list sources [09:31:30 CET] <bloobloo> furq: https://pastebin.com/71fnTwx0 [09:38:43 CET] <furq> i guess you want -f pulse -i 1 [09:41:30 CET] <Nacht> isn't it 3.0 instead of 3,1 ? [09:41:38 CET] <Nacht> *3,0 [09:45:30 CET] <bloobloo> furq: that indeed works [09:45:59 CET] <bloobloo> Nacht: both should work [09:46:08 CET] <bloobloo> if i remember correctly [10:30:06 CET] <kazuma_> i have a video with "Chroma subsampling : 4:2:0 (Type 2)" [10:30:43 CET] <kazuma_> when i encode it, it becomes "4:2:0", how can i maintain the (Type 2) ?? [10:32:01 CET] <JEEB> I have no idea what that means, 4:2:0 is 4:2:0 [10:32:48 CET] <JEEB> in other words, find out wtf whatever you're reading that from means with that thing [10:33:30 CET] <kazuma_> https://pastebin.com/raw/TCuwVWXx [10:34:30 CET] <kazuma_> it's this video JEEB, i was told when encoding it, i should keep the same settings for everything eg, 5.1, 4:2:0 type 2, 10bit, btrec2020 [10:36:07 CET] <kazuma_> i think it's somthing to do with hdr primaries [10:37:13 CET] <JEEB> uhh [10:37:29 CET] <JEEB> there is no metadata for 4:2:0 type1/2, there is no such distinction [10:37:50 CET] <JEEB> so really, ask Mediainfo [10:38:13 CET] <kazuma_> i might make a post later, thanks for the info [10:38:17 CET] <JEEB> the range, primaries, transfer characteristics are what matter (and then you have the special HDR metadata which is sepatate) [10:38:21 CET] <JEEB> *separate [10:39:22 CET] <JEEB> kazuma_: also I don't know of two different 4:2:0 modes in HEVC, pretty sure won't find it in https://www.itu.int/rec/T-REC-H.265-201612-I/en [10:39:41 CET] <JEEB> so as I noted, find out WTF mediainfo means with that and if it actually means anything [10:40:41 CET] <kazuma_> ok, will see what i can find out [10:40:44 CET] <jkqxz> Chroma sample location, perhaps? [10:40:53 CET] <jkqxz> That's kindof a property of the subsampling rather than anything else. [10:47:10 CET] <JEEB> jkqxz: yea but I would expect it to output it like ffprobe then [10:47:15 CET] <JEEB> Chroma Location: Top Left or so [10:47:25 CET] <JEEB> instead of "4:2:0 (Type 2)" [10:47:32 CET] <JEEB> in chroma subsamppling [10:53:58 CET] <kazuma_> ffprobe shows it as "yuv420p10le" [10:55:58 CET] <pmjdebruijn> so that's 10bit [10:56:45 CET] <pmjdebruijn> kazuma_: so not all codec have a 10bit mode [11:01:16 CET] <JEEB> kazuma_: that's just 10bit , 4:2:0. ffprobe will also show a lot of other stuff esp. with -v verbose [11:02:19 CET] <JEEB> verbose adds the chroma location as well [11:02:22 CET] <JEEB> `yuv420p(tv, bt709, top first, left)` [11:02:32 CET] <JEEB> is from an interlaced thing I have on hand :P [11:03:01 CET] <inkubot> hi all.. not sure to create a bug report so i will start here... ffprobe is putting every i-frame as IDR key_frame=1 ... [11:03:51 CET] <JEEB> inkubot: check with current master if possible, and post a sample + link it on the trac issue tracker [11:04:03 CET] <inkubot> anyone is using ffprobe to analyze video, with 2sec GOP and I-Frame insertion in scene changes?? before our scripts were working ok because it wasn't open gop [11:04:12 CET] <inkubot> ok JEEB thanks [11:04:16 CET] <inkubot> will try it [11:05:04 CET] <JEEB> with open gop I recall reading the H.264 parser and it would only mark things as random access points if a) IDR or b) open GOP random access point SEI + I [11:05:16 CET] <JEEB> if it's anything else it shouldn't mark it as a random access point [11:06:12 CET] <inkubot> sorry my mistake not open gop... just and IDR every 2 seconds and i-frame insertion in scene change inside the chunk [11:06:27 CET] <inkubot> i will try with current [11:06:51 CET] <JEEB> well I just noted to you the two ways I remember FFmpeg's H.264 parser notes random access points with H.264 (unless the container has that information) [11:07:23 CET] <JEEB> because if the container has a random access point flag then that is of course trusted [12:13:56 CET] <LiamC> Anybody come across "Invalid UE golomb code" when converting AVI to MP4 with ffmpeg? [14:32:46 CET] <wouter> hi -- I'm having issues with concatenated video [14:33:37 CET] <wouter> getting output like http://paste.debian.net/1008324/ on stderr [14:33:55 CET] <wouter> and the result is a video that just freezes when it should switch to the next component [14:34:17 CET] <wouter> (I'm doing 'ffmpeg -f concat foo.txt -c:v copy -c:a copy', in case that matters) [14:34:29 CET] <wouter> although that's not the entire command line; I can get you one if you need [14:38:13 CET] <wouter> any ideas what I might be doing wrong? [14:43:13 CET] <mort> I'm calling av_frame_get_buffer, which allocates the frame's 3 buffers. frame->buf[{0,1,2}] exist, and claim to have a size which seem appropriate, but calling 'av_buffer_get_opaque' on them returns NULl. Am I missing something? [14:47:07 CET] <jkqxz> mort: What are you trying to do? The opaque field is owned by whoever allocates it and generally shouldn't be touched by anything else. [14:48:22 CET] <mort> jkqxz: it's allocated by a codec I'm trying to add to libavcodecs (using that av_frame_get_buffer function), and used by webrtc [14:48:53 CET] <mort> I'm trying to add a codec to chromium's webrtc implementation, and that uses ffmpeg, so I'm adding it as an ffmpeg codec [14:49:10 CET] <mort> webrtc is using av_buffer_get_opaque and casting the result to its own VideoFrame struct [14:49:49 CET] <jkqxz> Well, that must be assuming it has a frame it allocated itself and put into AVFrame. [14:50:25 CET] <mort> https://cs.chromium.org/chromium/src/third_party/webrtc/modules/video_codin… [14:50:51 CET] <mort> it's not allocating av_frame_->buf[0] itself, that's allocated by avcodec_decode_video2 [14:51:57 CET] <jkqxz> It must have allocated the frames itself if it expects that to work. [14:52:39 CET] <mort> av_frame_ itself is just allocated by 'av_frame_.reset(av_frame_alloc())' [14:52:40 CET] <jkqxz> That will definitely not work on any frame allocated by libav*. [14:53:26 CET] <jkqxz> If that's comig from receive_frame(), presumably it set a get_buffer callback so that it can do the allocation? [14:53:54 CET] <mort> right, yes, there's actually a get_buffer callback [14:54:13 CET] <mort> I didn't think about that, that's probably why it works; thanks [14:54:43 CET] <kepstin> wouter: i'm guessing that the videos you're concatenating were not encoded with compatible settings (and ffmpeg doesn't or isn't able to to midstream parameter updates in most containers) [14:55:56 CET] <wouter> kepstin: I just noticed that the audio layout wasn't entirely the same; but beyond that, it should [14:56:26 CET] <kepstin> wouter: in this particular case, it looks like one of the later videos was encoded with a higher number of reference frames than a previous video. [14:56:27 CET] <wouter> kepstin: I ran 'ffprobe -show_format -show_streams' on all files and compared the output; didn't find anything totally out of the ordinary [14:56:38 CET] <wouter> oh, okay [14:56:41 CET] <kepstin> wouter: ffprobe won't show this, no. [14:57:13 CET] <wouter> so what I'm trying to do is add opening credits and closing credits based on a .png file to a video [14:57:42 CET] <wouter> so I use ffmpeg to generate a 5-second video file based on the two PNG files first, and then concatenate the two together [14:57:48 CET] <wouter> but perhaps that's not the best way to do it? [14:58:02 CET] <kepstin> wouter: assuming the existing video was encoded with x264, you should be able to use mediainfo or so to find out what x264 settings were used, and attempt to copy those. [14:58:11 CET] <kepstin> that might be enough to get it to work [14:58:29 CET] <wouter> hrm, okay. Where is this "mediainfo" documented? Haven't heard of it... [14:58:49 CET] <wouter> oh, it's a separate program, right [14:59:04 CET] <kepstin> or you could just try using something like -preset veryslow when making your credits, so your first video uses all the x264 features [14:59:09 CET] <kepstin> that might be enough. [14:59:48 CET] <wouter> mm, let me try that one [15:16:53 CET] <saml> good morning my friends [15:24:33 CET] <wouter> kepstin: -preset veryslow doesn't seem to be fixing it. mediainfo output on a sample of the video that we're trying to convert is http://paste.debian.net/1008324/; what parameters should I add to ffmpeg to make a file that is compatible? [15:24:39 CET] <wouter> kepstin: current command line is: [15:24:40 CET] <wouter> Running: 'ffmpeg' '-loglevel' 'warning' '-y' '-loop' '1' '-framerate' '25/1' '-i' '/srv/sreview/assets/fosdem2018_sponsors_bg.png' '-f' 'lavfi' '-i' 'anullsrc=channel_layout=mono' '-c:v' 'libx264' '-r:v' '25/1' '-speed' '4' '-c:a' 'aac' '-ar' '48000' '-t' '5' '-pix_fmt' 'yuv420p' '-preset' 'veryslow' '/tmp/transpaVhji/video_test-postroll.mkv' [15:24:56 CET] <wouter> (actually, that would be "libfdk_aac", but anyway) [15:25:29 CET] <kepstin> wouter: wrong paste? that's not the mediainfo output [15:25:45 CET] <wouter> whoops [15:25:49 CET] <wouter> http://paste.debian.net/1008338/ is the right one [15:26:21 CET] <wouter> (I really want to "do it right" at some point, but don't have the time right now, FOSDEM is this weekend and it needs to work then...) [15:26:31 CET] <saml> are you concating two same codec? [15:27:23 CET] <kepstin> saml: same codec, but different encoder settings in a way that means the sps from the first video isn't compatible with the second video. [15:27:28 CET] <wouter> saml: I'm trying to create a 5-second file from a .png file that is compatibl with what the video team records [15:28:12 CET] <kepstin> wouter: hmm, that video might not be from x264 then, if it's off a camera or capture card or something. [15:28:38 CET] <wouter> yeah, it's from a blackmagic hardware encoder. [15:28:48 CET] <wouter> sorry, you did mention that [15:28:53 CET] <saml> one static image for 5 secs followed by whatever vid? [15:29:08 CET] <kepstin> wouter: honestly, i'd probably just re-encode the whole thing with x264 (use fast settings if needed), since figuring out x264 settings close enough to match it would be a lot of trial and error. [15:29:13 CET] <wouter> yes, and the same at the end, in reverse [15:29:30 CET] <wouter> the one at start works right now, but it's the end slide that fails [15:29:59 CET] <saml> audio is none? [15:30:08 CET] <kepstin> wouter: oh, it's the transition from main video to end credits that fails? [15:30:14 CET] <wouter> kepstin: yes [15:30:24 CET] <kepstin> i thought it was front credits to main video. [15:30:25 CET] <wouter> opening credits to main video works fine [15:31:08 CET] <wouter> there's an example at https://video.fosdem.org/2018/J1.106/2018-02-03/video_test.mp4 [15:31:42 CET] <wouter> (sorry about the annoying audio, wasn't my fault ;) [15:32:22 CET] <kepstin> ok, setting '-profile:v main -level 31' when encoding the end video will probably be enough [15:32:34 CET] <kepstin> that should match the hardware encoder close enough. worth a try anyways [15:32:43 CET] <wouter> yeah, I'll give that a go [15:32:53 CET] <wouter> those are output options, right? [15:32:55 CET] <kepstin> yes [15:33:54 CET] <kepstin> if you're got some time, and particularly if you're going to be distributing these videos over the internet, you should probably still re-encode the whole thing with x264 if only to reduce the size. [15:34:10 CET] <wouter> we're also transcoding to vp9 ATM [15:34:21 CET] <wouter> shipping mp4 because it exists, but I really only care about the vp9 [15:34:28 CET] <wouter> and that ends up being about half size, so... [15:34:35 CET] <kepstin> ouch. I hope you've got libvpx 1.7 for the multithreaded vp9 encoder :) [15:34:54 CET] <wouter> we're going to be transcoding 600+ videos, I don't care about the time for a single video ;-) [15:35:06 CET] <wouter> but I did see the recommended settings on the google website, and we're using that [15:35:21 CET] <kepstin> re-encoding the mp4 with x264 should let you reduce the size quite a bit at similar quality - hardware encoders are not very efficient in general [15:35:39 CET] <kepstin> it'll probably be close to the vp9 file [15:35:44 CET] <wouter> yeah, but it would also need some testing and coding, and it's too late for that now [15:44:13 CET] <wouter> kepstin: that failed too :-/ [15:49:43 CET] <wouter> kepstin: can I tune the reference frame settings in ffmpeg somehow? Reading the manpage, but can't find it... [15:49:49 CET] <furq> -refs [15:49:59 CET] <furq> or maybe -ref, i forget which one is ffmpeg and which is x264 [15:50:08 CET] <furq> check in ffmpeg -h encoder=libx264 [15:51:56 CET] <saml> i'm asking this question again. what is a good lossless codec and container? [15:52:33 CET] <furq> depends what you need [15:52:38 CET] <saml> -vcodec libx264 -crf 0 out.mp4 is good but I don't like .mp4 cause I cannot send stream to -i [15:52:45 CET] <furq> use mkv then [15:52:58 CET] <saml> what's a good video codec for mkv? [15:53:20 CET] <furq> anything [15:54:18 CET] <wouter> kepstin: would it perhaps be possible to tell ffmpeg to re-encode the first and last videos, but not the main one? [15:55:41 CET] <furq> isn't the main video the one that's causing issues [15:56:12 CET] <wouter> well, yeah, but it's also the huge one [15:56:24 CET] <wouter> the main one would be a whole talk (say an hour or so), the other two are 5 seconds each [15:56:33 CET] <furq> well yeah you'd still have the same problem then [15:56:35 CET] <saml> https://gist.github.com/saml/a384801a53a87bfd4a78df6a5a5308a2 i'm still hung up on this psnr. am i doing lossless mkv wrong way? [15:56:48 CET] <wouter> and I'm really only transcoding PNG files to x264 because otherwise it seems impossible to do that? [15:56:48 CET] <therage3> saml: mkv container supports an obscene amount of video codecs, so choose one that serves your purpose the best. [15:56:48 CET] <furq> there's no way to get x264 to automatically match the sps values of another stream [15:57:01 CET] <wouter> but maybe I missed something obvious [15:57:25 CET] <saml> sps? [15:57:25 CET] <furq> i'm sure there's a tool that shows you all the sps/pps values but i can't find it now [15:57:38 CET] <furq> afaik those should ideally match exactly if you want to concat two streams [15:57:44 CET] <furq> although some decoders are probably a bit more lax about it [16:01:08 CET] <wouter> Hrm. Is there a page with recommended settings for x264 encoding somewhere? Things like bitrates etc [16:01:13 CET] <furq> oh duh [16:01:14 CET] <furq> wouter: https://github.com/aizvorski/h264bitstream [16:01:28 CET] <furq> the h264_analyze utility from that should be able to show you what's different [16:01:35 CET] <wouter> ah, heh, okay [16:01:36 CET] <wouter> thanks [16:01:57 CET] <furq> i forgot there's an actual binary in that, i thought it was just a lib [16:02:06 CET] <wouter> right [16:07:18 CET] <wouter> furq: https://grep.be/~wouter/test.264 is the output from the hardware decoder [16:08:35 CET] <wouter> er, I mean, what that tool produces on the output of the hardware *en*coder, obviously [16:11:28 CET] <wouter> the postroll just doesn't have any lines saying "sps"... what does that imply? [16:12:05 CET] <wouter> furq: https://grep.be/~wouter/post.264 [16:12:40 CET] <furq> how did you encode the postroll [16:13:22 CET] <wouter> ffmpeg '-loglevel' 'warning' '-y' '-loop' '1' '-framerate' '25/1' '-i' 'fosdem2018_sponsors_bg.png' '-f' 'lavfi' '-i' 'anullsrc=channel_layout=mono' '-c:v' 'libx264' '-r:v' '25/1' '-speed' '4' '-c:a' 'aac' '-ar' '48000' '-t' '5' '-pix_fmt' 'yuv420p' '-profile:v' 'main' '-level' '31' 'video_test-postroll.mkv' [16:14:13 CET] <wouter> (that's a generated command line, but...) [16:14:35 CET] <furq> weird [16:14:43 CET] <furq> i take it that plays by itself [16:15:02 CET] <wouter> let me double-check that ;) [16:15:19 CET] <wouter> yeah, it does [16:15:25 CET] <furq> if there's actually no sps then it probably wouldn't play at all [16:15:31 CET] <furq> and also ffmpeg shouldn't be producing anything that broken [16:15:37 CET] <furq> so i wonder if h264_analyze just isn't very good [16:15:42 CET] <wouter> obviously though, since it's a single thing that doesn't move... [16:15:59 CET] <wouter> furq: I need to go away now for a while, not sure when I'll be back, but at least an hour or so [16:16:38 CET] <wouter> furq: thanks for the help so far anyway, I'll see if I can think out of the box a bit and maybe fix it in some way [16:53:25 CET] <yusa> Hello there, i was just trying to read png with 10 fps and convert dem to a video on the fly and displaying with mpv with: "cat output/*png | ffmpeg -r 10 -i - -c:v libx264 -f flv - | mpv -" But it seems that, First: All PNGs are loaded and then trancoding is started. Thats a problem for me because actually i want to read PNGs coming from a named pipe and transcode them on the fly to video displayed by mpv. Any ideas to overcome this is [16:54:58 CET] <yusa> Sorry for typos: *dem=them [16:58:46 CET] <kepstin> yusa: by default, libx264 uses a very large buffer of frames so it can do efficient encoding. If you instead want it to output frames as soon as possible, add "-tune zerolatency" to the ffmpeg output options. [16:59:34 CET] <kepstin> but that said, you should be able to convince mpv to play the png stream directly without needing ffmpeg in the middle [17:03:40 CET] <yusa> that would be fine also :-D [17:04:46 CET] <yusa> with -tune zerolatency it seems to start working roughly after frame 50 [17:05:00 CET] <kepstin> yusa: that's probably just down to pipe buffers then [17:05:17 CET] <yusa> cat output/*png | mpv - This is not working :D [17:05:39 CET] <yusa> yes probably due to my pipe [17:05:48 CET] <kepstin> you'd see different behaviour if you're slowly passing frames in instead of using cat to load a lot at once [17:07:56 CET] <kepstin> yusa: try "mpv --demuxer-lavf-format=image2pipe -" [17:09:04 CET] <kepstin> you might also need to add --demuxer=+lavf [17:13:01 CET] <furq> failing that, if this is just for mpv then just use -c:v rawvideo -f nut in your original command [17:13:22 CET] <yusa> Awesome man, thanks a lot! This works for me: cat <>out_pipe.png | mpv --demuxer-lavf-format=image2pipe - [17:13:50 CET] <yusa> What would the lavf option mean? [17:14:11 CET] <kepstin> yusa: mpv has a bunch of its own demuxers, or it can use libavformat (from ffmpeg) to demux [17:14:16 CET] <kepstin> lavf is short for libavformat [17:15:11 CET] <yusa> ok thanks [17:18:01 CET] <yusa> No ffmpeg command needed anymore, i think i have to leave irc now :P ;-) [17:27:53 CET] <saml> hi bloodbath [18:17:56 CET] <zerodefect> What is the easiest/best way to do a AVFrame format conversion using the C-API. I'm using BT.601 and BT.709, so I'd like to preserve the transfer characteristics. Setting up a graph is a bit cumbersome, and it feels a bit over the top. [18:18:28 CET] <zerodefect> I'd like to convert from YUVV422 (interleaved) to YUV422P [18:18:42 CET] <zerodefect> *YUV422 [18:18:50 CET] <zerodefect> to YUYV422P [18:19:09 CET] <kepstin> zerodefect: you either have to use libswscale directly, which means you have to do a lot of manual work with AVFrames, or use libavfilter, which means setting up a filter graph [18:20:06 CET] <kepstin> the latter is *probably* the better option if you're already working with AVFrames [18:21:16 CET] <zerodefect> Ok. I'll go down that route. [18:21:25 CET] <zerodefect> thanks @kepstin [18:53:31 CET] <saml> [Parsed_ssim_1 @ 0x5631b0e6f660] SSIM Y:0.874944 (9.028965) U:0.962720 (14.285209) V:0.965424 (14.612272) All:0.904654 (10.206954) [18:53:38 CET] <saml> does that mean two videos are similar? [18:53:46 CET] <saml> i'm not sure what's the number in parens [19:10:02 CET] <kepstin> saml: I think the main number is the similarity (1.0 is identical), which means the scond is... hmm, I have no idea. [19:43:13 CET] <wouter> furq: so I'm an idiot, it actually is ffmpeg after all, and I found the exact command line that's in use, so I can copy settings [19:43:18 CET] <wouter> sorry about confusing you ;-) [19:45:57 CET] <wouter> turns out I needed to add -g 45 [19:46:04 CET] <wouter> not sure what that parameter does, but it fixes the issue [19:47:03 CET] <wouter> actually, might be probesize and/or analyzeduration, too, but anyway [19:47:22 CET] <kepstin> -g sets the gop size (keyframe interval); the default is 250 which is much larger -and means more reference frames. [19:51:54 CET] <wouter> ahh, there we go, so yeah, that's probably the reason then [19:51:59 CET] <wouter> thanks for your help! [20:02:47 CET] <saml> it's so weird. ssim filter even works on two videos with different framerates [20:05:23 CET] <saml> if i'm changing framerate to optimize for some players, is -r better option that -vf framerate or -vf fps ? [20:05:40 CET] <furq> -r is -vf fps [20:08:13 CET] <saml> https://lists.ffmpeg.org/pipermail/ffmpeg-user/2013-July/016273.html this person suggests they are different [20:09:00 CET] <saml> or i'm reading wrong. it's hard to read [20:09:32 CET] <BtbN> that looks like a confused wall of text to me [20:09:36 CET] <furq> yeah he's confused [20:09:44 CET] <furq> -r as an output option appends -vf fps to the end of the filterchain [20:09:53 CET] <furq> -r as an input option is an alias for the -framerate option some demuxers have [20:09:59 CET] <saml> yup [20:10:17 CET] <saml> so, for output, would you use -vf fps or -vf framerate ? [20:10:20 CET] <furq> fps [20:10:25 CET] <saml> why? [20:10:51 CET] <saml> framerate is just computationally more expensive without noticible effect on human perception? [20:12:05 CET] <wouter> saml: framerate is "frames per second", which abbreviates to fps? [20:12:14 CET] <wouter> unless you speak a different version of english [20:12:58 CET] <wouter> unless I'm missing something [20:12:59 CET] <saml> there are two filters: fps and framerate [20:13:13 CET] <wouter> oh, okay, sorry [20:13:15 CET] <saml> there's also minterpolate filter but it's way too expensive [20:14:30 CET] <furq> framerate does a linear blend of missing frames and it generally looks terrile [20:14:33 CET] <furq> b [20:14:45 CET] <furq> if you prefer the way it looks for your input then by all means use that [20:16:05 CET] <saml> ah i see. so when down sampling (? going down frame rate), either makes no difference [20:33:01 CET] <kepstin> saml: I think when reducing framerate, there's some circumstances where the 'framerate' filter may still blend frames? [20:40:29 CET] <saml> hrm i see [20:55:50 CET] <Pandela_> Hey guys [20:56:03 CET] <Pandela_> Is there an ffplay for android? [21:49:04 CET] <saml> what is ffplay [21:49:54 CET] <saml> FFplay is a very simple and portable media player using the FFmpeg libraries and the SDL library. It is mostly used as a testbed for the various FFmpeg APIs. [21:50:06 CET] <saml> nice [21:50:08 CET] <JEEB> it's a proof of concept level thing [21:50:18 CET] <JEEB> never, ever think of it as a proper multimedia player [21:50:32 CET] <JEEB> it can be useful for testing in some cases [21:50:56 CET] <BtbN> I have used it on some "professional" situations, where I just needed a UI-less player to play a video in infinite loop forever. [21:50:56 CET] <saml> that's cool [21:51:04 CET] <BtbN> No other player could do that as easily as ffplay [21:51:14 CET] <saml> kiosk? [21:51:20 CET] <saml> mplayer ? [21:51:32 CET] <BtbN> mplayer just crapped on itself after a few months [21:51:34 CET] <JEEB> I've been doing similar stuff with mpv's --loop [21:51:35 CET] <BtbN> so ffplay it was [21:51:44 CET] <saml> wow so uptime of months? [21:51:58 CET] <JEEB> although I haven't usually run it for more than a full day or so [21:52:02 CET] <BtbN> it's playing on loop for 3 years now [21:52:11 CET] <saml> that's more stable than erlang [21:52:13 CET] <DHE> ffplay has some interesting user interactions. for example if you click anywhere in the player, it's treated as a seek request based on the horizontal offset of the position [21:53:13 CET] <saml> can ffplay play HLS? /me hides [21:53:27 CET] <JEEB> anything lavf can read [21:53:30 CET] <BtbN> it can play anything libav* can [21:54:10 CET] <saml> so it could be a viable option for devices like chromecast? [21:54:19 CET] <DHE> that includes hls, but last I checked it wasn't good enough to, for example, do dynamic bitrate control [21:54:47 CET] <JEEB> yea, vlc is one of the few to actually have dynamic profile switching [21:54:47 CET] <saml> because tv isn't touch screen, it won't seek [21:55:57 CET] <geuis> k [21:55:59 CET] <BtbN> chromecasts only support a very few selected formats for no good reason [21:56:14 CET] <geuis> clear [21:56:23 CET] <geuis> sry trying a new irc client [21:56:50 CET] <DHE> but if you wrote an app for chromecast, you should be able to use libavformat (and only avformat) to make a generic video player, but use the hardware decoder for h264 and the codecs... [21:57:09 CET] <DHE> I should get a chromecast... [21:57:28 CET] <BtbN> can you even run anything on them? [21:57:58 CET] <DHE> there's limited apps. but I think the main intention is for them to be the go-between for your phone and a TV [21:58:09 CET] <saml> you can write a streaming server using ffmpeg and give chromecast url of your server to stream anything [21:58:35 CET] <DHE> you can pull up a youtube video on your phone's youtube app, select "Cast to Chrome" (or whatever it's called) and the chromecast will play it. even if the phone is shut down, it keeps playing even through the "Next up" stuff [22:01:00 CET] <karen__> Hello JEEB , thanks for your help yesterday. I thought I'd pass on that the final workaround ended up being: ffmpeg -c:v hevc -i 1_01_R_171112194500.avi -c copy fixed.mp4 (instead of the .mkv that ya'll suggested) [22:01:42 CET] <karen__> it gave me a file that i can playback in mplayer (not vlc though) - and mplayer was able to seek the file as well - [22:10:42 CET] <saml> -c:v in front of -i has different meaning? [22:25:22 CET] <bencc> do I need to pay for license if I transcode from HEVC to VP8 on a server? [22:29:43 CET] <kepstin> bencc: ask a lawyer? random people on irc can't really give legal advice :) [22:30:01 CET] <kepstin> bencc: you probably don't need to pay anything for encoding to vp8, at least :) [22:31:21 CET] <bencc> kepstin: not asking for official legal advice [22:31:30 CET] <bencc> but people here knows about codecs :) [22:31:48 CET] <bencc> I can't find info if transcoding from hevc requires a license [22:32:07 CET] <kepstin> bencc: I know that several groups of companies and individual companies have patents on hevc, and while some of them have public licensing terms, not all of them do. [22:32:24 CET] <kepstin> and those patents may or may not apply to you depending on where you are [22:32:28 CET] <kepstin> so ask a lawyer. [22:32:50 CET] <bencc> thanks [23:12:21 CET] <caim> Hello ^_^ Have a noob questions please :D I found out ffmpeg can copy the streams ? and redid my command to copy the audio stream with -c:a copy , is there a way to copy the video also ? I'm using this command to transmux or w/e it's called this rtmp stream to a HLS stream [23:13:04 CET] <caim> >> ffmpeg -v verbose -i rtmp://ip:1935/live1/gcha -c:v libx264 -c:a copy -ac 1 -strict -2 -tune zerolatency -crf 23 -preset veryfast -profile:v baseline -maxrate 1200k -bufsize 1200k -x264opts keyint=30:min-keyint=10:no-scenecut -b:v 500k -threads 0 -g 40 -movflags +faststart -flags -global_header -hls_time 10 -hls_list_size 6 -hls_wrap 10 -start_number 1 /var/www//testgreen2.m3u8 [23:14:16 CET] <caim> so maybe i can delete all the stuff about x264options buffsize etc and have only -c:v copy and -c:a copy ? [23:15:16 CET] <BtbN> just don't specify a stream, and it will apply to all. [23:15:29 CET] <caim> hmm [23:25:45 CET] <alexpigment> caim: judging by the "hmm", i'm guessing you may not have misunderstood BtbN's suggestion [23:25:50 CET] <arooni> question; 00 libavformat >= 58.0.102 libswscale >= 5.0.101 libavfilter >= 7.0.101 libswresample >= 3.0.100' not found) Unable to find development files for some of the required FFmpeg/Libav libraries. Git master is recommended. ;; how do i get these libraries on mac os x [23:25:54 CET] <arooni> was trying to install mpv from source [23:26:21 CET] <alexpigment> caim: so what he means is to just say -c copy , rather than -c:a copy (which is specifying the audio stream when you put :a) [23:26:41 CET] <furq> caim: copying the video stream won't work very well with hls because it'll end up ignoring -hls_time [23:26:46 CET] <caim> ah so it copies both that's cool [23:26:50 CET] <furq> unless your input happens to have 10-second gops [23:27:59 CET] <BtbN> i think hls actually supports segment/gop length mismatches [23:28:25 CET] <caim> yea I\ll leave it like this hope it doesn't crashes overnight with WriteN, RTMP send error 104 (5 bytes) i read somewhere i need to reduce the settings to reach speed > 1x [23:28:38 CET] <caim> i saw when speed dropped to 0.986x this error pops up [23:29:04 CET] <furq> i'm pretty sure apple devices will throw a fit if the segment size doesn't match the EXTINF duration [23:29:24 CET] <furq> so it depends how smart ffmpeg's hls muxer is about that [23:29:52 CET] <furq> hopefully it puts the actual duration and not whatever you set hls_time to [23:31:18 CET] <furq> it might also compare it to ext-x-targetduration as well, i forget now [23:38:23 CET] <bonk> does anybody have any idea how to combine a video and audio stream live? my ip cam gives me /video and /audio.opus and i need to combine them before i serve the content [23:39:31 CET] <klaxa> you could try ffmpeg -i video-url -i audio-url -map 0 -map 1 [whatever output you need] but it will probably be out of sync [23:40:17 CET] <BtbN> will be hard if not impossible to sync up perfectly [23:40:48 CET] <bonk> oh ok [23:40:49 CET] <bonk> thanks [23:40:59 CET] <bonk> il try that [23:41:22 CET] <BtbN> could try to pass through device timestamps, and then just hope it does something sensible with them [23:44:47 CET] <caim> oh wow did it with -c copy only and this 1.9% cpu is awesome while the other one that does encoding is at 34.9%. Seems to be working fine and plays on my iphone. Thanks so much everyone! [23:46:50 CET] <arooni> yay building from source [23:46:56 CET] <arooni> always best for latest and greatest [23:48:27 CET] <bonk> the map command that was sent earlier doesn't seem to actually output any audio [23:48:38 CET] <bonk> if i listen closely there is only static [00:00:00 CET] --- Fri Feb 2 2018

1 0

ffmpeg-devel.log.20180131
by burek 01 Feb '18

01 Feb '18

[01:20:35 CET] <cone-612> ffmpeg 03Jun Zhao 07release/3.4:9aa0ed850b77: avfilter/formats: fix wrong function name in error message [01:20:36 CET] <cone-612> ffmpeg 03Kelly Ledford 07release/3.4:a3832486e4f1: libavfilter/af_dcshift.c: Fixed repeated spelling error [01:20:37 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:0f0a2ff5a09d: avcodec/vp9: mark frame as finished on decode_tiles() failure [01:20:38 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:d6a13f031ced: avcodec/h264_parse: Treat escaped and unescaped decoding error equal in decode_extradata_ps_mp4() [01:20:39 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:d147e2d55d29: avcodec/hevcdsp_template: Fix undefined shift in put_hevc_qpel_bi_w_hv() [01:20:40 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:2e426fae43f3: avcodec/hevc_sei: Fix integer overflows in decode_nal_sei_message() [01:20:41 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:43c03866b23a: tests/audiomatch: Add missing return code at the end of main() [01:20:42 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:0288d15cdded: avcodec/hevc_cabac: Fix integer overflow in ff_hevc_cu_qp_delta_abs() [01:20:43 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:e55a6c5f055c: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_DD97iH0() and COMPOSE_DD137iL0() [01:20:44 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:0e7d8ce37c2f: avcodec/hevcdsp_template.c: Fix undefined shift in FUNC(dequant) [01:20:45 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:fb9560b366da: avcodec/flacdec: avoid undefined shift [01:20:46 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:7e402c31efd8: avcodec/hevcdsp_template: Fix Invalid shifts in put_hevc_qpel_bi_w_h() and put_hevc_qpel_bi_w_w() [01:20:47 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:91f5a2b7b88a: avcodec/flacdec: Fix overflow in multiplication in decode_subframe_fixed() [01:20:48 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:6abe1e06f592: avcodec/exr: Check buf_size more completely [01:20:49 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:b1af55778b00: avcodec/dnxhddec: Check dc vlc [01:20:50 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:62024c127798: avcodec/h264_slice: Do not attempt to render into frames already output [01:20:51 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:5365904e9642: avcodec/jpeg2000dsp: Fix integer overflows in ict_int() [01:20:52 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:a3add1924095: avcodec/opus_parser: Check payload_len in parse_opus_ts_header() [01:20:53 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:097bc4d32d59: avcodec/diracdec: Fix integer overflow with quant [01:20:54 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:8263246ba8f6: avcodec/dirac_dwt: Fix overflows in COMPOSE_HAARiH0/COMPOSE_HAARiL0 [01:20:55 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:4715ef27a068: avcodec/h264addpx_template: Fixes integer overflows [01:20:56 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:ece787999249: avcodec/arm/sbrdsp_neon: Use a free register instead of putting 2 things in one [01:20:57 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:04949cc08ece: avcodec/utils: Avoid hardcoding duplicated types in sizeof() [01:20:58 CET] <cone-612> ffmpeg 03Carl Eugen Hoyos 07release/3.4:092febb2add6: configure: bump year [01:20:59 CET] <cone-612> ffmpeg 03Jun Zhao 07release/3.4:7b56d6584c46: lavfi/deinterlace_vaapi: fix can't show full option information. [01:21:00 CET] <cone-612> ffmpeg 03Nikolas Bowe 07release/3.4:facd0521e440: avformat/matroskadec: Fix float-cast-overflow undefined behavior in matroska_parse_tracks() [01:21:01 CET] <cone-612> ffmpeg 03Nikolas Bowe 07release/3.4:e755482d367a: avformat/lrcdec: Fix memory leak in lrc_read_header() [01:21:02 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:56b0179b6a03: avcodec/ac3dec_fixed: Fix integer overflow in scale_coefs() [01:21:03 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:f56215d3ff63: avcodec/jpeg2000: Check sum of sizes of band->prec before allocating [01:21:04 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:bae4d39437fe: avcodec/wavpack: Fix integer overflows in wv_unpack_stereo / mono [01:21:05 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:540f4467c825: avcodec/ulti: Check number of blocks at init [01:21:06 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:aed915b8a62c: avcodec/snowdec: Fix integer overflow before htaps check [01:21:07 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:6ed5e44998ed: avcodec/truemotion2: Fix integer overflow in TM2_RECALC_BLOCK() [01:21:08 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:edf200e2bc9a: avcodec/hevc_cabac: Move prefix check in coeff_abs_level_remaining_decode() down [01:21:09 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:c1b74d608c6e: avcodec/dxtory: Fix bits left checks [01:21:10 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:2fdb27b5123d: avcodec/mjpegdec: Fix integer overflow in DC dequantization [01:21:11 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:11498c22a0db: avcodec/hevc_cabac: Check prefix so as to avoid invalid shifts in coeff_abs_level_remaining_decode() [01:21:12 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:2980b95fafb3: avfilter/vf_transpose: Fix used plane count. [01:21:13 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:6723a436095f: avcodec/mpeg4videodec: Check mb_num also against 0 [01:21:14 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:cd478122b0a0: avcodec/get_bits: Document the return code of get_vlc2() [01:21:15 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:d07f78ae726b: avcodec/mpeg4videodec: Avoid possibly aliasing violating casts [01:21:16 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:93437a18d878: avcodec/hevc_ps: Check log2_sao_offset_scale_* [01:21:17 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:d06972535e48: avcodec/indeo5: Do not leave frame_type set to an invalid value [01:21:18 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:c1c50fc4a754: avcodec/dirac_dwt: Fix several integer overflows [01:21:19 CET] <cone-612> ffmpeg 03Michael Niedermayer 07release/3.4:dd93df46a618: Update for 3.4.2 [02:11:24 CET] <cone-612> ffmpeg 03James Almer 07release/3.4:64f0fd599845: avcodec/hevc_ps: add a function to uninitialize parameter set buffers [02:11:25 CET] <cone-612> ffmpeg 03James Almer 07release/3.4:d7d5a3379dfe: avcodec/hevcdec: use ff_hevc_uninit_parameter_sets() [02:11:26 CET] <cone-612> ffmpeg 03James Almer 07release/3.4:e5bbb5219441: avcodec/hevc_parser: use ff_hevc_uninit_parameter_sets() [02:11:27 CET] <cone-612> ffmpeg 03James Almer 07release/3.4:af54886de8ab: avcodec/mediacodecdec: use ff_hevc_ps_uninit() [02:14:02 CET] <cone-612> ffmpeg 03James Almer 07release/3.4:9b97afe7ad06: Changelog: update for the previous four commits [02:46:10 CET] <SortaCore> wait, you can get an nvidia primary with intel secondary? [02:46:24 CET] <SortaCore> isn't primary decided by motherboard? [02:46:41 CET] <SortaCore> re that ticket #6996 just posted [05:00:39 CET] <philipl> BtbN: I can get -cq to do something. It *looks* like it's trying to do something like crf. [05:02:03 CET] <philipl> The bitrate (-b:v) seems to influence it to, and acts as some sort of upper bound (although not literally an upper bound) so if the b:v is low, then setting -cq to a 10 (for example) doesn't do anything; it's constrained by the bitrate. but if you up the bitrate, then it makes a difference. If you set cq to 51, then you get appropriate q values reported back. [05:02:16 CET] <philipl> But obviously, these interactions are not documented. [06:39:43 CET] <wm4> av_opt_serialize() was used by ffserver only [15:31:12 CET] <jdarnley> atomnuker: I want to ask you about the following two commits and applying them to ffmpeg upstream. [15:31:18 CET] <jdarnley> https://github.com/OpenBroadcastSystems/ffmpeg/commit/e6a8de2ea62030bedc187… [15:31:24 CET] <jdarnley> https://github.com/OpenBroadcastSystems/ffmpeg/commit/eefdd82193b140b830709… [15:32:29 CET] <jdarnley> I think I do understand the first but I am less clear about what the second one does and why. [15:34:01 CET] <jdarnley> I thought that the packet size allocation was roughly equivalent before and after the change [15:34:52 CET] <atomnuker> its a bloody hack because kierank was too lazy to write proper parsing code a whole few months before IBC 2016 so I had to make them equal [15:35:14 CET] <jdarnley> Oh [15:35:46 CET] <jdarnley> Does upstream not really want that one then? [15:35:55 CET] <atomnuker> No. [15:36:43 CET] <jdarnley> But the first one can be useful to others too, right? [15:39:13 CET] <atomnuker> yes [15:54:33 CET] <sfan5> " If using GCC, consider adding -ftree-vectorize to --extra-cflags. Most recent versions of GCC do not miscompile FFmpeg with the auto-vectorizer enabled, [...] Therefore, configure by default disables the auto-vectorizer on GCC, and it must be enabled by the user explicitly if desired, such as via the method outlined above. " ~https://trac.ffmpeg.org/wiki/CompilationGuide#PerformanceTips [15:55:27 CET] <sfan5> this seems inaccurate, if I configure with --extra-cflags='-ftree-vectorize', config.mak ends up with CFLAGS= -ftree-vectorize [...] -fno-tree-vectorize [...] [15:55:36 CET] <sfan5> am I missing something or is the wikipage just outdated? [15:58:08 CET] <jdarnley> It sounds outdated or just wrong. [15:58:54 CET] <jdarnley> I'm sure everytime people have tried to enable vectorisation it gets disabled a few commits later when it screws something up [16:04:56 CET] <JEEB> yea [16:06:18 CET] <JEEB> every time people vectorization is enabled, some not-so-exotic compiler is found to muck around with things badly [16:22:38 CET] <sfan5> no fate failures here with -ftree-vectorize, Linux x86_64 + gcc 7.2.1 20180116 [16:27:09 CET] <jdarnley> Then happily use it on your own machines [16:28:07 CET] <sfan5> sure, I wasn't advocating for official support for this option [16:35:06 CET] <jamrial> fate might pass, but since only about 60% of the code is actually tested by it, it doesn't mean much [16:35:50 CET] <jamrial> last time vectorization was applied a bunch of issues were found by downstreams [17:12:27 CET] <atomnuker> jdarnley: no one's going to review it, you should just push it [17:18:43 CET] <jdarnley> okay [17:42:12 CET] <cone-796> ffmpeg 03Rostislav Pehlivanov 07master:61a4ee8ab482: avcodec/vc2enc: prevent bitrate overshoots [21:21:13 CET] <Chloe> git: 'send-email' is not a git command. See 'git --help'. [21:21:14 CET] <Chloe> thanks gfit [21:21:43 CET] <Chloe> why is this in a separate package [21:24:43 CET] <JEEB> because it's just an additional perl script :D [23:06:06 CET] <Zeranoe> Check out this message sent to me, subject line was "Do any of you idiots know how to fucking code": https://i.imgur.com/slA6QUQ.png [23:06:43 CET] <sfan5> /g/-tier bait [23:13:27 CET] <klaxa> lol [23:14:42 CET] <klaxa> aren't there dozens of front-ends for ffmpeg? [23:42:05 CET] <tmm1> lol [23:45:31 CET] <chance83> =) [23:47:22 CET] <chance83> ffmpeg ncurses [23:49:29 CET] <thardin> someone doesn't know about handbrake [23:49:52 CET] <thardin> or that you can wrap CLIs in GUIs [23:54:36 CET] <Chloe> or that vlc and kodi use ffmpeg [23:54:45 CET] <chance83> Chloe +1 [00:00:00 CET] --- Thu Feb 1 2018

1 0

ffmpeg.log.20180131
by burek 01 Feb '18

01 Feb '18

[01:42:51 CET] <FishPencil> What's the correct format to pipe raw YUV data? [01:48:58 CET] <kepstin> FishPencil: use the 'rawvideo' format, but you also have to specify the pixel format, frame size, and framerate of course. [01:49:10 CET] <JEEB> nut lets you have timestamps and audio if you want [01:49:38 CET] <JEEB> of course you need to be able to read nut on the other side, too [01:50:32 CET] <FishPencil> kepstin: If it's just going out I would think I don't specify that stuff? [01:50:44 CET] <FishPencil> s/would/wouldn't [01:50:51 CET] <kepstin> yeah, you just need to tell the reasing side that [03:53:20 CET] <hiihiii> hello [03:54:19 CET] <Diag> hiihiii: [04:02:57 CET] <hiihiii> I'm sorry I lost my cnx [04:03:27 CET] <hiihiii> did I post my question? [04:06:50 CET] <Lunchbox> hey guys i'm trying to stream my desktop over lan to a media player on another computer but i'm getting a few errors [04:06:51 CET] <Lunchbox> '[ffmpeg/video] h264: non-existing PPS 0 referenced' [04:06:51 CET] <hiihiii> can motion detection duplicate regions of frames? i.e. can it lead to an object, which should have moved from point A to point B, still be present at point A for an additional frame due to cpu/memory factors [04:06:51 CET] <Lunchbox> '[ffmpeg/video] h264: decode_slice_header error' [04:06:54 CET] <Lunchbox> ' [ffmpeg/video] h264: no frame!' [04:09:28 CET] <hiihiii> try flv, header errors are probably mp4 [04:09:39 CET] <geuis> Wondering if someone might have some insight. I have two sets of images, layer-%d.png and layer-%d.svg. The intention is to overlay the svg files over the pngs for the same duration [04:09:59 CET] <geuis> This is a simplified version of what I thought might work "ffmpeg -y -framerate 1 -i layer-%d.png -i layer-%d.svg -filter_complex "[0:v]fps=30[base];[1:v]fps=30[date];[date][base]overlay=(0):(0)" -preset ultrafast -movflags +faststart -vcodec libx264 -crf 23 -pix_fmt yuv420p out.mp4" [04:10:56 CET] <hiihiii> [base][date]overlay [04:11:10 CET] <geuis> thought they had to be reversed [04:12:07 CET] <geuis> hah awesome it works. thanks man [04:31:17 CET] <Lunchbox> hiihiii it says unable to recognize file format using flv [04:32:00 CET] <geuis> hmm, so I have multiple overlays throughout the video but the old ones stick around and stack up. any way to clear them? [08:35:28 CET] <ovi_> hello [08:37:01 CET] <ovi_> I used the following command https://pastebin.com/vvCKv83t [08:37:33 CET] <ovi_> but now I get "cat: Argument list too long" [08:38:01 CET] <ovi_> because I have over 20 000 file in that pattern [08:38:25 CET] <ovi_> it is possible to specify the input without using the image2pipe? [09:45:27 CET] <FishPencil> What data type is the YUV information when dumped with -c:v rawvideo? I'm just trying to read the YUV info in something else, but buff[0] (which should be Y), doesn't look right. I'm using uint8_t right now. [09:48:54 CET] <JEEB> if you need it API-wise I would jus utilize the API, which gives you AVFrames straight off the bat which says which pix_fmt it is, too :P [09:49:09 CET] <JEEB> see examples under docs [09:49:44 CET] <FishPencil> I'm trying to read the yuv file outside of FFmpeg [09:50:45 CET] <JEEB> well yes [09:50:55 CET] <JEEB> if you have buffers and stuff I definitely recommend you start using the API [09:51:20 CET] <JEEB> since it lacks a lot of the complications you have with "just trying to get the decoded samples out" [09:51:42 CET] <JEEB> otherwise I recommend you add support for either NUT or Y4M to your application [09:51:58 CET] <JEEB> which contain the pixel format information in addition to other stuff, so you can pipe that to your thing :P [09:52:40 CET] <FishPencil> Getting the YUV to decode is an important step even in that.. [09:53:28 CET] <JEEB> if you know from the stuff you're pushing in WHAT it is, that helps :P [09:53:42 CET] <JEEB> because "rawvideo" in ffmpeg.c is your common weasel word for whatever came out of your filter chain or decoder [09:53:45 CET] <JEEB> capisci? [11:21:35 CET] <hojuruku> Strange problem with ffmpeg git mesa git and libva (latest sable in gentoo).... [11:21:50 CET] <hojuruku> how to replicate: ffmpeg-git -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -ss 120 -t 120 -i xyz.mkv -map 0:0 -map 0:1 -c:v h264_vaapi -b:v 4000k -qp 20 -bf 0 -profile:v 578 -movflags +faststart -quality:v 0 -level:v 3.1 -coder:v cavlc -c:a aac -ab 128k -ar 48000 -ac 2 vaapitest4.mp4 [11:22:02 CET] <hojuruku> the mp4 is not playable by gstreamer but mpv can handle it fine. I use a mkv container it works in gstreamer, but hardware players still can't handle the h264 data in mkv. Amd's can't use bframes so I have to use the baseline constrained profile [11:22:17 CET] <hojuruku> this is what gstreamer complains with: qtdemux qtdemux.c:9719:qtdemux_parse_trak:<qtdemux0> Track shorter than 20% (5761024/48000 vs. 5834998/1000) of the stream found, assuming preview image or something; skipping track [11:22:50 CET] <hojuruku> both libx264 and vaapi encoded streams report the same in ffprobe except for the bitrate Stream #0:0(eng): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuv420p, 1920x808, 3913 kb/s, SAR 1:1 DAR 240:101, 23.98 fps, 23.98 tbr, 24k tbn, 48k tbc (default) [11:23:10 CET] <JEEB> you can look at the timestamps of the mp4 file with, say, L-SMASH's tools [11:23:18 CET] <JEEB> it could be that VAAPI is just pushing out borked timestamps [11:23:28 CET] <JEEB> although without bframes the timestamps should be monotonically rising [11:57:17 CET] <hojuruku> that looks like the plan, i'll do that, but the question is where does the bug go? libva? mesa who do the vaapi driver for our hardware of ffmpeg? [11:57:49 CET] <hojuruku> JEEB: it seems that the framerate stays at zero as it revs up and the bitrate starts out low and it goalseeks to the desired bitrate. [11:58:12 CET] <hojuruku> the libomxil-bellago driver doesn't take bitrate only crf settings which explains why it works in gstreamer. [12:00:24 CET] <jkqxz> Does it work if you overwrite the timestamps with something fixed? (Something like "-r 30" as an input option.) [12:02:21 CET] <jkqxz> VAAPI does not work sensibly with VFR at all (the API has no concept of timestamps), and your 48k tbc there suggests a VFR stream. [12:20:21 CET] <JEEB> hojuruku: where the bug goes depends on what is actually giving out timestamps IF AND ONLY IF (IFF) the timestamps from the vaapi encoder are weird [12:21:54 CET] <bigeast> hi, I want to compile ffmpeg with all other tools disabled, i.e. ./configure --disable-all --enable-xxx. But the command line file is disabled too, is there any configure option like --enable-programs ? [12:44:28 CET] <sfan5> bigeast: not sure if --enable-programs exists, but --enable-ffmpeg should work [12:45:11 CET] <sfan5> but if you just want an "ffmpeg" binary as result i'd configure with --disable-shared --disable-{ffplay,ffprobe} [13:13:55 CET] <rk__> Hi, I am using libavformat to mux a VP8 encoded rtp stream into a webm file. I need a small help regarding how to set pts and dts values in the AVPacket, using rtpTimeStamp. Do I need to get NTP timestamp from RTCP and set that as pts or is there any other way ? [13:15:56 CET] <mux> im using libavformat to rk__ a vp8 encoded rtp stream [13:35:36 CET] <dradakovic> Guys, i compiled the ffmpeg according to the guide and it works ok. I would now like to install the additional library "libswresample". Any idea on how to do that? [13:37:05 CET] <sfan5> ffmpeg comes with libswresample [13:38:08 CET] <JEEB> dradakovic: unless you disabled building/installation of the library in your configuration parameters, it should have been installed [13:38:27 CET] <JEEB> PKG_CONFIG_PATH=/your/ffmpeg/prefix/lib/pkgconfig pkg-config --libs --cflags libswresample [13:38:32 CET] <JEEB> is a good way to test [13:38:50 CET] <JEEB> the prefix being what you passed to the configure script as --prefix (/usr/local by default) [13:52:20 CET] <dradakovic> Thank you. I will try it right away [13:55:02 CET] <dradakovic> No package 'libswresample' found [13:55:31 CET] <dradakovic> I followed the guide exactly as it is on the compiling guide web page [14:00:51 CET] <Nacht> Question. I'm not super sure I'm understanding the memory in work here. Why is this wrong ? https://play.golang.org/p/oiWDlGwsob_s [14:02:19 CET] <Nacht> Isn't P an alias for b[i:i+188], and when I say p[0] = nil it would just change b ? [14:07:00 CET] Last message repeated 1 time(s). [14:17:15 CET] <dradakovic> So it seems like i dont have libswresamble installed as i get: [14:17:17 CET] <dradakovic> Package libswresample was not found in the pkg-config search path. [14:17:17 CET] <dradakovic> Perhaps you should add the directory containing `libswresample.pc' [14:17:17 CET] <dradakovic> to the PKG_CONFIG_PATH environment variable [14:17:17 CET] <dradakovic> No package 'libswresample' found [14:17:36 CET] <furq> Nacht: you don't need the & and also this is the wrong channel [14:18:41 CET] <Nacht> Oh snap, wc idd :D [14:18:51 CET] <Nacht> cheers furq :) [14:19:38 CET] <furq> https://play.golang.org/p/XfKj_Lnw3kH [14:22:31 CET] <c_14> dradakovic: which guide? [14:22:57 CET] <dradakovic> exactly this one: https://trac.ffmpeg.org/wiki/CompilationGuide/Centos [14:24:55 CET] <c_14> PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" pkg-config --libs --cflags libavformat <- what does that return? [14:35:17 CET] <dradakovic> -I/root/ffmpeg_build/include -pthread -L/root/ffmpeg_build/lib -lavformat -lavcodec -lvpx -lz -lfdk-aac -lmp3lame -lopus -lvorbisenc -lvorbis -logg -lx264 -lpthread -lx265 -lstdc++ -lrt -lswresample -lavutil -lm -ldl [14:35:20 CET] <dradakovic> This [14:35:31 CET] <c_14> and if you replace libavformat with libswresample it fails? [14:35:35 CET] <c_14> do you still have your config.log? [14:36:43 CET] <dradakovic> it didnt fail [14:36:44 CET] <dradakovic> -I/root/ffmpeg_build/include -pthread -L/root/ffmpeg_build/lib -lswresample -lavutil -lm -ldl [14:37:23 CET] <dradakovic> Any clue where i would find config.log [14:40:19 CET] <dradakovic> Seems like there is a libswresample.pc in the pkgconfig folder [14:40:41 CET] <dradakovic> did your command already enable it? Or do i have to do something else [14:44:03 CET] <c_14> nah, now you just have to pass PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" to whatever you have that needs libswresample [14:44:25 CET] <c_14> (if it uses pkg-config) [14:44:33 CET] <c_14> otherwise you'll have to pass the CFLAGS/LDFLAGS manually [14:45:41 CET] <dradakovic> Ok c_14. I will figure it out how to do it. Thank you for your time [15:02:45 CET] <glumanda> How do I prevent package loss? When I try to watch an rtsp stream with vlc it runs a lot smoother than with ffmpeg. [15:05:25 CET] <pmjdebruijn> presumably that's just buffersize related? [15:05:49 CET] <glumanda> pmjdebruijn: i tried with -bufsize 6000k according to the streaming guide, but it won't help [15:05:58 CET] <glumanda> i dont know what vlc does different [15:06:09 CET] <glumanda> it has set a network-cache to 1000ms [15:06:20 CET] <pmjdebruijn> i'm not sure how much focus ffmpeg has had as a client [15:06:44 CET] <glumanda> i'm trying to stream an rtsp stream to an rtmp server [15:07:20 CET] <bigeast> sfan5: thanks for your advice! What I want is a ffmpeg executable with only H.264 decoder enabled, without encoder, other decoder or parser or muxers(which I don't know what they are). [15:07:56 CET] <sfan5> what container formats are you expecting to handle? [15:08:23 CET] <bigeast> I tried --disable-all --enable-ffmpeg, the configure can generate a Makefile, but still no ffmpeg executable files after make [15:09:11 CET] <DHE> ffmpeg has additional dependencies. --disable-all really does disable everything. [15:09:22 CET] <bigeast> It's strange to me that I find no "enable-ffmpeg" string in the configure file, but it doesn't report it as an error. [15:09:41 CET] <bigeast> sfan5: raw H.264 stream [15:10:05 CET] <DHE> that still requires a parser or demuxer to parse the elementary stream into the individual frames, doesn't it? [15:10:08 CET] <furq> bigeast: --disable-programs --enable-ffmpeg [15:10:18 CET] <furq> maybe, idk if that actually works [15:10:26 CET] <furq> it's more likely than --disable-all though [15:10:46 CET] <c_14> bigeast: you have to enable all the libs and other things [15:10:56 CET] <c_14> at least libavformat, libavcodec, libavutil [15:11:02 CET] <c_14> and the h264 decoder/parser [15:11:07 CET] <saml> i should learn about bitrates [15:11:18 CET] <c_14> and a demuxer of some sort [15:11:18 CET] <DHE> you probably want --disable-everything instead which targets individual codecs etc rather than the libraries as a whole [15:11:20 CET] <saml> everyday learnin [15:11:54 CET] <sfan5> something like --disable-shared --disable-ff{play,probe} --disable-{encoders,decoders,hwaccels,demuxers,parsers,bsfs} --enable-decoder=h264 --enable-parser=h264 --enable-demuxer=h264 [15:12:10 CET] <furq> you'll need --enable-protocol=file [15:12:15 CET] <DHE> yeah but.. then what? ffmpeg is a converter and it can't output anything. literally. [15:12:19 CET] <furq> or whatever protocol you want to handle the stream on [15:12:28 CET] <furq> and yeah you'll need a muxer and an encoder [15:12:29 CET] <sfan5> yeah you probably want at least --enable-encoder=rawvideo [15:12:36 CET] <DHE> you gotta provide some kind of output format, muxer and codec even if it's the dumb ones [15:13:07 CET] <furq> and ofc you'll need the protocol for the output as well as for the input [15:13:09 CET] <DHE> I'm also going to recommend --enable-protocol=file or else ffmpeg isn't going to be able to do basic IO [15:13:14 CET] <DHE> yeah [15:13:37 CET] <bigeast> YUV out is fine. [15:13:41 CET] <furq> bigeast: basically be prepared to build this a bunch of times when ffmpeg tells you it can't do something [15:14:45 CET] <furq> you will at the bare minimum need a decoder, parser, demuxer, muxer, encoder, and protocol (or more than one of each) [15:16:46 CET] <saml> why do you want to build ffmpeg like that bigeast ? just curious [15:17:07 CET] <bigeast> furq: so if I --disable-all, and then enable one option for these items, then --enable--fmpeg will generate ffmpeg executable? [15:17:15 CET] <saml> does that make it faster and more web scale in dockerized serverless? [15:17:18 CET] <sfan5> --disable-everything, not --disable-all [15:17:18 CET] <furq> bigeast: probably not [15:17:24 CET] <furq> yeah, that [15:18:27 CET] <furq> --disable-components might be a better name than --disable-everything [15:19:00 CET] <sfan5> having two options with synonymous names but different effect is indeed confusing [15:20:14 CET] <saml> --start-from-scratch [15:20:19 CET] <bigeast> saml: At first, I want a minmal libavcodec.a. Then I decide to make some change to the H.264 decoder, and compare the performance difference. [15:20:41 CET] <saml> oh you're building your own statically linked program? [15:20:51 CET] <saml> would it be open source? [15:21:03 CET] <sfan5> you don't need a minimal libavcodec.a to measure performance [15:21:22 CET] <furq> i assume this is to make it build as quickly as possible [15:21:31 CET] <bigeast> furq: yes [15:21:32 CET] <saml> ah that makes sense [15:21:44 CET] <sfan5> well make will only rebuild what's necessary [15:21:47 CET] <furq> yeah [15:21:50 CET] <sfan5> unless you do a clean build every time [15:22:17 CET] <DHE> I do something similar, but more like "--disable-encoders --enable-encoder=libx26?,mpeg*,aac,..." rather than throwing around --disable-everything. [15:22:44 CET] <DHE> it's better to err on the safe side. hopefully ffmpeg isn't getting built that often compared to your own app [15:23:11 CET] <saml> does netflix have the best video encoding program? [15:23:22 CET] <furq> they're probably just using ffmpeg [15:23:25 CET] <furq> youtube definitely are [15:23:45 CET] <saml> they don't make custom modification? like what bigeast is doing [15:24:03 CET] <saml> i mean, modifying codec source code and stuff [15:24:32 CET] <DHE> we don't know the details. the only obvious signs are the encoder signatures in the metadata [15:24:51 CET] <furq> yeah we wouldn't know that unless they contributed source back [15:24:55 CET] <saml> ffprobe shows me that metadata? [15:24:56 CET] <sfan5> given how good x264, netflix are probably using it with modifications [15:25:00 CET] <furq> which they're under no obligation to if it's internal use only [15:25:09 CET] <sfan5> ffprobe won't show that metadata, e.g. mediainfo can [15:25:18 CET] <furq> youtube strips that metadata so netflix probably does as well [15:26:29 CET] <saml> Writing application : google [15:29:11 CET] <saml> what's good documentation about bitrate? https://trac.ffmpeg.org/wiki/Encode/H.264 ? [15:29:25 CET] <furq> that's a vague topic [15:29:44 CET] <furq> if you mean "what bitrate is good" then that depends on too many factors to have an answer you could write down [15:29:47 CET] <saml> like, i have no idea what bit rate means. [15:30:06 CET] <furq> it's the size of the video stream in bits divided by the number of seconds [15:30:13 CET] <saml> ISP's bitrate [15:30:45 CET] <saml> ah i see. do you calculate bitrate based on encoded bits per second? or some raw pixel data bits per sec? [15:31:19 CET] <furq> encoded [15:31:21 CET] <saml> 1Mbps could mean a lot of frames if it was 1Mbits of very well compressed data [15:31:30 CET] <furq> it's literally just the size of the output stream [15:32:02 CET] <saml> so filesize/file_duration [15:32:10 CET] <furq> right [15:32:14 CET] <bigeast> I'm curious about how --enable-small will affect the speed, and in the configure file I see what it does is replace the default -O3 flag with -Os. I want to test the performance between the executable build with or without -Os when decoding H.264 stream. What's more, I'm not sure whether other options will affect on this so I want disable all of them. [15:32:28 CET] <saml> i guess container and codec has little impact on bitrate [15:33:28 CET] <saml> i wonder if ffmpeg or x264 source code has test suite to measure such performance [15:33:46 CET] <saml> then you can create a quick feed back loop: modify code, build, run the test [15:33:57 CET] <bigeast> saml: me too [15:34:13 CET] <saml> or if you build your own, open source it so i can get it for free :P [15:34:50 CET] <DHE> bigeast: --enable-small also strips out a lot of the ffmpeg library text message. for example "ffmpeg -h" will be a lot less useful [15:35:29 CET] <bigeast> what I do is very simple... I guess it's not worth to open soruce it :O [15:35:32 CET] <furq> bigeast: probably --disable-optimizations [15:35:45 CET] <furq> that will obviously make the code itself run slower though [15:35:55 CET] <saml> performace here is encoding speed? how would you measure encoding quality? psnr? [15:36:00 CET] <furq> and also if you're trying to do speed comparisons of your code then it's not much good to run it with -O0 [15:36:16 CET] <DHE> would that also disable assembly routines? [15:36:17 CET] <bigeast> saml: I want to test decoding speed. [15:36:25 CET] <furq> it just says "disable compiler optimizations" [15:37:18 CET] <bigeast> saml: encoding quality is measure by BD-bitrate, in MPEG. [15:37:55 CET] <saml> shouldn't you measure decoding quality as you modify decoder? if your decoder just decodes everything to 0, it'll be fast [15:38:08 CET] <saml> i guess you can use psnr here indeed :P [15:38:30 CET] <bigeast> DHE: probably not, -Os just disable some align optmization, you can see the gcc man [15:38:45 CET] <saml> like, get a standard decoder decode. and that decoded gop is your reference [15:39:09 CET] <furq> DHE: looks like it just builds with -O1 [15:39:19 CET] <sfan5> how is psnr useful for performance measuring? [15:39:46 CET] <bigeast> saml: the decode result is for sure, with no post-processing. so it's only speed that maters. [15:39:51 CET] <DHE> sfan5: well, it's not. but if changes in optimizations produce different image quality results then it should be measurable by PSNR [15:40:33 CET] <sfan5> true [15:40:33 CET] <bigeast> compiler flag only affect the speed I guess? [15:41:36 CET] <furq> actually on gcc it just builds it without -O at all [15:41:48 CET] <saml> ah if you're not changing source code but only fiddling with compilers and their flags [15:42:20 CET] <saml> you can also try different compilers to see if they produces more performant decoder [15:42:56 CET] <bigeast> gcc under macOS is just an alias of clang... [15:43:16 CET] <saml> https://trac.ffmpeg.org/wiki/CompilationGuide#PerformanceTips i'm not sure if this is relevant [15:43:32 CET] <bigeast> and it's may be trick to install the GNU gcc on mac I assume [15:43:41 CET] <sfan5> you can also try icc [15:43:56 CET] <saml> is your producing running ffmpeg on mac? [15:44:01 CET] <saml> production* [15:44:20 CET] <DHE> new versions of gcc support "-Og" for optimizations that don't affect ability to debug... that worth using maybe? [15:44:23 CET] <bigeast> or tcc which is writen by the same author with ffmpeg :D [15:45:39 CET] <saml> just curious, why do you need to optimize decoder? so far i haven't had to optimize ffmpeg binary. i just use whatever OS provides [15:46:28 CET] <saml> it'd be nice if by changing ffmpeg binary, i get to save N% of processing time [15:48:12 CET] <pmjdebruijn> bigeast: I don't think tcc is viable for non-trivial projects [15:48:41 CET] <saml> if I use -r 30 as output option on a 60fps video input, is there equivalent filter? I tried -filter_complex "fps=fps=30" but it doesn't seem to be the same. and framerate=fps=30 is not the same either. [15:49:19 CET] <bigeast> I want the libavcodc to be small, then I found --enable-small can do that, but I want to make sure that the performance is not too much slower. [15:49:39 CET] <pmjdebruijn> why do you want it to be small? [15:49:56 CET] <Guest94689> hi! is it possible to use ffmpeg to stream from a dvr to youtube via raspberry pi 3 (dvr-->rp3-->yt)? [15:50:29 CET] <Guest94689> dvr and rpi3 connected in the same network [15:50:42 CET] <sfan5> if you don't need to transcode, probably [15:50:45 CET] <sfan5> if you need to, definitely not [15:50:48 CET] <sfan5> the rpi is way too slow for that [15:50:52 CET] <pmjdebruijn> Guest94689: this is literally the first google result https://gist.github.com/olasd/9841772 [15:51:06 CET] <pmjdebruijn> aside from the transcoding issue [15:51:06 CET] <bigeast> pmjdebruijn: ehh, becauce it's too big? [15:51:12 CET] <pmjdebruijn> bigeast: too big for what? [15:51:26 CET] <pmjdebruijn> bigeast: are you on embedded hardware? [15:51:35 CET] <Guest94689> i see [15:53:21 CET] <Guest94689> pmjdebruijn:i was looking to that link prior to enter. thank you anyway [15:53:48 CET] <pmjdebruijn> but the transcoding point is rather valid :) [15:54:33 CET] <pmjdebruijn> bigeast: ? [15:54:37 CET] <furq> ffmpeg supports the pi's hardware encoder now [15:54:43 CET] <furq> admittedly that thing sucks [15:54:57 CET] <furq> so transcoding is possible, it'll just be bad [15:54:59 CET] <pmjdebruijn> sucks as in it only supports a subset of the h264 spec? [15:55:10 CET] <pmjdebruijn> or sucks as in the result are poor even consider the previous point? [15:55:12 CET] <furq> sucks as in it's terrible quality [15:55:21 CET] <bigeast> pmjdebruijn: yes, say I'm on android. [15:55:50 CET] <pmjdebruijn> bigeast: most android devices aren't remotely resource constrained enough for you to worry about ffmpeg's size, unless it's a bottom of the barrel device :) [15:56:55 CET] <pmjdebruijn> the point i'm trying to make is, fiddling with options few people use in real life, might get you more grief than you bargained for :) [15:57:05 CET] <pmjdebruijn> that's just general advice, i'm not an ffmpeg expert :) [15:57:52 CET] <bigeast> it make sense for me, thanks~ [15:58:48 CET] <pmjdebruijn> bigeast: enable-small practical result may also depend a bit on the particular CPU [15:59:17 CET] <pmjdebruijn> bigeast: the best way to reduce ffmpeg's size is to not build it with support for codecs you won't use [15:59:22 CET] <pmjdebruijn> at least that's my first thought [15:59:55 CET] Action: pmjdebruijn isn't sure what autoenabled these days [16:01:33 CET] <pmjdebruijn> ldd will tell you where the resulting binary links too (unless you're building a static binary of course) [16:02:43 CET] <Guest94689> since I'm not familiar with streaming or ffmpeg I'm assumig that sending a rstp with ffmpeg will probably kill rp3 [16:03:37 CET] <sfan5> not necessarily [16:03:58 CET] <sfan5> you're just receiving some data, doing some maths and sending it somewhere else [16:04:18 CET] <sfan5> well that's a little vague [16:04:29 CET] <sfan5> my point is (de-)muxing a video stream is not resource intensiver [16:04:33 CET] <sfan5> s/r$// [16:05:34 CET] <bigeast> pmjdebruijn: yes, that's why I disable-all at the very first. Even disable-all, enable-small can still make the library smaller, I want to know how it'll affect the speed. [16:06:08 CET] <pmjdebruijn> bigeast: just encode some video samples [16:06:51 CET] <pmjdebruijn> bigeast: ffmpeg -benchmark -i input -c:v libx264 -f null - [16:06:52 CET] <pmjdebruijn> or whatever [16:07:29 CET] <pmjdebruijn> but does enable-small make such a big difference? [16:09:01 CET] <bigeast> Since there isn't a simple configure option to enable-ffmpeg after disable-all, I guess I'll disable some, and leave others there, and hope they are irrelevant. [16:09:05 CET] <pmjdebruijn> oh darn, avcodec is 12M [16:09:18 CET] <bigeast> pmjdebruijn: that's what I want to find out. [16:09:25 CET] <sfan5> you shouldn't use --disable-all [16:09:31 CET] <sfan5> the result will be a non-functional ffmpeg [16:09:35 CET] <sfan5> use --disable-everything instead [16:10:08 CET] <bigeast> on macOS, libavcodec.a s 15M [16:10:24 CET] <JEEB> the size of the libraries heavily depends on how much one has enabled [16:10:30 CET] <Guest94689> sfan5: what I want is just sending rstp://user:pass@ipaddress/cam/<params> to youtube server. other parameters that i want to send is cbr=3000, x264 if needed and audio if needed , [16:10:38 CET] <JEEB> and if the dependencies are static or shared for it (like libx264 if you link against it) [16:12:06 CET] <sfan5> you want to transcode then? [16:12:40 CET] <sfan5> on the pi your only option is the h264 hardware encoder, no chance for x264 [16:12:50 CET] <saml> wow libvmaf is so slow [16:13:12 CET] <JEEB> saml: I don't think anyone optimized it and the whole library was still heavily Work In Progress last I checked [16:13:17 CET] <bigeast> sfan5: disable-everything is very close to what I need! [16:15:05 CET] <Guest94689> sfan5: ok. [16:16:37 CET] <Guest94689> sfan5: i followed this tutorial https://www.jeffreythompson.org/blog/2014/11/13/installing-ffmpeg-for-raspb… [16:17:52 CET] <sfan5> that uses x264 which is way too slow on the pi [16:20:03 CET] <bigeast> ./configure with default option generate a 142M libavcodec.a, while disable-everything then enable only h264 decoder reduce it to 16M, and with an executable. [16:20:23 CET] <bigeast> on Ubuntu x64 machine [16:20:39 CET] <sfan5> that's due to debug info [16:20:43 CET] <sfan5> --disable-debug [16:20:47 CET] <Guest94689> sfan5: ooo, i see.... [16:22:09 CET] <Guest94689> sfan5: can you please, if possible, with an command example ? [16:23:56 CET] <sfan5> https://www.raspberrypi.org/forums/viewtopic.php?t=199775 try this guide [16:23:59 CET] <sfan5> you can skip the steps for mpv [16:25:26 CET] <Guest94689> sfan5: thank you [16:26:38 CET] <bigeast> sfan5: you'r right. --disable-debug make it to 16M too! Then there's no meaning in disable-everything? I'm a little fuzzy [16:27:05 CET] <sfan5> uh well [16:27:15 CET] <sfan5> disable-everything should make libavcodec much, much smaller [16:27:25 CET] <sfan5> since it doesn't actually have any functionality anymore [16:27:49 CET] <bigeast> how come it enable all the codec and result the same with disable-everything! [16:28:22 CET] <sfan5> ¯\_(Ä)_/¯ [16:37:39 CET] <DHE> bigeast: you can also run: "strip --strip-debug" on your binaries to remove debug symbols. [16:37:53 CET] <DHE> or "strip --strip-unneeded" if you're not doing any testing at all [17:20:42 CET] <saml> is 60 psnr max? [17:21:04 CET] <alexpigment> i want to say "inf" is max [17:22:21 CET] <saml> ffmpeg -i a.mp4 -i a.mp4 -filter_complex 'libvmaf=psnr=1:log_path=vmaf.log' -f null - # gives psnr of 60 [17:22:24 CET] <saml> same file [17:22:35 CET] <saml> i guess libvmaf is yolo [17:23:08 CET] <alexpigment> i've never used libvmaf tbh [17:23:31 CET] <alexpigment> anyway, i remember numbers in the high 40s, so it would make sense if 60 is the effective max [17:41:32 CET] <FishPencil> Given argv[1] is i.yuv and was created with 'ffmpeg -i i.png -pix_fmt yuv420p i.yuv', shouldn't this correctly display the first Y value: uint8_t y; std::ifstream i(argv[1], std::ios::binary); i >> y; std::cout << +y << std::endl; [17:44:47 CET] <kepstin> FishPencil: assuming that the "i >> y" actually reads a single byte, then I'd assume so yeah. [17:45:53 CET] Action: kepstin doesn't know enough about the C++ type system to say whether or not that is correct. [17:47:17 CET] <FishPencil> kepstin: So the first pixel is R: 226, G: 137, B: 125, which I believe should be 162 Y, but it's showing as 155 [17:48:16 CET] <sfan5> since you are dealing with 4:2:0 YUV, I wouldn't just expect this to be equal [17:48:17 CET] <kepstin> are you accounting for the conversion to tv range (Y=16 is black, y=239 is white) [17:48:33 CET] <sfan5> oh nevermind ignore me [17:52:19 CET] <kepstin> If I convert 162 in pc range to tv range, i get ~157, which seems pretty close (particularly when you account for chroma subsampling, etc.) [17:56:54 CET] <FishPencil> kepstin: I think that's it [17:58:18 CET] <FishPencil> kepstin: How is that conversion done? [17:59:36 CET] <kepstin> simple scaling. I gave you the values above ^^ [18:05:43 CET] <furq> 155 should be correct [18:06:12 CET] <furq> 162 * 220/256 + 16 = 155.2 [18:06:57 CET] <kepstin> hmm, I was off by a bit. Did I get the wrong value for the white point? [18:07:16 CET] <furq> limited is 16-235 [18:07:27 CET] <kepstin> ah, yeah, I did. my fault :) [18:07:50 CET] <furq> i used 224 instead of 220 at first so we probably made the same mistake [18:57:10 CET] <ChocolateArmpits> Has anyone encoded any av1 content yet? How well does cpu-used=0 compare to cpu-used=8 ? The processing speed drops by at least 40 times so I'm still a day away from any results lol. [19:20:48 CET] <SortaCore> is there any point in passing dxva2 to libx264 [19:21:09 CET] <SortaCore> via hw_device_ctx [19:21:27 CET] <SortaCore> or does libx264 just ignore that [19:22:24 CET] <sfan5> you could look at libavcodec/libx264.c and check yourself [19:23:33 CET] <SortaCore> yea, it's like instead of trying to find the book in the library, asking the librarians >.> [19:25:02 CET] <SortaCore> ok, no sign of hw_device_ctx or dxva2 in that file [19:25:11 CET] <SortaCore> so does that mean nothing, or does it mean I have the wrong file? [19:26:59 CET] <sfan5> former [19:27:55 CET] <kepstin> SortaCore: x264 is a completely software/cpu encoding library in normal usage [19:33:07 CET] <saml> are there different interlacing method? [19:35:26 CET] <kepstin> saml: there lots of different *de*interlacing methods [19:36:00 CET] <ChocolateArmpits> saml, can you be more specific ? Generally you either have a odd lines or even lines as the first field. You can store them as a whole frame or each field as a separate frame. [19:36:23 CET] <kepstin> interlaced content is can be either produced natively from a camera that does interlaced capture, or via a telecine process to convert from progressive footage [19:36:28 CET] <tyng> does libavcodec supports the dts:x extension? [19:36:59 CET] <tyng> https://comfy.moe/limnty.dts [19:37:25 CET] <saml> hrm let me read up on those. i was wondering if two videos of same size, frame rate.. but one is interlaced , it would generate different psnr. so I wanted to use ffmpeg to generate a video with interlacing on [19:38:08 CET] <kepstin> saml: interlacing vs. deinterlaced changes the image data so obviously the psnr will be different, yes. [19:38:48 CET] <kepstin> you can't recover the original interlaced video from deinterlaced version (except in the telecine case), and deinterlacing the other video means you're just comparing deinterlacers, so... [19:38:49 CET] <ChocolateArmpits> saml, depends on the codec used. Some may store both fields as a single frame with a flag checked but with no temporal distinction [19:39:05 CET] <kepstin> psnr between interlaced and deinterlaced video is basically even more meaningless than usual. [19:39:19 CET] <sfan5> tyng: that file doesn't play here so I'd say no [19:39:56 CET] <saml> i see [19:40:01 CET] <saml> on man psnr just die [19:40:09 CET] <saml> https://gist.github.com/saml/1e512d7b9a74a62e9c5e20d661dfc6a0 [19:40:20 CET] <ChocolateArmpits> Generally storing both fields as a frame will require higher bitrate to preserve comb edges [19:40:53 CET] <kepstin> saml: and again, you shouldn't be using the 'framerate' filter to convert - the blending it does generally looks bad *and* lowers psnr [19:41:45 CET] <saml> hrm i see. i guess -filter fps is same as -r then? [19:41:47 CET] Action: saml tries [19:42:26 CET] <kepstin> saml: of course, neither the framerate nor fps filter guarantees that the frames will line up with the other video you have [19:42:37 CET] <kepstin> which means of course that the psnr is still useless [19:43:00 CET] <saml> i wish psnr just errors out if two input videos are different in anything other than bit rate [19:43:29 CET] <saml> then i can just report. nope, you can't use psnr for that [19:44:28 CET] <tyng> sfan5 ffprobe detects it as dts-hd ma profile but is also contains a dts:x extensions as detected by libmediainfo [19:44:39 CET] <tyng> compare "ffprobe -of json -show_streams -f dts https://comfy.moe/limnty.dts" and "mediainfo --Language=raw https://comfy.moe/limnty.dts" [19:44:40 CET] <saml> how do you change frame rate of 120fps slow mo (gopro) to 30fps but still maintain playback speed? when I use -r 30, video seems to play faster [19:45:29 CET] <kepstin> saml: the problem is probably that your player can't play 120fps correctly [19:46:02 CET] <saml> ah that's true. mplayer did complain my system is too slow [19:47:06 CET] <saml> PSNR calculation is only meaningful when main and ref have same spec other than bit rate. (is this true?) [19:47:28 CET] <furq> i feel like we've said that a bunch of times [19:47:49 CET] <sfan5> tyng: ah i was missing the -f dts, if ffmpeg doesn't detect the DTS:X content it likely doesn't support it [19:48:27 CET] <kepstin> saml: psnr calculation doesn't correspond to visual quality as perceived by humans. In some circumstances it can be used to make relative comparsions between the *same* video encoded with slightly different settings. [19:49:17 CET] <saml> do you have example of those settings that are allowed? obviously i can't use -r fps [19:49:17 CET] <SortaCore> is it correct that nvenc is slower with d3d11 hw context than dxva2? [19:49:19 CET] <kepstin> saml: this is why netflix is working on stuff like vmaf, which *does* correspond to visual quality as perceived by humans - at least better than anything else we have so far. [19:49:33 CET] <kepstin> saml: changing fps means it's not the same video being encoded. [19:49:42 CET] <furq> maybe it wasn't you who was asking this before, but it's difficult to get meaningful psnr results from videos that are different sizes or framerates [19:49:52 CET] <furq> especially framerates [19:50:09 CET] <saml> it was all me. psnr stuff [19:51:24 CET] <kepstin> psnr does not account for the perceptual quality loss from a lower framerate having lower temporal resolution - indeed, I don't know of any metrics which do account for that. [19:51:26 CET] <saml> so, only allowed parameters for psnr testing is -maxrate -bufsize -b:v -crf ? [19:51:33 CET] <saml> if any other parameter is used, psnr is useless [19:51:44 CET] <furq> change whatever you want other than the rate and size [19:52:06 CET] <furq> remember these metrics are only useful at all to compare a source and reference [19:52:18 CET] <furq> comparing two different encodes doesn't tell you anything [19:52:23 CET] <furq> and er [19:52:25 CET] <kepstin> saml: but even if you keep rate and size the same, psnr still isn't very useful unless only computers are watching your video. [19:52:30 CET] <furq> a source and encode, i mean [19:52:44 CET] <furq> and also yeah psnr/ssim aren't that useful with modern codecs because of psy [19:52:52 CET] <furq> vmaf supposedly takes that into consideration [19:53:05 CET] <furq> i couldn't tell you how good it is though [19:53:22 CET] <saml> yeah i'm calculating psnr of source and encode. but encode does use -r and -s (changes both framerate and size) [19:53:39 CET] <furq> well yeah you're not comparing the same frames [19:54:15 CET] <kepstin> saml: run a first pass encoding to a temp file (lossless?) with -r and -s, then encode from that temp file. Run a psnr compare between the temp file and final encode. [19:54:42 CET] <saml> kepstin, that works pretty well. except when encode is generated with -filter framework, not -r [19:54:50 CET] <sfan5> x264 is not deterministic is it? [19:54:56 CET] <furq> not by default [19:55:03 CET] <saml> this is theoretical situation. i don't do -filter framerate [19:55:08 CET] <furq> there's some settings you can disable to make it bitexact but i forget which ones right now [19:55:31 CET] <furq> i'm pretty sure you have to disable frame threading and something else [19:55:43 CET] <furq> so it's not something most people are going to do [19:55:46 CET] <saml> so, to test an encoding pipeline, i need to figure out what it's exactly doing. if it's using -r or -s... etc. i create a lossless encoding with same -r and -s ... etc. and do psnr [19:56:00 CET] <kepstin> saml: -r ? is the same as -vf fps=? [19:56:06 CET] <furq> -r is the fps filter and -s is the scale filter [19:56:39 CET] <kepstin> saml: basically, you need to compare psnr between the lossless output of the filters and the final encoded file. [19:56:53 CET] <furq> yeah the filters aren't encoding anything [19:57:02 CET] <furq> just use the same filterchain to generate a lossless output and an encoded output [19:57:09 CET] <furq> although at this point it's unclear what you're actually testing [19:57:17 CET] <kepstin> yeah :/ [19:57:42 CET] <furq> scaling and decimating has already reduced the quality relative to the source [19:57:42 CET] <kepstin> saml: why do you think you want psnr values in the first place, anyways? What do you plan to do with them? [19:58:03 CET] <saml> -r 30 r30.mp4 vs. -vf fps=30 fps30.mp4 would you expect r30.mp4 and fps30.mp4 to have psnr inf? [19:58:26 CET] <kepstin> saml: those are both the same command, so the result should be identical (except for x264 nondeterminism) [19:58:29 CET] <furq> no but only because x264 isn't bitexact by default [19:58:33 CET] <furq> funny how that came up again so quickly [19:58:41 CET] <furq> the psnr should be very high though [19:59:31 CET] <furq> oh, actually [19:59:45 CET] <furq> it's non-deterministic with frame threading and the vbv enabled [19:59:53 CET] <furq> so i guess it will be bitexact by default [19:59:59 CET] <kepstin> no, threading is enabled by default [20:00:15 CET] <furq> both frame threading and the vbv [20:00:16 CET] <kepstin> oh, or did they make threading deterministic at some point? [20:00:23 CET] <furq> https://mailman.videolan.org/pipermail/x264-devel/2015-April/011035.html [20:00:26 CET] <kepstin> it might depend on x264 version then [20:00:44 CET] <saml> i want metric to test encoding pipeline v1 and v2. I have source code of both v1 and v2. I know exactly what ffmpeg they are executing. before rolling v2 out to production, i want to make sure it does not have abnormali against v1 [20:01:30 CET] <saml> so I wanted to encode sample originals through v1 and v2 and somehow measure something numerically [20:01:31 CET] <kepstin> furq: this other post: https://mailman.videolan.org/pipermail/x264-devel/2015-April/011037.html measures that simply changing threads affects psnr [20:02:11 CET] <furq> oh fun [20:02:55 CET] <kepstin> furq: I'm fairly sure that frame threading in x264 is non-deterministic. I believe libvpx 1.7's new threading mode is deterministic, tho. [20:03:13 CET] <furq> is that row-mt or did they finally add frame threading [20:03:30 CET] <kepstin> i think it's row-mt. [20:03:52 CET] <kepstin> libvpx 1.7.0 is just the first release to include row-mt [20:03:56 CET] <furq> yeah [20:04:43 CET] Action: kepstin has been using git snapshots for ages tho. [20:05:45 CET] <kepstin> saml: if you have the original source of both videos, and both were encoded at the same fps/size as the original source, then you can do vmaf of sourceencode1 and sourceencode2 and compare the values. [20:09:53 CET] <saml> if encode1 and encode2 are different, the best bet for me is to generate two lossless from source that matches encode1 and encode2 and do psnr or vmaf of lossless1->encode1 and lossless2->encode2 [20:10:05 CET] Action: saml tests this [20:15:35 CET] <killown> how can ffmpeg auto set font size depending on video aspect ratio size etc, I mean, some videos the text gets too big and some too small, ffmpeg -i "$originalfile" -vf "drawtext=text='MYTEXT':x=w-tw-10:y=h-th-20:fontsize=35:fontcolor=white@0.6:shadowcolor=black@0.2:shadowx=2:shadowy=2:box=1: boxcolor=DarkMagenta@0.2:boxborderw=5" "$newfile" [20:16:51 CET] <ddubya> killown, multiply the font size by some function of the frame size [20:17:55 CET] <ddubya> if you want the font to be 10% of height then fontSize=0.1*h [20:18:08 CET] <killown> ddubya, thank you I will try [20:18:22 CET] <kepstin> saml: but that won't account for perceptual differences due to the resolution or framerate changes, so it's kinda incomplete. [20:22:16 CET] <saml> yeah. i think it's better to start measuring encoding time and other exact numbers and compare how long it takes to encode the same video in pipeline1 and pipeline2... etc [20:23:50 CET] <geuis> hmm. How can I clear an overlay after some amount of time? I'm importing a stack of pngs at 1fps and a stack of svgs at 1fps, then overlaying the svgs. [20:24:03 CET] <geuis> Current command: ffmpeg -y -framerate 1 -i layer-%d.png -framerate 1 -i layer-%d.svg -filter_complex "[0:v]fps=30[base];[1:v]fps=30[date];[base][date]overlay=(0):(0)" -preset ultrafast -movflags +faststart -vcodec libx264 -crf 23 -pix_fmt yuv420p out.mp4 [20:30:06 CET] <ddubya> geuis, maybe it would clear if you ran out of svgs? [20:31:14 CET] <kepstin> geuis: the overlay filter takes framesync options, see https://www.ffmpeg.org/ffmpeg-filters.html#framesync - The default is to keep showing the last frame forever [20:31:27 CET] <geuis> its a 1-1 correlation. Each svg is created to last as long as the base png [20:32:47 CET] <killown> ddubya, thanks a lot, this worked [20:35:08 CET] <saml> wait.. just noticed if i have to create lossless encoding to use as reference to psnr, i could just pass -psnr -tune psnr. and be done with it [20:35:18 CET] <saml> re-encode with -psnr param :P [20:35:30 CET] <saml> i don't need to create lossless reference and use psnr filter [20:36:28 CET] <kepstin> saml: but you don't want -tune psnr if humans are watching your video [20:36:41 CET] <kepstin> saml: -tune psnr makes the video look worse, but the psnr number higher [20:36:46 CET] <geuis> kepstin, would it look like this? "[base][date]overlay=(0):(0),framesync=repeatlast=0" [20:37:28 CET] <kepstin> geuis: no, "[base][date]overlay=(0):(0),repeatlast=0" (or "[base][date]overlay=(0):(0),eof_action=pass" might be better actually) [20:40:53 CET] <saml> since psnr is logarithmic scale, difference of 1.0 is huge? [20:41:05 CET] <saml> i feel like i'm writing a paper [20:42:29 CET] <geuis> @kepstin: says its an invalid argument -filter_complex "[0:v]fps=30[base];[1:v]fps=30[date];[base][date]overlay=(0):(0),repeatlast=0" [20:43:06 CET] <kepstin> geuis: sorry, my fault. syntax issue. It should be a : not a , [20:45:01 CET] <geuis> ah right [20:54:26 CET] <geuis> hmm. @kepstin tried all of the framesync options but the overlays persist [20:55:43 CET] <kepstin> geuis: do you have an svg corresponding to each png file? [20:55:49 CET] <kepstin> or fewer svgs than pngs? [20:56:17 CET] <geuis> yeah, 1-1 [20:57:14 CET] <kepstin> geuis: expected behaviour then. If you want the svg overlay to stop earlier, just delete some of the files? Or you can add a trim filter after one of the fps filters, to set an end point on that stream. [21:00:32 CET] <kepstin> geuis: so something like "[0:v]fps=30[base];[1:v]fps=30,trim=end=10[date];[base][date]overlay=(0):(0):repeatlast=0" will stop the overlayed frames after 10 seconds. [21:04:37 CET] <geuis> semicolon or comma between fps=30,trim=end=10? [21:04:52 CET] <geuis> I get them mixed up [21:05:07 CET] <sfan5> comma [21:05:45 CET] <geuis> why a comma there, but a semi in "[base][date]overlay=(0):(0):repeatlast=0" [21:06:40 CET] <saml> overlay(base, date, 0, 0, repeatlast=0) [21:06:48 CET] <sfan5> "Filters in the same linear chain are separated by commas, and distinct linear chains of filters are separated by semicolons. " [21:06:49 CET] <saml> I think that's rough C-like syntax [21:06:50 CET] <sfan5> from the docs [21:07:15 CET] <geuis> ah that makes sense saml [21:07:46 CET] <saml> foo,bar means bar(foo(a)), i think [21:07:47 CET] <geuis> commas are like passing the results from one function to the next, semis are arguments for a function [21:08:12 CET] <saml> foo;bar is foo(); bar() (not necessarily sequentially) [21:08:26 CET] <geuis> yah [21:10:20 CET] <furq> it's bar(foo(a)) in languages that don't have multiple returns [21:10:41 CET] <furq> if a filter takes or emits more than one stream you always need ; [21:10:47 CET] <furq> even if the outputs go to the next input [21:11:39 CET] <furq> actually nvm maybe i'm wrong [21:13:27 CET] <geuis> hmm not working [21:14:02 CET] <geuis> tried end and duration with different values for trim [21:14:34 CET] <geuis> all it seems to be doing is cutting off the overlay at a certain point, then no new ones are shown afterwords [21:15:01 CET] <geuis> like its treating all of the svgs as a single video source rather than individually [21:16:45 CET] <saml> you want layer-1.svg to be overlayed to layer-1.png and become frame 1? [21:16:58 CET] <saml> and layer-2.svg is overlayed to layer-2.png and become frame 2 [21:19:21 CET] <geuis> what's the definition of frame in this context? [21:19:27 CET] <kepstin> geuis: yes, that's exactly what it's doing. it's making a video out of the svgs by putting one frame after the next [21:20:10 CET] <geuis> I have pairs of png and svg. Trying to have each svg overlay its png for an equal duration [21:20:27 CET] <geuis> so 10 input pngs at 1fps create a ten second animation [21:21:20 CET] <geuis> and each matching svg should overlay at the start of its png and be cleared when the next png input is shown [21:22:29 CET] <geuis> currently they all start correctly, but the tricky bit is getting the associated svg to be cleared after its 1 second duration [21:23:17 CET] <geuis> is there a way to set a keyframe at each second and have ffmpeg clear everything? [21:23:51 CET] <Jared> Hey guys, my new download install failed but I can't find the console log in ffbuild, should I just re-run to see if it makes one next time or is it in a different location on Mac? [21:24:48 CET] <kepstin> ok, so you want each png to be shown for 10 seconds, but the svg to be shown for 1 second, and then 9 seconds of blank? [21:25:07 CET] <kepstin> geuis: that's gonna be really hard to do, I don't know any easy way to do it via ffmpeg filters. [21:25:24 CET] <saml> i wonder if it's easier to overlay png and svg using different program in a loop, generating overlayed-%d.png ... [21:25:45 CET] <geuis> each png is shown for 1 second. each svg is overlayed for 1 second over its png [21:25:56 CET] <kepstin> geuis: that should be what it's doing... [21:25:59 CET] <saml> it's like as if you're watermarking each slide with different watermark and create a slideshow [21:26:16 CET] <geuis> yes, that's a close analogy [21:26:35 CET] <kepstin> geuis: you've created a 1fps video of pngs, and a 1fps video of svgs, and you've overlayed one video over the other. Everything should be matching up. [21:26:42 CET] <geuis> they do [21:26:55 CET] <geuis> but I need each svg to stop displaying after 1fps [21:27:08 CET] <saml> oh that's clever way to do it [21:27:22 CET] <saml> ah do you see buffering effect(?) on svg video stream? [21:27:30 CET] <kepstin> geuis: I'm not sure what you mean. After 1s, the first svg should be replaced with the next. [21:27:34 CET] <geuis> I can't show a sample unfortunately (internal company thing) [21:27:45 CET] <saml> i mean like buffer isn't cleared before drawing next svg [21:27:50 CET] <geuis> lemme screen shot [21:27:54 CET] <geuis> one min [21:28:11 CET] <thebombzen_> in the configure script, what does --enable-gray actually do? [21:28:29 CET] <thebombzen_> it says 'full grayscale support (slower color)' but what does that even mean? [21:30:20 CET] <kepstin> thebombzen_: it looks like it adds a fastpath for grayscale in a few codecs, at the expense of adding a bunch of extra conditionals (if statements) which make the regular colour path slower [21:30:51 CET] <kepstin> thebombzen_: you'd probably have to benchmark individual use cases to see if it helps/hurts. [21:31:10 CET] <saml> it seems to enable gray9be and gray9le pix_fmt [21:31:40 CET] <thebombzen_> cause I find it strange that adding full grayscale support would slow down color, since most of the computation would be done knowing the pixel format, right? [21:31:46 CET] <thebombzen_> I mean how much slower does it really make color? [21:31:57 CET] <saml> i have ffmpeg with --enable-gray and -pix_fmts include gray9be and gray9le ffmpeg without --enable-gray don't have those [21:32:00 CET] <kepstin> thebombzen_: "kepstin> thebombzen_: you'd probably have to benchmark individual use cases to see if it helps/hurts." [21:32:11 CET] <thebombzen_> oh lol, okay then. [21:32:15 CET] <geuis> ok hopefully this is clearer https://imgur.com/a/IsEni [21:32:17 CET] <saml> ah i'm wrong [21:32:26 CET] <kepstin> thebombzen_: but in general, adding more conditionals/if statements makes code slower [21:32:41 CET] <kepstin> so if you add an if statement "if grey, don't do colour stuff" then the colour stuff is slower [21:33:03 CET] <geuis> I have 5 pngs of background imagery I'm overlaying with an svg that contains some date text and other graphical elements. [21:33:07 CET] <thebombzen_> yea but I was under the impression the if statements weren't done repeatedly [21:33:33 CET] <thebombzen_> I also wonder if that logic can be fixed with -fpredictive-commoning [21:34:25 CET] <sfan5> isn't that just a fancy way of adding __builtin_except(/* is color? */, 1) aka __likely() ? [21:34:32 CET] <sfan5> s/except/expect/ [21:35:07 CET] <thebombzen_> predictive commoning affects a compiler's branch prediction yea. and since you're always encoding the same pixel format it should be pretty good at the branch prediction [21:35:39 CET] <sfan5> well that can only do so much, there will still be nonzero overhead [21:36:06 CET] <thebombzen_> true, but it might be worth it. Depending on how frequently you execute teh if statements it might be negligible [21:38:40 CET] <Loeb> Is there an encoder that uses cuda for h264, independent of nvenc/nvidia's on chip hardware encoder? [21:39:41 CET] <furq> not in ffmpeg [21:39:46 CET] <furq> there's some commercial one iirc [21:41:24 CET] <thebombzen_> Loeb: in general GPU-accelerated encoding is a very difficult thing to do [21:41:31 CET] <furq> x264 can use opencl for lookahead but the results are very patchy [21:41:48 CET] <furq> it's generally not something you can do well on an gpu [21:42:03 CET] <furq> you're better off just using the gpu for filtering [21:42:12 CET] <furq> it was designed for image processing after all [21:42:15 CET] <thebombzen_> teh design of these codecs is such that good encoders make lots of decisions on how to allocate bitrate [21:42:25 CET] <thebombzen_> and GPUs are specifically very bad at "lots of decisions" [21:42:27 CET] <Loeb> Yeah, right now we are running ffmpeg with cuda decode and nvenc encode but we are maxing out the gpu's encoder chip [21:42:41 CET] <Loeb> Wasn't sure if we could pile on something that used the other GPU bits on top [21:43:06 CET] <thebombzen_> if all you're doing is decoding with cuvid and encoding with nvenc, you're just suffering from generation loss for no reason it seems [21:43:21 CET] <thebombzen_> if you have any filtering in between, that's a good thing to do on the GPU as furq said [21:43:34 CET] <Loeb> All we are doing is going form mpeg2 to h264 right now [21:43:37 CET] <furq> is this a quadro [21:43:40 CET] <Loeb> from* [21:43:42 CET] <Loeb> Yeah, P4000 [21:43:46 CET] <furq> oh ok [21:43:54 CET] <thebombzen_> You might want to consider using x264 [21:43:57 CET] <furq> i guess you are actually maxing it out and not just running into the concurrent stream limit then [21:44:09 CET] <Loeb> x264 runs on the CPU though, right? [21:44:19 CET] <Loeb> Yeah we are at around 24 encoding threads [21:44:24 CET] <kepstin> Loeb: sure, but you have all those cpus free because you're encoding on the gpu right? :) [21:44:46 CET] <thebombzen_> yes. but x264 is so much better than nvenc. nvenc's coding inefficiency is really bad [21:44:47 CET] <Loeb> Unfortunately I think we could only shove another 3-4 encoders on the CPU before it maxes out [21:44:56 CET] <furq> what cpu [21:45:04 CET] <Loeb> E5-2603 v4 [21:45:08 CET] <Loeb> No core speed [21:45:21 CET] <specing> you need tha power [21:45:23 CET] <furq> 1.7ghz apparently [21:45:24 CET] <thebombzen_> also Loeb you should decode mpeg2 on the cpu. FFmpeg's mpeg2video decoder is faster than Cuvid's mpeg2video hardware decoder. [21:45:26 CET] <specing> tha IBM openpower [21:45:28 CET] <furq> so yeah that's not going to do too great [21:45:35 CET] <thebombzen_> or rather [21:45:39 CET] <thebombzen_> maybe not with that core speed [21:45:39 CET] <kepstin> ah, so you got a slow chip with a lot of pci-e just to run the gpus, then. [21:45:44 CET] <Loeb> Also this is for streaming use, so we are running higher bitrates than normal x264 use [21:45:52 CET] <furq> it doesn't really matter if it's faster if cuvid isn't the bit that's maxed out [21:45:55 CET] <thebombzen_> x264 can do any bitrate? [21:46:22 CET] <Loeb> thebombzen_, the decoder isn't the limiting factor I believe, nvidia-smi is reporting different utilization counters for decode and encode [21:46:23 CET] <Loeb> I could be wrong [21:46:31 CET] <thebombzen_> ah okay [21:46:34 CET] <Loeb> Yes but we don't have any quality issues with nvenc [21:46:37 CET] <thebombzen_> might be worth it anyway though for power reasons [21:46:44 CET] <Loeb> We just wanna push more data through it. If anything we should drop the quality settings... [21:46:45 CET] <furq> 24 streams with nvenc is a fair old amount [21:46:50 CET] <furq> i wouldn't be surprised if that was the limiting factor [21:47:04 CET] <furq> i take it this is sd [21:47:07 CET] <Loeb> It might be, I just wanted to make sure there wasn't any better way to utilize the rest of the GPU [21:47:12 CET] <thebombzen_> you might be hitting max TDP too on the GPUs [21:47:14 CET] <Loeb> Some SD some 1080i [21:47:19 CET] <BtbN> I'm surprised it even managed 24 without dieing horrible [21:47:20 CET] <thebombzen_> so perhaps you should consider software decoding the mpeg2 [21:47:23 CET] <Loeb> Nowhere near TDP limit actually [21:47:28 CET] <thebombzen_> oh then, nvm [21:47:28 CET] <kepstin> thebombzen_: nah, if the 3d engine isn't being used it should be nowhere near tdp [21:47:34 CET] <furq> maybe offload the sd streams to the cpu then [21:47:51 CET] <furq> i'm not sure how many you could get on that cpu but x264 is very quick if you use fast settings [21:47:53 CET] <thebombzen_> yea SD on a CPU is actually quite fast [21:48:09 CET] <thebombzen_> probably fast enough [21:48:14 CET] <furq> yeah and you'd probably want to use nvenc's deinterlacer for 1080i [21:48:15 CET] <thebombzen_> which is all that matters if streaming. "fast enough" [21:48:21 CET] <Loeb> We aren't even deinterlacing [21:48:23 CET] <furq> oh [21:48:24 CET] <furq> well that helps [21:48:25 CET] <thebombzen_> rip [21:48:27 CET] <Loeb> Literally just mpeg2 > h264 [21:48:41 CET] <thebombzen_> Although you can save bitrate with IVTC [21:48:53 CET] <thebombzen_> not sure how well you can IVTC in realtime though [21:49:04 CET] <thebombzen_> (since 30 -> 24 fps is lower bitrate I mean) [21:49:05 CET] <furq> i doubt this is telecined [21:49:11 CET] <kepstin> ivtc doesn't help unless it's telecined :) [21:49:13 CET] <thebombzen_> well it's 30 fps interlaced mepg2 [21:49:19 CET] <thebombzen_> so I'm guessing it's telecined [21:49:28 CET] <furq> that's a weird guess to make [21:49:30 CET] <kepstin> nah, it could be any ntsc interlaced video. [21:49:51 CET] <thebombzen_> okay, so *if* it's telecined, IVTC could save you some bitrate [21:50:16 CET] <thebombzen_> (I just see interlaced 1080i mpeg2 and figured it was a digital TV broadcast) [21:50:30 CET] <thebombzen_> I've been hanging out with anime encoders too much [21:50:30 CET] <furq> it probably is a digital tv broadcast but a lot of that is 30i anyway [21:50:47 CET] <thebombzen_> but most content is filmed in 24 [21:50:53 CET] <furq> i don't think it is [21:51:09 CET] <furq> maybe if you work for HBO it is [21:51:12 CET] <thebombzen_> film and animation industry use 24 as standard, afaik. lemme find a soruce on that. [21:51:19 CET] <furq> yeah the film industry does [21:51:26 CET] <furq> that's distinct from the tv industry though [21:56:22 CET] <kepstin> tv industry is still mostly 60i/50i for broadcast stuff and general tv productions (which is why high framerate is sometimes called "soap opera effect") [21:56:32 CET] <geuis> @kepstin I isolated this to just the svgs http://i.imgur.com/Mo39Ld8.gifv [21:57:11 CET] <kepstin> geuis: alright, so my guess is that it's a bug in the svg rendering in ffmpeg [21:57:27 CET] <kepstin> where it's drawing over a previously rendered frame rather than drawing each separately on a clear frame [21:57:34 CET] <geuis> ffmpeg -y -i layer-%d.svg -preset ultrafast -movflags +faststart -vcodec libx264 -crf 23 -pix_fmt yuv420p out.mp4 [21:57:37 CET] <geuis> yeah [21:58:16 CET] <geuis> I wonder if I convert them to pngs first.. [21:58:38 CET] <kepstin> using an external svg renderer would work around the bug, yes. [21:58:51 CET] <kepstin> unless your svgs themselves are bad (have stuff stacked in the svg) [21:59:42 CET] <geuis> actually, yes I do [21:59:43 CET] <furq> maybe try -i layer-%d.svg -filter_complex "color=black:s=640x480[bg];[bg][0:v]overlay=shortest=1" [21:59:52 CET] <geuis> there are a few different elements going on [22:00:14 CET] <furq> assuming these images have a transparent background [22:00:26 CET] <kepstin> geuis: if your svg rendered by itself looks like that, then... ffmpeg can't really do anything about it? [22:00:39 CET] <geuis> no, each svg is fine on its own [22:01:12 CET] <geuis> there's <text> for the date and an external svg for the company logo being written into the svg [22:04:02 CET] <geuis> @furq the background isn't actually black. We've been trying to diagnose a problem I'm running into using svgs as overlays [22:04:24 CET] <geuis> previous frames are bleeding through [22:10:34 CET] <kepstin> furq: the suspicion I have is that the libsrvgdec code isn't correctly clearing the buffer (which might be re-used?) before drawing the next svg. [22:11:05 CET] <furq> yeah i subsequently realised that they're obviously being overlaid on something anyway [22:11:16 CET] <furq> i had to call my isp earlier so forgive my brain being broken [22:12:54 CET] <kepstin> hmm, looking at the librsvgdec code, the functions it's using to clear the buffer do in fact look wrong. [22:13:12 CET] <kepstin> it's clearing the buffer - by painting *over* it with transparent black [22:13:17 CET] <kepstin> which obviously does nothing [22:13:28 CET] <geuis> heh. I feel like a snow plow for bugs [22:13:53 CET] <kepstin> it's gonna be a 2-3 line patch to fix, refereincing the faq at https://www.cairographics.org/FAQ/#clear_a_surface [22:15:21 CET] <kepstin> geuis: apply this patch and rebuild your ffmpeg, should fix it: https://gist.github.com/kepstin/0e71839057301334ae65fdf4c26b372c [22:15:42 CET] <kepstin> er, wait, no that's wrong [22:15:47 CET] <kepstin> that'll do opaque black [22:16:00 CET] <geuis> I've also noticed something else, the fonts embedded in the svg aren't being rendered in the svg [22:16:06 CET] <geuis> was going to tackle that later [22:16:40 CET] <kepstin> ^^ I've updated that link to fix it to clear to transparent black [22:16:46 CET] <geuis> er, fonts referenced by file path in the svg document aren't being used when the svg is rendered into the graphic [22:17:15 CET] <kepstin> geuis: hmm, the renderer probably has disabled referencing external files. [22:17:19 CET] <geuis> @kepstin ok will need to tackle that in a big [22:17:27 CET] <geuis> bit [22:17:41 CET] <kepstin> geuis: either rendering the text as paths in the svg or using system fonts via fontconfig should work [22:19:25 CET] <geuis> haven't tried this yet, but since we have the font file I was going to try referencing it with fontconfig to see if that might work. [22:20:19 CET] <karen__> Is there somewhere to find help with opening video surveillence footage? My system encoded some footage @~4K in H.265, but mplayer and vlc won't play it. The terminal output says to upload it to the ftp, but I figured I'd see if this is an issue that might arise with some frequency and ask here first... [22:22:01 CET] <kepstin> karen__: can you pastebin the output from "ffplay <file>" so we can take a quick look at what's going wrong? [22:22:58 CET] <kepstin> geuis: let me know if that patch works, and I'll send it over to ffmpeg-devel [22:23:10 CET] <JEEB> karen__: you most likely just have old software (or the file format is something proprietary in which the HEVC is) [22:23:21 CET] <karen__> https://pastebin.com/4wbhVcbu [22:23:47 CET] <karen__> im running manjaro (current - updated yesterday) and ... [22:23:48 CET] <JEEB> also that seems like it's getting read as H.264, not HEVC [22:23:54 CET] <kepstin> karen__: huh, it's been misdetected as h264. You're missing the top of that output, can you go back and get the earlier bits? [22:24:09 CET] <karen__> yeah, i saw that - but the output checkmark says 265 [22:24:17 CET] <JEEB> karen__: I recommend using ffprobe and posting the log with the version numbers of `ffprobe FILE` [22:24:17 CET] <karen__> sure, i can - just a sec [22:24:39 CET] <JEEB> the version markers should tell us how old your FFmpeg etc is [22:25:00 CET] <karen__> oh, well i just installed that from manjaro repo [22:25:02 CET] <kepstin> the full ffplay output includes the version info too [22:25:21 CET] <karen__> 3.4.1-3 for ffmpeg [22:25:39 CET] <JEEB> kepstin: yes but we don't need playback [22:25:48 CET] <JEEB> ffprobe is more useful to just get the probed format info etc [22:25:56 CET] <karen__> okay [22:26:01 CET] <kepstin> JEEB: sure, but ffplay prints that too ... at the top [22:26:03 CET] <JEEB> karen__: ok, so you have a new enough thing for HEVC [22:27:23 CET] <karen__> https://pastebin.com/h3k3Z4tE [22:27:55 CET] <JEEB> ok, so it seems like AVI with H.264 [22:28:07 CET] <JEEB> yet it cannot parse it as H.264 [22:28:45 CET] <kepstin> so this is an avi file containing hevc, but with the h264 fourcc? ugg. [22:28:53 CET] <JEEB> could be something like that :P [22:28:54 CET] <furq> this all sounds very chinese [22:28:55 CET] <karen__> right, but the manual and the screen on the surveillence equipment both say h.265 default and h.264 is not on [22:29:09 CET] <JEEB> karen__: yea but the file could just be shoddily written by the device [22:29:17 CET] <JEEB> it seems to be saying "hey this is H.264" [22:29:22 CET] <JEEB> in the file for the video track [22:29:26 CET] <furq> is there such thing as hevc in avi [22:29:36 CET] <JEEB> well there is no real official mappings for AVC or HEVC [22:29:37 CET] <furq> outside of whatever device wrote this [22:29:42 CET] <JEEB> or heck, even MPEG-4 Part 2 [22:29:48 CET] <kepstin> karen__: can you possibly use a different container instead of avi? [22:29:56 CET] <karen__> I cannot anylonger [22:29:59 CET] <karen__> and when i exported it [22:30:03 CET] <karen__> it chose mp4 [22:30:11 CET] <karen__> but it came out like this [22:30:15 CET] <JEEB> lol [22:30:20 CET] <JEEB> great software/hardware [22:30:34 CET] <JEEB> anyways, I would just try rewriting the FourCC of that AVI file [22:30:42 CET] <karen__> seriously - f)(k binary/propiatary blobs right? [22:30:44 CET] <furq> to what, though [22:30:44 CET] <JEEB> to whatever FFmpeg reads as HEVC [22:31:14 CET] <karen__> I don't know what rewriting the fourcc means [22:31:59 CET] <JEEB> possible 'HEVC' would work [22:32:02 CET] <kepstin> hmm. would forcing the codec on an ffmpeg command (using -c:v as an input option) work to override this case? [22:32:15 CET] <JEEB> I don't think it would :/ [22:32:27 CET] <furq> yeah i don't think that works but it's worth a try [22:32:50 CET] <karen__> Yesterday i tried to force VLC to use different codecs to play the video back, and didn't have any luck - I mean, i'm kinda just feel like im guessing and fumbling around at this point, and the trouble is, this creep that was stalking me is in the clip... photographing my house.. *le sigh [22:33:24 CET] Action: kepstin honestly wouldn't trust this security camera to be ... secure. [22:33:43 CET] <karen__> oh hell, it's not on the network.. lulz [22:33:56 CET] <kepstin> but if you're only using it to record outdoor stuff (not private), probably good enough. [22:34:11 CET] <furq> it's not good enough if you can't play back the footage [22:34:26 CET] <JEEB> karen__: basically there's currently a thing in the AVI file that says literally 'H264 ', you could try rewriting that identifier (called FourCC) to 'HEVC' or so [22:34:31 CET] <furq> call me old-fashioned but i would say that is one of the main features of a security camera [22:34:32 CET] <JEEB> and hope that FFmpeg knows that [22:34:34 CET] <karen__> nor the internet - but the picutres look good on the machine, but the export function, the only time ive needed it seems to have failed me [22:34:46 CET] <JEEB> but yes, that thing has generated you broken-beyond-commision files :P [22:35:03 CET] <karen__> right furq? lol [22:35:12 CET] <furq> karen__: you can try ffmpeg -c:v hevc -i foo.avi -f null - [22:35:31 CET] <furq> emphasis on try because i don't think that works [22:35:47 CET] <karen__> foo.avi with my file name? [22:35:50 CET] <furq> right [22:36:00 CET] <karen__> oh, yhea - this looks like what i was trying yesterday [22:36:08 CET] <karen__> when i tried h26x and such too [22:36:22 CET] <JEEB> most likely it won't work because that's actually within a container and all [22:36:25 CET] <furq> yeah [22:36:31 CET] <JEEB> so ffmpeg.c already has the Trusted Information [22:37:05 CET] <kepstin> geuis: any news back on whether my patch fixes your svg problem? [22:37:13 CET] <karen__> Too many packets buffered for output stream 0:0.32:22.77 bitrate=N/A speed=N/A [22:37:36 CET] <JEEB> karen__: in the output of ffmpeg.c do you see if the input track is noted as HEVC or H.264? [22:37:42 CET] <JEEB> it's in the relative beginning of the log [22:37:52 CET] <JEEB> if you succeeded in overriding it to HEVC, congratulations [22:38:25 CET] <karen__> um, wheres the ffmpeg.c? [22:38:41 CET] <JEEB> it's the command line ffmpeg tool [22:38:50 CET] <kepstin> karen__: please just pastebin the output of that ffmpeg command *from the top* [22:38:56 CET] <karen__> oh [22:39:50 CET] <furq> if you don't get a million h264 decoder errors (like in the ffprobe paste) then we might be onto something [22:39:52 CET] <karen__> https://pastebin.com/MmafrFFw [22:40:02 CET] <karen__> oh no, it was way smaller error [22:40:03 CET] <furq> oh wow nice [22:40:03 CET] <JEEB> con-fucking-gratulations [22:40:11 CET] <furq> i genuinely didn't think that would work [22:40:17 CET] <JEEB> Stream #0:0: Video: hevc (Main) (H264 / 0x34363248), yuvj420p(pc, bt709), 2560x1440, 2087 kb/s, 9 fps, 9 tbr, 9 tbn, 36 tbc [22:40:32 CET] <JEEB> so you actually managed to override the darn thing [22:40:35 CET] <furq> i wonder if this is because whoever wrote the avi muxer is familiar with china [22:40:37 CET] <JEEB> and suddenly it has way more info [22:40:56 CET] <kepstin> karen__: you should be mostly good to go then, try running "ffmpeg -c:v hevc -i 1_01_R_171112194500.avi -c copy fixed.mkv" and see if the result is playable. [22:40:56 CET] <geuis> kepstin: haven't had a chance to try it yet [22:41:02 CET] <furq> yeah i was just typing that [22:41:07 CET] <JEEB> ok, kepstin wrote it down :) [22:41:09 CET] <geuis> juggling the task masters atm [22:41:15 CET] <JEEB> that should hopefully generate a valid matroska file [22:41:17 CET] <JEEB> with HEVC [22:41:23 CET] <furq> i have to suspect the audio codec is wrong as well but who knows [22:41:25 CET] <JEEB> which should play in mpv for example [22:41:28 CET] <furq> i'm guessing that bit is less important anyway [22:41:32 CET] <JEEB> furq: yea probably it is :D [22:41:47 CET] <JEEB> might as well -an that I guess? [22:41:50 CET] <kepstin> geuis: cool. I'll probably just send the patch off anyways, I'm pretty sure it's correct. [22:42:21 CET] <geuis> trying to think how I'm going to do this. got ffmpeg built from source via homebrew [22:43:32 CET] <geuis> my other env is in a local docker image but its not setup as part of the rendering pipeline yet [22:44:14 CET] <geuis> will your patch go into 3.4.1 or wait until another release? [22:44:33 CET] <kepstin> geuis: probably won't be into 3.4.x, but who knows. [22:44:42 CET] <kepstin> depends on if it can be considered a security issue [22:44:56 CET] <JEEB> it doesn't have to be security [22:45:05 CET] <JEEB> if it is applicable to that release branch and you care [22:45:19 CET] <JEEB> that's pretty much how backports work right now I think :P [22:51:25 CET] <karen__> https://pastebin.com/0Xhuzs4q [22:52:09 CET] <alexpigment> karen__: what are you trying to do here? [22:52:25 CET] <karen__> karen__: you should be mostly good to go then, try running "ffmpeg -c:v hevc -i 1_01_R_171112194500.avi -c copy fixed.mkv" and see if the result is playable. [22:52:26 CET] <JEEB> right [22:52:30 CET] <JEEB> the tag is incorrect [22:52:48 CET] <JEEB> not sure why it requires it but let's see if there's an ffmpeg.c parameter to force it [22:53:25 CET] <karen__> Thanks. Am feeling rather defeated :p [22:53:38 CET] <JEEB> karen__: -tag:v "HEVC" after input [22:53:41 CET] <JEEB> try that :) [22:53:57 CET] <JEEB> or maybe input? [22:54:01 CET] <JEEB> *before input [22:54:23 CET] <alexpigment> is -c:v hevc even a thing? [22:54:31 CET] <JEEB> yes [22:54:31 CET] <kepstin> alexpigment: for the decoder, yes [22:54:34 CET] <alexpigment> i guess i'm not used to specifying a decoder [22:54:42 CET] <kepstin> (and it's an alias for whatever the default hevc encoder is) [22:54:53 CET] <JEEB> the format didn't have another name yet when the decoder was made in libavcodec [22:55:03 CET] <JEEB> it was still being called H.HEVC in ITU-T as well [22:55:04 CET] <alexpigment> ah [22:55:34 CET] <JEEB> as the specification was finally finished, then ITU-T announced they'd take it in and call it H.265 [22:55:38 CET] <JEEB> and absolutely no-one was surprised [22:55:43 CET] <alexpigment> :) [22:56:01 CET] <alexpigment> well, it's ideal to name something close to something people are already familiar with [22:56:31 CET] <alexpigment> and maybe if HD-DVD would have succeeded, there would be a lot less confused old people about blu-ray [22:57:04 CET] <kepstin> i still find it interesting that some companies have started putting out SD content on blu-ray (not upscaled) [22:57:14 CET] <JEEB> that's been in the spec for ages [22:57:19 CET] <alexpigment> sorry, just a side rant here. i really hate that blu-ray didn't catch on in time, and that most stores still stock more dvd than blu-ray :( [22:57:22 CET] <JEEB> to be able to put DVD content there [22:57:36 CET] <alexpigment> kepstin: yeah, it's usually for supplemental content though [22:57:45 CET] <alexpigment> just reusing existing assets [22:58:02 CET] <therage3> wait [22:58:02 CET] <alexpigment> i'm fine with it. i don't need them to upscale something that my player can already upscale [22:58:04 CET] <JEEB> physical stuff is going the way of the dodo outside of use cases where you just want the best thing you can get :P [22:58:10 CET] <therage3> what? SD as in Standard Definition? like 480p stuff?? [22:58:12 CET] <JEEB> as in, a normal person cannot get a master [22:58:13 CET] <kepstin> doing a new encode in h264 should be possible tho too [22:58:15 CET] <therage3> on BR? [22:58:18 CET] <alexpigment> i always want the best thing i can get. not sure why i would not want that [22:58:19 CET] <JEEB> therage3: yes [22:58:19 CET] <kepstin> therage3: yeah. [22:58:26 CET] <therage3> fr [22:58:27 CET] <therage3> lr [22:58:28 CET] <alexpigment> 480i to be exact [22:58:37 CET] <JEEB> both 480i and 576i [22:58:37 CET] <therage3> like, for what purpose? to have 10 hours of it= [22:58:39 CET] <therage3> ? [22:58:49 CET] <alexpigment> because you have a movie with some sd-mastered extras [22:58:51 CET] <JEEB> usually to put already created SD content there [22:58:53 CET] <kepstin> I think the samurai pizza cats release on BD is 480p, and *probably* a new encode [22:58:57 CET] <alexpigment> and they put the sd extras on in SD [22:58:57 CET] <kepstin> entire season on one disk [22:59:03 CET] <JEEB> kepstin: wow [22:59:15 CET] <therage3> oh. so it isn't the whole thing [22:59:17 CET] <therage3> just some extras [22:59:18 CET] <JEEB> also I've seen literally two discs utilize 720p60/1.001 [22:59:31 CET] <kepstin> therage3: you can do the whole thing in sd, there's been a few cases [22:59:45 CET] <alexpigment> JEEB, i've done that on a lot of discs i've mastered too. the source was 720p60, so... :) [22:59:51 CET] <kepstin> some concert releases iirc, and it looks like a few companies doing anime releases for stuff that was originally sd. [22:59:56 CET] <JEEB> alexpigment: :) [23:00:03 CET] <JEEB> it's good when you have stuff like that [23:00:22 CET] <JEEB> the one disc I know was a demoscene BD which had all the demos rendered at that rate [23:00:25 CET] <alexpigment> well, i do a lot of broadcast backups to blu-ray. abc and maybe fox is still native 720p60 [23:00:34 CET] <JEEB> and the other just used it for 60/1.001Hz refresh rate [23:00:40 CET] <JEEB> because they made a java-based adventure game [23:00:42 CET] <therage3> that'd be a massive waste of capabilities, especially if you end up with a lot of unused space. I wonder if those same releases also have a DVD release which is the same, but costs less [23:01:00 CET] <JEEB> therage3: well granted you can use H.264 and actual nice GOPs and bit rates [23:01:00 CET] <kepstin> therage3: DVD is terrible if you can do a new encode from a good source [23:01:13 CET] <JEEB> so in that sense you can get the best version of that SD content you have [23:01:21 CET] <alexpigment> yeah, sd to blu-ray can look much better [23:01:30 CET] <kepstin> and the BD is probably *cheaper* because you have to manufacture fewer disks [23:01:33 CET] <alexpigment> so i get it. i've just never personally seen a case where the whole disc was SD [23:01:48 CET] <JEEB> yea, DVD was goddamn awful. 1.5mbps and 8mbps maxrate? [23:01:57 CET] <kepstin> it's rare, yeah. Upscales have generally been more common. [23:01:59 CET] <JEEB> look at your buffer running away while you eat! [23:02:15 CET] <kepstin> JEEB: hey, you could use up to 10.something mbit maxrate... if you had no audio ;) [23:02:21 CET] <kepstin> iirc. [23:02:24 CET] <kepstin> or 9.8 or something [23:02:26 CET] <alexpigment> kepstin: yeah, 9.2 [23:02:27 CET] <JEEB> well yea, but that doesn't save the 1.5 megabit bufsize [23:02:28 CET] <JEEB> lol [23:02:28 CET] <kepstin> i forget [23:02:32 CET] <therage3> JEEB, kepstin, I see [23:02:34 CET] <alexpigment> well, the "safe" bitrate was usually 9.2 [23:02:40 CET] <therage3> kepstin: hm, it could be [23:02:40 CET] <alexpigment> but yeah, you coudln't use PCM then :( [23:02:45 CET] <therage3> tell me about it. that cartoon I was trying to rip for so long gave me nightmares [23:02:47 CET] <therage3> fucking variable telecine with hardcoded blended frames [23:02:48 CET] <therage3> yeesh, what a nightmare [23:02:59 CET] <JEEB> well that part wouldn't change if the source is shit [23:03:09 CET] <JEEB> but you'd get a better thing out of that shitty master [23:03:39 CET] <alexpigment> you know, i had a few archiving projects where i authored an SD Blu-ray, which i had forgotten about until just now [23:03:47 CET] <JEEB> basically the amount of damage making the disc itself to the turd will be minimized [23:03:55 CET] <JEEB> *from making the disc... [23:04:01 CET] <alexpigment> VHS captures that were like 4 hours long with no obvious place to split. so i kept the 16mbps h.264 bitrate and burned the whole thing to blu-ray [23:04:13 CET] <kepstin> but if you had a good source for the SD, like i dunno digibeta broadcast tapes or something, then a new encode SD Blu-Ray could look a lot better than a DVD. [23:04:39 CET] <alexpigment> kepstin: actually, i find the opposite case to be much truer [23:04:41 CET] <JEEB> well yea, and even with the turds you can get a better image quality. just that if it's FUBAR, it will still be FUBAR [23:04:51 CET] <alexpigment> if you have a bad source for SD, you need more bitrate [23:05:12 CET] <JEEB> karen__: so did it go through with the forced tag? [23:05:15 CET] <JEEB> (fourcc) [23:05:18 CET] <kepstin> hey, even with a clean source, DVD still looks awful due to bitrate limits. [23:05:23 CET] <alexpigment> yeah i agree [23:05:36 CET] <JEEB> kepstin: suddenly got movement? WELCOME YOUR BLOCKY MASTERS! [23:05:51 CET] <JEEB> s/MASTERS/OVERLORDS/ [23:05:53 CET] Action: kepstin thinks it's literally impossible to encode the Haruhi anime opening to DVD without looking like a blocky mess. [23:06:02 CET] <alexpigment> just saying though, the absolute worst analog signal (static) needs to most digital bitrate. it's kinda comical how that worked out.. [23:06:05 CET] <JEEB> and for americans the HBO logo [23:06:06 CET] <JEEB> lol [23:06:15 CET] <alexpigment> yeah HBO logo for sure [23:06:30 CET] <alexpigment> i haven't seen the hbo logo look decent in years [23:07:45 CET] <JEEB> kepstin: I think the initial airings of haruhi and esp. the second season are the most fabulous though, since someone clearly passed the air masters through some analogue equipment [23:07:47 CET] <alexpigment> i'm actually very surprised they didn't change it [23:08:00 CET] <JEEB> so you got stuff like dot crawl and rainbows [23:08:38 CET] <JEEB> it seemed to be popular up until 2009-2010 or so to push out certain things with crappy masters on terrestial [23:08:53 CET] <alexpigment> i hate seeing dot crawl on dvd releases :( [23:08:53 CET] <JEEB> cropping things to 4:3 and passing through analogue equipment [23:09:14 CET] <kepstin> i dunno if it was unintentional badness or on purpose to make the dvds sell better. [23:09:26 CET] <JEEB> it looked pretty purposeful [23:09:50 CET] <JEEB> same for other shows on less popular networks, although there might have been a necessity due to lack of tapes or whatever [23:09:57 CET] <JEEB> for example chiba tv would get shafted [23:10:04 CET] <JEEB> while tokyo mx would get gut quality [23:10:32 CET] <JEEB> and it definitely wasn't their encoder as it could handle other stuff that came from similar sources a'OK [23:11:29 CET] <JEEB> I guess people just stopped using some sort of tapes or whatever around 2011, because that stuff just stopped around that time (the TBS stuff with kyoani being crap on terrestial got fixed before that) [23:11:33 CET] <SortaCore> kepstin: try encoding the Maid Dragon opening [23:11:57 CET] <SortaCore> one part it goes fast motion and technicolor [23:12:04 CET] <kepstin> SortaCore: heh, yeah. I know crunchyroll couldn't encode that (but then again, i'm not convinced they can encode anything) [23:12:16 CET] <JEEB> kepstin: http://www.mod16.org/randompics/screencaps/shit/tayutama-chiba2.png -> http://www.mod16.org/randompics/screencaps/shit/tayutama-tokyomxgasm.png [23:12:19 CET] <JEEB> was a fun difference [23:12:30 CET] <JEEB> (there were plenty of such cases) [23:12:48 CET] <kepstin> crunchyroll can't even match up the gops for quality switching on the hls streams they use for most of their apps (ps3/4/chromecast/phone/etc) [23:12:54 CET] <saml> how are you doing? [23:13:46 CET] <kepstin> so you're watching a show on crunchyroll, and halfway through the opening it'll bump to higher quality and randomly move you forward/backward up to 10 seconds [23:14:09 CET] <saml> is that a feature? [23:14:12 CET] <kepstin> presumably because they forgot to set their x264 to use fixed gop size [23:14:33 CET] <JEEB> most players can do the switch just fine with HLS [23:14:37 CET] <saml> is it same as -r 30? [23:14:38 CET] <JEEB> even without matching GOPs [23:14:48 CET] <saml> i think you need constant frame rate for HLS [23:14:52 CET] <JEEB> no [23:14:59 CET] <JEEB> HLS has no requirements for frame rates [23:15:05 CET] <kepstin> JEEB: my favourite fun difference was the episode of hidamari sketch where the 4:3 version has some of the faces squished compared to the 16:9. [23:15:09 CET] <saml> otherwise, you can't switch to different conversion based on bandwidth [23:15:20 CET] <saml> you can switch.. but it'll not be at the same time [23:15:20 CET] <JEEB> kepstin: yup, TBS stuff there too [23:15:27 CET] <JEEB> saml: wrong again [23:15:30 CET] <JEEB> please read the specification [23:15:37 CET] <JEEB> https://tools.ietf.org/html/rfc8216 [23:15:52 CET] <kepstin> JEEB: hmm, maybe this jumping thing is just a problem with their ps3 player then [23:16:07 CET] <JEEB> kepstin: I mean all of their players *could* be shit, I just don't know [23:16:22 CET] <JEEB> heck, it could just also be switching to the next segment's start point [23:16:23 CET] <saml> i mean keyframes should line up [23:16:24 CET] <JEEB> or previous [23:16:44 CET] <JEEB> saml: no such requirement for the segments to have to be of the same length in time or to have matching GOPs [23:16:50 CET] <saml> unless i'm using HLS wrong [23:16:54 CET] <saml> hrm i see [23:16:58 CET] <JEEB> you can do it, but it's not required [23:17:06 CET] <JEEB> it also depends on what sort of retarded ass clients you have to support [23:17:12 CET] <JEEB> if you go down there to the very low point [23:17:15 CET] <JEEB> there's shit there [23:17:18 CET] <kepstin> well, guess I'll send this librsvgdec patch. It doesn't break anything, at least. [23:17:19 CET] <JEEB> which breaks the spec etc [23:17:26 CET] <saml> yup [23:17:32 CET] <saml> hsl.js or something [23:17:35 CET] <geuis> kepstin: how do I apply your patch? [23:17:41 CET] <JEEB> no, hls.js actually handles mismatching GOPs as far as I know [23:17:43 CET] <geuis> beyond manually editing the file [23:17:49 CET] <JEEB> real shitty stuff is random plastic boxes [23:17:49 CET] <saml> that thing will jump time [23:17:51 CET] <JEEB> including TVs [23:17:57 CET] <kepstin> geuis: if you have git, "git apply <patch-filename" will do it. [23:18:04 CET] <kepstin> (even if it's not a git checkout) [23:18:06 CET] <JEEB> jumping time is still OK. the best I've seen wasn't even HLS though :P [23:18:29 CET] <JEEB> it was one vendor's player just not thinking that segments aren't aligned and thus leading to a/v desync [23:18:32 CET] <JEEB> for the rest of the video [23:18:36 CET] <geuis> ok building now [23:18:38 CET] <JEEB> I think this was a DASH player even [23:18:41 CET] <saml> Matching content in Variant Streams MUST have matching timestamps. This allows clients to synchronize the media. [23:19:06 CET] <JEEB> saml: yes, as in the timestamps have to be matching overall for the content [23:19:15 CET] <JEEB> as in, 3min in profile A is 3min in profile B [23:19:17 CET] <JEEB> that makes sense [23:19:37 CET] <JEEB> as in, they have to share the overall time line [23:19:42 CET] <saml> Matching content in Variant Streams MUST have matching Discontinuity Sequence Numbers [23:19:49 CET] <saml> along with that, you need to have same gop [23:20:17 CET] <saml> x.1.ts -> variant.2.ts to continue this smoothly [23:20:27 CET] <saml> x.ts-1 -> variant.ts-2 [23:20:46 CET] <JEEB> uhh, no. I'm pretty sure that doesn't read like that because then every mux would have to be equal in MPEG-TS packet count [23:20:58 CET] <saml> otherwise, if you do have to go from x.ts-1 to variant.ts-2, you'll land at weird timestamp [23:21:24 CET] <saml> hrm i see. probably i'm wrong. i'm noob [23:21:29 CET] <JEEB> oh, wait no. that's the discontinuity flags in the playlist [23:21:41 CET] <JEEB> so it just means that if you have discontinuity in one profile, you have to have it in all [23:21:51 CET] <JEEB> which maeks sense, since you are using the same input for all [23:22:24 CET] <JEEB> saml: I think it basically tells you that you cannot use the location of a segment in the array of available segments as a synchronizer there somewhere [23:22:35 CET] <JEEB> it specifically says that you cannot use that as the way to switch [23:22:45 CET] <JEEB> instead you have to go by the timestamps in the playlist, which makes sense [23:22:51 CET] <JEEB> I just don't remember the exact wording [23:24:05 CET] <saml> how do I convert container format only so that I can stream mp4 to ffmpeg command? [23:24:46 CET] <saml> hrm i see. player just has to be smarter [23:24:59 CET] <saml> instead of incrementing index [23:26:26 CET] <JEEB> saml: right, 6.3.2 , the thing that starts with A client MUST NOT assume" [23:31:36 CET] <alexpigment> saml: to convert container format, you just use ffmpeg -i [input] -c copy [output.ext] [23:31:41 CET] <alexpigment> the extension usually implies the format [23:31:50 CET] <alexpigment> but if not, you can put -f [format] after the input [23:32:11 CET] <alexpigment> usually for streaming, it's just ffmpeg -i [input.mp4] -c copy [output.ts] [23:44:53 CET] <geuis> kepstin: patch confirmed [23:47:46 CET] <kepstin> Good to know, thanks for testing. [23:48:49 CET] <saml> thanks all [23:59:26 CET] <linux50> hello everyone. [00:00:00 CET] --- Thu Feb 1 2018

1 0