Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

September 2017

1 participants
60 discussions

ffmpeg-devel.log.20170924
by burek 25 Sep '17

25 Sep '17

[00:01:28 CEST] <brash> thanks jamrial for your response. More info: I am reading from an mp4 with h264 stream and wanting to copy that h264 stream into a mkv container. Do the packets not share the same DTS and PTS between containers? [00:02:41 CEST] <jamrial> not necessarely. timebase may differ, and chances are it will in your specific case [00:02:49 CEST] <jamrial> in any case, this is a question for #ffmpeg [00:03:19 CEST] <jamrial> this channel is for development of ffmpeg itself [00:03:37 CEST] <brash> My mistake. Thanks for you help. [00:03:41 CEST] <brash> *your [00:46:58 CEST] <cone-133> ffmpeg 03James Almer 07master:86be73c7c1a5: avformat/mpeg: zero initialize idx_pkt [01:14:56 CEST] <cone-133> ffmpeg 03James Almer 07master:5a9415533dd0: ffplay: zero initialize copy avpacket [02:37:26 CEST] <cone-133> ffmpeg 03Jaroslav Beran 07master:00a1e1337f22: libavdevice/v4l2: fix invalid access to struct v4l2_buffer [02:37:27 CEST] <cone-133> ffmpeg 03Michael Niedermayer 07master:9cec1742475b: avcodec/snowenc: Replace "return -1" by named constants [02:37:28 CEST] <cone-133> ffmpeg 03Michael Niedermayer 07master:d8ef5a47bba8: avcodec/flacenc: Replace "return -1" by named constant [02:37:29 CEST] <cone-133> ffmpeg 03Kaustubh Raste 07master:7f8417f22619: avcodec/mips: Improve hevc uni-w copy mc msa functions [02:37:30 CEST] <cone-133> ffmpeg 03Kaustubh Raste 07master:d6737539e77e: avcodec/mips: Unrolled loops avc intra msa functions [02:37:31 CEST] <cone-133> ffmpeg 03Kaustubh Raste 07master:16adbfe60c35: avcodec/mips: Improve avc chroma horiz mc msa functions [11:15:00 CEST] <horox> Hello, I have a question regarding .mlv video files played with wrong color tint. FFMPEG has support for Magic Lantern .mlv files for quite a while now, but they are all played back with a greenish color tint. I have looked in the bugtracker and have not found an entry for this, should I file a bug? [12:07:43 CEST] <horox> discussion of the problem: https://www.magiclantern.fm/forum/index.php?topic=18392.0 a issue with black level decoding (Green Cast).... [17:13:29 CEST] <Chloe> anyone got a .mod file with a subsong? [17:32:30 CEST] <Chloe> dw I got one. [17:32:38 CEST] <Chloe> Also ffmpeg's ssh key has changed? [17:33:06 CEST] <Chloe> Does SHA256:KVBtJbvfrNcF+McexrkKdLtPNr+37PXjOUnRuGcqwJo look right? [17:47:47 CEST] <nevcairiel> it changed like half a year ago, when did you use it last? [17:48:19 CEST] <Chloe> more than that most likely [17:53:21 CEST] <cone-907> ffmpeg 03Jörn Heusipp 07master:3d2da6d58550: avformat/libopenmpt: Query duration and metadata after selecting subsong [21:57:29 CEST] <cone-929> ffmpeg 03Michael Niedermayer 07master:3dabb9c69db1: avcodec/takdec: Fix integer overflows in decode_subframe() [21:57:29 CEST] <cone-929> ffmpeg 03Michael Niedermayer 07master:4f5eaf0b5956: avcodec/proresdec2: Check bits in DECODE_CODEWORD(), fixes invalid shift [21:57:29 CEST] <cone-929> ffmpeg 03Michael Niedermayer 07master:5d31f03a0264: avcodec/takdec: Fix integer overflow in decode_lpc() [21:57:29 CEST] <cone-929> ffmpeg 03Martin Vignali 07master:45c15b7490cf: libavformat : add mov dataformat tag for HapAlphaOnly and HapQAlpha [21:57:29 CEST] <cone-929> ffmpeg 03Martin Vignali 07master:cab71e4e4e51: libavcodec/hapdec : add support HapAlphaOnly [21:57:29 CEST] <cone-929> ffmpeg 03Paras Chadha 07master:4efb1658f5ab: fate/fits: add missing png & gif dependencies [00:00:00 CEST] --- Mon Sep 25 2017

1 0

ffmpeg.log.20170924
by burek 25 Sep '17

25 Sep '17

[00:21:53 CEST] <brash> Anyone familiar with using ffmpeg api to copy a video stream from one container to another? [00:56:17 CEST] <c3r1c3-Win> brash: hoorible recommendation by me but... if you look at the code in OBS it uses FFMPEG to remux stuff. [00:57:47 CEST] <thebombzen> alternatively, look at the code in ffmpeg.c [00:57:55 CEST] <thebombzen> what it does when you pick -codec copy [01:21:27 CEST] <brash> Those sound like good recommendations. Thanks c3r1c3-Win and thebombzen. [03:12:46 CEST] <kevinn_> Hi, I am using libav to decode frames encoded with x264 and I am wondering how to decrease latency (or what appears to be latency) between the source and destination. I am *fairly* confident that the frames are encoded in such a way that there shouldn't be any latency in the frames (with zerolatency and i_keyint_max=1). Any help would be greatly appreciated! [03:44:43 CEST] <DHE> zero latency means that the old API (avcodec_encode_video2) will return the encoded version of the exact frame put in, and the new API should allow you to alternate between send_frame and receive_packet to the same effect [03:48:35 CEST] <kevinn_> DHE: I am actually using x264 to encode, and yes that is what I have been led to believe is happening. I think there might be something wrong with the way I am decoding (through libav) [03:48:46 CEST] <kevinn_> is there anything special I need to do on the decode end? [03:56:33 CEST] <DHE> I doubt it. zerolatency source material does speed up decoding in the same way as well [04:17:52 CEST] <furq> https://web.archive.org/web/20150507012544/http://x264dev.multimedia.cx/arc… [04:17:55 CEST] <furq> kevinn_: see comment #8 [04:33:30 CEST] <royyuuki> Hi [04:34:00 CEST] <royyuuki> I was advised by your rep in Twitter that I should use IRC to contact you guys for complex discussions. [04:35:23 CEST] <royyuuki> Can someone please send me a PM on how can I read an error log from FFmpeg? I use -xerror to QC all of my video files that I work with, however, the error log only shows the memory address and I dont know how to convert that to a specific TC/frame so I can manually check the problem [09:10:45 CEST] <stunts513> im a bit lost. i just transcoded a live stream to an mp4 and apparently there were some hiccups along the way as i have a 2.3gb mp4 thats a little over 3 min long. [09:11:11 CEST] <stunts513> it keeps trying to seek past that but has issues. any ideas? [10:19:17 CEST] <horox> Hello, I have been using older versions of ffmpeg, where you could click in the video file while it is played and scrub it forward and backward with the mouse, as well as if you clicked at the left edge of the video window, it would be played from the beginning, if you clicked in the middle, it would play from the middle and so on. On recent builds this feature does not work any more, is there a way to reactivate it at compile-time, [10:19:18 CEST] <horox> or is there a flag for it? [10:43:41 CEST] <drv> horox: seeking in ffplay is right mouse button now [11:04:13 CEST] <horox> right. Thanks! [11:05:06 CEST] <horox> I have mouse gestures on right mouse button, so I did not recognize that. [11:09:16 CEST] <horox> I have another question regarding video files played with wrong color tint. FFMPEG has support for Magic Lantern .mlv files for quite a while now, but they are all played back with a greenish color tint - I guess its better to ask that in the ffmpeg-devel channel? [12:00:24 CEST] <royyuuki> 10:35 royyuuki: Can someone please send me a PM on how can I read an error log from FFmpeg? I use -xerror to QC all of my video files that I work with, however, the error log only shows the memory address and I dont know how to convert that to a specific TC/frame so I can manually check the problem [15:25:40 CEST] <nominator> hi, is there any way how to convert MPD files to any other format using ffmpeg? [15:34:51 CEST] <arpu> any one an idea why i get EOF timestamp not reliable always after 31:28:26.06 [15:35:00 CEST] <arpu> http://lpaste.net/742000276633812992 [15:36:08 CEST] <arpu> http://lpaste.net/8267065609548726272 ffmpeg command testsrc [19:35:32 CEST] <faLUCE> Hello. Is it true that for an audio+video mpegts stream, audio and video are already synchronized at the source (---> no need to sync them on the demuxer) because the mpegts muxer uses a common PCR for both the tracks ? [22:02:50 CEST] <azarus> I sometimes record my desktop and I'd like to know what formats are usable. It's an old laptop (Core 2 Duo P8600 to be precise) so not dropping frames is kinda difficult. [22:03:21 CEST] <azarus> I used h264 in the past, is there any viable alternative? [22:03:35 CEST] <azarus> I tried vp8, but it's *way* too slow to encode. [22:10:50 CEST] <Mavrik> azarus, it's usually way better to record into a very fast inefficient format [22:10:53 CEST] <Mavrik> and then reencode [22:11:13 CEST] <azarus> Mavrik: Sure, makes sense. What are some very fast, inefficient formats? [22:11:16 CEST] <Mavrik> Something like losless FFV1, or ultrafast losless H.264 profile [22:11:24 CEST] <Mavrik> *libx264 [22:11:32 CEST] <Mavrik> Yeah, the video will be hugeish (a few 10GB) [22:11:44 CEST] <Mavrik> But then you can encode it at your leisure without worrying about dropped frames [22:12:24 CEST] <azarus> Great, thanks! [22:12:44 CEST] <Mavrik> On ffmpeg wiki there's info on how to do losless H.264 :) [22:12:48 CEST] <Mavrik> FFV1 too probably [22:17:01 CEST] <azarus> Huh, with libx264 I get 26 fps, with FFV1 I get 16. [22:17:31 CEST] <Mavrik> possibly. Did you actually use a fast preset with libx264? [22:19:34 CEST] <azarus> ultrafast. [22:20:48 CEST] <Mavrik> try with huffyuv as well, that was the fastest one. Bad compression tho :) [22:32:53 CEST] <furq> ffvhuff is even faster and should compress better [22:33:07 CEST] <furq> if you don't mind it only being supported by ffmpeg [22:33:42 CEST] <furq> utvideo is also a decent choice if you mostly care about speed [22:33:49 CEST] <furq> ffv1 and x264 lossless will compress much better than either [22:55:10 CEST] <Snaggle> is enable-vda supposed to work on OS X? When I try it, config.log says that its dependencies vda_framework pthreads arent satisfied, but I couldnt find any errors in config.log relating to those two deps. [23:03:00 CEST] <Snaggle> to expand: with ffmpeg-3.3.4, I get audiotoolbox, vda, videotoolbox_hwaccel, and xvmc providing hardware acceleration. But with git HEAD, I need to not-enable-vda for ./configure to finish and then I get no hardware acceleration. [23:10:41 CEST] <Mavrik> Snaggle, afaik VDA is obsolete and nonexistent in new macOS [23:14:40 CEST] <Snaggle> Mavrik: ok, but since Im not on latest-macOS (still on 10.11), and the configure option to disable it still exists, it stands to reason that it _should_ still build on my system, right? [23:14:53 CEST] <Mavrik> Uhh. [23:15:08 CEST] <Mavrik> It's pretty unmaintained tbh. [23:15:13 CEST] <Mavrik> So I guess try with older ffmpeg? [23:18:45 CEST] <Mavrik> Snaggle, you should have videotoolbox available though, is there an issue with that? [23:18:56 CEST] <Snaggle> 3.3.4 configure output shows a whole lot of hwaccels (*_videotoolbox, *_vda, and *_xvmc), but HEAD has lost all of those. Im trying to understand why, or if ffmpeg is still using hwaccel, but just not listing it in the configure output. [23:20:37 CEST] <Snaggle> ugh. I have disable-autodetect in ./configure. too many options to parse them all by eye [23:21:35 CEST] <Snaggle> ok. videotoolbox comes back by fixing that [23:23:06 CEST] <Snaggle> !lart trying to go for deterministic builds and then forgetting how I got there [00:00:00 CEST] --- Mon Sep 25 2017

1 0

ffmpeg-devel.log.20170923
by burek 24 Sep '17

24 Sep '17

[01:47:49 CEST] <atomnuker> last version of the opus psychoacoustic system sent to the ml, will push tomorrow if there are no objections [01:48:01 CEST] <atomnuker> RiCON: ping if you want to test how it sounds [07:20:52 CEST] <cone-030> ffmpeg 03James Almer 07master:bb4b7624d9dd: avformat/apngenc: use av_packet_alloc() [07:20:52 CEST] <cone-030> ffmpeg 03James Almer 07master:afe674734bbe: avformat/gif: use av_packet_alloc() [08:48:55 CEST] <cone-030> ffmpeg 03Jorge Ramirez-Ortiz 07master:1ef7752d64cb: libavcodec: v4l2: add support for v4l2 mem2mem codecs [09:45:28 CEST] <cone-030> ffmpeg 03Rostislav Pehlivanov 07master:2ad1768c7b48: opusenc: implement a psychoacoustic system [14:48:40 CEST] <JEEB> funky [14:51:33 CEST] <JEEB> atomnuker: I think you broke ffserver :D (I only know because it gets built with the default config) [14:52:57 CEST] Action: JEEB adds explicit "disable-ffserver [15:03:54 CEST] <atomnuker> JEEB: I broke it? how? [15:08:04 CEST] <JEEB> I dunno, it just doesn't link :D [15:08:06 CEST] <JEEB> sec [15:10:30 CEST] <nevcairiel> opusenc_psy.c:510: undefined reference to `ff_generate_window_func' [15:10:32 CEST] <nevcairiel> atomnuker: ^ [15:10:40 CEST] <nevcairiel> all of fate is turning red [15:11:21 CEST] <JEEB> yea, I just pointed out that for him :) [15:17:44 CEST] <atomnuker> yeah, I have a fix, testing now [15:22:50 CEST] <atomnuker> durandal_1707: patch ok? https://0x0.st/hBB.patch [15:25:51 CEST] <durandal_1707> atomnuker: switch have one indentation level too much [15:26:47 CEST] <atomnuker> odd, was my text editor, fixed [15:27:45 CEST] <atomnuker> so okay now? [15:27:51 CEST] <nevcairiel> does "simplify dependency" mean "gets rid of"? avcodec can't depend on lavfi, because lavfi already depends on avcodec, circular is trouble [15:28:44 CEST] <atomnuker> I guess [15:28:51 CEST] <atomnuker> I could move it to lavu [15:29:07 CEST] <atomnuker> (since its universally useful) [15:32:40 CEST] <durandal_1707> well whatever you prefer [15:34:46 CEST] <atomnuker> I prefer the way its done currently, until I find another application for it not in lavfi [15:36:13 CEST] <cone-133> ffmpeg 03Rostislav Pehlivanov 07master:039ebaa5f39e: lavfi: make window_func an inline function [17:26:20 CEST] <JEEB> ok, I think I got some stuff backported that is useful [17:26:58 CEST] <JEEB> for some reason our version of movenc utilizes a different time base in the muxer, but otherwise the output seems correct so I'll just update the output of the FATE tests [17:27:31 CEST] <JEEB> - timescale = 30 [17:27:32 CEST] <JEEB> + timescale = 15360 [17:27:45 CEST] <JEEB> why? E_NO_IDEA [17:28:06 CEST] <JEEB> (none of the timescale-related code was changed) [17:29:12 CEST] <JEEB> which just means the +/-1 becomes +/-512 in CTS offsets [17:31:43 CEST] <cs122> Hello! [17:45:12 CEST] <JEEB> alright, posted the back-ports for the negative CTS offset support onto ffmpeg-devel [18:24:45 CEST] <cone-133> ffmpeg 03James Almer 07master:b8eaecbf39a5: avcodec/opusenc_utils: add missing preprocessor guards [18:24:46 CEST] <cone-133> ffmpeg 03James Almer 07master:e4fd7b1fea7e: avcodec/opusenc_psy: use av_clip_uintp2() [18:40:31 CEST] <cs122> The android bionic libc defines B0 on termbits.h, and ffmpeg libavcodec uses some variables with B0 in its name, which gets renamed by the preprocessor expansion. [18:41:38 CEST] <cs122> This leads to build errors that can be fixed, amongst other ways, by renaming those variables by replacing B0 with B_0 or another similar name [18:41:52 CEST] <cs122> However I don't know if this is the way to go. [19:22:50 CEST] <cone-133> ffmpeg 03Marton Balint 07master:7f80b065a626: avformat/mxfdec: factorize packet pts setter function [19:22:51 CEST] <cone-133> ffmpeg 03Marton Balint 07master:01911b9b3cad: avformat/mxfdec: use the common packet pts setter function for opatom files [21:20:57 CEST] <cone-133> ffmpeg 03Thomas Mundt 07master:58ca446672fe: avfilter/tinterlace: use drawutils for pad mode [21:20:58 CEST] <cone-133> ffmpeg 03Thomas Mundt 07master:40bfaa190c61: avfilter/interlace: add support for 10 and 12 bit [22:53:35 CEST] <cone-133> ffmpeg 03James Almer 07master:015f976aaee5: avcodec/frame_thread_encoder: use av_packet_alloc() [23:14:21 CEST] <cone-133> ffmpeg 03James Almer 07master:ff7f859c2595: avcodec/Makefile: skip v4l2_m2m headers if needed [23:14:22 CEST] <cone-133> ffmpeg 03James Almer 07master:d1e7e4fbe2b0: avcodec/v4l2_m2m: add missing header inclusions [23:46:21 CEST] <brash> What do 'starting new cluster due to timestamp' info messages mean? Specifically, I am reading with av_read_frame into a packet, and then using av_copy_packet into a new packet using av_write_frame to write the packet. [23:59:23 CEST] <jamrial> brash: that's a matroska mxuer log message, and it probably means something may be wrong with your packet timestamps [00:00:00 CEST] --- Sun Sep 24 2017

1 0

ffmpeg.log.20170923
by burek 24 Sep '17

24 Sep '17

[00:03:41 CEST] <martyrs> guys thanks for the help [00:04:15 CEST] <martyrs> now i need to process 700+ video files without killing my server cpu1 [00:11:46 CEST] <sabusanta> Outsource to the cloud [00:14:57 CEST] <sabusanta> alexpigment: you were right about them comments. good tip [00:14:57 CEST] <martyrs> sabusanta: pricey [00:15:48 CEST] <alexpigment> sabusanta: glad to hear it :) I've been checking the site every day since the early 2000s - when I actually listened to the music they covered. I get the distinct impression that everyone who comments is in the same boat [00:15:51 CEST] <Sebas_> limit threads to half your cores? [00:16:13 CEST] <sabusanta> martyrs: maybe. I guess if you factor in burning your CPU, electricity costs, time, and cooling might even out [00:16:19 CEST] <sabusanta> or under [00:16:52 CEST] <sabusanta> alexpigment: Nu-metal will always have a place in my heart tho. my teenage angst heart \ [00:18:18 CEST] <alexpigment> I can relate [00:18:44 CEST] <alexpigment> they also cover Deftones constantly on that site, which is always good imho [00:25:31 CEST] <furq> https://www.youtube.com/watch?v=7W6dDqEksKc [00:25:33 CEST] <furq> what do u think [00:32:04 CEST] <thebombzen> BtbN: it's 10-bit [00:33:11 CEST] <thebombzen> I'm not sure if it's a bug in lavc's hevc_cuvid or if it's someone else's fault [00:33:31 CEST] <thebombzen> FWIW, the sample is here: http://0x0.st/vfK.mp4 [00:53:08 CEST] <lindylex> I am using this https://pastebin.com/RuhupF49 to place to videos side by side. I want to place a black line on top the video. This can be a black video dynamically created with the width of 2 pixel and height of 720. Or it can be a black image. Any suggestions on how to do this? [03:20:16 CEST] <AndrewMock> I want to mix 5.1 to stereo WITH LFE. Can't find an ideal way online. [03:21:20 CEST] <AndrewMock> the stereo will go through a crossover. but i want prevent a bassy mix. can't find a good matrix [03:35:07 CEST] <kepstin> the trick you have to know is that in most 5.1 systems, the sub channel is actually stored at a different gain from the other channels [03:35:15 CEST] <kepstin> so you have to adjust that when mixing it [03:37:20 CEST] <kepstin> although iirc the lfe is usually stored 10dB *quieter* than the other tracks, so mixing it straight in shouldn't normally make stuff be "too bassy" [03:40:16 CEST] <kepstin> I'd expect simply centre-panning it into a stereo mix shouldn't be unreasonable, plus or minus some gain to taste. [03:45:22 CEST] <AndrewMock> it'll pass thru a live sound console on its way out. i'll tell the engineer to EQ to taste. thx. [05:06:16 CEST] <lindylex> I am using this https://pastebin.com/RuhupF49 to place to videos side by side. I want to place a black line on top the video. This can be a black video dynamically created with the width of 2 pixel and height of 720. Or it can be a black image. Any suggestions on how to do this? [12:09:17 CEST] <kubast2> Hey how can I read a font style used in softsub? When I cut a video the font style of softsubs seems to change [12:28:49 CEST] <c_14> kubast2: ass? [12:28:53 CEST] <c_14> output it and open in a text editor? [12:31:08 CEST] <kubast2> yeah I see now thx [13:24:48 CEST] <norbert> hi, I'm transcoding DOSBox AVI to MP4 for usage in kdenlive 720p 60fps, using: ./ffmpeg -r 70.086 -i in.avi -vf "scale=1152:720,pad=1280:720:64:0:black" -b 4000k -ab 160k -r 60 -acodec libvo_aacenc out.mp4 [13:25:42 CEST] <norbert> in the project bin (clips overview) of kdenlive, when I click the MP4 and play it, it plays in its entirety, but when I move the clip onto a track it only plays and shows about 2/3 of the clip [13:26:34 CEST] <norbert> while this might primarily be a kdenlive issue, I'm wondering if anyone here has a suggestion how I could transcode the clip differently to make it more likely that kdenlive will properly display/play the clip inside one of its tracks? [13:54:44 CEST] <norbert> nobody? [14:07:03 CEST] <blap> hi [14:48:03 CEST] <Sharkigator> i want to encode a video with h.264 and preserve true black [14:48:19 CEST] <Sharkigator> when i encode it with libx264 it becomes gray [14:48:38 CEST] <Sharkigator> but with libx264rgb it keeps it [14:49:06 CEST] <Sharkigator> but is there another way, without using the rgb color format? [14:53:05 CEST] <c_14> you can try encoding yuv444p [14:53:18 CEST] <c_14> or using the zscale filter to do the color conversion [14:54:26 CEST] <Mavrik> hmm [14:54:36 CEST] <Mavrik> Sounds like HDMI black level issue? [14:54:47 CEST] <Mavrik> It encodes to 14-255 range? [15:04:09 CEST] <Sharkigator> yuv444p still makes it gray [15:05:19 CEST] <utack> are you sure the ENcoding is wrong, not the hardware decoder used for playback? some gpus like to mess things up or do odd processing. have you decoded a frame to something like png again with ffmpeg and looked at it in a image tool [15:05:41 CEST] <utack> my old amd card had some post processing by default that did this for example [15:05:53 CEST] <Sharkigator> i'm looking at it with vlc [15:06:09 CEST] <Sharkigator> but i'll try [15:06:44 CEST] <utack> probably not the issue wehn other videos in that format look ok, but it is easy enough to exclude as potential problem [15:07:45 CEST] <Sharkigator> well, the .pngs look fine [15:10:59 CEST] <Sharkigator> but vlc says hardware acceleration is disabled [15:11:30 CEST] <Mavrik> Sharkigator, can you pastebin ffmpeg output for the encode? [15:15:58 CEST] <Sharkigator> Mavrik <https://pastebin.com/Fn38Y8sp> [15:17:04 CEST] <Mavrik> Sharkigator, can you do -pixfmt yuvj444p ? [15:17:27 CEST] <Mavrik> I'm 90% sure that yuv444p implies HDMI black levels where "black" is actually "14" color value instead of "0" [15:18:03 CEST] <Sharkigator> still gray [15:18:35 CEST] <Mavrik> *shrug* Out of ideas then :) [15:18:48 CEST] <Sharkigator> but it also says [swscaler @ 00000000026b9fe0] deprecated pixel format used, make sure you did set range correctly [15:20:03 CEST] <Sharkigator> hm, thank you though [15:21:43 CEST] <Mavrik> Yeah, I'm still thinking it's a color range isse [15:21:55 CEST] <Mavrik> But the fact that you have a funny input format means that it can be anything :/ [15:24:41 CEST] <Sharkigator> unrelated: when i try to set the profile option, it always says the profile is not supported [15:25:02 CEST] <Sharkigator> [libx264 @ 00000000001ec740] Error setting profile main. [15:25:02 CEST] <Sharkigator> [libx264 @ 00000000001ec740] Possible profiles: baseline main high high10 high422 high444 [15:29:51 CEST] <Mavrik> IIRC you can't have 4:4:4 in main profile [15:31:11 CEST] <Sharkigator> i don't set the pixel format, shouldn't it choose a correct one? [15:31:27 CEST] <furq> it'll pick 4:4:4 if the input is rgb [15:32:27 CEST] <furq> you can try -pix_fmt yuvj420p [15:32:38 CEST] <furq> that's not an ideal solution but it'll at least tell you if it's a full/limited range issue [15:32:57 CEST] <Sharkigator> btw, sorry, i just found another checkbox in vlc... "use hardware yuv->rgb conversions" [15:33:07 CEST] <Sharkigator> not it is actual black... [15:33:11 CEST] <Sharkigator> *now [15:33:14 CEST] <furq> oh [15:33:15 CEST] <furq> fun [15:34:04 CEST] <Mavrik> hmm, fun :) [15:36:22 CEST] <furq> on which note, how does one actually do rgb to yuv with zscale [15:36:32 CEST] <furq> every time i've tried it i get "no path between colorspaces" [15:37:07 CEST] <furq> i assume i need to set the input primaries and whatnot but idk what those should be for a screen capture [18:55:58 CEST] <thebombzen> when I use ffmpeg -f x11grab to grab the screen, the Y offset isn't working correctly [18:56:57 CEST] <thebombzen> if I use: ffmpeg -f x11grab -video_size 1280x720 -i :0.0+320+180, the area it grabs is indeed 1280x720, but it starts at X=320 and Y=0, not X=320 and Y=180 [18:57:12 CEST] <thebombzen> I believe this is a bug [18:57:16 CEST] <c_14> use , instead of the second + [18:57:49 CEST] <thebombzen> oh thanks [18:57:53 CEST] <thebombzen> did that change? :O [18:57:58 CEST] <c_14> it's always been that way? [18:58:21 CEST] <thebombzen> weird [18:58:27 CEST] <thebombzen> I swear I remember doing it the other way /shrug [18:58:56 CEST] <thebombzen> hm, the docs agree with you. idk wow [19:11:04 CEST] <rjp421> furq, JEEB, my pi's sdcard went belly up while rebuilding the /opt/vc.... i was not able to test the raspivid piped to ffmpeg-git... hopefully someone else can, i would like to know if it still works [19:24:13 CEST] <faLUCE> 1) in a mpegts audio+video stream is the PCR necessary to sync audio and video? 2) should the PCR be sent on the first PES of the stream? [19:24:18 CEST] <faLUCE> (hello) [19:25:10 CEST] <rjp421> anyone with a pi and pi-cam, and updated packages+kernel+ffmpeg-git: can you please test piping raspivid to ffprobe or ffmpeg? confirm whether or not ffmpeg crashes [19:26:10 CEST] <Mavrik> faLUCE, PCR is pretty much critical for any player yeah [19:26:19 CEST] <Mavrik> a lot of them sync on it [19:27:12 CEST] <faLUCE> Mavrik: do the players sync on it when the stream is audio+video or even audio or video only? [19:27:28 CEST] <Mavrik> It's pretty much the input mux that does it [19:27:33 CEST] <Mavrik> Which doesn't care about the content yet :) [19:27:40 CEST] <Mavrik> In other words: [19:27:51 CEST] <Mavrik> Without valid PCR you might have a really bad time playing back your stream. [19:28:27 CEST] <faLUCE> Mavrik: but my question was different [19:31:06 CEST] <faLUCE> [19:27] <faLUCE> Mavrik: do the players sync on it when the stream is audio+video or even audio or video only? [19:31:49 CEST] <Mavrik> And I told you it doesn't matter what is inside the stream. [19:31:54 CEST] <Mavrik> Meaning "on all". [19:34:21 CEST] <faLUCE> Mavrik: I'm not sure you are right. It seems for example that gstreamer uses it as offset for syncing audio and video. But for audio/video only, it uses the first useful frame as offset. [19:34:57 CEST] <Mavrik> Hence the word *might have a bad time* [19:35:13 CEST] <Mavrik> I'm sure there are players that will attempt to play broken TS streams anyway. [19:35:18 CEST] <Mavrik> I guarantee you there are players that will not. [19:35:40 CEST] <Mavrik> TS stream needs a PCR on container level no matter what's in it. [19:36:11 CEST] <Mavrik> Without it, your stream might still play (especially in software players) [19:36:25 CEST] <Mavrik> But certanly not on all players and sync miight be completely off as well [19:36:47 CEST] <faLUCE> let's ask in another way. If I have a video-only stream, I don't need the PCR for the FIRST frame, in order to START PLAYING the stream. But I need the PCR in order to start playing an audio+video stream, right? [19:39:00 CEST] <faLUCE> Mavrik: in other words, given what you said: is it true that the PCR is necessary 1) for syncing audio and video AND 2) for having good timestamps on all the elementary streams ? [19:44:57 CEST] <Mavrik> faLUCE, yes and yes :) [19:45:16 CEST] <Mavrik> and you'll probably need PCR on some players for video-only stream as well [19:49:27 CEST] <faLUCE> Mavrik: sorry, had connection problem: [19:49:35 CEST] <faLUCE> [19:36] <faLUCE> let's ask in another way. If I have a video-only stream, I don't need the PCR for the FIRST frame, in order to START PLAYING the stream. But I need the PCR in order to start playing an audio+video stream, right? [19:49:42 CEST] <faLUCE> [19:39] <faLUCE> Mavrik: in other words, given what you said: is it true that the PCR is necessary 1) for syncing audio and video AND 2) for having good timestamps on all the elementary streams ? [21:59:25 CEST] <dviola> hi [21:59:47 CEST] <dviola> I want to increase the audio volume of a video (re-encoding the audio) but without re-encoding the video itself, how can I do this? [22:00:15 CEST] <dviola> more like normalize the audio [22:02:12 CEST] <Mavrik> pass -codec:v copy [22:02:16 CEST] <Mavrik> which will just copy video stream [22:02:24 CEST] <Mavrik> and set audio filters / encoding parameters as usual [22:03:28 CEST] <dviola> I see, thanks [22:08:29 CEST] <dviola> -filter:a "volume=20dB" [22:08:34 CEST] <dviola> would something like that work? [22:10:04 CEST] <dviola> there's also -filter:a loudnorm -- not sure which one I should use [22:12:07 CEST] <dviola> "Loudness Normalization (loudnorm): This is recommended for most applications, as it will lead to a more uniform loudness level compared to simple peak-based normalization." [22:12:10 CEST] <dviola> I guess this is what I need [23:42:30 CEST] <molecman> hi i am not sure of function of file used in feed section (just a buffer ?) so why not use memory with /dev/shm instead of /tmp ? [00:00:00 CEST] --- Sun Sep 24 2017

1 0

ffmpeg-devel.log.20170922
by burek 23 Sep '17

23 Sep '17

[01:45:16 CEST] <cone-234> ffmpeg 03Carl Eugen Hoyos 07master:724cf83f1000: Remove some unneeded casts of bit_rate. [02:25:33 CEST] <cone-234> ffmpeg 03Lou Logan 07master:183fd30e0f6f: Fix several typos [03:56:51 CEST] <newbie1> hello, I have an H264 stream (a collection of raw NAL units) that I pump into FFmpeg to decode video. The problem is that FFmpeg avcodec_receive_frame() is returning ONLY 1rd of the decoded resolution. [03:57:35 CEST] <newbie1> on the other hand, if I pump the NALs into av_parser_parse2() then the decoded frame returned by avcodec_receive_frame() is 100% of the frame. [03:58:55 CEST] <newbie1> It seems like a bug in either FFmpeg or some flag isn't set, but I get no decoding errors so I can't tell why decoding doesn't work with this sequence "avcodec_send_packet, avcodec_receive_frame" but works with this sequence "av_parser_parse2,avcodec_send_packet, avcodec_receive_frame" [04:00:54 CEST] <newbie1> This sort of problem only seems to happen when H264 stream has a group of few consecutive IDR frames in a row (instead of the usual single IDR every few second) [04:20:20 CEST] <newbie1> Is it required to call av_parser_parse2()? It seems like with the stream I have I cannot just use avcodec_send_packet()/avcodec_receive_frame() as I get partially decoded images (again no errors in logs). [04:23:25 CEST] <wm4> newbie1: yes, ffmpeg expects 1 frame per packet [04:23:36 CEST] <wm4> and the parser can take care of that [04:24:10 CEST] <newbie1> I have tried splitting the NALs and feeding 00 00 00 01 NAL into the avcodec_send_packet() one at a time, still doesn't work [04:24:38 CEST] <newbie1> like I said with most H264 streams I've seen it works fine, it's this stream that contains group of IDRs that decoding seems to silently fail. [04:24:58 CEST] <newbie1> Is there any flags or options I can explore? [04:25:52 CEST] <wm4> does ffmpeg's raw h264 demuxer with ffmpeg cli eat the stream? [04:26:43 CEST] <newbie1> not sure if I understand that fully. If I pipe the data into FFmepg.exe it works (I suspect because behind the scene it uses parser2) [04:27:23 CEST] <newbie1> so I know that the data is good and it's all there...the problem seems to be the way it's fed into decoder via send packet and receive frame [04:27:37 CEST] <newbie1> I've tested this with FFmepg 3.3.x latest release [04:27:56 CEST] <wm4> so use the parser [04:28:35 CEST] <newbie1> well, the documentation doesn't mention to use parser...also I'm concerned parse is doing extra work such as memcpy etc [04:34:02 CEST] <wm4> yes it will [04:34:25 CEST] <newbie1> ? [04:34:34 CEST] <wm4> it'll do memcpy [04:34:47 CEST] <wm4> even if the docs don't mention it, 1 frame per packet is required [04:35:45 CEST] <newbie1> "1 frame per packet", does that mean the NALs need to be assembled into "1 frame' before calling avcodec_send_packet()?? [04:36:16 CEST] <rcombs> yes, and the parser will do that [04:36:27 CEST] <rcombs> memcpy on coded data is cheap; don't worry about it [04:36:56 CEST] <wm4> typically you only need to "cut" the stream on boundaries between the required slice NALs [04:37:13 CEST] <newbie1> understood. Should I file a bug since avcodec_receive_frame() returns okay but the decoded frame is partial. [04:37:18 CEST] <wm4> since you need padded and aligned packets, you probably need to do memcpy on some level anyway [04:37:26 CEST] <wm4> no [04:38:41 CEST] <newbie1> is there existing function that can "cut" the stream on boundaries? My input is a start_code data start_code data .... [04:41:08 CEST] <wm4> well, the parser [04:41:16 CEST] <newbie1> :) I figured you'd say that [04:43:08 CEST] <newbie1> should we update documentation to say use parser https://www.ffmpeg.org/doxygen/3.2/group__lavc__encdec.html [04:43:36 CEST] <newbie1> There is no mentioning of parser in "send/receive encoding and decoding API overview" [04:44:23 CEST] <newbie1> I think this change has come to be when the send/recv functions were introduced as part of the new API [04:49:25 CEST] <rcombs> did the docs for the old API mention that? (the old API also required correctly-split packets IIRC) [04:49:29 CEST] <rcombs> either way, yeah, it'd be good to mention [04:52:59 CEST] <wm4> we can't really document the exact requirements for each codecs in the doxygen [04:53:12 CEST] <wm4> that would blow up quickly [04:53:31 CEST] <wm4> maybe per-codec external docs (like with for private options), but nobody reads those [05:00:04 CEST] <wm4> jkqxz: can you ACK or NACK the v4l patch? [05:00:14 CEST] <rcombs> wm4: why not just say you need to use the parser if one's available [05:01:55 CEST] <wm4> that would be a bit too strong [08:42:37 CEST] <liyou> hi [08:43:04 CEST] <liyou> does ffmpeg run slowly? [08:50:06 CEST] <wm4> no, it's super fast [08:54:41 CEST] <liyou> why do you say that [08:56:27 CEST] <wm4> because it's the Truth(tm)(C) [09:45:25 CEST] <nevcairiel> your very generic question can only get very generic answers. In some areas its the fastest solution available anywhere, some other areas could probably use enhancements [10:42:40 CEST] <BtbN> Why do people randomly E-Mail me to push their patch? It's not in any code I maintain, nor in an area I have any experience with. [10:45:34 CEST] <wm4> it only takes 1 or 2 people who know you to lose faith in humanity [10:45:47 CEST] <wm4> (worst case) [10:48:03 CEST] <rcombs> huh, I don't get those [10:48:11 CEST] <rcombs> don't tell them I have push access, I guess [10:48:13 CEST] <nevcairiel> me neither [10:48:33 CEST] <BtbN> I get at least one or two mails a month asking me about random patches [10:48:47 CEST] <BtbN> I usually ignore them, unless it's nvenc/cuda related [10:48:48 CEST] <rcombs> wm4: also wait nononono it's not "super fast" [10:48:49 CEST] <rcombs> it's a [10:48:50 CEST] <rcombs> Hyper fast Audio and Video encoder [10:48:54 CEST] <atomnuker> rcombs: flac imagecover patch v4 or whatever pll0x [10:48:57 CEST] <wm4> right, hyper fast [10:49:06 CEST] <rcombs> atomnuker: I need sleep [10:49:16 CEST] <rcombs> remind me in like 32400 seconds [10:49:25 CEST] <wm4> (there was even a patch to remove "hyper fast" because someone contended the speed) [10:49:42 CEST] <rcombs> lol [10:50:04 CEST] <rcombs> how do you get git to generate patch version numbers anyway [10:50:10 CEST] <rcombs> in send-email [10:50:47 CEST] <wm4> -v3 [10:53:41 CEST] <atomnuker> rcombs: --subject-prefix="PATCH v3" in format-patch [10:54:17 CEST] <nevcairiel> using -v seems easier [10:54:28 CEST] <rcombs> TIL about -v [10:54:36 CEST] <rcombs> also that arbitrary format-patch args work for send-email [10:54:47 CEST] <nevcairiel> yeah it passes whatever it doesnt handle itself to format-patch [10:54:49 CEST] <nevcairiel> which is kinda handy [10:55:17 CEST] <wm4> sometimes order seems to matter too [10:55:20 CEST] <wm4> rather confusing [10:56:51 CEST] <atomnuker> huh, I didn't know about -vN either [10:57:18 CEST] <wm4> it's well-hidden [10:57:33 CEST] <wm4> <insert git manpage generator joke link> [10:58:28 CEST] <nevcairiel> its just there in the man page [11:24:18 CEST] <thardin> msbuild is such a joke [11:42:11 CEST] <ubitux> the fuck is this export_all shit [11:42:30 CEST] <mateo`> a bit of context: mov.c [11:43:31 CEST] <nevcairiel> some people beleive that allocating all metadata that one might not read is super wasteful, so they need to save a few bytes [11:43:58 CEST] <JEEB> mateo`: btw have you seen crashes inside stagefright? [11:44:24 CEST] <JEEB> like http://up-cat.net/p/82b841eb [11:44:25 CEST] <ubitux> nevcairiel: it's exporting binary as string [11:44:37 CEST] <ubitux> null terminated randomly [11:44:39 CEST] <ubitux> it makes no sense [11:44:45 CEST] <ubitux> CAME : «xs9?>1 ">Î;(Ø©¬ [11:44:48 CEST] <ubitux> SETT : Ç [11:44:52 CEST] <ubitux> MUID : «xs9?>1 ">Î;(Ø©¬?·QI [11:44:55 CEST] <ubitux> GUMI : éß-?Ü|ÙF:Ç©n"Üx [11:44:58 CEST] <ubitux> wth... [11:45:35 CEST] <mateo`> we'd like to export a list (defined by the user) of udta atoms as side data [11:45:38 CEST] <wm4> ubitux: ih what's that [11:45:41 CEST] <wm4> *uh [11:45:46 CEST] <ubitux> -export_all in mov demuxer [11:45:46 CEST] <mateo`> or something that can be exposed to the user [11:45:51 CEST] <mateo`> and remuxed [11:46:14 CEST] <mateo`> not binary in strings [11:46:15 CEST] <wm4> oh referring to the fact that we export random atoms as tags [11:46:25 CEST] <wm4> I hate that [11:46:29 CEST] <ubitux> yes [11:46:32 CEST] <ubitux> all of them are broken [11:46:35 CEST] <ubitux> it's in a string [11:46:36 CEST] <wm4> it just makes random shit end up in remuxed files [11:46:46 CEST] <wm4> where it has nothing lost [11:47:02 CEST] <wm4> s/nothing lost/no business/ [11:47:15 CEST] <mateo`> JEEB: I did not had this crash [11:47:41 CEST] <JEEB> some samsung devices seem to have this sometimes [11:47:43 CEST] <ubitux> we don't have side data for AVFormatContext? [11:48:02 CEST] <mateo`> JEEB: using the ffmpeg wrapper I guess ? [11:48:09 CEST] <nevcairiel> ubitux: no, its either stream or codec [11:48:31 CEST] <ubitux> or packet or frame [11:48:39 CEST] <ubitux> can we add it to formats? [11:48:50 CEST] <nevcairiel> i dont really see the usecase [11:48:57 CEST] <ubitux> exporting these udta [11:49:08 CEST] <mateo`> (using a whitelist provided by the user) [11:49:24 CEST] <nevcairiel> sounds like something extremely specific thats not going to be of use anywhere else, tbh [11:49:41 CEST] <ubitux> pretty sure mov isn't the only format to store random binary user data [11:50:15 CEST] <mateo`> JEEB: do you have a way to reproduce the crash ? [11:50:19 CEST] <JEEB> nope :D [11:50:22 CEST] <wm4> ubitux: obviously export it as hex LOL [11:50:29 CEST] <mateo`> wm4: NO NO NO [11:50:33 CEST] <ubitux> yeah %08x in metadata tags [11:50:35 CEST] <ubitux> let's do this [11:50:43 CEST] <JEEB> I just see the 1-2% of users having that (Ž4@) [11:50:45 CEST] Action: wm4 gets his axe ready [11:50:48 CEST] <ubitux> :) [11:50:48 CEST] <wm4> think carefully! [11:50:58 CEST] <ubitux> i'll go for format side data [11:51:03 CEST] <wm4> what's udta? [11:51:05 CEST] <ubitux> and make export_all do that [11:51:08 CEST] <ubitux> "user data" [11:51:18 CEST] <wm4> so just untyped...? [11:51:23 CEST] <nevcairiel> random undefined unspecified data [11:51:27 CEST] <wm4> pairs of name + binary data? [11:51:32 CEST] <ubitux> all kind of binary atoms [11:51:55 CEST] <ubitux> http://sprunge.us/NCdj [11:52:01 CEST] <wm4> could it be made an AVStream? (though that sounds like something that could be regretted later) [11:52:04 CEST] <nevcairiel> typically it contains text tags [11:52:10 CEST] <nevcairiel> which we read into metadata [11:52:16 CEST] <nevcairiel> but i guess some people shove random shit in there [11:52:22 CEST] <ubitux> wm4: no, it's on the format [11:52:54 CEST] <wm4> if you do it as side data, can we have a proper concept + reuseable implementation, instead of duplicating the buggy crap we have everywhere else? [11:53:18 CEST] <wm4> like, say, have struct AVSideDataList, which could be reused elsewhere [11:54:05 CEST] <mateo`> sounds like a good idea [12:03:24 CEST] <cone-493> ffmpeg 03Yogender Gupta 07master:21e077fcb3d9: avfilter/thumbnail_cuda: add cuda thumbnail filter [12:20:48 CEST] <cone-493> ffmpeg 03Kaustubh Raste 07master:2b1562699749: avcodec/mips: preload data in hevc sao edge 90 degree filter msa functions [12:20:49 CEST] <cone-493> ffmpeg 03Kaustubh Raste 07master:f160a63badfc: avcodec/mips: Remove generic func use in hevc non-uni copy mc msa functions [12:20:50 CEST] <cone-493> ffmpeg 03Michael Niedermayer 07master:2c933c51687d: avcodec/svq3: Fix overflow in svq3_add_idct_c() [12:20:51 CEST] <cone-493> ffmpeg 03Michael Niedermayer 07master:d00fc952b6c2: avcodec/ffv1dec: Fix integer overflow in read_quant_table() [12:20:52 CEST] <cone-493> ffmpeg 03Michael Niedermayer 07master:67da2685e038: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_FIDELITYi*() [14:18:33 CEST] <durandal_1707> BtbN: what patches? [14:19:35 CEST] <BtbN> https://patchwork.ffmpeg.org/patch/2221/ in this case [14:20:11 CEST] <BtbN> Someone should finally fix that certificate [16:37:13 CEST] <sangy> Hello, I noticed that there are two CVE's fixed on ffmpeg but not on ffmpeg2.8. (These are CVE-2017-14223 and -14222). Are there any plans on fixing it ? [17:30:13 CEST] <BtbN> Are you sure 2.8 is even affected? [17:33:03 CEST] <sangy> BtbN: we checked the vulnerable code areas on monday. I think they are there [17:33:22 CEST] <BtbN> Can always just try to apply the patch [17:33:29 CEST] <nevcairiel> those CVEs arent even real vulnerabilities [17:35:59 CEST] <sangy> I imagine, I think one of the patches would be harder to apply because some of the code was refactored to a diff-module [17:36:21 CEST] <sangy> nevcairiel: can you elaborate please? [17:39:14 CEST] <jamrial> oh god, an swscale patch with intrinsics [18:44:21 CEST] <atomnuker> rcombs: reminding you after 9 hours [00:00:00 CEST] --- Sat Sep 23 2017

1 0

ffmpeg.log.20170922
by burek 23 Sep '17

23 Sep '17

[00:00:14 CEST] <Johnjay> I've almost got my setup to convert youtube->mp3 finalized. I just need a way to click a link in the browser [00:00:21 CEST] <Johnjay> and automatically get youtube-dl and ffmpeg to go to work on it [00:00:28 CEST] <Johnjay> on a windows box if that wasn't clear [00:00:55 CEST] <Johnjay> unless there's some other way i'll have to resort to autohotkey [00:01:20 CEST] <rjp421> afaik raspivid isnt *necessary*, now that ffmpeg has h264_omx.. but last i checked i cant h/vflip without raspivid [00:02:39 CEST] <furq> there might be a way to force the pi cam to give you rawvideo [00:02:55 CEST] <furq> in which case you can just hflip/vflip as you normally would with ffmpeg and then encode it from there [00:03:01 CEST] <furq> that might be slower though [00:03:08 CEST] <Johnjay> what's the difference between raspivid and rawvideo? [00:03:24 CEST] <furq> raspivid outputs h264 iirc [00:03:36 CEST] <furq> but it uses the encoder chip on the pi, which ffmpeg can use [00:04:15 CEST] <Johnjay> i see [00:04:41 CEST] <furq> rjp421: try -f rawvideo or -c:v rawvideo before -i [00:04:51 CEST] <furq> and -i /dev/video0 or whatever instead of piping [00:05:04 CEST] <furq> it's probably -c:v rawvideo -f v4l2 -i /dev/video0 [00:05:39 CEST] <rjp421> furq, how does raspivid do the h/vflip before encoding? can ffmpeg copy its process? [00:05:47 CEST] <furq> i have no idea [00:06:09 CEST] <furq> if it's something built into vc then ffmpeg will be slower [00:06:23 CEST] <furq> but i don't think it's a very slow operation really [00:06:30 CEST] <furq> it's worth a try anyway [00:10:33 CEST] <thebombzen> hflip and vflip are very fast [00:11:28 CEST] <thebombzen> vflip especially because memcpy [00:25:18 CEST] <kerio> furq: did you just say "might" [00:25:21 CEST] <kerio> it's HELLA SLOW [00:25:31 CEST] <kerio> copying raw crap from and to the videocore [00:28:29 CEST] <SavinaRoja> is there a non web-based dash segment validator, the official one seems to be unresponsive and the dash muxer output i'm producing appears to be nonconformant in the segments [00:31:32 CEST] <matteo> hi all [00:31:34 CEST] <matteo> ffmpeg -y -video_size 256x144 -framerate 25 -f x11grab -i :0.0+0,0 -c:v ffvhuff ppp.avi [00:31:38 CEST] <matteo> what's wrong in this grab command? [00:31:43 CEST] <matteo> it only grabs 34 frames [00:40:56 CEST] <llogan> did you press "q"? [00:41:28 CEST] <llogan> command looks ok [00:41:37 CEST] <llogan> console output looks blank [00:43:30 CEST] <llogan> guess he pressed "q" [04:44:25 CEST] <chocolate-elvis> anyone having issues encoding files from FCP X? getting lookahead errors when encoding. [04:44:56 CEST] <chocolate-elvis> from H264 mov files exported from FCP 10.3.4 [09:37:54 CEST] <lindylex> I am using this to place to videos side by side : ffmpeg -i c4.mov -i c5.mov -filter_complex "[0:v]setpts=PTS-STARTPTS, pad=iw*2:ih[bg]; [1:v]setpts=PTS-STARTPTS[fg]; [bg][fg]overlay=w; [0:a][1:a]amix" -y t.mp4 I want to add a black border between the two videos. I tired adding the following pad=iw+1:ih:0:0 . It add a border to the video on the right. This make sense because the filter complex treats the video as one large video. [10:09:33 CEST] <Gaulois94> Hello [10:11:37 CEST] <Gaulois94> Hum, I may have a problem about sending an encoded frame... Here is the code, with the main loop : https://pastebin.com/aeF3Ea9b [10:12:07 CEST] <Gaulois94> I don't know why, vlc can't read the full stream. Though, it detects images and can draw them each time I open the file [10:22:19 CEST] <Gaulois94> Sorry, wrong file version : https://pastebin.com/k5ACACGV [17:25:32 CEST] <Johnjay> I'm amazed I was able to tweak the windows cmd box [17:25:43 CEST] <Johnjay> so I can just type "mp3 <filename>" and have ffmpeg convert it to mp3 [17:32:08 CEST] <Diag> yes [17:32:10 CEST] <Diag> windows is good [17:32:39 CEST] <iLoveWindows> very very good [17:35:06 CEST] <Johnjay> lol [17:35:13 CEST] <Johnjay> I detect some sarcasm here [17:39:08 CEST] <Diag> nah windows is the shit [17:39:22 CEST] <Diag> I do like da terminal on *nix [17:39:23 CEST] <Diag> but [18:17:11 CEST] <blap> good for whom? [18:18:31 CEST] <Johnjay> is there an ffmpeg filter that rotates a file by time t? [18:18:41 CEST] <Johnjay> i.e. takes the first t seconds and cuts it to the end? [18:19:34 CEST] <squirrel> hi. i've got an old-ish tv that supports this https://fluf.cf/s/xi4gqj1502 , and the following avi is not playing on it https://fluf.cf/s/ze67sukjz4 , saying something about drm [18:19:55 CEST] <squirrel> can i somehow verify that the file has some drm in it? [18:20:29 CEST] <squirrel> it plays on my computer just fine [18:34:27 CEST] <relaxed> squirrel: pastebin.com the output of ffmpeg -i file [18:35:23 CEST] <squirrel> relaxed: https://fluf.cf/p/xqf11x69ah [18:37:28 CEST] <relaxed> pal or ntsc? [18:38:05 CEST] <CoreX> its pal file [18:38:06 CEST] <CoreX> 25 fps, 25 tbr, 25 tbn, 30k tbc [18:38:20 CEST] <relaxed> er, this is an hdtv ? [18:39:07 CEST] <squirrel> well, it's the usual full hd resolution tv [18:39:17 CEST] <squirrel> some obscure uk brand named jmb [18:40:51 CEST] <squirrel> i did $ ffmpeg -i input.avi output.avi (just this, no other options), and now the tv plays the file. but the picture is very distorted [18:41:31 CEST] <squirrel> well, not ditorted.. [18:42:13 CEST] <squirrel> that's how it looks now https://fluf.cf/s/cxn749axbv [18:43:13 CEST] <relaxed> try, ffmpeg -i input.avi -c:v mpeg4 -q:v 2 -c:a libmp3lame -b:a 192k -ac 2 -vtag XVID output.avi [18:44:06 CEST] <squirrel> will try, brb [18:44:42 CEST] <Johnjay> -vol says that 256 is normal audio. i wonder if i understood mp3 if that would make more sense [18:53:08 CEST] <squirrel> relaxed: works like a charm, thanks a bunch! e [18:53:33 CEST] <squirrel> i'll investigate the parameters that you used [18:55:35 CEST] <JonnyGreen> Hello guys, do you know if there is a command to list the timestamps of a video please ? [18:55:49 CEST] <JonnyGreen> I want to be sure each frame has the right timestamp [18:56:05 CEST] <Johnjay> squirrel: why did that command work? [18:57:44 CEST] <squirrel> Johnjay: beats me. ffmpeg is magic in my books [18:57:59 CEST] <Johnjay> ok. at least you're honest about it. [19:05:51 CEST] <JonnyGreen> Hello, I have an mp4 video that I've encoded with iOS at 30 fps. I don't know why, but when I play it on the facebook player or other players, there is some lag. I was wondering if there was some problems with my encoding. How can I be sure there are no problems ? [19:06:24 CEST] <JonnyGreen> Do you know if there is an ffmeg util to list problems ? Can I debug the timestamps ? [19:07:49 CEST] <Mavrik> ffprobe -show_frames [19:07:54 CEST] <Mavrik> will list all the frames with timestamps [19:08:10 CEST] <Mavrik> Also remember that mobile devices (including iPhones) don't record with constant frame rate [19:11:07 CEST] <JonnyGreen> ffprobe -i <input> -show_frames [19:11:07 CEST] <JonnyGreen> ? [19:11:51 CEST] <JonnyGreen> Oh yes, thanks it works ! [19:11:58 CEST] <JonnyGreen> I have these values for example : [19:12:00 CEST] <JonnyGreen> 11.800000 [19:12:07 CEST] <JonnyGreen> 11.833333 [19:12:15 CEST] <JonnyGreen> 11.866667 [19:12:25 CEST] <JonnyGreen> 11.900000 [19:12:30 CEST] <JonnyGreen> Looks correct for 30 fps... [19:19:50 CEST] <JonnyGreen> Thanks Mavrik anyway ! [20:12:09 CEST] <Sebas_> Hi :) I created a mpd file with multiple representations for video and audio.. but how can I control min_seg_duration for each video? Or can I compile them seperate then merge mpd files? [20:12:23 CEST] <Sebas_> lower bitrate gives very small chunk files :) [20:23:17 CEST] <Sebas_> Does ffmpeg have a merge options? or should I use DOM code to merge them into a single mpd file? [20:58:54 CEST] <Sebas_> Was able to merge automaticly using my own code :) works.. audio segments are 10x longer then video now less http requests [20:59:19 CEST] <Sebas_> also lower bitrate segments are longer now [21:53:40 CEST] <martyrs> Hello, i have a video which encoded in 1920x1080, ffprobe output: https://pastebin.com/2xGXDrKF [21:54:00 CEST] <martyrs> i am trying to generate 720p and 480p versions for this video [21:54:56 CEST] <martyrs> but 480p versions gives me "[SAR 1280:1281 DAR 16:9]" in ffprobe, i just want to know if it's normal to get SAR 1280:1281 value [21:55:16 CEST] <martyrs> while 720p version gives me [SAR 1:1 DAR 16:9] in ffprobe [21:56:02 CEST] <martyrs> here are the commands i am running https://pastebin.com/sqb5mB6A [22:11:02 CEST] <martyrs> i have multiple commands to convert video to 480p but i don't know which way is the best. "-vf scale=-2:480", "-vf scale=854x480,setsar=1:1" or "-s hd480" [22:30:46 CEST] <furq> the first one [22:31:05 CEST] <furq> except add -sws_flags lanczos [22:35:39 CEST] <martyrs> @furq "-sws_flags lanczos", right? [22:36:31 CEST] <martyrs> should i add it for 720p command too? [22:36:43 CEST] <martyrs> "ffmpeg -i 819.mp4 -vf scale=-2:480 -sws_flags lanczos -c:v libx264 -c:a copy 819_480p.mp4" [22:36:52 CEST] <thebombzen> I have an HEVC video file that decodes correctly with the ffhevc software decoder, but hevc_cuvid produces hideous artifacts [22:37:05 CEST] <thebombzen> is this the fault of cuvid, or should I send a sample? [22:40:49 CEST] <BtbN> Even if you send a sample, there's not much to be done [22:41:02 CEST] <BtbN> Is it 10 or 12 bit stuff? [23:03:34 CEST] <furq> martyrs: you should always add that when downscaling unless you have a messy source [23:03:59 CEST] <furq> the default is bicubic which is a bit better for hiding artifacts [23:04:34 CEST] <furq> you could also use -f zscale=-2:480:f=lanczos if your build has zscame [23:05:04 CEST] <furq> l [23:05:13 CEST] <martyrs> this is my final command for encoding both 720p and 480p [23:05:26 CEST] <martyrs> "ffmpeg -i 819.mp4 -vf scale=-1:720 -sws_flags lanczos -c:v libx264 -c:a copy 819_720p.mp4 -vf scale=-2:480 -sws_flags lanczos -c:v libx264 -c:a copy 819_480p.mp4" [23:05:43 CEST] <furq> you probably want some x264 options in there [23:06:14 CEST] <BtbN> it's also more efficient to do that in seperate processes [23:06:26 CEST] <furq> it is? [23:06:28 CEST] <BtbN> as ffmpeg will not encode in parallel, but sequentially [23:06:46 CEST] <BtbN> feed frame to encoder 1, wait until it's done, feed to encoder 2, wait until it's done, next frame [23:07:22 CEST] <BtbN> unless you are somehow bottlenecked by the decoder [23:07:31 CEST] <furq> nice [23:08:07 CEST] <martyrs> furq: which options for x264? [23:08:13 CEST] <furq> -crf -preset -tune [23:08:19 CEST] <furq> are the usual ones you want to change [23:08:24 CEST] <martyrs> BtbN: so i should run 720p and 480p seperately [23:08:35 CEST] <furq> if this is for hls then maybe the defaults will be ok [23:08:38 CEST] <furq> or dash or whatever [23:08:47 CEST] <furq> but they're not really suitable for archival [23:08:47 CEST] <martyrs> furq: default CRF is 23, right? [23:08:48 CEST] <BtbN> the defaults are almost never ok [23:08:50 CEST] <furq> yes [23:09:21 CEST] <martyrs> and do you guys know how to set moov atom at the beginning of the video? [23:09:27 CEST] <furq> -movflags faststart [23:09:34 CEST] <BtbN> + [23:09:39 CEST] <furq> do you still need that [23:09:42 CEST] <alexpigment> nope [23:09:45 CEST] <alexpigment> it's optional [23:10:11 CEST] <martyrs> where i should add -movflags faststart option? [23:10:35 CEST] <furq> before both outputs [23:12:34 CEST] <alexpigment> also, re: doing those processes separately as BtbN suggested - separate will use up more CPU and often end up faster, but it's also pretty harsh on your resources. use them together like you have them if you plan on doing other things concurrently on the system [23:12:38 CEST] <alexpigment> just my 2 cents, of course [23:13:04 CEST] <BtbN> that's a weird suggestion [23:13:15 CEST] <BtbN> use nice if you want to use the CPU for something else at the same time [23:13:19 CEST] <alexpigment> there's also some scenario where it's slower, but it's been a few months since I did the benchmarks [23:13:23 CEST] <furq> if that command is consistently using 100% cpu then it's probably fine [23:13:40 CEST] <martyrs> well, my server has some load, it's a production server i can say [23:13:41 CEST] <furq> i can't imagine it's massively quicker to run them separately [23:13:52 CEST] <martyrs> so actually i have 700 videos to be processed [23:13:56 CEST] <alexpigment> I'm just relaying my experience with it. I'm not sure if it was the CPU alone, but I would get crazy system lag when using separate processes [23:14:06 CEST] <furq> were you swapping or something [23:14:08 CEST] <martyrs> i'd like to do it slowly and by limited cpu power [23:14:18 CEST] <BtbN> Use a high niceness then [23:14:21 CEST] <alexpigment> furq: it was marginal in my experience [23:14:39 CEST] <BtbN> Or do them seperately, but not in parallel, but one after another [23:14:41 CEST] <alexpigment> BtbN: I'll defer to your judgement on this [23:15:10 CEST] <alexpigment> I think parallel was faster than sequential - just not faster than separate processes concurrently [23:15:25 CEST] <BtbN> yes, doing it in parallel will almost always be faster [23:15:35 CEST] <BtbN> but if it's about saving system resources, it's better [23:15:39 CEST] <martyrs> and one more question [23:15:51 CEST] <martyrs> should i encode 480p from 720p file? [23:15:55 CEST] <martyrs> or 1080p file? [23:16:09 CEST] <BtbN> Don't re-encode more often than neccesary [23:16:22 CEST] <BtbN> Quality will never get better [23:16:31 CEST] <alexpigment> yeah, 1080p to 480p [23:16:41 CEST] <martyrs> okay so i should encode it from 1080p [23:16:44 CEST] <alexpigment> 1080p to 720p is already mathematically innaccurate [23:16:49 CEST] <martyrs> thats what i tought but just wanted to make sure [23:16:57 CEST] <alexpigment> *inaccurate, rather [23:18:14 CEST] <alexpigment> martyrs: for reference, furq mentioned using lanczos earlier because you're doing non-integer scaling. 1080/720=1.5, 1080/480=2.25 [23:18:43 CEST] <alexpigment> as you can imagine, the scaler has to make some less-than-optimal decisions about what to do with your pixels [23:19:06 CEST] <alexpigment> when you go from 1080p to 720p to 480p, you're amplifying those bad decisions [23:19:17 CEST] <alexpigment> in addition to re-encoding and losing quality, as BtbN pointed out [23:20:11 CEST] <martyrs> alexpigment: got it [23:20:40 CEST] <furq> reencoding is the bigger problem there by far [23:20:47 CEST] <furq> especially at crf 23, preset medium [23:21:01 CEST] <furq> but yeah you should always use the original copy regardless [23:21:02 CEST] <alexpigment> true, just pointing out the scaling issues in the event that it comes up again in a lossless encode scenario [23:21:22 CEST] <furq> you should use the highest quality copy you have in general [23:21:32 CEST] <martyrs> btw, when encoding to 480p, i get "Stream #0:0(eng): Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv420p, 854x480 [SAR 1280:1281 DAR 16:9], q=-1--1, 60 fps, 15360 tbn, 60 tbc (default)" [23:21:36 CEST] <furq> even if that means downloading it in 4k from usenet [23:21:45 CEST] <furq> i mean uh [23:21:47 CEST] <martyrs> 854x480 [SAR 1280:1281 DAR 16:9], is this normal to have SAR 1280:1281? [23:21:47 CEST] <furq> acquiring it legally [23:21:49 CEST] <alexpigment> furq: haha [23:22:23 CEST] <alexpigment> martyrs: it's because 854x480 isn't a true 16x9 resolution [23:22:27 CEST] <alexpigment> it's slightly off [23:22:30 CEST] <furq> ^ [23:22:41 CEST] <alexpigment> mathematically, it should be 853.333333 [23:22:52 CEST] <alexpigment> the SAR is adjusted to be slightly less than 1:1 to account for this [23:23:09 CEST] <martyrs> alexpigment: oh, understood [23:23:29 CEST] <alexpigment> 16x9 480p has caused me more headaches over the years than any other format [23:23:39 CEST] <furq> how much of that has to do with dvd [23:23:42 CEST] <alexpigment> there's always something that doesn't want to play it right [23:23:49 CEST] <alexpigment> furq: for me, none actually [23:24:08 CEST] <alexpigment> it's how web players and browsers and standalone video players deal with it [23:24:39 CEST] <martyrs> as you can see, video recorded in 60fps, should i specify any specific profile while encoding? [23:25:02 CEST] <martyrs> visually, CRF 23 looked good to me, so i just decided to leave everything default [23:25:34 CEST] <alexpigment> martyrs: I personally really dig 480p60 as a format, but if device compatibility is a concern, there is an argument to be made for doing 480p30 instead [23:25:51 CEST] <alexpigment> that being said, I personally would just leave it as is in terms of the framerate [23:26:02 CEST] <martyrs> on my original videos (1080p), i use 15000kb/s bitrate, which is really high for average connections [23:26:08 CEST] <furq> martyrs: there's never any need to set the profile manually nowadays [23:26:20 CEST] <furq> unless you're targeting super old devices or BD compatibility [23:26:30 CEST] <furq> you might need to set the level for 720p60, idk [23:26:47 CEST] <alexpigment> there was an Apple TV that required 720p to be Main profile, but fortunately that device is effectively dead ;) [23:27:08 CEST] <martyrs> when i render footage using adobe premiere, 60fps only renders in High 5.1 profile or something [23:27:19 CEST] <alexpigment> martyrs: that means the bitrate is high [23:27:27 CEST] <alexpigment> 1080p60 is generally level 4.2 [23:27:34 CEST] <alexpigment> but if the bitrate spikes, you end up at 5.1 [23:27:43 CEST] <furq> you might want to clamp the 720p60 encode at level 4.1 [23:27:51 CEST] <furq> but it won't make a difference with preset medium [23:28:13 CEST] <alexpigment> i have a feeling 720p60 would never hit 4.2 at crf 23 ;) [23:28:27 CEST] <furq> it probably would with -preset veryslow because of the refs [23:28:32 CEST] <furq> i can't remember the specifics though [23:28:45 CEST] <martyrs> may you guys explain little bit more about difference between levels? i always ended up with 5.1 while encoding 15mbit bitrate and 60fps [23:29:08 CEST] <furq> https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels [23:29:26 CEST] <alexpigment> martyrs: there may just be a setting you need to turn down to 4.2 [23:29:26 CEST] <furq> that doesn't mention it but the number of reference frames also makes a difference [23:29:38 CEST] <furq> you generally don't want to go above 4.1 if you want widespread hwdec support [23:29:50 CEST] <alexpigment> yeah, but if you want to do 1080p60, 4.2 is where you'd cap it [23:30:07 CEST] <alexpigment> but yes, 1080p60 is a bit of a decoder crapshoot [23:30:11 CEST] <furq> yeah [23:30:33 CEST] <furq> it's generally not something you need to worry about unless you're encoding 1080p [23:30:36 CEST] <furq> or above [23:31:10 CEST] <furq> setting -profile and -level in ffmpeg with x264 will disable certain settings that would exceed that level [23:31:29 CEST] <furq> but you can't set -level 1 with 1080p60, say [23:31:40 CEST] <furq> unless you want a broken file [23:32:01 CEST] <martyrs> can i set 4.1 for 720p version? [23:32:23 CEST] <furq> it's better not to set it unless you know it'll exceed it [23:32:48 CEST] <furq> if you set 4.1 on a file that only needs 3.0 then it'll still flag it as 4.1 [23:32:55 CEST] <furq> it'll show you the output level when you start running an encode [23:32:57 CEST] <alexpigment> 720p60 will usually stay at 3.2 automatically [23:33:01 CEST] <furq> yeah [23:33:09 CEST] <martyrs> is there any way to check current level with ffprobe? [23:33:16 CEST] <furq> -show_streams [23:34:36 CEST] <martyrs> level 5.1 with original file, level 3.2 with 720p and level 3.1 with 480p [23:35:07 CEST] <martyrs> looks good, right? [23:35:32 CEST] <furq> yeah that's about what i'd expect [23:35:51 CEST] <martyrs> okay and how about limiting audio bitrate on 480p version? [23:35:56 CEST] <martyrs> original file audio is 320kb [23:36:04 CEST] <furq> ac3? [23:36:10 CEST] <martyrs> aac [23:36:15 CEST] <furq> is that 5.1 [23:36:34 CEST] <furq> that's a really weird choice for stereo [23:36:43 CEST] <martyrs> original file: Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 317 kb/s (default) [23:36:47 CEST] <furq> lol [23:37:02 CEST] <furq> yeah that's really excessive [23:37:25 CEST] <furq> i normally use fdk_aac -vbr 5, but the builtin aac encoder should do just fine at 128k [23:38:22 CEST] <martyrs> do you think aac is a good choice for playback compability? [23:39:21 CEST] <furq> it's the only choice [23:39:46 CEST] <martyrs> -c:a libfdk_aac -b:a 128k [23:40:17 CEST] <martyrs> going to try it now :) [23:40:27 CEST] <furq> if you didn't build ffmpeg yourself then you won't have fdk-aac [23:40:39 CEST] <furq> but -c:a aac -b:a 128k will work and do a fine job [23:40:47 CEST] <martyrs> oh it's external library, right [23:40:54 CEST] <martyrs> k going to use builtin then [23:42:47 CEST] <furq> anything starting with lib is external [23:43:05 CEST] <furq> but builds with fdk are non-redistributable because it's not gpl compatible [23:43:20 CEST] <alexpigment> furq: aac caps out at 320kbps, generally speaking. perhaps an odd choice, but it makes sense in that respect [23:43:54 CEST] <alexpigment> but yeah, 128kbps is more than acceptable for aac [23:44:13 CEST] <furq> yeah if it's for streaming then i guess it sort of makes sense [23:44:22 CEST] <furq> for archival that would be dreadful [23:44:39 CEST] <furq> also "sort of makes sense" in the sense that it still sucks but i can at least understand how the decision was arrived at [23:44:56 CEST] <martyrs> i set 64kbps for 480p version and 128kbps for 720p version [23:45:11 CEST] <alexpigment> 64kbps is low, but should still be ok [23:45:14 CEST] <furq> you might as well use 128k for both really [23:45:15 CEST] <alexpigment> if you find it's too low, try 96 [23:45:17 CEST] <alexpigment> k [23:45:54 CEST] <alexpigment> i've never personally used 64kbps for stereo audio, but again, it's not terrible with aac [23:45:54 CEST] <martyrs> just experimenting but yeah 128k should be fine for both i think [23:46:26 CEST] <alexpigment> anyone remember when Windows Media Player ripped at 64kbps MP3 by default? ;) [23:46:45 CEST] <alexpigment> rather, 64kbps WMA [23:46:48 CEST] <furq> nice [23:46:49 CEST] <alexpigment> anyway, THAT was unlistenable [23:46:56 CEST] <furq> tbf the wmp builtin mp3 encoder was just as bad [23:47:12 CEST] <alexpigment> well, it didn't default to that level [23:47:14 CEST] <furq> i remember seeing friends ripping cds with wmp in like 2006 and getting really upset with them [23:47:22 CEST] <furq> NO YOU MUST USE "EAC" [23:47:25 CEST] <alexpigment> the whole thing was a tie-in with Zune so that they could advertise more songs compared to the iPod [23:47:33 CEST] <furq> it was like i'd told them to go to jupiter [23:48:01 CEST] <alexpigment> well, it really only mattered when you were using an on-the-cusp bitrate [23:48:12 CEST] <furq> with that said it was only a couple of years before that that i copied a cd by ripping it to 128k mp3 and then burning those to the cd [23:48:16 CEST] <alexpigment> if you ripped at 192kbps or higher, the difference was not significant [23:48:28 CEST] <furq> while i still had the original cd in my computer [23:48:33 CEST] <alexpigment> furq: great archival work ;) [23:48:43 CEST] <alexpigment> "this'll do." [23:48:50 CEST] <furq> i genuinely didn't understand why it made a difference [23:49:00 CEST] <furq> but then i'd have been 17 at the time so it was almost certainly a shit cd anyway [23:49:01 CEST] <alexpigment> i hope it was something awful like "let the bodies hit the floor" by drowning pool [23:49:07 CEST] <furq> most likely [23:49:28 CEST] <furq> i think it might have actually been a DISTURBED album i was copying for a friend [23:49:33 CEST] <alexpigment> i'd like to tell anyone who saw my CDs in the late 90s, *there wasn't really a whole lot of choice* [23:49:44 CEST] <alexpigment> furq: i had that album too, I must admit [23:49:49 CEST] <furq> that's right folks...i was down with the dang sickness [23:49:50 CEST] <sabusanta> lol [23:50:21 CEST] <alexpigment> I bought it after hearing "stupify". i didn't realize the rest was a bunch of musical coughing and gagging noises [23:50:41 CEST] <sabusanta> That "Let The Body Hit The Floors" song is overplayed in the military in every presentation that could ever be [23:50:50 CEST] <alexpigment> man, that's so wrong [23:51:20 CEST] <alexpigment> also, it's like a genuinely bad song. i give no passes on ever liking that song ; [23:52:10 CEST] <martyrs> and anyone remember Audiograbber? [23:52:13 CEST] <sabusanta> I thought it was decent. Tho, I've always was a fan of "that genre" when I was young. [23:52:24 CEST] <alexpigment> martyrs: the hand animation is etched into my brain [23:52:36 CEST] <martyrs> alexpigment: hahah, same here [23:52:44 CEST] <furq> http://www.audiograbber.org/ [23:52:49 CEST] <furq> i can't believe that site is still up [23:52:58 CEST] <alexpigment> sabustanta: you might get a kick out of the website theprp.com . they still cover nu metal for some reason, but the comments section for every story is hilarious [23:53:19 CEST] <sabusanta> alexpigment: Thank I will try to later [23:53:24 CEST] <alexpigment> i can't remember what the deal was with audiograbber [23:53:33 CEST] <sabusanta> Now have 75 tabs open. [23:53:42 CEST] <alexpigment> the Xing company made a product that was exactly like it with a slightly different name [23:53:55 CEST] <alexpigment> so i don't know if they sold the tech or what [23:54:14 CEST] <alexpigment> Xing Audio Catalyst - that's it [23:54:52 CEST] <martyrs> aahh, audiocatalyst [23:54:57 CEST] <martyrs> that was so popular [23:55:19 CEST] <furq> lol i think i used that [23:55:30 CEST] <alexpigment> yeah, the wikipedia doesn't say it specifically, but audiograbber may have just been a ripoff of audio audiocatalyst that used LAME instead of Xing's encoder [23:55:40 CEST] <alexpigment> I definitely used audio catalyst [23:56:04 CEST] <alexpigment> as well as Winamp, before I knew any better [23:56:14 CEST] <alexpigment> (their ripper, I mean) [23:56:24 CEST] <alexpigment> it was limited to 2x until you paid for Winamp Pro :( [23:57:16 CEST] <alexpigment> also Musicmatch Jukebox - that one was pretty good actually, although it was bloated as hell [23:59:06 CEST] <martyrs> Dance eJay, best software back in '99 [23:59:55 CEST] <alexpigment> that one flew past my radar I guess [00:00:00 CEST] --- Sat Sep 23 2017

1 0

ffmpeg-devel.log.20170921
by burek 22 Sep '17

22 Sep '17

[00:00:05 CEST] <j-b> and I'll soon move to doing Javascript and web development [00:00:19 CEST] <Compn> no not javascript [00:00:24 CEST] <JEEB> j-b: sounds like something that will pay the bills [00:00:58 CEST] <j-b> JEEB: Javascript is awesome! [00:01:12 CEST] <JEEB> ecmascript is bearable [00:01:29 CEST] <JEEB> (as there really isn't anything better on the web) [00:02:03 CEST] <JEEB> and there are things like TS (thank you visual studio for registering that extension from my video players) that add the "notice mistakes before you go into production" [00:02:06 CEST] <JEEB> layer [00:02:29 CEST] <j-b> oh yes [00:03:04 CEST] <Compn> JEEB : you could make a new cross-plat browser language to replace javascript which is showing its age [00:03:10 CEST] <Compn> and make a lot of money doing that... [00:03:14 CEST] <Compn> there, another $1m idea. [00:03:26 CEST] <iive> firefox support webassembly or something like that [00:03:27 CEST] <JEEB> nah, I'll rather just watch mobile game footage https://www.youtube.com/watch?v=mSxrvUsssGE [00:03:30 CEST] <j-b> yep [00:03:34 CEST] <j-b> port Qt to wasm [00:03:36 CEST] <JEEB> yea, webasm is the thing coming [00:03:59 CEST] Action: Compn waiting for a real web browser to come along :( [00:04:41 CEST] <j-b> vivaldi? [00:04:42 CEST] <j-b> brave? [00:05:05 CEST] <Compn> vivaldi just sent me an email [00:05:17 CEST] <Compn> guess i should read how much they really want to change chrome but end up not changing it [00:05:17 CEST] <JEEB> brave seemed fun. also mozilla making the tab containers a freely available add-on instead of a registration-needed experiment [00:06:19 CEST] <Compn> containers lol [00:06:32 CEST] <JEEB> hey, I like the idea [00:06:33 CEST] Action: Compn just has portable browsers in different locations [00:06:40 CEST] <Compn> guess i'm ahead of the currrrrrve [00:06:47 CEST] <JEEB> https://addons.mozilla.org/en-US/firefox/addon/multi-account-containers/ [00:07:00 CEST] <JEEB> so you can have tab groups that have 100% separate local storage [00:07:03 CEST] <Compn> right [00:07:12 CEST] <wm4> isn't firefox breaking addons [00:07:14 CEST] <Compn> its called portable browsers in different locations. [00:07:25 CEST] <JEEB> wm4: yes, which is why these are based on the new APIs [00:07:40 CEST] <JEEB> the old API extensions will have a lot of extinction [00:07:41 CEST] <wm4> oh so there is a new API [00:07:44 CEST] <JEEB> after 57 hits [00:08:01 CEST] <JEEB> wm4: and they recommend people who have missing functionality to make experiments which let you draw the interfaces [00:08:17 CEST] <JEEB> so that they can be evaluated and implemented if people feel it's a useful addition to the WE API [00:08:32 CEST] <JEEB> but as I've already noted, the death of the XUL add-ons *will* kill a lot of extensions [00:08:41 CEST] <JEEB> because people were making them for fun [00:08:43 CEST] <Compn> LOL brave inserts its own ads [00:08:50 CEST] <Compn> also based on chromium [00:08:51 CEST] <JEEB> and people don't want to do random rewrites [00:08:59 CEST] <JEEB> yea, everything and their dog has chromium there [00:09:01 CEST] <Compn> how is it faster than chrome if its using chrome ? [00:09:03 CEST] <graphitemaster> I've been using firefox-nightly on Windows and Linux (now uses the new stylo by default and electrosys (their multi threaded browser renderer)), they're working on an interruptible html/css rewrite too to be threaded which is in beta, the performance has been nothing short of amazing. In terms of user experience alone, I'd argue it's 2 to 4 times nicer feeling. [00:09:22 CEST] <JEEB> graphitemaster: yea I'll get on that train as 57 hits beta [00:09:32 CEST] <JEEB> also it will also show me how much I will miss tab groups [00:09:38 CEST] <Compn> multi threaded just means its going to lock up more threads :P [00:09:40 CEST] <JEEB> so I can have my por^Wprivate content in another group [00:09:58 CEST] <Compn> opens browser ... 50 porn tabs start loading [00:09:59 CEST] <Compn> hmmmmmmmmmm [00:10:22 CEST] <JEEB> and that is why you have them in multiple groups ;) [00:10:24 CEST] <wm4> I wonder if slack in firefox will finally be usable [00:10:38 CEST] <graphitemaster> por^Wprivate content is best suited to the por^Wprivate hub app on Android with a VR headset, you don't even need VR content, just being able to lay back and het a nice "large screen TV" feel ;-) [00:10:46 CEST] <JEEB> pfft [00:10:51 CEST] <JEEB> I mostly read that sort of stuff [00:11:02 CEST] <JEEB> so a screen and an easily operable reader is all I need 8) [00:11:04 CEST] <graphitemaster> slack isn't usable in any context. [00:12:36 CEST] <iive> what is that slack you are talking about? [00:13:11 CEST] <graphitemaster> slack is a webapp based chat thing like IRC but with more features, like inline images and emojis and videos, very media rich [00:13:51 CEST] <graphitemaster> also slow as crap since it's a billion lines of javascript apparently that takes 95 hours for your browser to interpret unless you have a JIT [00:14:47 CEST] <Compn> i think the web as we know it is outdated [00:14:51 CEST] <wm4> yes, it's like IRC but worse and with web shit [00:14:59 CEST] <Compn> in the future all websites will just be streamed video with interactive content [00:15:08 CEST] <Compn> thus getting rid of html/javascript 99% [00:15:20 CEST] <Compn> j-b : you going to make this a reality? ^^^ [00:15:24 CEST] <Compn> you can have my idea for $1m [00:15:57 CEST] <Compn> the only thing the client gets is html5 or flash video [00:16:06 CEST] <Compn> website is all server side again :) [00:17:19 CEST] Action: Compn wonders why he gives all of his great ideas away for free [00:18:15 CEST] <iive> Compn: there will actually be only one site. facebook. [00:18:23 CEST] <j-b> very more likely [00:19:41 CEST] <iive> does facebook have its own Alexa like device? [00:21:07 CEST] <Compn> good question [00:21:18 CEST] <Compn> google, apple siri, amazon alexa... [00:21:51 CEST] <Compn> iive : the internet says fb is working on a voice speaker/video chat device [00:22:22 CEST] <j-b> iive: every android device? [00:22:41 CEST] <iive> j-b: android is google [00:22:58 CEST] <j-b> fb is preinstalled in all android devices [00:23:04 CEST] <j-b> with all the permissions set [00:23:33 CEST] <iive> well, Alexa is a tube that you put in your house and that has 8 microphones that work at all time. [00:23:41 CEST] Action: Compn checks and sees that there is no facebook app on his phone [00:23:42 CEST] <Compn> wew [00:23:47 CEST] <iive> phones turn off some stuff to preserve power. [00:24:28 CEST] <Compn> facebook is built into the accounts thing in android [00:24:35 CEST] <Compn> if you add your account there, that is [00:26:07 CEST] <iive> also, Alexa like devices cost about $50, they are basically giving them away for free. [00:31:44 CEST] <Compn> wm4 : whats your plan for ffmpeg future ? [00:34:42 CEST] <wm4> nothing [00:36:08 CEST] <graphitemaster> what's your plan for ffmpeg past? [00:36:49 CEST] <Compn> j-b : what about the proposed plan to destroy the git history and re-make it without the merge commits ? [00:37:00 CEST] <Compn> or to modify git so a checkout does not land on a merge ? [00:37:08 CEST] <Compn> and that merges are silenced ... [00:37:09 CEST] <j-b> Compn: I have that, personnally [00:37:44 CEST] <Compn> j-b : i was under the impression that a lot of devs would want such a repo... if you want to share it with them [00:37:52 CEST] <j-b> no. [00:37:54 CEST] <j-b> pay me. [00:38:01 CEST] <Compn> how much [00:38:04 CEST] <j-b> Compn: 1million [00:39:12 CEST] <wm4> chance missed I guess [00:39:27 CEST] <Compn> wm4 : didnt you want such a repo or no ? [00:39:46 CEST] <j-b> Compn: seriously, now is not the time to discuss all this. [00:39:48 CEST] <wm4> whatever would fix the dumb fork situation [00:39:50 CEST] <Compn> oh ok :P [00:40:02 CEST] <Compn> j-b : have fun at vdd! :) [00:40:36 CEST] <j-b> Compn: we have the money (in the million $ range), we have the capacities, we have the skillz. So the issue is mostly the will. [00:41:15 CEST] <j-b> and now, bed it is. [00:42:09 CEST] <Compn> wm4 : come to vdd and see the fork situation in person , face to face :) [00:43:45 CEST] <wm4> probably not [00:45:59 CEST] <graphitemaster> there's an ffmpeg fork? [00:46:17 CEST] <Compn> there are quite a few ffmpeg forks [00:46:22 CEST] <wm4> for 6 years or so [00:46:35 CEST] <graphitemaster> is it the whole libav vs ffmpeg thing [00:46:42 CEST] <graphitemaster> I thought that was finally over [00:46:45 CEST] <Compn> yes, wm4 wont let it go [00:46:50 CEST] <Compn> :P [00:47:42 CEST] <wm4> graphitemaster: why would you think it's over [00:50:43 CEST] <graphitemaster> because fighting over superficial shit isn't engineering? [00:51:27 CEST] <JEEB> I don't think people fight, both camps are happily camping in their own corner [00:52:48 CEST] <Compn> i've been trying to teach people that forks are natural (see xfree86 xorg or redhat / debian or even freebsd / openbsd ) [00:54:36 CEST] <Compn> and trying to reunite ffmpeg and libav would be like trying to get redhat and debian to merge [00:55:08 CEST] <Compn> or debian/ubuntu if you prefer [00:55:34 CEST] <Compn> but i think everyone hates me now [00:55:40 CEST] <iive> hum... ubuntu is way too similar to debian [00:55:41 CEST] <Compn> and most people have me on /ignore [00:59:17 CEST] <Loriker> compn: :-D [01:01:44 CEST] <wm4> Compn: please stop spewing bullshit [01:01:53 CEST] <wm4> why are you always making things harder than they are [01:02:11 CEST] <Compn> you imply that i have any power or say in the matter, wm4 [01:02:30 CEST] <Compn> but i do not. [01:03:31 CEST] <Compn> these are just my opinions [01:20:22 CEST] <graphitemaster> reuniting ffmpeg and libav would be like trying to get north korea and the united states to stop instigating each other [01:24:50 CEST] <wm4> no it wouldn't [02:23:13 CEST] <rcombs> less "north and south korea" and more "north and south dakota" at this point, I think [02:27:54 CEST] <wm4> on that topic: I bet 1988 nobody thought west/east germany unification would have been possible [03:11:52 CEST] <cone-847> ffmpeg 03Tatsuyuki Ishi 07master:598e41684066: GnuTLS: eat PREMATURE_TERMINATION error [03:11:52 CEST] <cone-847> ffmpeg 03Kaustubh Raste 07master:b5da07d4340a: avcodec/mips: Unrolled loops and expanded functions in avc put mc 10 & 30 msa functions [03:11:52 CEST] <cone-847> ffmpeg 03Kaustubh Raste 07master:bba9c1c6bb17: avcodec/mips: Reduced conditional cases in avc inter lpf msa functions [06:08:18 CEST] <atomnuker> kierank: which train are you getting to paris? [06:13:22 CEST] <kierank> atomnuker: 12:24 [06:14:05 CEST] <atomnuker> I'm on the 9:24 [06:18:02 CEST] <kierank> I might be too sick for disneyland [06:19:15 CEST] <atomnuker> did you go to dirtyburger? [07:55:52 CEST] <kurosu> So, is this an exercise in futility to use movntq/movntdqa in checkasm's randomize buffers stuff ? I don't like the speed aspect of checkasm to be essentially reading from known addresses (thus cached) of very recent data (thus L1 or L2 at worst) [07:56:43 CEST] <kurosu> plus everyone does rnd() and reads 16bits of it: is this being entropy-conscious or cargo-culting? [08:01:26 CEST] <kurosu> can't find an equivalent for ARM, but caches are likely smaller [08:02:15 CEST] <kurosu> hum, scratch the movntq/... stuff, you'd need to do it for every call of the tested functions [09:46:20 CEST] <JEEB> was the result of something like (x > y) safe to put into an int, or is having a !! there preferred? [10:08:16 CEST] <rcombs> JEEB: comparisons return 1 or 0, so that's fine [10:08:48 CEST] <JEEB> ok [10:20:05 CEST] <JEEB> rcombs: you can guess what sort of damage is being done in write_traf/trun >_> [10:20:18 CEST] <JEEB> (and I'm trying to make it as presentable/sane as possible) [10:20:35 CEST] <rcombs> my condolences [10:41:13 CEST] <JEEB> there most likely is a much better way of doing this, but I want to get this to some state at the very least >_> [13:35:06 CEST] <cone-208> ffmpeg 03Vittorio Giovara 07master:6f15f1cdc853: pixdesc: Add API to map color property names to enum values [13:47:47 CEST] <bidiko> hi, I'm using FFmpeg library in my ios project. But I'm getting memory leak error how can i solve this problem ? [13:50:15 CEST] <JEEB> valgrind is your friend [13:50:39 CEST] <JEEB> also make as much of the code run'able outside of iOS so you don't cry when you have to debug your multimedia code, if only possible [13:54:03 CEST] <bidiko> valgrind ? I don't know him or her [13:55:23 CEST] <bidiko> if you want to help maybe you can shut up [13:55:38 CEST] <durandal_1707> bidiko: google for valgrind [13:55:42 CEST] <JEEB> those both were very serious recommendations [13:55:48 CEST] <JEEB> a) valgrind is awesome [13:56:00 CEST] <JEEB> b) the more code you can run on your actual workstation, the better for any debugging [13:56:09 CEST] <JEEB> since you don't have to be running it in your iOS emulator [13:56:17 CEST] <JEEB> esp. since I'm not sure if you can run valgrind within your emulator [13:56:37 CEST] <JEEB> http://valgrind.org/docs/manual/quick-start.html [13:56:44 CEST] <JEEB> for all the spoon-feeding [13:57:10 CEST] <JEEB> also this is not -devel stuff, you're an API user so off to #ffmpeg you go [14:06:42 CEST] <atomnuker> who's arriving today? [14:07:43 CEST] <thardin> JEEB: -fsanitize is pretty cool too. not as thorough as valgrind, but much faster [14:07:56 CEST] <thardin> so not excuse not to run it on say FATE [14:08:03 CEST] <thardin> no* [14:57:24 CEST] <TD-Linux> atomnuker, some of use are chilling in the moz office [16:01:59 CEST] <Gramner_> so where is everyone? I heard something about dinner&drinks at le bloc, but dunno what time [17:12:34 CEST] <cone-762> ffmpeg 03Steven Liu 07master:7e9cdd3f49e5: avformat/hlsenc: fix CID 1418106 [17:12:34 CEST] <cone-762> ffmpeg 03Steven Liu 07master:02bf023afe00: MAINTAINERS: modify the hlsenc description [17:12:34 CEST] <cone-762> ffmpeg 03Steven Liu 07master:c34c0e3a649e: avformat/hlsenc: support http method for hls fmp4 init file [20:58:02 CEST] <atomnuker> kierank / Gramner_ / TD-Linux / anyone here: want to hang out [20:58:34 CEST] <kierank> We are at the place [20:58:39 CEST] <atomnuker> the place? [20:59:01 CEST] <kierank> Le bloc [20:59:38 CEST] <atomnuker> the cafe just next to the hotel? [21:01:22 CEST] <atomnuker> kierank: guess its not that one, where is it? [21:01:47 CEST] <kierank> No [21:01:53 CEST] <kierank> It's 10 mins walk [21:02:38 CEST] <atomnuker> ah, the one next to brochant? [21:03:05 CEST] <atomnuker> k, leaving now, do wait for me [22:59:47 CEST] <durandal_1707> dont get drunk and vomit here [23:09:59 CEST] <jvanriper> Hullo, all. I want to provide a small update to support captioning in DirecTV, but I also want to ensure it fits the code. [23:10:15 CEST] <Compn> sure [23:10:17 CEST] <Compn> whats up jvanriper [23:11:11 CEST] <jvanriper> Currently, ffmpeg supports 'a53_cc', and the ff_alloc_a53_sei function sets up the header accordingly. [23:11:45 CEST] <jvanriper> DirecTV, however, didn't wait for the standard, and went forward with a slightly different header. It's close, but different enough to cause problems for some folks who are trying to send to their receivers. [23:12:16 CEST] <jvanriper> Ergo, I want to provide another function, say, ff_alloc_directv_sei, that would hopefully set the headers according to what their receivers need. [23:12:49 CEST] <jvanriper> So, nice and clean... separate functions... but we need a way to select the appropriate function based on some kind of argument. [23:13:21 CEST] <jvanriper> I noticed that you have an a53cc argument that sets this up. It uses OFFSET(a53_cc), etc. [23:14:12 CEST] <jvanriper> But, it's expected to be a BOOL, where for my needs an INT might be better... when set to 0, it's disabled, 1 for a53_cc, 2 for directv_cc. [23:15:17 CEST] <jvanriper> So, perhaps a directvcc argument would be set, which would lead to this (currently) a53_cc being set to 2. But a53cc would set a53_cc to 1. [23:15:41 CEST] <jvanriper> I'd need to ensure all the functions currently relying upon these settings work appropriately, of course. [23:16:13 CEST] <jvanriper> (and, unfortunately, I haven't considered yet *reading* this instead of *encoding* it, as my focus has been more on encoding it). [23:16:50 CEST] <jvanriper> Anyway, I don't want to move forward with an idea like this, if it doesn't quite fit in with things. Or if someone might have a better approach that fits the project better (I'm certainly not familiar with it). [23:17:04 CEST] <Compn> sure , someone should have a better idea [23:17:08 CEST] <Compn> i'm not familiar with that part of the code [23:17:14 CEST] <Compn> maybe ask ubitux ? [23:17:42 CEST] <jvanriper> Okay. Might I find him/her through email? [23:17:57 CEST] <jvanriper> (or perhaps just go through the e-mail list?) [23:18:02 CEST] <Compn> yes [23:18:10 CEST] <jvanriper> Okay. [23:18:22 CEST] <Compn> sure asking on ffmpeg-devel would also be good [23:18:32 CEST] <Compn> or you can wait around here if you want [23:18:36 CEST] Action: Compn going afk [23:18:42 CEST] <jvanriper> kk. Just thought I should check here first, just in case. kk. [23:18:47 CEST] <Compn> no problemo [23:18:51 CEST] <Compn> feel free to ask questions [23:18:57 CEST] <Compn> i think people just arent on irc right now [23:19:02 CEST] <jvanriper> Alrighty. Take care, then, and thanks. [23:28:26 CEST] <J_Darnley> yeah, people are out drinking too much at VDD [23:29:28 CEST] <llogan> isn't that the norm? [23:31:05 CEST] <llogan> does libfdk_aac support aac_eld profile? https://pastebin.com/raw/02JkC5xu [23:33:40 CEST] <Compn> euhhhhhhhhhh [23:33:42 CEST] <Compn> dont know [23:33:49 CEST] <Compn> aacdec has that nice list of supported things [23:33:56 CEST] <Compn> wonder if fdk has it too [23:34:30 CEST] <llogan> it should...if the docs are correct [23:40:01 CEST] <Compn> oh [23:40:14 CEST] <Compn> is our profile correctly sending to libfdk [23:40:15 CEST] <Compn> ? [23:41:03 CEST] <Compn> e.g. does -profile work with libfdk and ... is it correct profile name... [00:00:00 CEST] --- Fri Sep 22 2017

1 0

ffmpeg.log.20170921
by burek 22 Sep '17

22 Sep '17

[00:05:50 CEST] <rewman> ffplay over sftp works fine with an MKV file [00:05:59 CEST] <rewman> but the same file over ftp gives me error [00:06:06 CEST] <JEEB> you are a pervert, congratulations [00:06:09 CEST] <rewman> Format matroska,webm detected only with low score of 1, misdetection possible! [00:06:21 CEST] <rewman> EBML header parsing failed [00:06:28 CEST] <rewman> why is there a difference? [00:32:42 CEST] <sikilikis> Hey all. I have the following in my ffmpeg command: "-loop 1 -framerate $FPS -i $IMGS" where $IMG will be like "/path/to/image%03d.tiff" [00:33:05 CEST] <sikilikis> this works just fine but I'm wondering if theres a way I can change that input on the fly, without having to start up another instance of ffmpeg [00:33:21 CEST] <sikilikis> I am using ffmpeg to stream 24/7 to youtube [00:41:34 CEST] <JEEB> sikilikis: not with ffmpeg.c, as it is rather static regarding inputs and outputs [00:41:46 CEST] <JEEB> the libraries let you create something like that though [00:43:34 CEST] <sikilikis> I'm not really feeling up to creating a "new" ffmpeg =/ but thanks for the info [00:45:31 CEST] <sikilikis> well heres an unrelated question. That command is being used to render a "slideshow" I suppose. Is there a way to set the "visual" fps, separate from the actual fps? if that makes sense? [00:46:03 CEST] <sikilikis> for example, if I only have two individual frames and I play that at 30 FPS, it will alternate between those frames at 30 fps so it will look like a seizure [00:46:31 CEST] <sikilikis> instead maybe I want to do something like "alternate frames every 10 seconds" while still having the actual video render at 30 fps [00:56:02 CEST] <dingwat> Is there a way to halt an encoding process in a way that leaves the video file playable? As in, I'm halfway through encoding a series of images into a video, but is there a way to stop it there but still have a "finished" video file? [00:57:07 CEST] <c_14> sigint or q [00:57:14 CEST] <c_14> should make ffmpeg quit gracefully [00:57:42 CEST] <dingwat> Thanks, I'll try that sometime! [00:59:44 CEST] <dingwat> Also, interestingly, this encoding process has been super stable at 10.2GB of RAM. CPU and network bandwidth are jumping all over the place, but the memory consumption is very consistent [01:00:56 CEST] <dingwat> And, good news, I'm almost halfway done. It's been less than 2hrs, so I guess that's relatively quick [01:07:55 CEST] <JEEB> dingwat: yes these things try to keep the number of buffers as static as possible and they try to allocate the anticipated ones in the beginning [01:13:46 CEST] <Johnjay> >10.2GB of RAM [01:13:56 CEST] <Johnjay> what in the world are you encoding that takes that much space [01:14:09 CEST] <JEEB> eight thousand and something of width [01:14:23 CEST] <JEEB> so yes the buffers will take space [01:15:18 CEST] <dingwat> JEEB: ah gotcha that makes sense [01:21:29 CEST] <Johnjay> i should probably know more about TVs than I do [01:21:38 CEST] <Johnjay> But I thought 4k res was the big thing now, not 8k. [01:22:21 CEST] <redrabbit> tv still uses mp2 / mpeg2 on most sat. feeds [01:22:25 CEST] <redrabbit> gross [01:22:44 CEST] <redrabbit> also, avc/mp2 [01:22:58 CEST] <redrabbit> avc/aac if lucky [01:24:40 CEST] <dingwat> Johnjay: Japan has stated that the 2020 Olympics will be in 8K. I'm just playing around though, I have some 8K source material and I'd like to see how Youtube handle it [01:25:14 CEST] <Johnjay> i've seen a 4k option on youtube i think [01:25:27 CEST] <Johnjay> but idk if it would really take an 8k upload. but then i don't use youtube much [01:25:30 CEST] <redrabbit> yep [01:26:00 CEST] <Johnjay> youtube uses ffmpeg to encode and decode, correct? [01:26:12 CEST] <dingwat> There is 8K content on Youtube. Which is actually from a 6K camera. I have rendered content though, not from a camera [01:26:14 CEST] <redrabbit> it uses gross stuff [01:26:49 CEST] <Johnjay> i remember being surpised to hear that. i would thought google would buy up and take over anything it depended on [01:27:13 CEST] <Johnjay> Like fork ffmpeg and rebrand it as Googpeg or something, lol [01:27:57 CEST] <redrabbit> sounds like a brand of vacuum sealed vomit [01:28:06 CEST] <dingwat> Welp. I now have an 8K video, supposedly, but neither of my computers can play it. [01:28:06 CEST] <blap> http://img.pr0gramm.com/2017/09/21/b91ade6e19139a4f.png My latest unicode IRC troll pic :P [01:28:24 CEST] <Johnjay> i'm sure google would call it something trendy [01:28:35 CEST] <Johnjay> But yeah the microsoft strategy. Embrace, extend, extinguish [01:32:02 CEST] <JEEB> dingwat: yea I'm doing my 2160p60 content the same way. game capture [01:32:25 CEST] <JEEB> thankfully some engines let you render at some random speed [01:32:31 CEST] <JEEB> and not miss a frame [01:32:45 CEST] <JEEB> (as in, your actual game doesn't have to run realtime) [01:48:07 CEST] <Johnjay> alright I have a 4:04:50 length file [01:48:20 CEST] <Johnjay> I told -segment_times to do 3600,3600,3600,4000 [01:48:24 CEST] <Johnjay> time to see if that work [02:56:32 CEST] <Johnjay> alright it didn't work [02:56:39 CEST] <Johnjay> falling back on the command on the super user page [02:56:46 CEST] <Johnjay> https://superuser.com/questions/820747/slicing-video-file-into-several-segm… [03:30:45 CEST] <Djfe> Hi! :) I'm downloading an hls stream atm. [03:31:09 CEST] <Djfe> and I'm getting red warnings/errors from the tls part of ffmpeg: [03:31:28 CEST] <Djfe> Unable to read from socket [03:31:37 CEST] <Djfe> Failed to send close message [03:32:12 CEST] <Djfe> are these actual errors or can they be ignored like warnings since tls ensures stream integrity? [03:59:41 CEST] <Cracki_> I know that guy [04:02:43 CEST] <Djfe> https://pastebin.com/GsAz204m [04:08:18 CEST] <Djfe> I'm using ffmpeg over a vpn connection which isn't completely stable. it seems to cause the tls connection to fail every now and then. [04:09:07 CEST] <Djfe> are those messages supposed to be forwarded from the tls error output to the ffmpeg console [04:46:20 CEST] <blap> i get those too so I use a client that is able to restart [04:54:41 CEST] <echelon> hi, the mkv file i recorded from my webcam doesn't have any playback option [04:55:02 CEST] <echelon> i guess there's no index? [04:55:08 CEST] <echelon> is there a way to fix it? [05:08:37 CEST] <Djfe> what do you mean by playback option? [05:09:17 CEST] <echelon> i can't skip ahead or backward [05:09:22 CEST] <echelon> anyway, i figured it out [05:09:46 CEST] <echelon> just passed it through copy [05:10:19 CEST] <echelon> anyway, i used -live 1 flag when i was recording and it didn't let me skip forward/back then either [05:16:50 CEST] <Djfe> +1 [05:32:20 CEST] <echelon> oh [05:39:25 CEST] <Djfe> "oh"? [05:40:16 CEST] <Djfe> I meant by that good that you got your problem solved ;) [05:40:33 CEST] <Djfe> (or do you another issue?) [05:48:13 CEST] <Djfe> *have [05:51:49 CEST] <Djfe> bye [05:51:51 CEST] <kepstin> echelon: yes, using the '-live 1' option will cause ffmpeg to not write an index [05:52:07 CEST] <kepstin> echelon: if you're saving to disk, then don't use that option. [05:52:26 CEST] <kepstin> (without that, ffmpeg will go back and add the index when it's done) [06:09:45 CEST] <echelon> kepstin: but i'm not able to go forward/backward even when i'm trying to read from the file while it's recording with the option [06:09:52 CEST] <echelon> am i supposed to stream it? [09:57:18 CEST] <Gaulois94> Hello [10:04:44 CEST] <Gaulois94> For avio_alloc_context, what is the "whence" parameter ? [10:08:08 CEST] <klaxa> Gaulois94: from what i can tell it's the same as for fseek (see man fseek) [10:08:26 CEST] <klaxa> it specifies from where the seek should be done (beginning, current position, end) [10:08:47 CEST] <Gaulois94> Ok, just to be sure [10:09:44 CEST] <Gaulois94> And for a std::istream it should return the value of tellg, right ? [10:10:49 CEST] <klaxa> no idea what istream is, but ftell() on FILE* structs should return the current position of an opened file [10:21:51 CEST] <chuckleplant> Hi (topic from yesterday), I'm using Live555 to receive an H264 stream from a camera. I am using libavcodec to decode the stream, and later OpenGL to render. All of that is working. However, as soon as I get a frame, I render it. This causes some image stuttering, as I'm not using timestamp info... Now, I'm trying to retreive the presentation timestamp (PTS) from the decoded AVFrame, but this value is not set. [10:21:56 CEST] <chuckleplant> From Live555 h264 parsing, I only get NAL unit PTS, which I feed to AVPacket. I also do not have a proper AVCodecCtx->time_base, neither the camera provides the time_base (time_scale) info in the SPS/PPS (it is optional according to the standard) [10:22:02 CEST] <chuckleplant> How could I, in this scenario, account for presentation timestamps? I'm sure there's something else I'm not using or misusing. But can't really spot it. [13:24:55 CEST] <Gaulois94> Hi, do you guys have a good tutorial to how streaming screenshots using FFMPEG and RTP protocol ? [13:45:19 CEST] <dingbat> Welp, my 8K video upload to youtube succeeded. Eventually. Plays like shit, but meh [13:47:35 CEST] <furq> 65mbit huh [13:47:40 CEST] <furq> i'm not surprised it plays like shit [13:48:27 CEST] <furq> wait what [13:48:43 CEST] <furq> 8k avc is 65mbit but 8k vp9 is 15mbit [13:48:49 CEST] <furq> i don't even want to consider how they've worked that out [13:55:55 CEST] <ritsuka> It would be nice to know hot long it took to convert the 8k video to vp9 :| [14:10:37 CEST] <bidiko> Hi, How can i use FFmpeg in my IOS project for RTSP connection ? I have one sample project but I'm getting memory leak error [14:14:11 CEST] <durandal_1707> cant guess [14:18:56 CEST] <bidiko> actually I'm using FFmpeg library in my project and I can connect RTSP camera. But I'm getting memoryl leak error and I need help how can i upgrade my FFmpeg library [14:26:10 CEST] <SavinaRoja> does anyone have experience with FFMPeg and mpeg-dash production? [14:28:19 CEST] <JEEB> SavinaRoja: the DASH muxer/mpd writer seems to have worked last I tried [14:29:05 CEST] <SavinaRoja> I've been working on this project for days and never heard of that... documentation link? [14:30:08 CEST] <stevenliu> ffmpeg -h muxer=dash [14:30:22 CEST] <SavinaRoja> JEEB: I'm getting apparently valid MPD files but validation fails on parsing of the mp4 files [14:30:55 CEST] <JEEB> use l-smash's boxdumper to check the structure of the fragments [14:31:04 CEST] <JEEB> `boxdumper --box file.m4s | less` [14:31:05 CEST] <JEEB> for example [14:31:28 CEST] <JEEB> (or you can dump the output to a text file) [14:31:52 CEST] <SavinaRoja> thanks, I'll give this a go [15:21:18 CEST] <SavinaRoja> so I tried out the dash muxer on some test input https://pastebin.com/u8rA0Ri7 [15:22:42 CEST] <SavinaRoja> and I uploaded it to a vps for testing and playback is still an issue [15:28:31 CEST] <SavinaRoja> http://dashif.org/conformance.html appears to choke on a plain IP URL [15:38:01 CEST] <fahadash> I am trying to cut audio of a portion of a video, is this command correct? .\ffmpeg.exe -i ".\video.mp4" -ss 15 -t 7 -vn -c copy audio.mp3 [15:38:56 CEST] <fahadash> I cannot see the output, I am on windows 10, the ffmpeg.exe crashes upon run when run under cmd.exe, I have to run it under powershell which launches a separate console window and the output scrolls fast and the window closes. [15:41:43 CEST] <SavinaRoja> fahadash: the command options look fine, are you sure that.\ffmpeg.exe is the correct path? [15:42:45 CEST] <SavinaRoja> "where.exe ffmpeg" should tell you if it can be found by just "ffmpeg" [15:57:27 CEST] <fahadash> I got it. Thanks [16:17:10 CEST] <SavinaRoja> does the ffmpeg dash muxer provide support for multiple representations? [18:08:59 CEST] <Johnjay> is there a way to divide a stream into N equal chunks? [18:09:52 CEST] <tdr> playable chunks or simply smaller ones (for transfering etc) ? [18:10:09 CEST] <Johnjay> er playable. it's nbd if not [18:10:54 CEST] <Johnjay> if I just say an hour or 45 min or 30 min I end up with an extra chunk of 5-10 min and can't remember the concat syntax [18:11:41 CEST] <Johnjay> actually this problem would be solved if I could insert audio markers at the start of each chunk [18:11:56 CEST] <Johnjay> like 2 beeps for part 2, 3 beeps for part 3, etc [18:12:04 CEST] <Johnjay> maybe i could write a script for that [18:15:33 CEST] <furq> Johnjay: segment muxer? [18:17:22 CEST] <Johnjay> I don't see anything in the doc about it [18:17:49 CEST] <Johnjay> although now that I look there is an option called segment_start_number I could use to start numbering at 1. lol [18:18:23 CEST] <Johnjay> My use case is a sports mp3 player with no interface except next, prev, and play/pause [18:18:59 CEST] <furq> !muxer segment [18:18:59 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_002c-… [18:20:35 CEST] <Johnjay> yeah that [18:23:01 CEST] <nohop> hey guys. I'm already using ffmpeg in my project to encode en write video streams to disk. Now, I need to create a web interface with video, so I need raw video buffers before they're written to file [18:23:26 CEST] <nohop> what would be the best way to have ffmpeg give me a callback and give me the buffer, instead of writing it to file ? [18:30:49 CEST] <Mavrik> pipe it as a second output I guess> [18:30:51 CEST] <Mavrik> ? [18:31:00 CEST] <Mavrik> Named papes or what are they called on unix [18:32:11 CEST] <BtbN> raw video frames to show them on a web interface sounds like a bad idea [18:32:33 CEST] <nohop> Mavrik: yeah... but that seems hacky as fuck :) [18:32:43 CEST] <nohop> BtbN: is it ? hmm :) [18:33:19 CEST] <BtbN> They are huge and I don't know any sane format to display raw frames in a browser [18:33:41 CEST] <BtbN> If you want a screenshot, png/jpeg. Otherwise just send video there. [18:33:59 CEST] <nohop> 'just send video there' is what i want [18:34:18 CEST] <nohop> problem is, my video is a ton of uncomperssed pixels at a high framerate [18:34:35 CEST] <Mavrik> hmm [18:34:42 CEST] <Mavrik> how about you setup a streaming server and tell it to record [18:34:48 CEST] <Mavrik> and then just stream encoded video to it? [18:35:38 CEST] <nohop> my application will be the server. The encoding and sending out encoded video is exactly what i want to do :) [19:01:36 CEST] <saml> how do I set up render farm? [19:01:43 CEST] <saml> i want something yolo fast [19:03:58 CEST] <saml> like distributed ffmpeg cluster to encode videos real fast [19:26:41 CEST] <nohop> BtbN: So, what would you recommend using to compress raw pixel data to send over http and show on a webpage ? [19:37:10 CEST] <kepstin> nohop: ffmpeg with the hls or dash muxer and nginx (or ffmpeg with the rtmp muxer sending to the nginx-rtmp module, which can generate hls) [19:37:39 CEST] <nohop> hmmm [19:38:01 CEST] <nohop> so i can't just get a buffer with it's output ? We're using our own webserver. No nginx [19:46:18 CEST] <kepstin> if you really want that, you should be able to make a custom AVIOContext and have nginx write to that [19:46:53 CEST] <nohop> hmmm [19:46:58 CEST] <nohop> i think there's a misunderstanding [19:47:04 CEST] <kepstin> have ffmpeg write to that i mean [19:47:07 CEST] <kepstin> sorry, typo [19:47:07 CEST] <nohop> oh [19:47:17 CEST] <nohop> i see, sorry :) [19:47:23 CEST] <nohop> okay, i'll look into that then [19:47:47 CEST] <kepstin> but that's gonna be tricky to deal with, since then you're responsible for getting the video to the browser... somehow, and browsers are very picky about how they accept video [19:48:04 CEST] <kepstin> so you're gonna have to do all the segmentation yourself then, which is of course hard. [19:48:31 CEST] <kepstin> (I don't *think* there's a way to use the ffmpeg segment muxer with a custom AVIOContext? could be wrong) [19:48:48 CEST] <nohop> Yeah, I see what you mean [19:49:29 CEST] <nohop> i might be better off using a horrible mjpeg stream :) [19:54:06 CEST] <furq> well if you want to use rawvideo (or mjpeg) then you'll need to have some custom handling for it anyway [19:54:17 CEST] <furq> in the browser, i mean [19:54:18 CEST] <furq> so it doesn't matter that much how you deliver it [19:54:39 CEST] <furq> rawvideo isn't really going to work over the web though unless it's very low resolution [19:55:51 CEST] <furq> if you actually want to use the browser's builtin video player, then you're pretty much stuck with hls or dash [19:56:42 CEST] <furq> and those are just mp4/mpegts/webm fragments served over http, so your webserver doesn't have to do anything other than serve files [19:57:13 CEST] <nohop> except i don't have files :) [19:59:52 CEST] <nohop> is this something ffmpeg could help me with, or am i better off getting some library aimed at doing this ? (as in, raw frames in -> servable bytestream out) [20:11:58 CEST] <JEEB> nohop: FFmpeg's libraries are just for that in my opinion [20:12:47 CEST] <JEEB> you make an AVFrame out of the raw samples, then feed that to a colorspace conversion filter if you need to switch between YCbCr and RGB one way or the other, then feed that result to an encoder [20:13:20 CEST] <JEEB> then you will get stuff out of the encoder (AVPackets) which you can then feed to the multiplexer that writes into some protocol [20:26:51 CEST] <kepstin> nohop: well, you could have files; just have ffmpeg's dash or hls muxer write files to a temp directory, then serve them up :) [20:27:22 CEST] <kepstin> nohop: the main problem is that for use in a web browser, there's no single servable bytestream you can use [20:28:39 CEST] <kepstin> I suppose you could maybe do something clever with sending stuff in a websocket connection then using mediasource extensions in javascript in the browser [20:29:30 CEST] <Mavrik> This is usually done by a streaming server instead of ffmpeg itself. [20:29:36 CEST] <Mavrik> But apparently he's doing something funny. [20:30:20 CEST] <kepstin> yeah, this is very much in "I want to write my own streaming server from scratch" territory, and that is of course very hard work :) [20:30:51 CEST] <Mavrik> I'd just deploy nginx-rtmp and let that handle it :P [20:39:28 CEST] <nohop> i know, i'm always doing things the hard and stupid way :) [20:39:54 CEST] <nohop> But i'll try to convince my colleagues that we need nginx :) [20:40:19 CEST] <furq> nohop: ffmpeg itself will write hls/dash fragments and the associated playlist [20:40:38 CEST] <furq> the libs will too but you don't really need it, you can just pipe rawvideo into ffmpeg [20:41:22 CEST] <nohop> yeah, but we're using the libs already. For now it just only outputs to files [20:41:31 CEST] <nohop> but they want a web interface aswell [20:42:31 CEST] <Johnjay> nohop: I looked everywhere for a rtmp compatible version of nginx [20:42:43 CEST] <Johnjay> turned out you have to download version 7.11.3 or some thing [20:42:54 CEST] <Johnjay> because obviously 7.11.2 just wasn't good enough for that [20:42:57 CEST] <Mavrik> There's a free plugin with a slightly misleading name " nginx-rtmp" [20:43:09 CEST] <Mavrik> Which also supports HLS and DASH (hence the misleading name) [20:43:19 CEST] <Mavrik> You can feed it directly from ffmpeg and it'll do segmentation and playlist stuff [20:43:35 CEST] <Mavrik> So basically [source] --> [ffmpeg] --> [nginx] ====> clients [20:43:51 CEST] <Mavrik> It's not the best streaming server I've seen, but it's plenty decent for a free one :) [20:46:50 CEST] <furq> and it's also very easy to set up [20:46:59 CEST] <furq> which isn't something i can say for any other free streaming server i've ever tried [20:47:57 CEST] <RonaldsMazitis> hello [20:48:01 CEST] <RonaldsMazitis> I am trying javascript version of ffmpeg [20:48:03 CEST] <RonaldsMazitis> and it does not find files in current directory [20:48:08 CEST] <RonaldsMazitis> how to find which directory my ffmpeg is in [20:49:29 CEST] <RonaldsMazitis> http://skatetube.sytes.net/VIDEOEDITOR/demo/ [20:49:39 CEST] <RonaldsMazitis> this is my javascript ffmpeg [20:50:01 CEST] <RonaldsMazitis> I need to know why it does not read files from current directory [20:50:51 CEST] <RonaldsMazitis> anyone? [21:02:11 CEST] <ChocolateArmpits> RonaldsMazitis, are you sure ffmpeg should be handling file finding? [21:04:00 CEST] <RonaldsMazitis> it should work on current directory [21:05:07 CEST] <RonaldsMazitis> http://bgrins.github.io/videoconverter.js/demo/ [21:05:12 CEST] <RonaldsMazitis> this is original [21:05:29 CEST] <RonaldsMazitis> "Also imagine that you have files called input.webm and input.jpeg in the current directory. " [21:07:10 CEST] <rjp421> i recently updated my rpi2 packages+kernel. when i tried to run ffmpeg, i got a missing .so (from libwebp.so.2 to .3 update)..... so i 'git pull'ed, and 'make uninstall ; make distclean ; make clean'... 'make -j5 && make install'.. i also rebuilt the /opt/vc/hello_pi with raspivid... but piping raspivid to ffmpeg suddenly gives Illegal Instruction https://pastebin.com/raw/hWRK9dVC [21:08:07 CEST] <rjp421> * piped to ffmpeg/ffprobe [21:10:28 CEST] <rjp421> this worked fine before the updates... how do i get further detail on the crash? even with loglevel debug, its not clear [21:12:12 CEST] <rjp421> i would use the h264_omx, but i need to v/hflip the video [21:12:25 CEST] <JEEB> make sure you build with debug symbols (aka, --disable-strip I think?) [21:12:34 CEST] <rjp421> afaik i couldnt do both at once? [21:12:48 CEST] <rjp421> JEEB, ok ty [21:12:49 CEST] <JEEB> and then build your own thing with -g3 -ggdb [21:12:57 CEST] <JEEB> (the hello_pi thing) [21:13:28 CEST] <JEEB> and then install gdb and follow rms's gdb tutorial http://www.unknownroad.com/rtfm/gdbtut/gdbuse.html#RUN [21:13:32 CEST] <JEEB> welcome to debugging on *nix .) [21:13:33 CEST] <JEEB> :) [21:14:05 CEST] <rjp421> ty, i will try. i just use their included "rebuild.sh" for the hello_pi (with raspivid) [21:14:25 CEST] <JEEB> make sure it has debug symbols enabled (-g3 -ggdb is what I usually use for compiler flags) [21:14:33 CEST] <JEEB> otherwise you will lose all visibility [21:14:49 CEST] <JEEB> basically, after `gdb program_name` it (gdb) should tell you that it was able to load symbols [21:14:58 CEST] <JEEB> if it can't find symbols, you're in trouble [21:14:59 CEST] <JEEB> :P [21:15:26 CEST] <JEEB> without symbols backtraces are rather... useless and uninformative [21:15:36 CEST] <JEEB> at most you find out the rough function something crashed in [21:15:42 CEST] <JEEB> if even that [21:16:55 CEST] <RonaldsMazitis> so why my javascript ffmpeg doesn't know current directory [21:19:35 CEST] <BtbN> Because it's running in a Browser and is isolated from everything, as it should be. [21:19:37 CEST] <rjp421> JEEB, "Reading symbols from /opt/vc/bin/raspivid...done." look good? should i still rebuild it? [21:19:48 CEST] <JEEB> that sounds positive [21:19:59 CEST] <JEEB> now if it finds the symbols from FFmpeg libraries as well [21:20:06 CEST] <JEEB> since by default I think FFmpeg strips [21:20:12 CEST] <JEEB> when it installs [21:24:12 CEST] <rjp421> ok, rebuilding with --disable-stripping [21:25:21 CEST] <JEEB> or it was --disable-strip [21:25:28 CEST] <JEEB> check if you get a warning when you try to configure [21:25:38 CEST] <JEEB> (--help |grep "strip" should show it) [21:29:37 CEST] <Mavrik> yeah, disable-strip and --enable-debug=3 helps [22:01:48 CEST] <rjp421> still compiling [22:13:50 CEST] <rjp421> now installing [22:15:09 CEST] <JEEB> rjp421: that's why I generally cross-compile and just rsync/copy/whatever to the ARM thing [22:15:12 CEST] <JEEB> because ARM things are *slow* [22:17:11 CEST] <rjp421> JEEB, how (should) to i get a coredump/backtrace? still just exiting with Illegal Instruction [22:17:27 CEST] <JEEB> when it crashes under gdb you should be able to get a backtrace [22:17:38 CEST] <rjp421> ah [22:17:48 CEST] <JEEB> see the tutorial I noted [22:21:22 CEST] <rjp421> JEEB, do i run gdb on raspivid or ffmpeg? im piping the raspivid to ffmpeg, which is when ffmpeg crashes. looking at that tutorial, im not sure which [22:22:01 CEST] <rjp421> gdb ffmpeg, then run <cmd>? [22:22:06 CEST] <JEEB> yes [22:22:09 CEST] <rjp421> ty [22:30:52 CEST] <rjp421> JEEB, doesnt look right https://pastebin.com/raw/2zycD73c ill try googling but not sure how to word the search [22:31:40 CEST] <JEEB> yea, you can only run a single thing in gdb [22:32:52 CEST] <rjp421> maybe rapsivid into a fifo, and use as input to ffmpeg? [22:33:27 CEST] <JEEB> or https://stackoverflow.com/questions/455544/how-to-load-program-reading-stdi… [22:33:34 CEST] <rjp421> ty [22:34:01 CEST] <JEEB> the fact that you can start running the program with -ex 'r parameters for thing' [22:34:14 CEST] <JEEB> and then the program at the end [22:47:50 CEST] <rjp421> -ex 'set args -loglevel debug -i - < raspivid ..... -o -' ? that the same as piping? [22:54:33 CEST] <rjp421> its not working :\ [23:17:10 CEST] <rjp421> JEEB, i wasnt able to figure out a working syntax, but i did get a coredump [23:20:48 CEST] <rjp421> Program terminated with signal SIGILL, Illegal instruction. [23:20:48 CEST] <rjp421> #0 ff_h264_idct_dc_add_neon () at libavcodec/arm/h264idct_neon.S:77 [23:20:48 CEST] <rjp421> 77 vld1.16 {d2[],d3[]}, [r1,:16] [23:21:29 CEST] <rjp421> JEEB, ^ sorry for flood [23:26:38 CEST] <rjp421> https://pastebin.com/raw/APRbBSgw lmk if i should paste 'bt full' [23:29:22 CEST] <rjp421> looks like something to do with decoding the h264 from the board? [23:33:31 CEST] <furq> rjp421: did you run rpi-update recently [23:33:41 CEST] <furq> it'll update the vc libs and headers [23:34:02 CEST] <furq> if you're running ffmpeg from git then you probably want the latest vc stuff [23:34:42 CEST] <furq> i've had similar problems in the past where i've had segfaults from running old vc libs even though it still built against them [23:35:26 CEST] <rjp421> furq, im using kali which doesnt have rpi-update... but i think still an old /opt/vc/.. i will get the latest src and rebuild ty [23:35:47 CEST] <furq> also yeah you probably want to cross compile ffmpeg if you have another *nix box [23:35:56 CEST] <furq> it's very easy on a recent-ish debian or ubuntu [23:52:56 CEST] <rjp421> git cloning the rpi-firmware is taking a long time... i just need the opt/vc folder [23:53:19 CEST] <Johnjay> rjp421: I have that folder. it's got neat stuff in it [23:53:26 CEST] <Johnjay> that's where the temp monitoring command is iirc [23:56:06 CEST] <rjp421> Johnjay, if you happen to have a pi-cam, and updated packages+kernel+ffmpeg-git, would you mind please piping raspivid to ffmpeg/ffprobe and see if you get the same crash as me? [23:57:21 CEST] <rjp421> im using kali which is not standard debian, maybe my setup [23:57:24 CEST] <Johnjay> ah cam is the one thing i didn't play around with on there [23:58:12 CEST] <Johnjay> i didn't even know raspivid was the command for camera until you said it [23:58:12 CEST] <rjp421> np :) if anyone else can try though it would be appreciated [23:58:15 CEST] <Johnjay> a problem i often run into on linux [23:58:49 CEST] <Johnjay> may I ask did you get mpv to work on it? or just ffmpeg? [23:59:22 CEST] <rjp421> Johnjay, its headless atm, no gui, so no mpv [23:59:33 CEST] <Johnjay> oh [00:00:00 CEST] --- Fri Sep 22 2017

1 0

ffmpeg-devel.log.20170920
by burek 21 Sep '17

21 Sep '17

[00:04:07 CEST] <jkqxz> Is fate-lavf-mxf_dvcpro50 meant to be failing? [00:11:55 CEST] <jamrial> jkqxz: not really [00:13:48 CEST] <jkqxz> It does for me, but no idea why at all. [00:13:52 CEST] <jkqxz> I've replied to the push on the ML to ask. [00:14:22 CEST] <jamrial> jkqxz: doesn't fail for me on mingw-w64 [00:14:32 CEST] <jamrial> it's a new test using the internal encoder and muxer [00:16:26 CEST] <cone-214> ffmpeg 03Mark Thompson 07master:375cf55fe9f5: vaapi: Disable deprecation warnings around use of old struct vaapi_context [00:16:27 CEST] <cone-214> ffmpeg 03Mark Thompson 07master:22afa87a8e90: kmsgrab: Fix DRM format definitions [00:16:28 CEST] <cone-214> ffmpeg 03Mark Thompson 07master:9f9625ea80ac: kmsgrab: Remove multiple-plane formats [00:16:29 CEST] <cone-214> ffmpeg 03Mark Thompson 07master:b0ece2b31fdf: hwcontext_vaapi: Fix DRM format mapping [00:16:30 CEST] <cone-214> ffmpeg 03Carl Eugen Hoyos 07master:f952edaa73ee: kmsgrab: Add more DRM plane formats [00:16:48 CEST] <jkqxz> Submitted fate results show it working everywhere else, too. [00:17:39 CEST] <jkqxz> Let me do a clean build and try again. Cosmic rays seem unlikely, but I guess they're possible. [00:18:36 CEST] <jamrial> jkqxz: https://0x0.st/7F_.mxf that's the "good" mxf output from the test [00:18:56 CEST] <jamrial> in case you want to compare it with what it generates in your case [00:19:53 CEST] <jamrial> i bet it's a byte or two somewhere in the header [00:21:14 CEST] <jamrial> jkqxz: also, want to check my hwcontext_dxva2 patch? [00:23:10 CEST] <jkqxz> Yep, looks like it <http://sprunge.us/hONZ>. [00:25:37 CEST] <jamrial> are you trying in some local branch or in a clean master? [00:25:55 CEST] <jamrial> it's really weird no fate client fails [00:26:19 CEST] <jkqxz> That's clean master now. [00:27:15 CEST] <jkqxz> Replied to the DXVA2 patch. [00:28:34 CEST] <jamrial> look at the file's metadata. your mxf file seems to have a modification_date tag the "good" output doesn't [00:30:14 CEST] <jkqxz> It passes on my laptop. Wtf. [00:31:32 CEST] <cone-214> ffmpeg 03James Almer 07master:18516d3e6959: avutil/hwcontext_dxva2: return an error when buffer allocation fails [00:56:48 CEST] <jkqxz> Right, shared libraries with the same version got me. [00:57:57 CEST] <cone-214> ffmpeg 03Carl Eugen Hoyos 07master:5cb70381d995: lavd/kmsgrab: Remove the mapping for AV_PIX_FMT_RGB8. [00:57:58 CEST] <cone-214> ffmpeg 03Carl Eugen Hoyos 07master:2f3a3a7e3270: lavf/utils: Do not force chapter end time before chapter start. [00:57:59 CEST] <iive> can we use DRI instead of DRM ? [00:58:03 CEST] <jamrial> a reminder to always test with static libraries :p [00:59:14 CEST] <jkqxz> Yeah. Normally you get a big "oh noes you fucked up!" message when you do that, but if they are exactly the same version then it doesn't notice. [01:00:50 CEST] <jamrial> debian stable is 3.2 it seems. I'd say a lot more tests should fail with a git master fate suite [01:00:51 CEST] <jkqxz> iive: What do you want to do with DRI? [01:01:22 CEST] <iive> just use that name [01:01:48 CEST] <jkqxz> Yeah. It was a copy I installed a day or two ago, so it was pretty much right except for that one test. [01:02:10 CEST] <iive> drm have a more popular meaning, that is still relevant in multimedia context. [01:02:28 CEST] <jkqxz> A meaning which should be subverted as much as possible. [01:02:44 CEST] <iive> that's not going to happen [01:02:56 CEST] <iive> you are just going to spread confusion. [01:03:24 CEST] <jkqxz> This is definitely DRM though, using libdrm and whatnot. You could kindof talk about DRI around it, but I would generally only use that to refer to the X11 protocols. [01:04:38 CEST] <jkqxz> I did write that frame-grabber originally on DRI2 rather than KMS, but it was much less useful in that form. [01:06:11 CEST] <iive> they did that mistake long ago... they are stuck with it. we can avoid it. [01:06:30 CEST] <iive> if you want you can use KMS instead... [01:11:07 CEST] <cone-214> ffmpeg 03Carl Eugen Hoyos 07master:b4b02477bd80: lavfi/stereo3d: Set SAR for every output frame. [01:13:28 CEST] <jkqxz> KMS is only one part of the DRM API. [02:14:40 CEST] <iive> jkqxz: yes, it is. it stands for kernel model setting and does little more than that. Yet it also signifies major API change. [02:15:52 CEST] <iive> the X does have modesetting DDX (2D driver), that can actually do a lot more than software framebufer. it does use glamor in order to provide 2D acceleration though opengl-like api. [02:16:59 CEST] <iive> so.. there will be no confusion if you use KMS. [02:19:43 CEST] <jkqxz> But I can only use KMS to refer to things which actually use KMS, such as kmsgrab. And that still returns DRM objects. [02:21:30 CEST] <cone-214> ffmpeg 03Carl Eugen Hoyos 07master:ca72cd137d3b: lavf/mpegts: Consider stream_type 0x0f just a hint towards AAC. [02:46:31 CEST] <wm4> I guess I acked a patch that was already merged [02:49:07 CEST] <iive> well, there used to be a custom, to send reply saying something has been committed, in order to avoid such confusion. [02:49:32 CEST] <iive> and no harm done. it would have been a problem if you rejected it ;) [03:01:11 CEST] <cone-214> ffmpeg 03Michael Niedermayer 07master:5480e82d7777: avcodec/pngdec: Clean up on av_frame_ref() failure [03:01:12 CEST] <cone-214> ffmpeg 03Thomas Mundt 07master:9777836670ae: MAINTAINERS: add myself for bwdif and (t)interlace [03:01:13 CEST] <cone-214> ffmpeg 03Kaustubh Raste 07master:f4ba85dc82f5: avcodec/mips: Fixed rnd_val variable to 6 in hevc uni mc msa functions [03:01:14 CEST] <cone-214> ffmpeg 03Kaustubh Raste 07master:e428e5ded626: avcodec/mips: preload data in hevc sao edge 0 degree filter msa functions [03:34:32 CEST] <cone-214> ffmpeg 03Carl Eugen Hoyos 07master:b4093e60c51a: lavf/caf: Support demuxing Opus. [04:08:23 CEST] <cone-214> ffmpeg 03Anton Khirnov 07master:5a3b602acda6: avformat/cafdec: reject multichannel Opus streams [14:10:41 CEST] <bove> where in the source can I find the bitstream filters? [14:12:54 CEST] <JEEB> bove: find . -iname '*bsf*.c' [14:13:03 CEST] <JEEB> they're all in libavcodec as far as I see [14:13:17 CEST] <bove> thanks [16:34:59 CEST] <kierank> atomnuker: meet at RO at 7? [16:40:05 CEST] <bjorn__> Hey all! Im working on this: https://trac.ffmpeg.org/ticket/4443 [16:40:15 CEST] <bjorn__> Ive got it working so that I can generate a transparent gif just fine but only a single frame. [16:40:28 CEST] <bjorn__> Multiple frames cause problems with the gif encodings oprtimizations, so I cant successfully create an animated gif with transparencies. [16:44:17 CEST] <bjorn__> I am pretty familiar with teh Gif format, but Im confused about how FFMPeg handles incoming transparencies. [16:48:37 CEST] <bjorn__> Is libavcodec/gif.c even designed to handle this situation? [18:18:31 CEST] <atomnuker> kierank: yeah, I'll be there [18:51:45 CEST] <atomnuker> kierank: sorry, can't go, got a meeting at 19:00 and I need to sleep right after it (messed up sleeping cycle for a month now) [18:52:54 CEST] <atomnuker> also got to finish my slides, send a patch for the opus psy thing and if I find the time eat [18:53:03 CEST] <atomnuker> we'll drink in paris on friday [18:53:13 CEST] <kierank> No Louie though [18:53:36 CEST] <kierank> It was meant to be louie's leaving party [19:11:59 CEST] <kierank> atomnuker: are you going to Disneyland [19:16:39 CEST] <atomnuker> no [21:46:08 CEST] <durandal_170> comming to disneyland with guns [21:50:02 CEST] <JEEB> no, you just have fun there [21:52:28 CEST] <Compn> nerf needs to do a nerf gun theme park [22:37:14 CEST] <gnafu> Compn: Wow, why haven't they already? [22:37:28 CEST] <gnafu> As soon as I read that... [22:37:32 CEST] <gnafu> Never thought of it before. [23:51:40 CEST] <Compn> gnafu : i am an expert consultant, you can have my idea for $500k [23:53:01 CEST] <j-b> you are cheap [23:53:27 CEST] <Compn> i was going to say $1m but i know gnafu does not have this on hand. [23:53:47 CEST] <wm4> regarding VDD, will there be a meeting between ffmpeg and libav [23:54:08 CEST] <JEEB> I don't think many from FFmpeg will be going [23:54:13 CEST] <Compn> there have been meetings at previous VDD for this [23:54:53 CEST] <iive> haven't there been meeting almost every year? [23:55:05 CEST] <iive> s [23:55:12 CEST] <JEEB> I think after that one co-meeting there was mostly just project-specific meetings [23:55:27 CEST] <Compn> iive : yes [23:55:42 CEST] <Compn> there are also project specific meetings. [23:56:20 CEST] <Compn> is this the year j-b will lay down the new plan? :P [23:56:25 CEST] <JEEB> lol [23:56:42 CEST] <JEEB> "everyone sucks, I'm going home" I guess ;) [23:56:44 CEST] <j-b> nope [23:56:46 CEST] <iive> wan't the new plan like 2 years ago? [23:57:02 CEST] <j-b> yeah, I offered some ideas and help [23:57:06 CEST] <j-b> my life has moved on [23:57:17 CEST] <JEEB> makes sense [23:57:17 CEST] <Compn> j-b : good , no reason to stress over this nonsense :) [23:57:42 CEST] <j-b> I'll make more money and have less pain than fight for other people to get rich [23:57:47 CEST] <Compn> i also offered help and ideas. but i also gave up :) [23:59:00 CEST] <Compn> https://www.youtube.com/watch?v=91edAkvQCxI [23:59:09 CEST] <Compn> australia solved the piracy problem! [23:59:39 CEST] <wm4> huh so all reunification ideas are dead [23:59:48 CEST] <wm4> and just merging libav commits is also dead [00:00:00 CEST] --- Thu Sep 21 2017

1 0

ffmpeg.log.20170920
by burek 21 Sep '17

21 Sep '17

[00:20:33 CEST] <DHE> kevinn_: see the doc/examples directory [00:21:26 CEST] <kevinn_> I see it, thank you! [02:55:14 CEST] <kevinn_> DHE: hey are you familiar with this example: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/examples/decode_video.c;… [02:57:32 CEST] <DHE> kevinn_: got a specific question? [02:58:05 CEST] <kevinn_> I just had a question as to where my actual picture data is... Is it in frame->data[0] on line 78? [02:59:02 CEST] <DHE> it depends on the format. for planar data, frame->data[0] will have all the data in frame->linesize[0] strides [02:59:47 CEST] <kevinn_> I think the data I am passing is what is called packed data, so will frame->data[0] also be packed? [03:00:13 CEST] <kevinn_> or am I confusing that term with something else [03:01:00 CEST] <DHE> the opposite of planar means that each compontent (Y,U,V or R,G,B) will be in frame->data[0], data[1], and data[2]. [03:02:01 CEST] <kevinn_> Ah! then I am using planar! okay cool, thank you so much for the help! [03:02:12 CEST] <DHE> or do I have them backwards... :/ [03:02:24 CEST] <DHE> I don't do this very much so I might have my terms mixed up slightly [03:03:49 CEST] <kevinn_> okay well let me test and see if that is the case [03:04:36 CEST] <SavinaRoja> I'm tying to use the ffmpeg static builds for linux on linux server, but I keep getting an error each time I use ffmpeg on output "Error initializing output stream 0:0" [03:09:39 CEST] <SavinaRoja> https://pastebin.com/Y8J8UEjy is a minimal reconstruction [03:11:08 CEST] <DHE> no error reported from x264... that's unexpected [03:11:27 CEST] <DHE> as an experiment, before the output filename put -crf 25 [03:11:46 CEST] <DHE> since you didn't specify any parameters [03:12:40 CEST] <SavinaRoja> https://pastebin.com/TujcuthM [03:13:34 CEST] <DHE> not that.. [03:14:01 CEST] <SavinaRoja> DHE: the original script, which runs on my local machine, has a lot more specification [03:24:54 CEST] <SavinaRoja> DHE: was there some other information I should provide? [03:25:35 CEST] <DHE> nothing comes to mind. someone else might be able to provide more insight [03:27:56 CEST] <SavinaRoja> I may just need to have their admin actually update the system... local code runs as expected [03:31:13 CEST] <SavinaRoja> but something else might be wrong, because this same error happens with the system installed version [03:42:26 CEST] <kevinn_> DHE: so I checked frame->data[0] byte for byte and but the data seems totally incorrect... [03:42:38 CEST] <kevinn_> and it doesn't even have the full framebuffer size [03:42:46 CEST] <kevinn_> it segfaults part way through [03:44:40 CEST] <DHE> kevinn_: did you check the linesize? see the save function from the sample application [03:46:24 CEST] <kevinn_> I ran x264 on a 1376x768 buffer with each pixel being 32 bits. The line size says it is 1376 but only reaches index 391151 (color wise). [03:46:38 CEST] <kevinn_> save function... do you mean decode? [03:47:03 CEST] <kevinn_> or do you mean pgm_save [03:47:04 CEST] <kevinn_> ? [03:47:17 CEST] <DHE> yeah the save function [03:48:10 CEST] <kevinn_> okay let me make it look identical to that [03:49:08 CEST] <DHE> hmm... 768 * 1376 should be good, but it wasn't [03:51:18 CEST] <kevinn_> wait a minute, this doesn't make sense: fwrite(buf + i * wrap, 1, xsize, f);. buf is a char array, so each element is 1 byte long. xsize is 1376. This function should copy line by line, but that can't be possible because each of my colors is 32 bits. so xsize should really be 1376 * 4 [03:51:21 CEST] <kevinn_> right? [03:52:47 CEST] <DHE> then it's probably in 3 planes. it'll be either red or luma in frame[0] [03:52:55 CEST] <DHE> check if the other frames have data [03:54:32 CEST] <kevinn_> okay the other frames do have data... [03:54:42 CEST] <kevinn_> is the alpha channel just chopped off? [03:55:25 CEST] <DHE> h264 doesn't do transparency [03:55:59 CEST] <kevinn_> right, okay that's fine [03:56:27 CEST] <kevinn_> but how can I tell if these points are yuv or rgb? [03:57:21 CEST] <kevinn_> the numbers are jumping around so much, I fear it might by yuv... [03:58:00 CEST] <DHE> AVFrame has a `format` field which will be one of AV_PIX_FMT_* such as YUV420P [04:01:30 CEST] <kevinn_> ahh, if I set it to AV_PIX_FMT_BGR32 will it be one buffer? [04:01:44 CEST] <kevinn_> like packed into frame[0]? [04:01:48 CEST] <DHE> well you get AVFrames from the decoder, so it's the decoder that provides them [04:02:54 CEST] <kevinn_> sorry, I don't get what you mean [04:04:27 CEST] <DHE> the decoder provides frames in the format it wants. for h264 that's almost always YUV [04:05:38 CEST] <kevinn_> hmm, okay so youre saying I can't change the format? [04:07:48 CEST] <SavinaRoja> DHE: very very odd, I can do h265 output [04:13:25 CEST] <kevinn_> DHE: can I not change the format? I added this bit of code: frame->format = AV_PIX_FMT_BGR32; and it didn't have an effect on the output [04:39:25 CEST] <kevinn_> Does anyone know how to change the decode format for libavcodec? [04:42:56 CEST] <jeffW_> Hi, I'm trying to build ffplay.exe by follow this guide from the wiki: https://trac.ffmpeg.org/wiki/CompilationGuide/MSVC I am using MSYS2, and have performed pacman -S make mingw-w64-x86_64-gcc mingw-w64-x86_64-sdl2 mingw-w64-x86_64-diffutils mingw-w64-x86_64-pkg-config [04:43:12 CEST] <jeffW_> I have opened: "VS2015 x64 Native Tools Command Prompt" and run vcvarsall.bat x86_amd64 then in MSYS2/Mingw-w64 I have run: export PATH="/c/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/x86_amd64":$PATH [04:43:23 CEST] <jeffW_> Then I checked this by typing which link produced: /c/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/x86_amd64/link [04:43:55 CEST] <jeffW_> I then performed: ./configure --prefix=/c/ffmpeg-output-shared --disable-network --disable-postproc --enable-gpl --enable-version3 --enable-asm --disable-encoders --arch=x86_64 --disable-ffserver --disable-ffmpeg --disable-ffprobe --disable-doc --enable-shared --disable-static --disable-bzlib --disable-libopenjpeg --disable-iconv --disable-zlib --pkg-config=pkg-config --toolchain=msvc [04:44:04 CEST] <jeffW_> This gave me the error: cl is unable to create an executable file. If cl is a cross-compiler, use the --enable-cross-compile option. Only do this if you know what cross compiling means. C compiler test failed. [04:44:21 CEST] <jeffW_> As it says in the wiki, if you get this error, it could be caused by using the wrong link.exe (But, as I explained, I already verified that is not the issue), or, "This can also indicate that you are mixing 64bit and 32bit versions of cl.exe and link.exe." [04:44:31 CEST] <jeffW_> Since I verified via which link and which cl that msys2/mingw-w64 is getting them from /c/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/x86_amd64/link I don't see how that could be possible. [04:44:43 CEST] <jeffW_> Can anyone help me figure out where I am going wrong here? [05:29:40 CEST] <kepstin> kevinn_: the video format returned by the decoder is based on the video stream itself and the decoder implementation. If you want something different, then use libswscale to convert it (but note that the conversion can cause some loss in precision) [05:30:29 CEST] <kevinn_> kepstin: the video stream itself is in that format, for some reason the decoder is splitting the bits up [05:31:17 CEST] <kepstin> how was the video made? [05:31:34 CEST] <kevinn_> the video was made using x264 [05:31:37 CEST] <kepstin> if the decoder's giving you YUV, then the stream is in YUV [05:31:57 CEST] <kevinn_> ahh, actually that was a bit inaccurate when I stated that [05:32:06 CEST] <kevinn_> It actually turned out to be rgb [05:32:10 CEST] <kepstin> note that when using x264 with the ffmpeg wrapper, you have to use the 'libx264rgb' encoder if you want an RGB stream. [05:32:43 CEST] <kevinn_> but it is still splitting it up into three buffers which I don't want [05:33:14 CEST] <kevinn_> anyway to make it output into one buffer? something like this? AV_PIX_FMT_BGRA [05:45:39 CEST] <kevinn_> kepstin: if you're still around is there anyway you can help me have avcodec_receive_frame output in a different format? such as AV_PIX_FMT_BGRA? [05:46:07 CEST] <kevinn_> I implemented get_format to see what formats are supported and the only one it printed was 82 [05:46:38 CEST] <kepstin> kevinn_: use libswscale to convert it to the format you want. if it's rgb with the same depth it's a lossless conversion. [05:47:32 CEST] <kevinn_> but is there no way to have libav output in the right format? what purpose does AV_PIX_FMT_BGRA serve if it can't be used? [05:49:11 CEST] <kepstin> some encoders/decoders use that rather than a planar rgb format, and you can convert to/from it [05:49:58 CEST] <kepstin> the formats supported depend on what the video stream contains + how the person who implemented the decoder decided to handle it [05:50:43 CEST] <kepstin> with the ffmpeg h264 decoder, since the internal way it represents rgb is planar, that's what you get out. [05:51:12 CEST] <kepstin> adding support for other formats would mean converting in the decoder, and that would be silly since that's what libswscale is for [05:51:45 CEST] <kevinn_> okay, I see, thank you so much for your help, I will use libswscale. [05:52:21 CEST] <kevinn_> Is libswscale quick enough where if I do it to every frame it will still look as if it is streaming? [05:52:31 CEST] <kevinn_> or will I likely have to multithread? [05:52:44 CEST] <kepstin> not if you're running it on a 100mhz pentium with a 4k stream [05:52:52 CEST] <kepstin> need more info [05:53:16 CEST] <kepstin> (on any reasonably modern computer, converting from planar to packed rgb should be ridiculously fast) [05:53:22 CEST] <kevinn_> 2k stream on an arm processor [05:53:40 CEST] <kevinn_> rpi3 [05:53:54 CEST] <kepstin> hmm, why do people keep trying to do video stuff on rpi :( [05:54:21 CEST] <kepstin> it'll probably work fine tho for decoding and converting to bgra. [05:54:30 CEST] <kevinn_> you don't think it'll be fast enough? [05:54:41 CEST] <kevinn_> okay :) [05:55:01 CEST] <kepstin> most of the people who run into issues on rpi are trying to encode, which is rather more cpu intensive. [05:55:46 CEST] <kepstin> but really, you're just gonna have to try and see for yourself :/ [06:03:32 CEST] <jeffW_> Could anyone help me figure out how to get FFmpeg to compile with MSYS2 ? I think I've tried everything, and the best I've gotten is exe's that crash when I try to use them. [07:28:52 CEST] <pankaj_> I'm trying to compress video but not getting success for mp4 files [07:31:09 CEST] <pankaj_> https://pastebin.com/nhgyxeAK [07:31:19 CEST] <pankaj_> command line [08:29:02 CEST] <dongs> does ffmpeg do MMT streams [08:29:44 CEST] <dongs> https://en.wikipedia.org/wiki/MPEG_media_transport i.e. thsi [08:31:45 CEST] <dystopia_> it can probably decode it [08:32:01 CEST] <dongs> its a container, not encoding format [08:32:40 CEST] <dystopia_> then i dunno [08:33:38 CEST] <dongs> http://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/2015-October/003151.html [08:33:41 CEST] <dongs> some discussion from 2015 [08:34:41 CEST] <dongs> http://gstreamer-devel.966125.n4.nabble.com/MPEG-MMTP-Element-td4684325.html [08:34:42 CEST] <dongs> RIP [08:36:17 CEST] <dongs> i've got an entire satellite doing ~500mhz worth of shit with MMTP, i wouldnt mind looking at some of it [08:36:55 CEST] <dystopia_> which sat out of curiosity? [08:37:17 CEST] <dongs> 132E so probly of no interest to you [08:37:18 CEST] <dystopia_> i can receive 5w to 28.2e [08:37:24 CEST] <dystopia_> ahh [08:37:26 CEST] <dongs> yea, other side of the world :D [08:38:21 CEST] <dongs> hmm i see 188byte packets in there with what looks like TS [08:38:25 CEST] <dongs> but alignment is inconsistent [08:38:45 CEST] <dystopia_> do you have transedit? [08:38:59 CEST] <dystopia_> i believe there is a free version [08:39:15 CEST] <dongs> yeah i have transedit/dvbiewer license. that isnt gonna help tho, this is lower level than that [08:39:15 CEST] <dystopia_> very good at analyzing transponders [08:41:23 CEST] <dongs> ya ffmpeg tries to sync to ts adn fails, but it definitely looks like mpeg2ts inside some weird container on top of it [08:41:53 CEST] <dystopia_> does ts-doctor tell you anything? [08:42:02 CEST] <dystopia_> has a free trial also if you have no license [08:48:14 CEST] <dongs> anyaw,y im almsot certain its mmtp with mpegts as its payload [08:48:27 CEST] <dongs> because there's definitely ts packets inside but t hey're intermixed with garbage [08:48:40 CEST] <dongs> maybe ill write some simple thing to go through and pull out everything with TS sync byte every 188bytes [08:48:43 CEST] <dongs> and see if that works [08:54:28 CEST] <dongs> that was easy [08:59:33 CEST] <dystopia_> it worked? [08:59:58 CEST] <dongs> it worked to pull about half the packets out and at least it looks like a transport stream etc, but too many cc errors, maybe packets are out of order or something in the mmt shit [09:00:12 CEST] <dongs> or it could be several transport streams muxed into a single thing (which is hte point of mmt i guess) [09:03:33 CEST] <dongs> got a bug where i forget to write last packet after sync loss [09:03:38 CEST] <dongs> maybe that'll fix it. [09:13:59 CEST] <dongs> damn [09:14:04 CEST] <dongs> the garbage nbetween ts bytes is variable too [09:14:20 CEST] <dongs> and mmtp doesnt seem to have any sync header type shit so i dont actually know if its mmtp stuff or not [09:32:40 CEST] <dongs> oh well giving up and moving my shit to the actual satellite i wanetd to be at. looks like opensource isnt gonna deliver anything useful this time either [10:36:36 CEST] <chuckleplant> Hi, I'm decoding an incoming RTSP stream. Everything works fine but I sometimes see some stutter. This is because I'm not using presentation timestamp or framerate at all. If I display frames as they come, they are ordered and fine... however, now that I want to use the PTS, I see that from the RTSP stream they are not in strict order [10:38:46 CEST] <chuckleplant> Here's a plot of the PTS of my AVFrames after I decode them: https://imgur.com/a/gNlhI [10:39:03 CEST] <chuckleplant> Should I be sorting frames as I queue them in my display buffer? [10:39:36 CEST] <BtbN> decoders should give you frames in display order [10:40:22 CEST] <chuckleplant> They are in display order (their PTS is not) .. but I'm not sure how to display them for their appropriate duration [10:40:45 CEST] <BtbN> that makes no sense [10:41:12 CEST] <BtbN> either they are in display order, so their PTS are monotonically increasing, or they are not [10:41:57 CEST] <chuckleplant> I say they're in display order, because I see no problem when visualizing the image, however, their PTS plot is the one I linked above [10:42:57 CEST] <BtbN> that plot makes no sense. In no location of a decoding chain [10:48:17 CEST] <chuckleplant> I sure made a mistake somewhere.. let me rephrase the question and forget about the PTS for a sec. Assuming a proper decoding pipeline. What is the proper way to display frames at the correct framerate? I already have a buffer of decoded AVFrames [10:49:01 CEST] <BtbN> You display them at the time their pts says, relative to from where you started playing [10:51:25 CEST] <JEEB> the PTS are just a way for you to synchronize on the time line (taking into account that different streams can and will have their own time_base) [10:52:03 CEST] <chuckleplant> Ok I see now [10:52:32 CEST] <chuckleplant> In my decoding pipeline the PTS is not set. When I get a frame with avcodec_decode_video2, the PTS value is always the same [10:52:48 CEST] <JEEB> for example audio packets might be on a time base of 1/4800, and then video on 1001/24000 for example [10:53:07 CEST] <chuckleplant> I must say this is a live RTSP H264 stream [10:53:09 CEST] <JEEB> and then the PTS should be the thing to synchronize between those [10:53:29 CEST] <JEEB> yea, it might be garbage in garbage out if the input doesn't have timestamps [10:53:43 CEST] <JEEB> I recommend looking at it with ffprobe's -show_frames for a while [10:53:52 CEST] <JEEB> if you want to parse it as json there's -of json [10:54:27 CEST] <JEEB> there's a way to limit ffprobe to a certain amount so you can stop it after X seconds without ctrl+C [10:54:36 CEST] <JEEB> (just don't ask me the parameter :P) [10:54:55 CEST] <chuckleplant> JEEB, the incoming stream does have PTS set in all the NAL units [10:55:24 CEST] <chuckleplant> Maybe I should be setting the AVPacket PTS somewhere before decoding? [10:55:27 CEST] <chuckleplant> hmmm [10:58:24 CEST] <chuckleplant> JEEB, thanks! Not completely clear on the time_base.. Las I checked my time_base was 0/2, does that make sense? [11:10:25 CEST] <chuckleplant> So I now set the appropriate AVPacket->pts from the incoming nal units. However, the PTS after decoding is still garbage [11:10:39 CEST] <chuckleplant> The decoder just does not set it [11:10:42 CEST] <chuckleplant> does this make sense? [11:43:21 CEST] <BtbN> chuckleplant, if your timebase is 0, that's not too surprising. [11:43:40 CEST] <BtbN> You also shouldn't need to parse any NAL units. The demuxer should give you valid timestamps already. [11:46:32 CEST] <JEEB> there's a h264 demuxer for raw annex B (and the rtsp protocol should pretty much stick you with it) [11:46:47 CEST] <JEEB> so that you can just feed the "rtsp://.." url to lavf [11:46:56 CEST] <JEEB> and you get AVPackets from it [11:50:58 CEST] <chuckleplant> JEEB, I thought I only needed a demuxer when I did not have a raw H264 stream. WHat I'm getting in my decoder are nal units with a presentation timestamp set. Should I feed that to a demuxer instead of filling the AVPackets manually? [11:51:58 CEST] <JEEB> I would test that out, although if your input is RTSP you can just feed that to libavformat [11:52:05 CEST] <JEEB> so that you don't have to add the H.264 stuff [11:52:16 CEST] <JEEB> it's just rtsp and the rtsp protocol picks whatever demuxer you need [11:54:30 CEST] <chuckleplant> Assuming I can't use libavformat, what must be set to AVPacket for the decoder to provide a PTS in the decoded AVFrames? [11:54:47 CEST] <chuckleplant> Due to the nature of my application and codebase I can't use libavformat, just libavcodec [11:58:12 CEST] <JEEB> ok, it seems like the parsing stuff is in the H.264 parser and the "demuxer" is just a probe function :) [11:59:42 CEST] <JEEB> although it does limited stuff with DTS/PTS [12:00:48 CEST] <JEEB> chuckleplant: basically you need to set valid DTS at the very least, might need the PTS as well although for that you'd have to parse the bit stream more (the decoder does the reordering for you, but the values you get for PTS etc might be funky [12:00:53 CEST] <JEEB> so start with DTS [12:00:55 CEST] <JEEB> then PTS [12:01:45 CEST] <chuckleplant> JEEB, thanks. My h264 parser only provides a PTS for each Nal unit. How can I determine the DTS from that? [12:11:47 CEST] <BtbN> Doing the re-ordering magic manually is a mess [12:12:28 CEST] <BtbN> I don't think you strictly needs dts though, if your packets come in in the right order [12:14:01 CEST] <Wodjin> Hello everyone, i'm using ffmpeg to try and add text to a video, the text has a background box containing it and I'm wondering if there is any way to fade the text and the box both in and out? more info on my issue here: https://video.stackexchange.com/questions/22379/fade-text-with-background-w… [12:15:38 CEST] <BtbN> you'll probably have to come up with a forumla to do the fading based on frame count or timestamps [12:15:49 CEST] <BtbN> and then somehow put that into the overlay/blend filters [12:16:59 CEST] <chuckleplant> BtbN, I don't want to re-order, just to know the PTS for rendering. I know my decoded frames are in the right order (because they render properly). It's just that there's a time stutter on the display side, decoding is fine... besides the PTS thing. [12:17:24 CEST] <BtbN> If you want to deduce the input dts, you will have to re-order the pts. [12:18:33 CEST] <Wodjin> hmm are you talking about something like fontcolor_expr? I've used that to fade the text itself but from what I've seen on other ppl's posts it looks like there is no alpha channel on the container box for the drawtext function [12:18:50 CEST] <Wodjin> also, thanks for the quick feedback BtbN! [12:20:22 CEST] <chuckleplant> BtbN, you mentioned I may not need dts. Assuming packets are ordered, how would you proceed? (thanks for your patience) [12:20:43 CEST] <BtbN> chuckleplant, just decode them in the right order, and pass through the pts. The decoder should re-order them [12:20:57 CEST] <BtbN> you need a valid and correct timebase though. if it's 0, the timestamps will be 0 or nonsensical [12:21:26 CEST] <BtbN> Wodjin, the blend filter has an all_expr argument, where you can stick in a formula [12:21:33 CEST] <BtbN> https://ffmpeg.org/ffmpeg-filters.html#blend_002c-tblend [12:21:40 CEST] <BtbN> There are some examples for fading [12:23:10 CEST] <chuckleplant> I see, then maybe it's about the time_base. So far, no matter what I do, my decoder always sets (or doesn't) the same PTS : -9223372036854775808 , which is nonsensical indeed [12:23:45 CEST] <BtbN> If you are parsing the raw h264 yourself, the timebase is in the SPS [12:24:05 CEST] <chuckleplant> I see, thanks! [12:30:46 CEST] <chuckleplant> BtbN, I'm testing with fprobe, is time_base in api, equivalent to timecode? [12:31:00 CEST] <BtbN> what? [12:31:10 CEST] <chuckleplant> BtbN, please forget that last line [12:31:20 CEST] <BtbN> The time_base is the increment the timestamps represent [12:31:53 CEST] <BtbN> so if the timebase is 1/30, and the timestamp increments from 1 to 2, it means 1/30 of a second [12:32:54 CEST] <chuckleplant> BtbN, so ffprobe does print a time_base of 1/90000, but my application does not.. :( Do I need to instantiate a AVStream? Or should the CodecCtx be getting this information too? [12:34:25 CEST] <BtbN> I thought you're only using avcodec? [12:34:36 CEST] <chuckleplant> Yes, I'm testing the incoming stream with ffprobe [12:35:09 CEST] <BtbN> avcodec will not give you the timebase. [12:35:13 CEST] <BtbN> it expects it as an input [12:35:21 CEST] <BtbN> So you will have to peel it out of the raw bitstream yourself [12:35:30 CEST] <chuckleplant> I see [12:35:32 CEST] <BtbN> which is why using more then just avcodec is probably a good idea [12:54:10 CEST] <Wodjin> BtbN, sorry for the delayed response, can i apply a blend filter to the drawtext filter only? to make only the result of the drawtext fade in and out? Sorry I never used this filter so I'm slightly lost :) [12:54:33 CEST] <BtbN> you'll have to build a complex filter chain, yes [12:55:33 CEST] <Wodjin> allright, thanks for the pointer, i'll dig deeper into it [13:18:37 CEST] <chuckleplant> BtbN, i've been reading on sps and pps.. is there a method in ffmpeg to parse the sps and get back the time_base info? I can use libavformat, just not the whole h264 parser. Can't find in ffmpeg code where time_base is set either [13:26:46 CEST] <BtbN> chuckleplant, it will be somewhere in the h264 parsing code in avcodec [13:27:02 CEST] <BtbN> but likely private API to use individually [14:24:47 CEST] <echelon> hi [14:25:08 CEST] <echelon> i'm recording from v4l2 webcam source [14:25:26 CEST] <echelon> but would like to be able to do playback while it's recording [14:25:35 CEST] <echelon> i have to start from the beginning every time [14:25:48 CEST] <echelon> i'm using an mkv container, is there something else i could do? [15:23:58 CEST] <c_14> echelon: -live 1 [15:24:27 CEST] <echelon> c_14: to ffmpeg? [15:24:31 CEST] <c_14> yes [15:24:35 CEST] <c_14> as an output option [15:24:52 CEST] <echelon> what does that do to file structure [15:25:11 CEST] <c_14> It just tells the matroska muxer not to write the CRC elements [15:25:25 CEST] <echelon> cool, thanks! :) [15:31:20 CEST] <advin> what is libavcodec/videotoolbox.h file is? [15:38:23 CEST] <DHE> it's a header file. what more do you need? [15:40:20 CEST] <paradoxspiral> Hey, I'm encoding a vid to x265 10bit. htop shows that ffmpeg uses between 35-40% of my cpu (r7 1700), io should be fine. Is it expected that it doesn't use my cpu's full potential, if so, why? [15:41:04 CEST] <c_14> how big is the video? [15:41:20 CEST] <c_14> (resolution) [15:41:30 CEST] <DHE> when the number of CPU cores is high multi-threading becomes less effective and CPU utilization doesn't reach 100% [15:41:45 CEST] <advin> Thanks, I know it's headerfile, but what I wonder is the purpose/use of that header file. [15:41:59 CEST] <paradoxspiral> 1280x720, c_14 [15:42:32 CEST] <paradoxspiral> 4 hours long. i left it on over the night and it got 1h done [15:43:43 CEST] <advin> h265 require more cpu time than h264. [15:44:13 CEST] <paradoxspiral> tbh I'd expect at least 60% usage, iirc AMD always advertize their great encoding potential [15:46:06 CEST] <DHE> that's more a statement of x265 than on AMD. the software isn't making full use of the hardware [15:46:19 CEST] <DHE> believe me, I've run a ryzen at 100% [15:46:36 CEST] <paradoxspiral> yeah, i was wondering [15:46:45 CEST] <paradoxspiral> whether it was because of ffmpeg or x265 [15:46:54 CEST] <paradoxspiral> does that even make sense? maybe not [15:48:13 CEST] <DHE> while ffmpeg (the CLI itself) could use some multi-threading improvements, I think x265 is the larger bottleneck if you're running at 1/8 realtime speed and not using the CPU very well [15:50:00 CEST] <paradoxspiral> I guess nothing I can do then >> [16:03:31 CEST] <alexpigment> hey guys, is there any way to build ffmpeg such that x264 uses a max number of threads, but is otherwise "auto"? [16:04:17 CEST] <c_14> I'm pretty sure x264 doesn't report the number of threads it uses internally to ffmpeg [16:04:22 CEST] <c_14> (though it might, not sure about the api) [16:04:30 CEST] <c_14> would require patching ffmpeg (and/or x264) though [16:04:57 CEST] <c_14> paradoxspiral: if you knew beforehand you could split the source file into x sections, encode those with different processes and then stitch them together afterwards [16:06:05 CEST] <paradoxspiral> c_14: ah, that'd work I think. ty [16:06:27 CEST] <alexpigment> c_14: so the -threads command can't be limited in some mathematical way? [16:06:40 CEST] <c_14> well it can [16:06:43 CEST] <c_14> if you use your shell [16:08:23 CEST] <c_14> well [16:08:33 CEST] <c_14> you can always set -threads to the max number [16:08:42 CEST] <c_14> but then you'll always have that many threads [16:11:43 CEST] <alexpigment> is there any downside to specifying 16 threads, then running it on a dual core non-hyperthreaded system? [16:12:02 CEST] <alexpigment> in other words, is it possible to overload a system by defining more threads than x264 would automatically allocate by itself? [16:12:25 CEST] <c_14> yeah, you get threading overhead [16:12:37 CEST] <alexpigment> yeah, that's my thought [16:13:24 CEST] <alexpigment> i just wish you could define something like "-threads (0,<17)" [16:14:03 CEST] <alexpigment> I suppose I could edit the x264 source code to do this somehow [16:15:28 CEST] <JEEB> that's something that you could in the libavcodec level [16:15:42 CEST] <JEEB> -threads_max etc [16:16:12 CEST] <JEEB> libx264 just wants a number or auto from you which you then adjust in libx264.c [16:16:24 CEST] <JEEB> no need to touch libx264 itself unless there's some specific reason :) [16:17:48 CEST] <alexpigment> JEEB: if the numeric value of auto is 0, do you think it would still be possible to limit to 16 at the libavcodec level? [16:18:11 CEST] <alexpigment> because it would have to limit to what auto turns out to be on the given system, which I suspect is actually in libx264 [16:18:27 CEST] <alexpigment> (in reality, it's 1.5x the number of logical cores) [16:20:28 CEST] <JEEB> alexpigment: yes, you just make another avcodec option for libx264 which is 'threads_max' or so [16:20:42 CEST] <JEEB> although... if you want to use auto [16:20:51 CEST] <alexpigment> yeah, i'm wanting to use auto [16:21:12 CEST] <alexpigment> to prevent using 16 threads on a system with 2 or 4 logical cores [16:21:13 CEST] <JEEB> ok, then you might need to poke libx264's developers first, then the libavcodec wrapper [16:21:24 CEST] <alexpigment> yeah that's what I'm thinking [16:21:25 CEST] <JEEB> wait how the fuck would it go so high :P [16:21:35 CEST] <alexpigment> well i need to limit it to 16 [16:21:37 CEST] <JEEB> since it's 3*<virtual cores> / 2 [16:21:42 CEST] <JEEB> IIRC [16:21:45 CEST] <alexpigment> right [16:22:13 CEST] <alexpigment> i'm just thinking that it would be hard to limit it in libavcodec when I'm using auto because it would have to know what the numeric value of auto is [16:23:02 CEST] <JEEB> according to my calc the thread number for four virtual (as I'm not sure what "logical" is) cores is (4*3) / 2 => 6 [16:23:07 CEST] <alexpigment> yes [16:23:09 CEST] <alexpigment> that is correct [16:23:15 CEST] <JEEB> which is what auto would go for [16:23:18 CEST] <alexpigment> right [16:23:27 CEST] <alexpigment> but what if you have a system with 32 logical cores [16:23:36 CEST] <JEEB> right, yes. now that example makes sense :P [16:23:36 CEST] <alexpigment> then you get 48 threads and 4K encoding fails [16:23:54 CEST] <JEEB> I'm an asshole in that sense [16:24:21 CEST] <JEEB> but yea, adding another parameter into the libx264 API shouldn't be too hard :P [16:24:30 CEST] <JEEB> poke #x264dev if the core devs of x264 are interested in that [16:24:34 CEST] <alexpigment> so i'm wanting to keep auto up to a point, but go no further than 16, because there's a warning explicitly saying that anything above 16 is recommended [16:24:45 CEST] <alexpigment> will do. thanks JEEB [16:25:01 CEST] <JEEB> I could see that as useful for myself as well I guess [16:25:12 CEST] <JEEB> although currently I'm just defining thread counts manually :P [16:29:56 CEST] <alexpigment> JEEB: yeah, for a scenario where you're only using one system, it's not a huge problem per se. although on a 16-core/32-logical system, you would have to know to not set it to auto, which is kinda bad from a user perspective [16:30:10 CEST] <alexpigment> and of course, we're about to get a hell of a lot more of those on the market [16:30:55 CEST] <JEEB> alexpigment: well you usually have a transcoding system and that's where I so far have handled limiting threads [16:31:09 CEST] <JEEB> looking at the already running jobs and the core count etc [16:31:33 CEST] <alexpigment> Sure, if you've got a transcoding system set up and you know what you're doing, it's not a problem [16:31:52 CEST] <alexpigment> I think that's a pretty niche situation though to be honest [16:32:16 CEST] <JEEB> I'd hope most places providing such services have some sort of workload control system :D [16:33:21 CEST] <alexpigment> Yeah, I'm just thinking about a dude with ffmpeg trying to encode a single video file [16:33:34 CEST] <alexpigment> Doesn't know what threads are, so he doesn't specify them [16:33:46 CEST] <alexpigment> Just using the bare minimum to get his file from point A to B [16:33:52 CEST] <JEEB> but yea, as I noted it makes sense to have a 'max_threads' or so param [16:34:06 CEST] <alexpigment> Yes, and it makes sense for that to be automatically set to 16 [16:34:07 CEST] <JEEB> what the default for it would be is up to debate [16:34:37 CEST] <alexpigment> well, i'm specifically referring to this message: "[libx264 @ 000000000054acc0] Application has requested 48 threads. Using a thread count greater than 16 is not recommended." [16:35:37 CEST] <JEEB> yea, that warning also I don't remember if it depends on the resolution (vertical one) or not [16:35:40 CEST] <JEEB> if it doesn't then yes [16:35:53 CEST] <JEEB> otherwise you might want to add calculation or so [16:35:58 CEST] <alexpigment> right [16:36:34 CEST] <alexpigment> ok, well I'll be looking into this more. thanks for the suggestions and I'll see what I can come up with by digging around the source code [16:37:28 CEST] <bjorn__> Hey all! Im working on this: https://trac.ffmpeg.org/ticket/4443 [16:37:28 CEST] <JEEB> oh [16:38:03 CEST] <bjorn__> Ive got it working so that I can generate a transparent gif just fine but only a single frame. [16:38:53 CEST] <bjorn__> Multiple frames cause problems with the gif encodings oprtimizations, so I cant successfully create an animated gif with transparencies. [16:39:09 CEST] <c_14> bjorn__: you probably want #ffmpeg-devel for devel-related talk [16:39:22 CEST] <bjorn__> Oops, you are right I [16:39:26 CEST] <bjorn__> m in the wrong room. [16:39:33 CEST] <bjorn__> Thanks! [16:50:41 CEST] <alexpigment> JEEB: so regarding the pthreads.c file, I've found the section you're talking about [16:51:15 CEST] <alexpigment> so basically the warning triggers if threads is greater than max auto threads [16:52:01 CEST] <alexpigment> is it possible to edit that line such that it actually sets threads to max auto threads if threads is greater? [16:52:32 CEST] <alexpigment> i'm usually don't write actual code myself, so I'm a bit green on how to do that [17:02:07 CEST] <JEEB> alexpigment: with a quick look the check was arbitrary, so actually the warning should be shut up with libx264 [17:02:25 CEST] <JEEB> since libx264 itself limits auto threads by default [17:02:33 CEST] <alexpigment> hmmm [17:03:01 CEST] <alexpigment> and max auto threads should be 16, right [17:03:01 CEST] <alexpigment> ? [17:03:05 CEST] <JEEB> no [17:03:42 CEST] <alexpigment> then what is it? [17:03:46 CEST] <JEEB> you'd have to read the code to check what the limits are within x264 [17:03:56 CEST] <alexpigment> can you point me to the particular file? [17:04:25 CEST] <JEEB> i'm on a phone amd I'm just repearing what bugmaster said on #x264dev [17:04:29 CEST] <JEEB> so no [17:04:39 CEST] <alexpigment> k [17:18:27 CEST] <BytesBaconBB> Has anyone done any encoding with hardware GPU acceleration? How's the quality vs software x264 encoding? [17:19:36 CEST] <Johnjay> With that segment filter is there a way to segment a video/audio clip into chunks of length N [17:19:40 CEST] <Johnjay> except for the last one? [17:19:51 CEST] <Johnjay> e.g. if it's hour and 45 minutes and you split it into 30 min chunks [17:20:04 CEST] <Johnjay> It segments it to file1, file2, file3 where file3 is 45 minutes [17:21:11 CEST] <c_14> if you hardcode segment_times [17:21:54 CEST] <Johnjay> er wait I can give it a list of times? [17:21:58 CEST] <Johnjay> i forgot the syntax lol [17:22:23 CEST] <c_14> >Specify a list of split points. times contains a list of comma separated duration specifications, in increasing order. See also the segment_time option. [17:23:03 CEST] <Johnjay> I guess I'm thinking of splitting into chunks of at least length N, as opposed to exactly length N [17:23:30 CEST] <Johnjay> after I tried splitting a file that was like 1 hr 18 min into two 30 min files and one 18 min one [17:23:32 CEST] <c_14> Well, that's easy [17:23:36 CEST] <c_14> Just don't split it into chunks [17:23:42 CEST] <c_14> They'll be "at least" the length [17:24:09 CEST] <c_14> But no, I know of no solution besides calculating the times yourself [18:16:16 CEST] <JEEB> BytesBaconBB: hw encoding is never used because it gives better quality but because low CPU usage is required for some reason or another [18:16:51 CEST] <JEEB> it can give more speed (but for example x264 superfast is pretty darn fast), but generally high compression ratio use cases are not what those things are used for [18:17:04 CEST] <JEEB> low latency/realtime is what they're generally made for and other requirements are minimal [18:21:39 CEST] <DHE> or where you can't spare much CPU at all (eg: gaming on a weak CPU) [18:21:59 CEST] <DHE> opencl offload on x264 is very much hit-and-miss. sometimes it's good, sometimes it's not. [18:22:12 CEST] <DHE> and by 'not' I very much mean a throughput penalty for using your GPU [18:22:44 CEST] <JEEB> and that feature is very minimal anyways [18:22:58 CEST] <JEEB> it's just one of the lookaheads moved to an opencl device with a lowres mode [18:23:19 CEST] <DHE> lowres? oh well screw that then [18:25:12 CEST] <JEEB> yea, to make the upload of data faster it uses lowres [18:25:34 CEST] <JEEB> anyways, it's a PoC by the multicoreware people to get them PR [18:25:36 CEST] <JEEB> basically [18:25:41 CEST] <JEEB> the good part is that it at least kind of works [18:25:44 CEST] <JEEB> :D [18:43:49 CEST] <DHE> curious if you could get "better" results using hardware decoding and keep it in the GPU that way... [18:44:08 CEST] <JEEB> well most of the encoding process then needs the images [18:44:26 CEST] <JEEB> as I said, only one of the lookaheads was being done on the opencl device [18:44:27 CEST] <JEEB> :D [18:44:27 CEST] <BtbN> you cannot pass GPU frames to x264 [18:44:39 CEST] <JEEB> it can take in NV12 at least [18:44:44 CEST] <JEEB> but not textures, yes [19:42:22 CEST] <C129> Is it possible to preserve subtitle stream timing when cutting up a view via ffmpeg and the -ss parameter? [20:12:16 CEST] <Martchus> C129: Don't know. As a workaround you could specify the input file twice (and use map to not get all tracks twice). [20:27:06 CEST] <alexpigment> JEEB: per our earlier conversation, I found the code you were talking about in x264/encoder/encoder.c [20:27:22 CEST] <JEEB> k [20:27:52 CEST] <alexpigment> after it defined the max threads, i just put a line that said if max threads are greater than 16, set them to 16 [20:27:55 CEST] <alexpigment> which works for me [20:27:57 CEST] <alexpigment> thanks for your help [20:28:56 CEST] <alexpigment> i also did the same for max sliced threads, but I wasn't sure if it should be half the number of threads or not [20:29:09 CEST] <alexpigment> 16 seems fine unless you think there's a reason to limit to 8 [20:31:44 CEST] <JEEB> alexpigment: umm, the question is whether or not the 16 threads limit is actually needed for x264 [20:31:53 CEST] <JEEB> because as we learned the message came from VERY GENERIC CODE [20:31:58 CEST] <JEEB> in libavcodec [20:32:10 CEST] <alexpigment> yes, but I've got a case where I know it fails on a 16-core system [20:32:12 CEST] <JEEB> I know libavcodec's decoders are often limited [20:32:13 CEST] <alexpigment> because of the auto logic [20:32:23 CEST] <JEEB> was that an out of memory case or otherwise? [20:32:33 CEST] <JEEB> if it was OOM then I don't think that's a threading problem [20:32:38 CEST] <alexpigment> I can't say for sure, but it said "conversion failed" [20:32:54 CEST] <alexpigment> when I set the threads lower below a certain threshold, it worked as expected [20:33:09 CEST] <JEEB> E_MORE_INFO_NEEDED [20:33:13 CEST] <alexpigment> 48 failed, 32 failed, 24 worked [20:33:23 CEST] <JEEB> I've had 48 threads work JustFine with auto [20:33:37 CEST] <alexpigment> there's no more information needed. I'm just saying that I had a failure case that was easily reproducible, and I've fixed it by not allowing the auto logic to make dumb decisions [20:33:46 CEST] <alexpigment> JEEB: you're running a 64-bit copy of FFMPEG presumably [20:33:48 CEST] <JEEB> and if x264 *itself* already limits auto threads [20:33:52 CEST] <JEEB> alexpigment: thus I asked if it was OOM [20:33:58 CEST] <JEEB> in which case it is not really a threading problem [20:34:00 CEST] <alexpigment> what is OOM? [20:34:04 CEST] <JEEB> Out Of Memory [20:34:11 CEST] <alexpigment> right [20:34:17 CEST] <alexpigment> how would I know? [20:34:22 CEST] <alexpigment> it just says conversion failed [20:34:33 CEST] <JEEB> somewhere higher it should say, -v debug might be needed [20:34:33 CEST] <alexpigment> ffmpeg doesn't crash or anything [20:34:37 CEST] <alexpigment> k [20:34:41 CEST] <alexpigment> i'll try that [20:34:44 CEST] <JEEB> yes, since people are surprisingly good at catching allocation failures sometimes :P [20:35:13 CEST] <JEEB> I've also had a subtitle renderer not crash after it tried to render a typo'd vector of a huge length in a 32bit process :P [20:35:25 CEST] <JEEB> just by catching the allocation failure and trying to handle it somehow [20:35:36 CEST] <JEEB> of course with initialization stuff in that case you just say "nope" [20:36:01 CEST] <JEEB> anyways, there really is no reason to use 32bit for transcoding since you have so much to gain from 64bit (more registers, more SIMD etc) [20:36:25 CEST] <JEEB> and if you need to use some input module that is crappy enough to be limited to 32bit, then you run just input in its own 32bit process [20:36:32 CEST] <alexpigment> error: "malloc of size 43687840 failed" [20:36:32 CEST] <JEEB> and pipe that into 64bit [20:36:39 CEST] <JEEB> alexpigment: welcome to allocation failures [20:36:42 CEST] <JEEB> so yes, not a threading problem at all [20:36:50 CEST] <alexpigment> JEEB: yeah, it's just about limiting size and not having two versions [20:36:56 CEST] <alexpigment> JEEB: how do you figure? [20:37:14 CEST] <JEEB> more threads might need more buffers, but that doesn't mean the threading is broken [20:37:25 CEST] <alexpigment> no one claimed it's broken [20:37:47 CEST] <alexpigment> basically for this 32-bit FFMPEG, if you run a 4K transcode on a 16-core processor, it fails [20:37:49 CEST] <JEEB> basically, it wants to allocate its buffers and the amount of buffers that is needed is not enough in 32bit application space [20:37:53 CEST] <alexpigment> that's the start and end of the problem [20:37:57 CEST] <JEEB> it has NOTHING to do with threading [20:38:06 CEST] <alexpigment> more threads = more memory [20:38:17 CEST] <JEEB> not threads, the buffers related to them. but yes [20:38:31 CEST] <alexpigment> then i'm not sure what your point in [20:38:32 CEST] <alexpigment> *is [20:38:58 CEST] <JEEB> but in this case I am deeply against adding any sort of limitations if things aren't actually broken, but rather you just hit a thing because your input is large enough that 32bit process space ends for you [20:39:20 CEST] <JEEB> as this is different from "over X threads is bad for quality" kind of things [20:39:44 CEST] <alexpigment> oh well that's separate [20:39:50 CEST] <alexpigment> there are several places in the code that say to limit it [20:40:14 CEST] <JEEB> yes, as bugmaster said there already are some limits in place for thread counts that would have negative effects [20:40:14 CEST] <alexpigment> including in encoder.c [20:40:42 CEST] <alexpigment> I'm not entirely sure about that, but I'll defer to your judgement [20:41:05 CEST] <JEEB> well the guy said so and the message you were seeing HAD NOTHING TO DO WITH X264 [20:41:14 CEST] <JEEB> which is why my comment was that it should be hidden from libx264 [20:41:22 CEST] <JEEB> (somehow, it's generic code I bet so meh) [20:41:23 CEST] <alexpigment> It says to avoid using too many threads because it affects VBV. It's not 100% clear to me that the code below that achieves that goal [20:41:44 CEST] <JEEB> I haven't looked at the code, just throwing generic statements around so far [20:41:45 CEST] <JEEB> anyways [20:41:50 CEST] <JEEB> my point was... [20:42:14 CEST] <JEEB> in any case, you are basically bringing the problem onto yourself in this case. limit threads according to input resolution if you must support 32bit binaries [20:42:34 CEST] <JEEB> although that is always fuzzy because you can't be sure at which point exactly it will OOM [20:42:35 CEST] <alexpigment> JEEB: you're making a lot of assumptions about my role in this :) [20:42:55 CEST] <alexpigment> At any rate, 16 seems safe [20:43:11 CEST] <JEEB> because depending on input decoding threads, filters, other stuff the amount of buffering outside of just x264 is done [20:43:18 CEST] <JEEB> also input demuxing buffers blah blah [20:43:22 CEST] <alexpigment> This will basically just keep blowing up as Threadripper gains popularity and Intel's new 10+ core chips come out [20:43:28 CEST] <JEEB> so just accept that 32bit is shit [20:43:32 CEST] <JEEB> and limit threads [20:43:39 CEST] <alexpigment> JEEB: already done :) [20:43:54 CEST] <JEEB> you don't need to patch x264 for it, since it's not x264's fault [20:44:00 CEST] <JEEB> just set less threads, and done [20:44:14 CEST] <alexpigment> JEEB: setting less threads means that you're often setting MORE threads when you don't need to [20:44:22 CEST] <alexpigment> this is a thread cap that still preserves the auto thread logic [20:44:54 CEST] <alexpigment> so on a 2-core processor, it uses 3 threads. on a 4 core processor, it uses 6. on a 16 core processor, it caps to 16 [20:44:56 CEST] <alexpigment> etc [20:45:14 CEST] <alexpigment> much better than being hamfisted about it and forcing it to always be 16 [20:45:27 CEST] <JEEB> well, I would have per-profile thread counts :P [20:45:33 CEST] <JEEB> but whatever [20:45:48 CEST] <JEEB> but I do kind of agree it might make sense to have a max_threads parameter in x264 [20:45:49 CEST] <alexpigment> for your use case, I agree that it's much much simpler to do that [20:46:02 CEST] <JEEB> so that in your crappy 32bit piece of shit you can set that [20:46:08 CEST] <alexpigment> haha [20:46:24 CEST] <JEEB> instead of patching x264 and most likely leaving it there for 64bit as well [20:46:27 CEST] <JEEB> :P [20:46:45 CEST] <alexpigment> It's not like I'm submitting a patch for this. This is a hack [20:46:48 CEST] <JEEB> also it is absolutely mind-boggling how people are OK with the slower performance of 64bit still [20:46:57 CEST] <alexpigment> 32-bit, you mean? [20:47:00 CEST] <JEEB> yes [20:47:19 CEST] <alexpigment> it's really just about avoiding having two binaries or including both and dealing with an extra 30MB of data [20:47:28 CEST] <alexpigment> seems trivial to some, but still [20:47:28 CEST] <JEEB> I'd say that's miniscule [20:47:34 CEST] <JEEB> I mean, at this point of time [20:47:38 CEST] <alexpigment> in practice, I agree with you 100% [20:47:58 CEST] <JEEB> the only people on 28,800bps modems I've seen were All Nippon Airways' LA office [20:48:02 CEST] <JEEB> don't ask why I was there >_> [20:48:20 CEST] <JEEB> and yes, on 28,800bps modem you request a USB stick or a CD with the app [20:48:23 CEST] <alexpigment> Japan has 28.8k still? [20:48:26 CEST] <JEEB> no, that was in LA [20:48:30 CEST] <JEEB> at LAX [20:48:30 CEST] <alexpigment> oh right [20:48:34 CEST] <alexpigment> sorry [20:48:35 CEST] <alexpigment> :) [20:48:59 CEST] <alexpigment> also that's weird that anywhere in america still has 28.8k [20:49:00 CEST] <JEEB> the worst I've had in an apartment in Japan in ~2005 was 3 megabits or so? [20:49:26 CEST] <alexpigment> I had 28.8k up until 2000 or so because the phone lines sucked where I lived [20:49:32 CEST] <JEEB> well, it was an office so there Muxt Have Been a Reason [20:49:36 CEST] <JEEB> *Must [20:49:41 CEST] <alexpigment> And then we beta tested cable before it was released to the rest of the city, so that was nice ;) [20:49:47 CEST] <JEEB> probably too expensive or corporate bullshit or whatever [20:50:38 CEST] <alexpigment> I have no clue what decisions would lead someone to keep dial-up, but oh well [20:50:47 CEST] <JEEB> but yes, in other words your issue wasn't threading but rather OOM due to more threads requiring more buffers [20:51:08 CEST] <JEEB> and yes, more threads with VBV can be a problem but not sure at which point you start hitting it [20:51:15 CEST] <JEEB> I would guess there should be docs on that somewhere [20:51:29 CEST] <JEEB> also as usual probably dependant on specific parameters [20:52:28 CEST] <alexpigment> JEEB: yeah, I was pretty sure I mentioned that I thought it was memory related from the get-go, but either way, no worries [20:52:55 CEST] <alexpigment> (I said that in the x264dev channel) [21:04:56 CEST] <devinheitmueller> alexpigment: there are plenty of places in the US where broadband simply isnt available (i.e. rural areas). Its dial-up or nothing. [21:05:16 CEST] <devinheitmueller> Hence for many people, its not a decision to choose slow speeds - they have no alternaitve. [21:05:23 CEST] <alexpigment> devinheitmueller: I was really referring to major cities, but I get your point [21:05:29 CEST] <JEEB> just for the reference, this was about LAX :D [21:05:43 CEST] <alexpigment> On the other hand, dialup is usually not used anyway in those cases. It's cellular or satellite [21:05:55 CEST] <devinheitmueller> Yeah, most cities are ok. Its the rural areas that are the issue. [21:06:51 CEST] <alexpigment> Not that I'd personally want to be on cellular or satellite for my main source of internet, but I'd still prefer that over dialup [21:07:15 CEST] <devinheitmueller> Anybody from #ffmpeg planning on attending the VDD conference this weekend? [21:08:35 CEST] <JEEB> absolutely no-one 8) [21:08:45 CEST] <JEEB> I am totally not trying to finish a presentation >_> [21:09:09 CEST] <alexpigment> JEEB: that's not what I heard. I heard that you were *totally trying to finish a presentation* right now [21:09:15 CEST] <alexpigment> ;) [21:09:23 CEST] <JEEB> nîn [21:12:14 CEST] <fsphil> quick question, trying x11grab via the api and just getting "Protocol not found". Code is basically just https://pastebin.com/raw/hb8zqhX8 [21:12:32 CEST] <fsphil> I'm sure i've done something stupid but I can't see it [21:13:08 CEST] <fsphil> (that pastebin is missing "fmt = av_find_input_format("x11grab");") [21:18:45 CEST] <fsphil> ah n/m, I missed init'ing libavdevice [21:33:57 CEST] <frankyboy_> hello :) i want to apply boxblur filter on video 2 times, but in different prefiod of time. but i a, failing in syntax https://pastebin.com/QEQ1Tap8 where i am worng [21:36:16 CEST] <frankyboy_> wrong* [22:10:17 CEST] <dingwat> Anyone have experience with encoding an 8K video for youtube upload with ffmpeg? x264 doesn't support 8K and I'm not sure which codec I should try instead [22:10:59 CEST] <BtbN> Why wouldn't x264 support 8k? [22:11:49 CEST] <BtbN> You will need _tons_ of RAM though. No matter what encoder you use. [22:12:01 CEST] <dingwat> As I understand it, x264 maximum resolution is 4096x2304 [22:12:14 CEST] <dingwat> BtbN: yeah, that's my other concern, but I'll tackle that when I get there [22:12:29 CEST] <dingwat> I guess I'll try HEVC and see what happens if I try to upload to youtube [22:12:37 CEST] <dingwat> Not sure if I have enough RAM, but meh [22:13:42 CEST] <dingwat> Uh oh my memory is going down the drain [22:14:39 CEST] <JEEB> dingwat: x264 is an encoder [22:14:52 CEST] <JEEB> it has a maximum resolution of probably the maximum values of int [22:15:01 CEST] <JEEB> (and possibly some other funky stuff) [22:15:08 CEST] <BtbN> x264, since 2017-06-14, should support h264 levels up to 6.2, and so up to 8,192×4,320@120 [22:15:10 CEST] <JEEB> most definitely not some arbitrary profile limit like 4096x2304 :) [22:15:20 CEST] <JEEB> that's just levels though [22:15:25 CEST] <BtbN> http://git.videolan.org/?p=x264.git;a=commit;h=6f8aa71ce797be01fd2ebe53c072… [22:15:27 CEST] <JEEB> it would happily still write you 5.1 before [22:15:37 CEST] <JEEB> but actually encode something incompatible with that in reality :P [22:15:40 CEST] <BtbN> 5.1 is limited to 4,096×2,160@60 though [22:15:50 CEST] <JEEB> yes, but that doesn't stop x264 from encoding it [22:15:53 CEST] <dingwat> JEEB: ah ok, I thought I was limited by H.264 5.2 [22:16:09 CEST] <BtbN> you should definitely grab a very recent x264 still [22:16:12 CEST] <JEEB> of course [22:16:14 CEST] <BtbN> so it does not violate the spec [22:16:21 CEST] <alexpigment> BtbN: i thought 5.1 was limited to @30 at the resolution [22:16:27 CEST] <alexpigment> (checking wikipedia now) [22:16:36 CEST] <JEEB> not that youtube will most likely care since it just feeds the stream into libavcodec [22:16:45 CEST] <JEEB> and libavcodec should be able to decode just fine [22:16:49 CEST] <dingwat> I'm definitely not able to encode h.264 with ffmpeg, it OOMs immediately. I thought the 5.2 limit was the reason, but maybe it's different [22:16:49 CEST] <JEEB> not caring about the level [22:17:02 CEST] <JEEB> dingwat: 32bit? [22:17:15 CEST] <dingwat> JEEB: 64bit windows [22:17:24 CEST] <JEEB> yes, but the ffmpeg.c binary you're using :P [22:17:32 CEST] <JEEB> if it OOMs it's 32bit most likely [22:17:36 CEST] <JEEB> get a 64bit one [22:18:08 CEST] <alexpigment> JEEB: well, it can happen at 64-bit too if you don't have enough physical memory, right? [22:18:11 CEST] <dingwat> I'm able to (slowly) encode x265 (0.2 fps) right now [22:18:33 CEST] <JEEB> dingwat: x265 will be both slower and worse bang for the buck most likely [22:18:40 CEST] <alexpigment> dingwat: try x264 and specify -threads 2 [22:18:42 CEST] <alexpigment> (as a test) [22:18:47 CEST] <alexpigment> see if you run out of memory [22:18:57 CEST] <JEEB> also I think youtube actually doesn't let you push HEVC into it? [22:19:03 CEST] <JEEB> or have they changed that [22:19:05 CEST] <alexpigment> you can of course bump that up more, but it's just to test [22:19:11 CEST] <dingwat> Yeah, I'm not sure if they support HEVC yet [22:19:20 CEST] <alexpigment> hard to believe youtube would turn away HEVC in 2017 [22:19:21 CEST] <JEEB> alexpigment: before that just make the idiot use 64bit FFmpeg [22:19:33 CEST] <dingwat> OK, so there shouldn't be any reason I can't do x264 with 8K? I will try to get that working then [22:19:36 CEST] <JEEB> there's no reason to use 32bit, losing the speed-ups [22:19:37 CEST] <alexpigment> JEEB: where did you see he was using 32-bit? [22:19:40 CEST] <BtbN> YouTube uses ffmpeg 0.10 or something. No HEVC support [22:19:47 CEST] <JEEB> if he ran out of memory it's 32bit [22:19:52 CEST] <JEEB> 64bit process will not fall the malloc() [22:19:58 CEST] <JEEB> it will just swap your shit if you go too far [22:20:02 CEST] <BtbN> unless you actually are out of memory [22:20:17 CEST] <BtbN> 8k transcoding can easily munch 10GB+, if not 20GB+ depending on ref frame count [22:20:18 CEST] <alexpigment> JEEB: fair point. I asked above if it was possible with insufficient ram, but if it goes to swap, then that makes sense [22:20:19 CEST] <JEEB> well in 64bit that is rather unlikely, unless you also run out of swap or something [22:20:31 CEST] <JEEB> also considering the goddamn speedups [22:20:39 CEST] <JEEB> 32bit just makes my head hurt [22:21:14 CEST] <alexpigment> JEEB: before you get back into a 32-bit rage, let's not assume he's using 32-bit without further proof [22:21:19 CEST] <alexpigment> ;) [22:21:25 CEST] <dingwat> This machine only has 8GB RAM, plus I'm running Vivado and a whole boatload of Chrome tabs. Let me clean some stuff up and try again [22:21:28 CEST] <JEEB> he OOM'd and noted his *windows* was 64bit [22:21:34 CEST] <JEEB> dingwat: that doesn't cause OOM [22:21:46 CEST] <JEEB> I mean, you have to really work hard to get OOM with 64bit [22:22:14 CEST] <JEEB> dingwat: just grab a 64bit one from https://ffmpeg.zeranoe.com/builds/ :V [22:22:15 CEST] <alexpigment> For what it's worth, I did a test on a 64-bit copy of FFMPEG earlier and it crashed Premiere :) [22:22:24 CEST] <alexpigment> the system took a nosedive for sure, but ffmpeg kept running [22:22:31 CEST] <dingwat> Sorry, it's hard to reply timely because my whole OS is really laggy right now. Let me check which build I have and give you the exact error message from x264 [22:22:33 CEST] <JEEB> yes, OOM is really hard [22:22:48 CEST] <JEEB> as someone who has debugged OSS software suddenly eating 60+ gigs [22:23:02 CEST] <JEEB> the thing just didn't stop until it caused the system to pop [22:23:31 CEST] <alexpigment> i cringe at the thought of what it means for a system to "pop" [22:23:41 CEST] <JEEB> and it only got killed by oom-killer because swap was run out of [22:23:52 CEST] <JEEB> and when you run out of swap the system starts finally killing things [22:24:57 CEST] <alexpigment> dingwat: anyway, like I suggested earlier, try doing this with -threads 2 in x264 [22:25:00 CEST] <alexpigment> or even -threads 1 [22:25:13 CEST] <JEEB> alexpigment: also regarding youtube and HEVC - they just want to stay the hell away from the licensing mess [22:25:16 CEST] <alexpigment> each additional thread will eat up more memory, and significantly so at higher ersolutions [22:25:18 CEST] <JEEB> and I don't blame them [22:25:37 CEST] <alexpigment> JEEB: I suppose that's fair. I just don't see how they can fight that codec for input formats [22:26:21 CEST] <JEEB> if you upload 4:2:2, 10bit that's usually prores or something else [22:26:31 CEST] <furq> i'm pretty sure youtube supports hevc now [22:26:33 CEST] <JEEB> I don't think many editors or whatever output HEVC for HDR etc [22:26:33 CEST] <alexpigment> yeah, prores is 422 10 by default [22:26:38 CEST] <JEEB> furq: hmm [22:26:43 CEST] <JEEB> could be possible [22:26:50 CEST] <furq> i've not tried it but i've heard people reporting that it works [22:26:53 CEST] <alexpigment> JEEB: the big ones all do. Premiere definitely does [22:27:09 CEST] <JEEB> well, then google caved in regarding HEVC [22:27:14 CEST] <JEEB> and my info was old :) [22:27:22 CEST] <furq> it's a pretty recent change [22:27:24 CEST] <alexpigment> once the camera manufacturers started using it, i'm sure they had to [22:27:34 CEST] <JEEB> I've only seen a single camera so far [22:27:36 CEST] <alexpigment> as well as, you know, Blu-ray UHD [22:27:39 CEST] <furq> someone's claiming that hevc is "now free for sites like youtube" but this is a reddit post so it's probably bullshit [22:27:54 CEST] <furq> also i doubt youtube really care about supporting people uploading bdremuxes [22:27:55 CEST] <JEEB> yea, they did improve the licensing around the late last year I think [22:28:20 CEST] <JEEB> and yes, "it's on BD" doesn't really matter since the person uploading to youtube most likely will upload the master he has on hand [22:28:23 CEST] <furq> the new iphones record in hevc don't they [22:28:24 CEST] <alexpigment> furq: yeah, i was kinda saying that as a secondary concern. really just implying that it's a legit standard at this point [22:28:25 CEST] <JEEB> *it's on UHD BD [22:28:33 CEST] <furq> if they're out yet [22:28:35 CEST] <JEEB> it has always been a legit standard [22:28:40 CEST] <JEEB> the licensing mess just made it eww [22:28:48 CEST] <JEEB> UHD BD crowd was the only one that really took it in [22:29:00 CEST] <furq> a lot of euro broadcasters are using it for hd aren't they [22:29:04 CEST] <furq> i know cz uses it for dvb-t2 [22:29:11 CEST] <JEEB> test broadcasts I've seen [22:29:17 CEST] <JEEB> not actual real broadcasts [22:29:40 CEST] <alexpigment> but yes, Apple adopted it for iOS [22:29:52 CEST] <JEEB> yea, after disabling it in the OS for quite a while [22:29:53 CEST] <alexpigment> so that's a huge thing to try and fight :) [22:29:55 CEST] <JEEB> now they went HEVC :) [22:30:02 CEST] <JEEB> yea, that's probably the biggest single thing [22:30:07 CEST] <JEEB> with the brainfart that is HEIF [22:30:10 CEST] <furq> ;_; [22:30:14 CEST] <alexpigment> it's an image format [22:30:17 CEST] <alexpigment> that's based on HEVC [22:30:17 CEST] <JEEB> https://ffmpeg.org/pipermail/ffmpeg-devel/2017-August/215003.html [22:30:31 CEST] <JEEB> just read the comment and it's like wutlol.jpg [22:31:06 CEST] <alexpigment> i was thinking it was HEVC based... according to that thread it's just JPEG [22:31:12 CEST] <furq> TL;DR this format is bad, but at least we're finally moving past JPEG. [22:31:17 CEST] <furq> alexpigment: it can be multiple codecs [22:31:20 CEST] <furq> the headline one is hevc [22:31:26 CEST] <alexpigment> ahh [22:31:29 CEST] <alexpigment> wiki: "The HEIF specification also defines the means of storing High Efficiency Video Codec (HEVC)-encoded intra images and HEVC-encoded image sequences in which inter prediction is applied in a constrained manner. [22:31:29 CEST] <alexpigment> " [22:31:46 CEST] <furq> just as webp was getting settled in, now this [22:31:53 CEST] <alexpigment> I want to say the big advantage is the storing of multiple images [22:32:03 CEST] <furq> just like everyone's favourite image format, tiff [22:32:09 CEST] <alexpigment> So that you can do multiple shots and let the user choose the best one without deleting the others [22:32:14 CEST] <JEEB> I recommend you read the rant/description on that post :P [22:32:15 CEST] <alexpigment> furq: lol [22:32:23 CEST] <furq> i feel like you can already do that by having multiple files [22:32:51 CEST] <JEEB> and yea, HEIF is just abusal of ISOBMFF [22:32:59 CEST] <JEEB> (colloquially called mp4) [22:33:00 CEST] <furq> the first time that's happened [22:34:04 CEST] <Mavrik> ^^ [22:34:21 CEST] <alexpigment> the rant is pretty funny, but I'll be the first to admit I understood only half of what he said :) [22:34:45 CEST] <dingbat> Welp, my computer ded [22:35:02 CEST] <furq> i love to store more than 2^16 images in one file [22:35:03 CEST] <alexpigment> 8K vs Computer = 8K wins? [22:35:32 CEST] <Mavrik> " Hopefully that never happens, because it would be a pain to work around." [22:35:39 CEST] <dingbat> Pretty much. I'm gonna set up networking and then try ffmpeg again on my Linux machine, which has 32GB [22:35:44 CEST] <furq> For some reason my phone running iOS 11 doesn't actually export HEIFs; it just gives me JPEGs with a .HEIC extension. [22:35:55 CEST] <furq> i assume he's running it on an old iphone that doesn't have the encoder [22:36:03 CEST] <dingbat> What ffmpeg build should I use on 64bit Ubuntu 16.04? [22:36:13 CEST] <furq> dingbat: https://www.johnvansickle.com/ffmpeg/ [22:36:29 CEST] <furq> i should probably add that link to the bot [22:37:28 CEST] <dingbat> 3.3.4 or git build? [22:37:47 CEST] <furq> either's probably fine [22:37:58 CEST] <furq> they both use the same libx264 [22:40:41 CEST] <dingbat> Ok. Now I just need to restart windows and get a share mounted. Hopefully the overhead from networked disk doesn't slow it too much [22:58:32 CEST] <dingbat> Computer finally restarted... [23:12:51 CEST] <dingwat> Ok. Computer is working again and I've got the source images mounted in linux. Now to try again [23:16:03 CEST] <dingwat> Welp, it doesn't immediately OOM. Using x264 and it's crawling along (0.5fps), but it seems like it's working [23:17:00 CEST] <alexpigment> dingwat: what's your memory usage? [23:17:55 CEST] <dingwat> So far, about 9.2GiB. This machine has 32GB and 8 cores. It looks like it's only using about 4ish cores [23:18:11 CEST] <alexpigment> seems reasonable [23:18:47 CEST] <alexpigment> there may be a bottleneck thread that's basically limiting what it can do in parallel [23:19:07 CEST] <alexpigment> (i've never tried 8K personally, so I don't know how parallelized it can be) [23:19:35 CEST] <dingwat> Yeah, it also might be limited by network [23:19:41 CEST] <BytesBaconBB> Thanks JEEB for the info about hardware encoding. I guess I'll just let it run on the CPU and look at faster rigs for the future. [23:23:29 CEST] <dingwat> Hmm. It might be bottlenecked with network or maybe even the spinny disk on the far end. I'm seeing up to 400Mbps over the network. My linux machine has an SSD, but the Windows machine has a spinny disk [23:47:28 CEST] <dingwat> Oof. It's been ~30mins and I'm 15% of the way through.... [23:49:11 CEST] <JEEB> that's fast [23:49:20 CEST] <JEEB> I can tell you stories about the reference encoder for HEVC [23:49:29 CEST] <JEEB> with a frame going past after a minute and a half [23:50:01 CEST] <dingwat> Yeah this machine is pretty beefy. I have a lot of spare CPU and only intermittent network usage, so I'm not sure what's holding it back [23:50:29 CEST] <JEEB> what's the input? [23:50:43 CEST] <dingwat> JEEB: png frames [23:51:02 CEST] <JEEB> ok, so you most likely are having colorspace conversion after decode at least [23:51:14 CEST] <dingwat> Yeah, probably [23:51:18 CEST] <JEEB> and PNG decoding is not threaded (albeit I'm not sure how quick it is) [23:51:44 CEST] <JEEB> I would basically start checking which part of the chain is bottlenecking you after you finish that one thing :P [00:00:00 CEST] --- Thu Sep 21 2017

1 0