Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

October 2017

1 participants
62 discussions

ffmpeg-devel.log.20171030
by burek 31 Oct '17

31 Oct '17

[01:16:22 CET] <cone-501> ffmpeg 03Lukas Stabe 07master:d3f1b0d3d87f: movenc: add m4b to ipod format extensions [01:16:23 CET] <cone-501> ffmpeg 03Jonas Licht 07master:59ad50469695: libavformat/mov.c: use calculated dts offset when seeking in streams [01:29:40 CET] <cone-501> ffmpeg 03wm4 07master:195dd5c59c89: lavc/avrndec: remove AV_CODEC_CAP_DR1, as it's broken [01:29:41 CET] <cone-501> ffmpeg 03Anton Khirnov 07master:4776c61424fa: decode: avoid leaks on failure in ff_get_buffer() [02:22:29 CET] <cone-501> ffmpeg 03James Almer 07master:783535a4cd26: x86/bswapdsp: add missing preprocessor wrappers for AVX2 functions [10:02:15 CET] <RiCON> could someone let jamrial know about the dangling parenthesis he left in libavdevice/{libndi_newtek_dec.c,decklink_dec.cpp}? [14:17:49 CET] <fx159159> Hey, I'm still developing an indev for android devices, got it working nice so far, it does receive frames by the android camera2 api, now my question: is there an api to rotate single avpackets/avframes? [14:18:36 CET] <fx159159> I can get the rotation of the sensor and optionally of the device and though about "normalizing" the image rotation based on the sensor orientation? [14:18:48 CET] <fx159159> *thought [14:20:16 CET] <fx159159> Or should I leave that out of the indev and up to the user? [14:20:22 CET] <JEEB> usually you'd pass the frame through avfilter's rotate filter or so after the fact as an API user [14:22:45 CET] <fx159159> JEEB: do you think I should keep that out of the indev? And apply filters afterwardsß [14:23:34 CET] <JEEB> in general yes, unless you can specifically request the indev itself to do some "normalization" without you having to implement it [14:23:43 CET] <JEEB> the indev should be an interface for the indev [14:29:28 CET] <fx159159> JEEB: I can get a sensor orientation, a picture has to be rotated by it so it is displayed upright... without any "normalization" the user would have to try some parameters [14:29:58 CET] <fx159159> JEEB: But for YUV images I can't ask the api to pre rotate the images... so... I should leave it out then I guess [14:30:13 CET] <JEEB> I think but am not sure if we have AVFrame-specific rotation flag [14:30:27 CET] <JEEB> because that would make sense if you get the rotation for each picture [14:32:26 CET] <JEEB> fx159159: it would make sense to expose that option for RGB capture I guess? [14:32:31 CET] <JEEB> if it is somehow optimized [14:33:22 CET] <fx159159> JEEB: As far as I understood only precompressed JPEG images can be rotated by the api, but that's not what I want [14:34:01 CET] <JEEB> heh [14:34:19 CET] <JEEB> yea that sounds not exactly nice. You noted YCbCr and thus I thought the other alternative was RGB [14:35:28 CET] <fx159159> Yeah, that would have been nice, but RGB unfortunately also has no rotation [14:36:00 CET] <fx159159> I decided to stay with YUV for now, as the api states all devices must support YUV, all other formats are "optional" [14:36:57 CET] <jkqxz> Rotation information can be attached to a packet as side data - it's AV_PKT_DATA_DISPLAYMATRIX. [14:37:10 CET] <JEEB> yea but that's packets [14:37:19 CET] <JEEB> AVFrames are for raw images, no? [14:37:46 CET] <jkqxz> AV_FRAME_DATA_DISPLAYMATRIX, then. [14:37:58 CET] <JEEB> yup [14:38:29 CET] <fx159159> Currently I'm working with AVPackets, is it av_packet_new_side_data then? [14:38:30 CET] <jkqxz> (Indevs still have to give you packets, though.) [14:38:36 CET] <JEEB> jkqxz: :< [14:38:46 CET] <JEEB> excuse me while I go weep on the side [14:39:45 CET] <JEEB> although it makes sense since it's similar to lavf :P [14:40:25 CET] <jkqxz> fx159159: Should be. There is av_display_rotation_set() as well for simple rotation by angles. [14:40:46 CET] <jkqxz> JEEB: s/'s similar to/ is/ [14:40:55 CET] <JEEB> well yea [15:07:11 CET] <fx159159> Is it up to the player to interpret the AV_PKT_DATA_DISPLAYMATRIX? [15:08:42 CET] <jkqxz> Yes, though ffmpeg also tries to apply the rotation automatically in transcode cases. [15:11:50 CET] <fx159159> jkqxz: Does that look right? https://pastebin.com/Kq46F9cT [15:49:21 CET] <cone-233> ffmpeg 03James Almer 07master:5c819f433e85: avdevice/decklink_dec: remove extra bracket [15:49:22 CET] <cone-233> ffmpeg 03James Almer 07master:da71351dd36a: avdevice/libndi_newtek_dec: remove extra bracket [17:28:23 CET] <cone-233> ffmpeg 03Diego Biurrun 07master:0fd0d4fd0a51: swscale-test: const correctness [17:28:24 CET] <cone-233> ffmpeg 03Diego Biurrun 07master:f25609ff06b0: doc/examples/filter_audio: const correctness [17:28:25 CET] <cone-233> ffmpeg 03Diego Biurrun 07master:ecc5c4db2dd3: doc/examples/output: Cast pointer to the right (const) type [17:28:26 CET] <cone-233> ffmpeg 03James Almer 07master:087e9ab1b357: Merge commit '0fd0d4fd0a518e30ff23972828ad7cf7f35cfb9d' [17:28:27 CET] <cone-233> ffmpeg 03James Almer 07master:4c410a58d783: Merge commit 'f25609ff06b093d82548c92fc2031cd2e66c20d3' [17:28:28 CET] <cone-233> ffmpeg 03James Almer 07master:91b4d109175e: Merge commit 'ecc5c4db2dd3a0f328d95df89daa59f78b4b2810' [17:30:41 CET] <cone-233> ffmpeg 03Sean McGovern 07master:2e1ab6a67dd5: vc1dec: raise an error if sprite picture data is missing [17:30:42 CET] <cone-233> ffmpeg 03James Almer 07master:29e1247d4132: Merge commit '2e1ab6a67dd5d9a30558d008aa6e541c68d76221' [17:54:01 CET] <cone-233> ffmpeg 03Anton Khirnov 07master:3889dfde9c02: dca: Move the downmix request check outside the loop [17:54:02 CET] <cone-233> ffmpeg 03James Almer 07master:032129cabd50: Merge commit '3889dfde9c0284b008c5cfcbc921c1d137fb81e2' [18:10:32 CET] <cone-233> ffmpeg 03Luca Barbato 07master:44aafa3325ec: configure: Properly escape arguments in filter/filter_out helper functions [18:10:33 CET] <cone-233> ffmpeg 03James Almer 07master:9b0ddd1d8767: Merge commit '44aafa3325ec09a120bdb81b8579b8dfd65b1693' [18:12:19 CET] <cone-233> ffmpeg 03Luca Barbato 07master:41262498ff89: configure: Fix sem_timedwait probe [18:12:20 CET] <cone-233> ffmpeg 03James Almer 07master:85f1896cffb9: Merge commit '41262498ff89ef48e5ce4823b2fc2dc514a3eb0c' [18:18:19 CET] <cone-233> ffmpeg 03Luca Barbato 07master:8c0cadd17e98: avplay: Do not try to allocate new frames when the player is closing [18:18:21 CET] <cone-233> ffmpeg 03James Almer 07master:ba45ca0e62e2: Merge commit '8c0cadd17e98547d84e82111550caca4fb40ff8d' [18:26:47 CET] <cone-233> ffmpeg 03Paul B Mahol 07master:7c25523cc8e6: utvideodec: Fix decoding odd sizes with interlaced video with some formats [18:26:48 CET] <cone-233> ffmpeg 03James Almer 07master:b428d445a817: Merge commit '7c25523cc8e618e77dc84d960e41e9644eaf8c33' [18:34:08 CET] <cone-233> ffmpeg 03Paul B Mahol 07master:b812db66af16: utvideodec: Fix gradient prediction when stride does not match width [18:34:09 CET] <cone-233> ffmpeg 03James Almer 07master:dbfc31b86ec9: Merge commit 'b812db66af160bfac2f64aef2ade4aed7eb76b12' [18:41:27 CET] <cone-233> ffmpeg 03James Almer 07master:39e9a7a80fd3: avcodec/avcodec.h: remove doxy from the old bsf API functions [18:59:25 CET] <cone-233> ffmpeg 03Luca Barbato 07master:c55f2ae2b8d4: avprobe: Handle unknown values for the color description [18:59:26 CET] <cone-233> ffmpeg 03James Almer 07master:162989521ce2: Merge commit 'c55f2ae2b8d4de473f945aebd6a7a89b6b83e87a' [19:18:26 CET] <jamrial> michaelni: 189157c3fc merges a decoder we already have, with basically no differences outside of cosmetic, some missing bug fixes, and the addition of an init_threadsafe flag [19:19:13 CET] <jamrial> it's the flag that i'm not sure if it's correct. init() fills some vlc tables without using ff_thread_once [19:19:45 CET] <jamrial> should i skip adding that flag, or is it indeed safe? [19:21:26 CET] <jamrial> AVCodec.init_static_data() should really be called from somewhere else than avcodec_register() tbh for cases like this [19:24:21 CET] <durandal_1707> ported ty demuxer [19:30:07 CET] <jamrial> durandal_1707: what do you think about the flag, for that matter? [19:30:22 CET] <jamrial> since you commited the decoder on our end back then [19:33:18 CET] <nevcairiel> jamrial: the vlc init seems to be things in the context, not global stuff, so the flag seems ok? unless i'm missing something [19:34:43 CET] <jamrial> nevcairiel: you're probably not, but since derek not too long ago sent a patch to add that flag everywhere, seeing it missing here made me doubt [19:47:04 CET] <michaelni> jamrial, all static tables seem to have const, iam not sure why this would be no thread safe [19:47:13 CET] <michaelni> noT [19:47:32 CET] <jamrial> michaelni: ok, will add the flag then. thanks [19:50:41 CET] <cone-233> ffmpeg 03Kostya Shishkov 07master:189157c3fc8e: Add ClearVideo decoder [19:50:42 CET] <cone-233> ffmpeg 03James Almer 07master:269ed71e93a4: Merge commit '189157c3fc8eeb691e3684b09d971eb5ddb47d5b' [19:52:34 CET] <cone-233> ffmpeg 03Diego Biurrun 07master:d0ce0634e094: clearvideo: Convert to the new bitstream reader [19:52:35 CET] <cone-233> ffmpeg 03James Almer 07master:63f82ab3897b: Merge commit 'd0ce0634e09403eecaea4283cf82a2c5cea7d1e1' [20:00:45 CET] <cone-233> ffmpeg 03Seppo Tomperi 07master:358adef03056: hevc: Add NEON IDCT DC functions for bitdepth 8 [20:00:46 CET] <cone-233> ffmpeg 03James Almer 07master:cc8c2d3609b2: Merge commit '358adef0305618219522858e471edf7e0cb4043e' [20:05:13 CET] <cone-233> ffmpeg 03Alexandra Hájková 07master:3d69dd65c677: hevc: Add support for bitdepth 10 for IDCT DC [20:05:14 CET] <cone-233> ffmpeg 03James Almer 07master:f9c3fbc00cd6: Merge commit '3d69dd65c6771c28d3bf4e8e53a905aa8cd01fd9' [20:35:50 CET] <cone-233> ffmpeg 03Anton Khirnov 07master:04b0f0e371ff: mem: uninline av_malloc(z)_array() [20:35:51 CET] <cone-233> ffmpeg 03James Almer 07master:4959f18a8e11: Merge commit '04b0f0e371ff81b682274b574fb465ba4395c09f' [20:36:55 CET] <cone-233> ffmpeg 03James Almer 07master:bee89ed3ec61: matroskaenc: don't warn about unknown spherical metadata when there isn't any [20:36:56 CET] <cone-233> ffmpeg 03James Almer 07master:21525e6d0d70: Merge commit 'bee89ed3ec61a4a0e72255ae6f4a4274d25b5ccd' [20:47:10 CET] <cone-233> ffmpeg 03Vittorio Giovara 07master:1f6e5dd4d4dd: mlp: Rename the channel layout variable [20:47:11 CET] <cone-233> ffmpeg 03James Almer 07master:8b63acaeee24: Merge commit '1f6e5dd4d4dd9c02371ad211049d27edb6d95286' [20:56:16 CET] <cone-233> ffmpeg 03Vittorio Giovara 07master:cea7fd9afb84: mlp: Drop ff_ prefix from a static function [20:56:17 CET] <cone-233> ffmpeg 03Vittorio Giovara 07master:94c54d97e7f4: mlp: Factor out channel layout subset checks [20:56:18 CET] <cone-233> ffmpeg 03James Almer 07master:1242a6170e93: Merge commit 'cea7fd9afb8488a6c48f7d7ee38602e1fd3dd425' [20:56:19 CET] <cone-233> ffmpeg 03James Almer 07master:e3ebc293c624: Merge commit '94c54d97e7f4fe90570c323803f2bdf6246c1010' [21:04:27 CET] <cone-233> ffmpeg 03Vittorio Giovara 07master:85c2bf9d2cc7: avfoundation: update to use AVCodecParameters [21:04:28 CET] <cone-233> ffmpeg 03Mark Thompson 07master:6af014f40282: vaapi_encode: Use gop_size consistently in RC parameters [21:04:29 CET] <cone-233> ffmpeg 03Mark Thompson 07master:64a5260c695d: lavc: Add flag to allow profile mismatch with hardware decoding [21:04:30 CET] <cone-233> ffmpeg 03Mark Thompson 07master:7acb90333a18: vaapi: Add external control of allow-profile-mismatch [21:04:31 CET] <cone-233> ffmpeg 03James Almer 07master:644dd659c5c2: Merge commit '85c2bf9d2cc7dad3d5c6dc79f802a74efa8d8fce' [21:04:32 CET] <cone-233> ffmpeg 03James Almer 07master:623a0526282f: Merge commit '7acb90333a187b0e847b66f9d3511245423dc0ce' [21:16:09 CET] <cone-233> ffmpeg 03James Almer 07master:ad52eef997dc: spherical: add functions to retrieve and request projection names [21:16:10 CET] <cone-233> ffmpeg 03James Almer 07master:498864fe800a: dump: use av_spherical_projection_name() to print spherical projection names [21:16:11 CET] <cone-233> ffmpeg 03James Almer 07master:c7bf98d4372e: avprobe: use av_spherical_projection_name() to print spherical projection names [21:16:12 CET] <cone-233> ffmpeg 03James Almer 07master:f3ccc5e22acd: Merge commit 'c7bf98d4372e9217c8d75d2ca1f298385909e4da' [21:31:15 CET] <cone-233> ffmpeg 03Vittorio Giovara 07master:dd3aa85b68c0: aac_ac3_parser: Drop in-parser downmix functionality [21:31:16 CET] <cone-233> ffmpeg 03Vittorio Giovara 07master:970c76f32283: mlp_parser: Drop in-parser downmix functionality [21:31:17 CET] <cone-233> ffmpeg 03James Almer 07master:9484b9f4ba66: Merge commit 'dd3aa85b68c017c419acb0c39ff6aa890ce89e87' [21:31:18 CET] <cone-233> ffmpeg 03James Almer 07master:34542ac033f8: Merge commit '970c76f32283bddf3a5afd24fe52db7a96186244' [21:37:04 CET] <cone-233> ffmpeg 03Michael Niedermayer 07master:f1251a6b9cca: ffmpeg: Fix stored encoder metadata with -bitexact [21:37:05 CET] <cone-233> ffmpeg 03Michael Niedermayer 07master:097675242070: avcodec/aacdec_fixed: Fix integer overflow in predict() [21:37:06 CET] <cone-233> ffmpeg 03Michael Niedermayer 07master:41d96af2a74c: avcodec/aacdec_fixed: Fix integer overflow in apply_dependent_coupling_fixed() [21:37:07 CET] <cone-233> ffmpeg 03Kaustubh Raste 07master:1181d93231e9: avcodec/mips: Improve avc avg mc 22, 11, 31, 13 and 33 msa functions [21:37:08 CET] <cone-233> ffmpeg 03Kaustubh Raste 07master:93218c223496: avcodec/mips: Improve avc chroma avg hv mc msa functions [21:40:27 CET] <cone-233> ffmpeg 03Seppo Tomperi 07master:0d4d43513786: hevc: Add NEON add_residual for bitdepth 8 [21:40:28 CET] <cone-233> ffmpeg 03James Almer 07master:999c2271a59a: Merge commit '0d4d43513786f1df4d561e1fac924fb0722c6700' [21:42:59 CET] <cone-233> ffmpeg 03Martin Storsjö 07master:e1c2453a4fac: arm: hevc_idct: Tune the add_res_8x8 and add_res_32x32 functions [21:43:00 CET] <cone-233> ffmpeg 03James Almer 07master:05beee44c6b2: Merge commit 'e1c2453a4fac1f7116244d0d05310935c20887e6' [21:55:36 CET] <cone-233> ffmpeg 03Anton Khirnov 07master:831018b0bbe2: mpeg4audio: Make avpriv_copy_pce_data() inline [21:55:37 CET] <cone-233> ffmpeg 03James Almer 07master:9ea06d48c272: Merge commit '831018b0bbe26a603802a9022472f714a59293be' [22:03:37 CET] <cone-233> ffmpeg 03Mark Thompson 07master:b43b95f4789b: vp9_raw_reorder_bsf: Remove a redundant allocation [22:03:38 CET] <cone-233> ffmpeg 03Mark Thompson 07master:9203aac22874: avconv_hw: Add implicit device creation with default parameters [22:03:39 CET] <cone-233> ffmpeg 03Mark Thompson 07master:e669db76108d: avconv: Support setting the hardware device to use when filtering [22:03:40 CET] <cone-233> ffmpeg 03Mark Thompson 07master:aa51bb3d2756: hwcontext_qsv: Support derivation from child devices [22:03:41 CET] <cone-233> ffmpeg 03Mark Thompson 07master:27978155bc66: hwcontext: Add frame context mapping for nontrivial contexts [22:03:42 CET] <cone-233> ffmpeg 03Mark Thompson 07master:eaa5e0710496: hwcontext_qsv: Implement mapping frames from the child device type [22:03:43 CET] <cone-233> ffmpeg 03Mark Thompson 07master:e1c5d56b18b8: hwcontext_qsv: Implement mapping frames to the child device type [22:03:44 CET] <cone-233> ffmpeg 03Mark Thompson 07master:c5714b51aad4: hwcontext: Improve allocation in derived contexts [22:03:45 CET] <cone-233> ffmpeg 03Mark Thompson 07master:38cb05f1c89c: vf_hwmap: Add device derivation [22:03:46 CET] <cone-233> ffmpeg 03Mark Thompson 07master:81a4cb8e5863: vf_hwmap: Add reverse mapping for hardware frames [22:03:47 CET] <cone-233> ffmpeg 03James Almer 07master:550e5d660253: Merge commit '81a4cb8e58636d4efd200c2b4fec786a7e948d8b' [22:08:42 CET] <cone-233> ffmpeg 03Alexandra Hájková 07master:edbf0fffb15d: hevc: Add NEON add_residual for bitdepth 10 [22:08:43 CET] <cone-233> ffmpeg 03James Almer 07master:31a411293619: Merge commit 'edbf0fffb15dde7a1de70b05855529d5fc769f14' [22:11:11 CET] <cone-233> ffmpeg 03Luca Barbato 07master:73fc82f3434d: vlc: Add header #include when the types are used [22:11:12 CET] <cone-233> ffmpeg 03Luca Barbato 07master:0ac1fec1c3da: bitstream: Move VLC reading functions into the vlc.h header [22:11:13 CET] <cone-233> ffmpeg 03James Almer 07master:ff173ce8f1a8: Merge commit '0ac1fec1c3dacedabbf3dd4122ef4bf8523e688c' [22:25:04 CET] <BBB> re: bug 6775, why flush the decoder after each discontinuity? [22:25:10 CET] <BBB> that seems overlay aggressive and unnecessary [22:26:51 CET] <nevcairiel> it is [22:28:18 CET] <nevcairiel> its perfectly expected for decoding to stop working after draining unless you call flush buffers [22:28:25 CET] <nevcairiel> i think its even documented that its required [23:13:33 CET] <cone-233> ffmpeg 03Diego Biurrun 07master:b5f19f747849: aac: Split function to parse ADTS header data into public and private part [23:13:34 CET] <cone-233> ffmpeg 03James Almer 07master:b9d3def9b2cb: Merge commit 'b5f19f7478492307e4b4763aeac3180faf50e17f' [23:26:22 CET] <kierank> what tools are good for debugging OOM memory leaks [23:27:07 CET] <atomnuker> malloc wrappers? [23:28:00 CET] <jkqxz> Normal memory leak tools + exit()? [23:31:24 CET] <kierank> valgrind just exits [23:31:32 CET] <kierank> after pruning [23:31:53 CET] <kierank> I can clearly reproduce that h264 leak at least [23:32:11 CET] <kierank> dunno how that guy managed to record that [23:36:31 CET] <kierank> something related to ff_h2645_extract_rbsp [23:48:52 CET] <iive> strange, valgrind has an option to report unfreed memory on exit [23:51:36 CET] <cone-233> ffmpeg 03Alex Converse 07master:504403ab2868: aacsbr: Turnoff in the event of over read. [23:51:37 CET] <cone-233> ffmpeg 03James Almer 07master:989254fcff82: Merge commit '504403ab28688588fb85817ad58964482f67f29f' [00:00:00 CET] --- Tue Oct 31 2017

1 0

ffmpeg.log.20171030
by burek 31 Oct '17

31 Oct '17

[00:01:40 CET] <c3r1c3-Win> Depends on the implementation, but usually RTMP out-of-the-box is about 30-60 seconds. [00:02:13 CET] <Cracki> can be 5 secs [00:02:29 CET] <Cracki> rtmp is an adobe flash technology though... [00:02:34 CET] <ZeroWalker> oh.. [00:02:50 CET] <Cracki> in any case... do you require this to work in a browser? [00:02:52 CET] <ZeroWalker> not a fan of adobe flash, isn't there something, newer xd? [00:02:55 CET] <Cracki> if yes, you have few options [00:02:57 CET] <c3r1c3-Win> But tons/others support it. Just because it's an Adobe tech doesn't mean much. [00:03:13 CET] <Cracki> if app, lots more options [00:03:20 CET] <c3r1c3-Win> HLs is usually 40-90 seconds out-of-the-box. [00:03:23 CET] <ZeroWalker> depends, it doesn't have to work in a browser, but that could ease things if it did [00:03:27 CET] <Cracki> browsers only have webrtc or DASH/HLS [00:03:35 CET] <c3r1c3-Win> DASH is about the same as HLS. [00:04:06 CET] <Cracki> dash/hls can be configured to have latency on the order of seconds [00:04:18 CET] <Cracki> that just means small blocks [00:04:31 CET] <c3r1c3-Win> Yes (and the keyframes to go with it) [00:04:32 CET] <JEEB> yea, lower segment lengths and then of course you can optimize latency on encoder side as well (less lookahead etc) [00:04:40 CET] <ZeroWalker> i could make a program in android that does the thing if that's recommended, a browser would just be useful for it's simplicity [00:05:43 CET] <ZeroWalker> hmm i guess in that case i would want something that's tcp based, as i would need to notice when a connection is dropped [00:05:45 CET] <Cracki> https://docs.peer5.com/guides/setting-up-hls-live-streaming-server-using-ng… [00:05:52 CET] <ZeroWalker> else it would be hard to do a "on demand" [00:05:55 CET] <Cracki> those things don't have connections [00:06:09 CET] <Cracki> the server might notice if nobody asks for the segments [00:06:35 CET] <ZeroWalker> hmm, so it basically sends data to the server [00:06:39 CET] <Cracki> but usually what happens is that the stream is constantly turned into segments and the most recent N of them are kept for streaming [00:06:44 CET] <ZeroWalker> and the server will send it to however is connected to it [00:06:55 CET] <Cracki> and in the case of HLS, the "stream" is a playlist-like thing [00:07:17 CET] <ZeroWalker> so it's basically small clips so to speak [00:07:18 CET] <Cracki> of those segments, which are reassembled clientside [00:07:30 CET] <Cracki> there's javascript that can reassemble them and feed them into the browser's video decoding [00:07:49 CET] <Cracki> mpeg transport stream files, commonly [00:08:18 CET] <ZeroWalker> hmm [00:08:18 CET] <Cracki> afaik only apple devices can do HLS natively. for everything else, there's javascript. it's pretty standard. [00:08:27 CET] <Cracki> it's just remuxing [00:08:34 CET] <Cracki> if even that [00:08:44 CET] <Mavrik> apple devices and Microsoft Edge :P [00:09:23 CET] <ZeroWalker> yeah, just thinking that it seems to be a roundabout way. it might be easier to just request the data, then a player will wait for it (tcp) and the server will begin transfering to that device [00:09:32 CET] <ZeroWalker> then when it's closed, it will wait for another request [00:09:42 CET] <furq> 23:01:40 ( c3r1c3-Win) Depends on the implementation, but usually RTMP out-of-the-box is about 30-60 seconds. [00:09:45 CET] <furq> uhh [00:10:12 CET] <furq> that's about 10 times higher than my experience of it [00:10:36 CET] <ZeroWalker> does html5 players support tcp from ffmpeg? [00:10:40 CET] <furq> no [00:10:43 CET] <ZeroWalker> :( [00:10:52 CET] <furq> html5 players support hls and dash [00:11:08 CET] <Cracki> ffmpeg is not a streaming server [00:11:08 CET] <ZeroWalker> didn't they add some kind of matroska support? [00:11:13 CET] <furq> webm [00:11:19 CET] <furq> which you can use for fash [00:11:20 CET] <furq> dash [00:11:22 CET] <Cracki> mkv is a superset of webm, so they do that [00:11:30 CET] <Cracki> >fash [00:11:32 CET] <ZeroWalker> but ffmpeg can stream p2p right? [00:11:38 CET] <furq> it can stream to a server [00:11:42 CET] <Cracki> what is p2p to you? [00:11:47 CET] <furq> it can also write hls or dash fragments, since those are just files served over http [00:11:54 CET] <ZeroWalker> ffmpeg on server to ffplay on client [00:11:58 CET] <ZeroWalker> for example [00:12:03 CET] <furq> you could do that but not to a browser [00:12:09 CET] <furq> and also ffmpeg will die if there are no clients [00:12:28 CET] <c3r1c3-Win> furq: Good point. I'm talking about my experience when streaming through a CDN, not direct connections. [00:12:30 CET] <ZeroWalker> cause that i can do, and then it should be fairly straightforward to just replace ffplay with something else, and then do some kind of automated request thing that activates the stream [00:12:31 CET] <furq> fwiw you don't have to touch anything adobe to use rtmp [00:12:44 CET] <furq> ffmpeg to nginx-rtmp to any decent standalone player on the phone [00:12:44 CET] <Cracki> one end must have a listening socket. ffmpeg only listens once, and only if you ask it to do that [00:12:57 CET] <furq> and yeah if you're not going through a cdn then less than 5 seconds of latency is trivial [00:13:06 CET] <ZeroWalker> furq, yeah and that would be fine, as then i could ignore the browser part and just have ffmpeg and some kind of server to do the requests [00:13:11 CET] <furq> right [00:13:13 CET] <ZeroWalker> so like if a request goes to camera 1 [00:13:18 CET] <ZeroWalker> it will then simply start ffmpeg [00:13:26 CET] <furq> i only recommend rtmp because there's an oss server which is easy to set up [00:13:26 CET] <c3r1c3-Win> You could just write a script to have ffmpeg listen and loop around if it doesn't get anything. ;-) [00:13:33 CET] <Cracki> ^ [00:13:50 CET] <furq> rtsp is probably better in general but i don't know of anything decent to serve it with [00:13:57 CET] <c3r1c3-Win> That's what I did to have ffmpeg recompress my stream coming from OBS on a different box. [00:14:21 CET] <furq> ZeroWalker: you can also do that with nginx-rtmp [00:14:29 CET] <furq> you can have it pull in a stream on a play request [00:15:13 CET] <furq> https://github.com/arut/nginx-rtmp-module [00:15:27 CET] <furq> that's easy to get running so i'd probably set that up and see if it works for you [00:15:36 CET] <furq> if not then there's probably other routes [00:15:42 CET] <furq> probably [00:16:29 CET] <ZeroWalker> hmm, not got any experience with nginx, but will try some stuff out and see where it leads me [00:17:43 CET] <blap> head towards the light [00:26:59 CET] <RadSurfer> I'm trying to convert a msmpeg4v3 to h264, with highest quality, can someone help please? [00:27:45 CET] <RadSurfer> can't seem to lower quality below 28 [00:50:44 CET] <pzich> what happens if you set -crf to something like 10? [00:50:58 CET] <RadSurfer> It appears to lock down to 25 then [00:51:22 CET] <RadSurfer> apparently a 700mb file will become 3x that size?? ouch [00:51:35 CET] <pzich> yeah, you pay a steep price for lossless [00:51:45 CET] <pzich> or anything closer to it [01:09:05 CET] <ZeroWalker> if you create your own ssl certificate with openssl, will the encryption and all be fine, and the only thing the browsers etc complain about is that it's not signed by some kind of authority [01:11:40 CET] <pzich> depending on how you want to set it up, you might be able to get a cert for free at https://letsencrypt.org/ [01:12:52 CET] <RadSurfer> filesize was just a bit larger than original .avi!! so this worked well enough. [01:17:07 CET] <redrabbit> and letsencrypt.org is quite easy to setup [01:22:14 CET] <ZeroWalker> oh, well totally new to this, i just did this: https://www.digitalocean.com/community/tutorials/how-to-create-an-ssl-certi… [01:22:22 CET] <ZeroWalker> if i can get a working thing for free then it's great [01:22:45 CET] <ZeroWalker> i only want it as i guess if you have a user/pass thing going on, if it's not ssl the data will be sent in plain text [01:23:15 CET] <redrabbit> letsencrypt.org avoids the issues you get with non-signed certs and its free [01:23:23 CET] <redrabbit> self-signed [01:24:26 CET] <ZeroWalker> ah [01:24:30 CET] <ZeroWalker> will see if i can get it working [01:25:42 CET] <redrabbit> also, i redirect clients that connect to http to https [01:26:31 CET] <ZeroWalker> ah, well i only want to use https so that would be nice [01:30:24 CET] <ZeroWalker> hmm, okay think i atleast got the certificate, maybe, no clue how to set it up with nginx though lo lxd [01:35:58 CET] <ZeroWalker> okay might be that i am using an ip as i don't own a domain and ssl forbids it it seems [01:56:19 CET] <DHE> ZeroWalker: off-topic, but encryption is no good if you can't trust that you're communicating with the target you think you are. self-signed certs don't have that level of trust. [01:57:01 CET] <ZeroWalker> ah [01:57:41 CET] <DHE> now, you can work around that by making your own certificate authority and adding it to your own browsers. that works if it's just you or your organization using them. otherwise, no do it properly [01:59:09 CET] <ZeroWalker> hmm, well i might get away with something like that i guess, as i might not even have to use http per see as it's just a p2p, so i could have application to application and then have some kind of encryption going on there or something [01:59:23 CET] <ZeroWalker> or maybe not, no clue at this point;p [01:59:43 CET] <ZeroWalker> btw is there a way to make a html button execute code on the server itself [01:59:48 CET] <ZeroWalker> or rather, a script [02:25:53 CET] <Quick_Wango> Hi! I'm currently using the loudnorm filter to normalize my audio. On a few Led Zeppelin songs the first pass (measuring) return inf and -inf values for multiple and -70 for the thresholds. Can anyone explain this? [02:27:00 CET] <Quick_Wango> might that be an encoder problem? [03:46:26 CET] <Quick_Wango> ok the audio file was just a little broken [04:12:20 CET] <hendry> is there a way to detect a blank .ts? https://s.natalian.org/2017-10-30/blank.ts [04:13:19 CET] <Dan0maN> hello all. i'm looking to purchase a usb RCA/S-Video capture device to try to digitize some old VHS and 8mm camera media. was looking at this one: https://www.amazon.com/Hauppauge-610-USB-Live-Digitizer-Capture/dp/B0036VO2… [04:13:48 CET] <Dan0maN> anyone have any other suggestions for one of these? [04:14:12 CET] <Dan0maN> (will be used on a linux host) [04:16:05 CET] <blap> where are you located Dan0maN [04:16:55 CET] <blap> well that's nice and convenient (usb)... i still have a hauppage dual-channel pci card here [04:17:07 CET] <blap> which would be nice if someone would use it [04:21:41 CET] <hendry> Dan0maN: i prefer the driverless USB UVC ones https://natalian.org/2015/03/13/HDMI_in/ [04:22:42 CET] <hendry> Dan0maN: i would probably get this http://www.magewell.com/usb-capture-hdmi [04:28:37 CET] <Dan0maN> thanks, hendry. and sorry, blap. i'm working with mostly laptops and tablets these days. [04:30:22 CET] <Dan0maN> hendry: these look to be hdmi only. i'm having to convert some ancient videos for my mother and wife. will need RCA and/or S-Video inputs [04:32:24 CET] <hendry> Dan0maN: i'm sure you can find some HDMI adaptors for that [04:32:44 CET] Action: blap ponders wat do [04:32:45 CET] <hendry> Dan0maN: aren't there firms that do that for you where you are? it's PAINFUL work [04:33:15 CET] <hendry> Dan0maN: if it's a linux host, then iirc all that hauppage / blackmagic wont' work. Magewell is the only realistic choice that I've found. [04:34:08 CET] <Dan0maN> hendry: interesting. i saw this for the hauppage: https://www.linuxtv.org/wiki/index.php/Hauppauge_USB-Live-2 [04:34:24 CET] <Dan0maN> and one of the amazon reviews shows it working for ubuntu with vlc [04:35:44 CET] <Dan0maN> i personally run centos, but if the 3.6+ kernels support it, then i should be covered by the 3.10. all else fails, i could pxe/livecd an ubuntu if i had to [04:35:51 CET] <hendry> Dan0maN: don't think i trust that [04:36:17 CET] <hendry> Dan0maN: i would want to see outputs like `v4l2-ctl -L -d /dev/video0` to get some confidence [04:36:33 CET] <hendry> but i guess you can always return it, since it's Amazon ? [04:37:04 CET] <Dan0maN> hopefully [04:37:26 CET] <Dan0maN> i mean, i just got some mid-ordered matcha tea in that apparently can't be returned. *shrugs* [04:38:09 CET] <Dan0maN> but thanks for the warnings, hendry. this is why i figured i would ask in here [04:38:21 CET] <Dan0maN> hoping to find a trustworthy device [04:43:16 CET] <Chad__> Hello. I'm struggling with getting an image to loop while I have audio input from a mic and pushing to rtmp server. I have figured out stream from my raspberry pi camera with the audio input, however, can't seem to figure out how to remove the video and replace with the image. This is the video command I got to work: ffmpeg -f alsa -ac 1 -i plughw:1,0 -f v4l2 -s 1920x1080 -r 30 -input_format h264 -i /dev/video0 -vcodec copy -preset v [04:43:29 CET] <Chad__> Hmm. It cut off the command: ffmpeg -f alsa -ac 1 -i plughw:1,0 -f v4l2 -s 1920x1080 -r 30 -input_format h264 -i /dev/video0 -vcodec copy -preset veryfast -r 15 -g 30 -b:v 64k -ar 44100 -threads 6 -b:a 96k -bufsize 3000k -f flv rtmp://rtmp_url [05:23:38 CET] <SolarAquarion> ibavdevice/decklink_dec.cpp: In function int ff_decklink_read_header(AVFormatContext*): [05:23:39 CET] <SolarAquarion> libavdevice/decklink_dec.cpp:962:77: error: expected ; before ) token [05:23:39 CET] <SolarAquarion> st->r_frame_rate = av_make_q(st->time_base.den, st->time_base.num)); [05:34:23 CET] <hendry> hi, what's good guide for a standard 1080p stream bitrate, 720p bitrate and so on? Any resources just for a rough guideline? [05:35:52 CET] <lindylex> I am trying to add an overlay to my concat videos like this but it is not working : ffmpeg -i c1.mov -i c2.mov -i c3_.mkv -i brandVideos.png -filter_complex " [0:v:0] [0:a:0] [1:v:0] [1:a:0] [2:v:0] [2:a:0] concat=n=3:v=1:a=1 [v] [a], overlay=x=770:y=680 " -map "[v]" -map "[a]" -vcodec libx264 -crf 23 -preset medium -acodec aac -strict experimental -ac 2 -ar 44100 -ab 128k -y love.mp4 [05:53:53 CET] <lindylex> I figured it out. This is how you do it ::: ffmpeg -i c1.mov -i c2.mov -i c3_.mkv -i brandVideos.png -filter_complex " [0:v:0] [0:a:0] [1:v:0] [1:a:0] [2:v:0] [2:a:0] concat=n=3:v=1:a=1 [v] [a]; [v]overlay=x=770:y=680 [out] " -map "[out]" -map "[a]" -vcodec libx264 -crf 23 -preset medium -acodec aac -strict experimental -ac 2 -ar 44100 -ab 128k -y love.mp4 [06:44:04 CET] <thebombzen> apparently Opus supports 5.1 surround sound, but ffmpeg refuses to encode 5.1 surround sound with libopus. is this a bug? [08:31:37 CET] <lebron_> Hi! I am trying to use ffmpeg for encoding video with vp8_vaapi encoder on Skylake i3 6006u CPU. On centOS im install IntelMediaSDK and compile ffmpeg with --enable-vaapi flag. But when encoding i got error "Failed to query surface attributes: 20 (the requested function is not implemented)." [08:31:37 CET] <lebron_> <nik> this is afret this command: ffmpeg -vaapi_device /dev/dri/renderD128 -i 1080p.mp4 -vf 'format=yuv420p,hwupload' -c:v h264_vaapi out.mkv [08:31:37 CET] <lebron_> <nik> can anyone help me with that? [08:59:12 CET] <hendry> never had any success with h/w driven encoding. i think i've heard ppl on this channel say you're better off with software encoding. Not entirely sure why. [09:15:16 CET] <JEEB> hendry: hw encoding never was made for good compression ratios. if you need something that doesn't utilize the cpu and you can stick bits at it until it sticks it works f.ex. for capture [09:15:37 CET] <JEEB> esp. with stuff like lossless cosing being available with newer nvidias :p [09:16:19 CET] <JEEB> x264's ultrafast or superfast can often end up as fast and have much better compression if you can utilize the cpu [09:17:30 CET] <JEEB> also the hw asics can only take on X encodes at a time as it's specific hardware for the task. cpu based encoding tends to be mire scalable [09:29:00 CET] <hendry> JEEB: good stuff [09:33:50 CET] <hendry> JEEB: whilst you're about, my screen recording tool's mkv cannot be groked by FCPX and most other tools without a heavy re-encode. https://github.com/kaihendry/recordmydesktop2.0/blob/master/x11capture#L55 Why is that? [09:36:56 CET] <JEEB> I just happened to be around and will not be for a while for anything longer :P [09:48:49 CET] <inter123> Hello there. I am getting a message of "http 403 forbidden" message(ffmpeg, linux, static build), whereas in my windows pc the link works fine [09:48:59 CET] <inter123> Does anyone have an idea what am I doing wrong? [10:05:29 CET] <rabbe> hey.. any SBC's which are good for running ffmpeg? [10:06:15 CET] <rabbe> since i want USB3 i have my mind on a Rock64 computer [10:14:58 CET] <sfan5> rabbe: odroid-xu4 might also be worth looking at [10:15:24 CET] <sfan5> really depends on which task you intend to run on it [10:16:42 CET] <rabbe> i have a USB3 capture card. intend on capturing 1080p@60fps, storing files temporarily and provide a REST api for 1 user to fetch it (then delete the file) [10:18:15 CET] <rabbe> further along, i would like to get WebRTC to work.. v4l2 -> rtsp -> webrtc using a Janus gateway to provide 2-3 clients with a live feed.. (as well as having the REST api to control recording of the stream + fetch recording) [10:19:14 CET] <rabbe> (alternativly control recording using webrtc data channels) [10:19:55 CET] <rabbe> odroid-xu4.. i will check out, tnx [10:23:31 CET] <sfan5> sounds like you need a high-end board for that [10:25:42 CET] <rabbe> any suggestion? [10:29:34 CET] <sfan5> nope no idea [10:30:47 CET] <rabbe> but just for recording and share to one client, it will work with rock64 or xu4? [10:32:11 CET] <rabbe> i guess i can adjust the quality, but frame rate is important [10:36:13 CET] <sfan5> do you intend to use x264? [10:40:15 CET] <rabbe> the solution i had so far (on x86) used ffmpeg to create an h264+aac flv over rtmp to nginx and recording was made by having another ffmpeg saving the rtmp as .ts until ctrl-c, followed by .ts > .mp4 [10:40:37 CET] <rabbe> guess i don't need nginx now [10:41:28 CET] <rabbe> so i don't know, ffmpeg directly to h264+aac .ts, followed by .ts > .mp4? [10:42:15 CET] <sfan5> that's a yes [10:42:22 CET] <rabbe> if i understand correctly, that you cannot save to .mp4 and stop recording with ctrl-c [10:42:34 CET] <rabbe> u need the .ts step [10:43:25 CET] <sfan5> since H.264 encoding is quite heavy on the CPU and ARM boards aren't the powerful ones you should consider hardware encoding [10:43:44 CET] <sfan5> getting it to work on these boards is always a huge mess but they provide predictable performance [10:44:58 CET] <rabbe> maybe i'm over my head then.. [10:45:24 CET] <Nacht> Good lord I'm building a monster now. Concatting trough filter, scaling and then adding an overlay, in one command [10:45:42 CET] <sfan5> it's not impossible for x264 to work nicely on an arm board, 1080p60 is just very demanding [11:14:32 CET] <inter123> Can someone please take a look at my problem? I have posted it here: https://superuser.com/questions/1263719/ffmpeg-on-linux-returns-http-error-… [12:59:25 CET] <rabbe> does ffmpeg need any parameters to use hardware encoding? [13:00:15 CET] <Nacht> rabbe: https://trac.ffmpeg.org/wiki/HWAccelIntro [13:02:04 CET] <rabbe> Rockchip MPP is used by the Rock64 computer? [13:08:00 CET] <Nacht> rabbe: I can't say I'm familiar with Rockchip [13:08:18 CET] <rabbe> seems to be Rock64 related anyway [13:13:45 CET] <sleepyhead> hi [13:13:55 CET] <sleepyhead> anyone here familiar with the work of mkvcage? [13:14:30 CET] <sleepyhead> i just want to know how this particular uploader manages to get his 720p uploads down to such a low file size [13:14:36 CET] <sleepyhead> non of the others manage to do it [13:15:28 CET] <sleepyhead> it's all h264. [13:20:27 CET] <CoreX> sleepyhead send me a link in pm to his work [14:34:36 CET] <rabbe> sfan5: is hardware encoding working for the xu4? [14:36:49 CET] <rabbe> using ffmpeg [15:11:11 CET] <firefish5000> I am trying to merge audio/video from a capture device to mkv AND output a frame every 5 seconds to a png (which I use with imagemagick to detect an end of stream frame) [15:12:13 CET] <firefish5000> the command I am using atm. ffmpeg -i /dev/video0 -f alsa -i 'sysdefault:CARD=USB20' -c:a copy -c:v copy -f matroska -y tmp.mkv -vf fps=1/5 -update 1 tmp.png [15:15:32 CET] <firefish5000> if I remove the png output part (everything after tmp.mkv) I get video and audio in the mkv as expected, but with the png output, I only get video, or audio is corrupted. Not sure which [15:36:42 CET] <firefish5000> This seems to work. ffmpeg -i /dev/video0 -f alsa -i 'sysdefault:CARD=USB20' -c:a copy -c:v copy -f matroska -y pipe:1 | ffmpeg -f matroska -i pipe:0 -c copy -f matroska -y tmp.mkv -vf fps=1/5 -y -update 1 tmp.png [15:57:01 CET] <sfan5> rabbe_: i'm guessing not, each arm bord usually has a somehow different hwenc solution so you're mostly on your own [15:57:41 CET] <rabbe_> okay [15:57:44 CET] <rabbe_> thanks [16:01:48 CET] <sfan5> if you can afford it a low-end i3 / pentium with vaapi encoding support (which is supported by ffmpeg) might be a better choice [16:51:26 CET] <schody> Hello, I use this command: ./ffmpeg -i input.avi -ss 800 -f mp4 -vcodec h264 -acodec aac -preset ultrafast -movflags frag_keyframe+empty_moov+faststart - It seems whole input file is decoded as I get long delay between ffmpeg starts to produce output. Is it intended? Produced output is correct regarding -ss flag. [16:52:01 CET] <schody> I expected the input is seeked to position pointed by -ss [17:02:11 CET] <diqidoq> Which is the best command line tool option for scaling images under Linux by knowing the algorythm under the hood? ffmpeg? imagemagick? The latter sadly do not show off if it is bilinear or lancosz etc. [17:04:07 CET] <diqidoq> or at least imagemagick do not say which version of lanczos [17:37:08 CET] <relaxed> diqidoq: did you look at "man ffmpeg-scaler" ? [17:37:59 CET] <diqidoq> relaxed: thanks for chiming in. I will check! [17:42:18 CET] <relaxed> diqidoq: look at https://trac.ffmpeg.org/wiki/Scaling%20(resizing)%20with%20ffmpeg and set the algorithm with -sws_flags [19:09:30 CET] <mbrr> Big thanks to all the developers and contributors to ffmpeg. Been able to achieve very low latency live audio streaming for my work. [19:09:55 CET] <JEEB> :) [19:15:51 CET] <mbrr> Last step is getting the audio to play on mobile. Currently it plays with ffplay on my laptop. Couldn't get vlc or any other application to play the opus/mpegts/udp stream. [19:16:36 CET] <mbrr> I'm installing android-studio with the Native Dev Kit to build an android app that uses ffplay. [19:16:52 CET] <JEEB> try mpv-android if you want something based on libavformat [19:17:02 CET] <JEEB> (in the file picker there's a thing to input a URL at) [19:17:23 CET] <JEEB> also vlc should work with UDP I'd say :/ [19:17:41 CET] <JEEB> it does have a different URL format [19:17:52 CET] <JEEB> if you are setting the source IP [19:18:02 CET] <JEEB> (which often is needed on many networks) [19:18:03 CET] <mbrr> I think the problem with vlc has something to do with opus in mpegts [19:18:11 CET] <JEEB> ah, then it's just an old vlc [19:18:27 CET] <JEEB> it plays opus in mpeg-ts with master (upcoming 3.0) [19:19:21 CET] <mbrr> oh maybe that's it. will try with vlc from source. thanks JEEB! [19:19:36 CET] <JEEB> np [19:19:58 CET] <mbrr> will try mvp-android too [19:20:03 CET] <JEEB> cheers :) [19:20:11 CET] <JEEB> it's probably the worst android app you've ever seen [19:20:19 CET] <JEEB> but hey, I'm a multimedia developer [19:20:34 CET] <JEEB> (and the other devs are more systems developers than UI developers) [19:20:48 CET] <JEEB> generally though, stuff like multicast over wifi can be rather flakey [19:20:53 CET] <JEEB> although I guess with audio only it might be better [19:21:22 CET] <JEEB> I couldn't get RTSP over UDP or multicast UDP to work at my office when I got some streams going :P [19:21:30 CET] <JEEB> and I wasn't even using wifi [19:21:36 CET] <JEEB> darn poor networks [19:22:01 CET] <mbrr> oh. That is what I'm doing - multicast udp. but you were working on video? [19:22:16 CET] <JEEB> yea I was dealing with a ~13 megabit mpeg-ts pipe [19:22:36 CET] <JEEB> was getting constant drops even over the wired network due to the switches etc [19:22:49 CET] <JEEB> but as I noted, a low bit rate audio thing is less likely to have that issue [19:24:55 CET] <JEEB> I mean, given that you get the multicast over the wifi altogether [19:24:56 CET] <mbrr> When you say drops, do you mean packets or streams? Would it come right back? [19:25:02 CET] <JEEB> packets [19:25:11 CET] <JEEB> and yes, it would stay around, just packet drops etc [19:25:24 CET] <JEEB> but this was over wired anyways [19:25:48 CET] <mbrr> I get that when I stream from rpi. [19:27:15 CET] <mbrr> thinking I'll need to move to a more powerful single board computer [19:34:09 CET] <mbrr> is mvp-android in the play store or should I pull from github? [19:34:44 CET] <furq> mbrr: i take it icecast is too high latency [19:34:57 CET] <pgorley> hi, does 3.4 contain all the hwaccel decode api changes? [19:35:27 CET] <mbrr> yeah. I didn't even try icecast. need real time [19:35:47 CET] <JEEB> mbrr: yea it is on the play store :) [19:35:49 CET] <sfan5> mbrr: it's in the play store, github has identicaly apks anyway [19:36:00 CET] <sfan5> identical* [19:36:03 CET] <JEEB> yup [19:38:13 CET] <mbrr> found it. was searching mvp. thanks [19:43:42 CET] <mbrr> it works! mpv-android, my savior [19:44:08 CET] <mbrr> Is there a way to specify the nobuffer flag like I was in ffplay? [19:44:47 CET] <sfan5> mpv has --no-cache but mpv-android does not provide any way to pass "raw" flags like that [19:44:48 CET] <mbrr> thank you. thank you. thank you. [19:45:56 CET] <JEEB> some protocols take parameters also in the URL [19:51:45 CET] <mbrr> May I fork mvp-android and use it as a base? just need to tweak the buffer size for real time. [19:52:22 CET] <JEEB> as long as you follow the license (also check the license for the file selector and if it doesn't match drop that one as a depedency) [19:56:26 CET] <sfan5> hint: it's mpv for "mpv plays video" [19:56:31 CET] <sfan5> ;) [19:59:59 CET] <mbrr> and a recursive acronym to top it off. mpv for the win. thanks all [20:01:33 CET] <JEEB> also do note that (lib)mpv's and FFmpeg's licenses are what in the end decide the license of the whole package, as those are the libraries basically doing all the heavy lifting :) [20:02:02 CET] <JEEB> although if you're just publicly forking and publishing all the sources you've used you should even be OK with GPL [20:49:05 CET] <mbrr> thanks sfan5 for these wonder buildscripts and documentation. [20:49:22 CET] <mbrr> *wonderful [20:49:44 CET] <JEEB> yea, he did a great job there :) [22:33:13 CET] <redrabbit> hi [22:33:23 CET] <durandal_170> hi [22:33:28 CET] <redrabbit> i tried using -c:v h264_cuvid for hw accelleration on input [22:33:39 CET] <redrabbit> it works well however mpeg2 content fails with this [22:33:53 CET] <redrabbit> and its for a streaming software that uses 1 line for any type of content [22:34:06 CET] <durandal_170> mpeg2 is not h264 [22:34:09 CET] <redrabbit> so i tried -hwaccel cuvid but it doesnt use hw accell [22:34:11 CET] <redrabbit> yep [22:34:22 CET] <redrabbit> i need something that works with both [22:34:44 CET] <redrabbit> suposedly -hwaccel cuvid does but it didnt enable hw decoding for me [22:38:16 CET] <redrabbit> h264_cuvid mjpeg_cuvid mpeg2_cuvid vc1_cuvid vp9_cuvid hevc_cuvid mpeg1_cuvid mpeg4_cuvid vp8_cuvid [22:39:11 CET] <redrabbit> meh.. looks like i have to stick with sw decoders because i dont see a way to use hw decoding with 1 line that fits with both mpeg2 and avc [22:39:43 CET] <durandal_170> no [22:42:53 CET] <redrabbit> so its not possible? [22:44:28 CET] <pgorley> you could do a bash script or something [22:44:59 CET] <redrabbit> well im not sure i can, its only a config file in a streaming iptv software [22:45:26 CET] <pgorley> :/ [22:45:36 CET] <redrabbit> maybe request such feature and sit tight [22:45:42 CET] <redrabbit> erf [22:48:19 CET] <pgorley> you could poke the cuvid maintainer, maybe they plan on making it follow the hwaccel api instead of using only standalone hw decoders [22:58:30 CET] <orbea> Hi, idk how or why, but suddenly the ffmpeg configure script started reaching an infinite loop on my system... I traced it to line 6668 in the master: unique ${linkunit}_extralibs [22:58:38 CET] <redrabbit> with hw decoder : 2.30% cpu, without : up to 25% [22:58:38 CET] <redrabbit> :( [22:58:43 CET] <orbea> I managed to work around it with this, but im not sure this is correct? http://dpaste.com/2X4N5B7 [22:58:50 CET] <redrabbit> good idea to try with cuvid [23:13:43 CET] <geri> hi [23:13:55 CET] <geri> what video codec you recommend for screen recording? [23:14:05 CET] <geri> screen capture [23:14:09 CET] <geri> i was reading about TechSmith or iSCC [23:17:14 CET] <furq> neither of those are part of ffmpeg, so probably not those [23:17:42 CET] <geri> ok [23:17:54 CET] <geri> whats recommended with ffmpeg lib? [23:18:44 CET] <furq> probably ffv1 [23:18:54 CET] <geri> i could only store those frames which include changes on the screen... [23:18:57 CET] <furq> or maybe qtrle if you're doing desktop capture [23:19:11 CET] <geri> are those codecs doing somth like that? [23:19:18 CET] <furq> ffv1 does [23:19:21 CET] <furq> well [23:19:25 CET] <furq> actually nvm i misread that [23:19:37 CET] <furq> no, but ffv1 does inter-frame compression, so any unchanged frames will be very small [23:19:48 CET] <furq> same with x264 lossless but i don't think that does particularly well with rgb [23:20:13 CET] <geri> it would be good if you could pass the video codec only those changes somehow' [23:20:32 CET] <geri> so in case if nothing changes the data beeing transferred will be small [23:20:32 CET] <furq> there are filters you can use to drop unchanged frames [23:20:45 CET] <furq> the capture device will still send every frame though [23:21:06 CET] <furq> !filter mpdecimate @geri [23:21:06 CET] <nfobot> geri: http://ffmpeg.org/ffmpeg-filters.html#mpdecimate [23:21:07 CET] <geri> in full resolution? [23:21:14 CET] <furq> yes [23:21:30 CET] <furq> you can adjust the capture framerate but that's probably not a great solution [23:24:27 CET] <geri> when i look at opencv the framerate should be constant [23:25:17 CET] <geri> is ffv1 fast? [23:25:27 CET] <furq> it should be fast enough [23:25:36 CET] <furq> depends what the resolution and framerate is, and what cpu you're using [23:25:54 CET] <geri> faster than 'H264' [23:26:05 CET] <geri> or X264 [23:26:11 CET] <furq> depends what x264 settings you're using [23:26:21 CET] <furq> it's probably slower than x264 ultrafast but i'd expect it to be smaller for rgb [23:31:36 CET] <Cracki> ffv1 has noticeable inter-frame compression? hm... last time, I didn't get that to work [23:35:19 CET] <furq> sure [23:35:29 CET] <furq> try -f lavfi -i smptebars -c:v ffv1 [23:35:38 CET] <furq> then compare that with ffvhuff or something [23:36:14 CET] <Cracki> -c:v ffv1 -g 1500 still gives me huge data rates [23:36:32 CET] <Cracki> does it need some more arguments? [23:37:07 CET] <geri> how is DIVX performance? [23:37:10 CET] <Cracki> (on screencast source) [23:37:17 CET] <furq> http://vpaste.net/5U6Ma [23:38:42 CET] <Cracki> 120 kbit/s for a static image is a bit much, I think [23:38:50 CET] <Cracki> suggests intra-only [23:38:56 CET] <Cracki> does it do inter-frame too? [23:39:50 CET] <Cracki> ok my screencast source might be bad... i'll try another [23:40:38 CET] <geri> H264 supports inter compression? [23:40:55 CET] <Cracki> got a qtrle source with static content, still 15 Mbit/s [23:41:15 CET] <Cracki> most video codecs get their data rate down by using inter-frame compression [23:42:13 CET] <Cracki> ah! ffv1 does no inter-frame prediction at all [23:43:03 CET] <Cracki> I should spend some time on the qtrle encoder code... [23:43:11 CET] <geri> are those videowriters in opencv always assume const framerate? https://docs.opencv.org/3.3.0/dd/d9e/classcv_1_1VideoWriter.html [23:43:19 CET] <Cracki> yes [23:43:27 CET] <Cracki> but nobody here is supposed to know that [23:45:53 CET] <furq> Cracki: what is ffv1 doing then [23:46:21 CET] <Cracki> intra [23:46:36 CET] <furq> i mean how is it so small compared to other intra-only codecs [23:46:48 CET] <Cracki> I wouldn't know [23:46:59 CET] <Cracki> perhaps other intra-only codecs are just _dumb_ [23:48:03 CET] <Cracki> https://en.wikipedia.org/wiki/FFV1#Compression_details [00:00:00 CET] --- Tue Oct 31 2017

1 0

ffmpeg-devel.log.20171029
by burek 30 Oct '17

30 Oct '17

[00:05:40 CEST] <ubitux> what's the state of our vorbis encoder? [00:05:48 CEST] <ubitux> is it good compared to libvorbis? [00:06:08 CEST] <ubitux> seems my shitty rpi3 isn't able to hold real time encoding, i wonder if it would help to use ffmpeg encoding [00:07:48 CEST] <atomnuker> I haven't yet merged the last gsoc patches (I really should) [00:09:01 CEST] <ubitux> atomnuker: btw, dunno if you were told, but mainline odroid is working [00:09:09 CEST] <ubitux> mainline on odroid c2* [00:09:15 CEST] <atomnuker> yep, I'm using it on my 2 c2 boards [00:09:24 CEST] <atomnuker> libvorbis doesn't seem to have any simd [00:09:31 CEST] <ubitux> yeah [00:09:36 CEST] <atomnuker> we have mdct simd for most platform so it should be faster [00:09:42 CEST] <ubitux> i'm assuming that's why i'm getting lags [00:09:55 CEST] <ubitux> but it's curious because i didn't have any issue with an old armv7 board [00:10:00 CEST] <atomnuker> the codec is good enough that even the worst encoder sounds decent, even at 54 kbps [00:10:19 CEST] <ubitux> ok [00:11:01 CEST] <ubitux> btw, funny that libvorbis has more autotools build files than source code [00:11:27 CEST] <nevcairiel> autotools is just evil like that [00:11:54 CEST] <ubitux> seriously, there is like at least 20 files for the build in the root dir [00:12:17 CEST] <atomnuker> do we have the float_dsp equivalent for non-float stuff? [00:12:49 CEST] <ubitux> fixed_dsp? [00:13:26 CEST] <ubitux> libavutil/fixed_dsp.h [00:13:42 CEST] <ubitux> seems it was introduced for mips [00:14:25 CEST] <atomnuker> nah, I need it for video [00:16:41 CEST] <nevcairiel> fixed_dsp is for fixed point numbers like the aac fixed point decoder, not sure how those compare to actual integer video data [00:40:16 CEST] <durandal_1707> admit it: ffmpeg is dead [00:45:33 CEST] <jamrial> ubitux: it can't even do real time? [00:46:24 CEST] <ubitux> i get a lot of stuttering [00:46:38 CEST] <jamrial> even a mid-low range x86 cpu can do 20x real time libvorbis with one thread [00:46:42 CEST] <jamrial> how shitty can that thing be o_o [00:46:51 CEST] <ubitux> :) [00:49:49 CEST] <durandal_1707> i cant introduce new flag for mb types, so i will add private option to mpeg2video decoder [00:51:02 CEST] <durandal_1707> why nobody calls a vote for hwaccel patch thing? [00:53:53 CEST] <jamrial> durandal_1707: wm4 didn't want to do it [00:54:22 CEST] <jamrial> durandal_1707: you mean new option to mpegvideo for the debug mv stuff? [00:55:44 CEST] <durandal_1707> yes [00:55:48 CEST] <ubitux> durandal_1707: private option in mpeg2 should be pretty fine for now, designing a clean api for mb types is going to take a lot of time to make everyone happy [00:58:27 CEST] <jamrial> if that's enough to not restore the disabled public symbols in avcodec.h and options_table.h, it should be fine for now [01:41:29 CEST] <TD-Linux> ubitux, my rpi2 encodes with libvorbis at 10x realtime... [01:42:32 CEST] <TD-Linux> er 4.8x realtime [01:44:02 CEST] <TD-Linux> (also libopus does 6x-12x realtime depending on complexity setting) [01:46:46 CEST] <cone-514> ffmpeg 03Carl Eugen Hoyos 07master:1da8c4ec85c1: lavfi/palettegen: Allow setting the background colour. [01:49:35 CEST] <TD-Linux> ubitux, one thing to keep in mind if you're trying to do really low latency stuff is that rpi3 core migrations are slow. try locking to one core with taskset [02:36:25 CEST] <cone-514> ffmpeg 03Carl Eugen Hoyos 07master:8b43039fe19c: lavfi/palettegen: Fix compilation after 1da8c4e. [03:38:38 CET] <BBB> durandal_1707: the private data for the avfilter is fine [03:38:49 CET] <BBB> durandal_1707: just document it as unspecified data and codec-specific, so we can chagne it over time [04:11:38 CET] <cone-514> ffmpeg 03James Almer 07master:ca2b7794234c: avformat: remove use of deprecated AVFMT_FLAG_KEEP_SIDE_DATA flag [05:33:45 CET] <cone-514> ffmpeg 03Steven Liu 07master:f5208307618d: avformat/hlsenc: fix base_output_dirname is null when basename_size is 0 bug [05:33:46 CET] <cone-514> ffmpeg 03Steven Liu 07master:c3e279e75227: avformat/hlsenc: fix missing first segment bug in fmp4 mode [05:33:47 CET] <cone-514> ffmpeg 03Steven Liu 07master:073986c5aeb8: avformat/hlsenc: reindent hlsenc code [09:35:36 CET] <cone-162> ffmpeg 03Martin Vignali 07master:7da254886fbf: libavcodec/magicyuv : remove unneed variable assignment [09:40:17 CET] <ubitux> TD-Linux: a bunch of things may be the cause of the trouble; i'm relying on MPD to do the encode, and i'm setting a relatively high profile iirc [09:40:39 CET] <ubitux> i haven't benched libvorbis in particular, i just know that's what being used [09:41:28 CET] <ubitux> in wasn't an issue previously on an old A10 [09:42:02 CET] <ubitux> it maybe also be related to the approximate aarch64 mainline support on rpi [12:16:30 CET] <cone-162> ffmpeg 03Paul B Mahol 07master:ca106d6a5c4c: avcodec/magicyuvenc: improve compression [13:06:32 CET] <JEEB> atomnuker: as I noted I was outside the reach of internets and I don't have my related ssh keys on my phone anyways [13:06:45 CET] <JEEB> I'd otherwise had pushed them [13:20:34 CET] Action: kierank wonders how to remove mpeg4video from mpegvideo.c without breaking ER [13:24:53 CET] <BBB> is ER still dependent on mpegvideo in itself? [13:25:05 CET] <BBB> if so, I think the answer is to refactor ER to become itself mpegvideo-independent [13:25:07 CET] <BBB> which is *hard* [13:36:21 CET] <kierank> not dependent actually [13:36:25 CET] <kierank> it does seem possible [14:17:17 CET] <cone-162> ffmpeg 03James Almer 07master:7df37dd319f2: avutil/frame: deprecate getters and setters for AVFrame fields [14:32:17 CET] <cone-162> ffmpeg 03James Almer 07master:307c24b32f30: avformat: move public AVStream fields up in the struct [14:32:18 CET] <cone-162> ffmpeg 03James Almer 07master:b7785d10b00c: avformat: deprecate getters and setters for AVFormatContext and AVStream fields [14:36:38 CET] <cone-162> ffmpeg 03James Almer 07master:c8e8092543dd: avformat/avformat.h: fix pairs typo [14:55:43 CET] <cone-162> ffmpeg 03Carl Eugen Hoyos 07master:9b0510a8e359: lsws/yuv2rgb: Fix yuva2rgb32 on big endian hardware. [15:05:34 CET] <jamrial> JEEB: if nicolas doesn't push his patchset by the time you're back then feel free to do it. git head has been broken long enough already and should be fixed asap [15:09:37 CET] <JEEB> jamrial: sure. getting to a computer in about 3h [15:09:49 CET] <jamrial> JEEB: thanks [15:22:06 CET] <cone-162> ffmpeg 03Martin Vignali 07master:e9930883a26c: libavcodec/bswapdsp : add AVX2 func for bswap_buf (swap uint32_t) [15:30:18 CET] <cone-162> ffmpeg 03Carl Eugen Hoyos 07master:75bd01090f5b: lavf/rtpenc: Add support for 24 bit pcm encoding as defined by RFC 3190. [18:31:18 CET] <cone-501> ffmpeg 03Anton Schubert 07master:3dca4887aef4: dashenc: fix bitrate estimation with correct scaling [18:31:18 CET] <cone-501> ffmpeg 03Peter Große 07master:44ede215b662: dashenc: set DASH related options for the subsequent matroska muxer when using webm [18:31:18 CET] <cone-501> ffmpeg 03Peter Große 07master:1443859a8d0d: dashenc: don't write header data before the first packet arrives [18:31:18 CET] <cone-501> ffmpeg 03Peter Große 07master:2911dabd51dc: dashenc: allow AdaptationSets to have different average frame rates [18:31:18 CET] <cone-501> ffmpeg 03Anton Schubert 07master:fe334712ddc6: dashenc: Don't output frameRates at both AS and Representation-level. Only output maxFrameRate at AS-level. [18:31:18 CET] <cone-501> ffmpeg 03Peter Große 07master:3c838e6442bb: dashenc: copy stream frame rate to output stream [18:31:18 CET] <cone-501> ffmpeg 03Michael Niedermayer 07master:fe533628b960: avcodec/jpeglsdec: Check ilv for being a supported value [18:31:19 CET] <cone-501> ffmpeg 03Michael Niedermayer 07master:f80224ed19a4: avcodec/jpeglsdec: Check for end of bitstream in ls_decode_line() [18:42:16 CET] <cone-501> ffmpeg 03Nicolas George 07master:bfb1a946255f: examples/avio_reading: return AVERROR_EOF at EOF. [18:42:17 CET] <cone-501> ffmpeg 03Nicolas George 07master:a606f27f4c61: lavf/avio: temporarily accept 0 as EOF. [18:42:18 CET] <cone-501> ffmpeg 03Nicolas George 07master:158a79c31d55: lavf/aviobuf: return EINVAL when reading from a write-only context. [18:42:25 CET] <JEEB> jamrial: pushed it [18:43:07 CET] <JEEB> had to modify the lavf/version.h bit a bit since in the middle there was another define added in the middle, but that didn't really seem to be a problem other than making the automagic application of hte patch fail [18:47:05 CET] <jamrial> JEEB: cool :D [18:47:39 CET] <jamrial> JEEB: reply to the thread saying you pushed it in that case [18:47:49 CET] <JEEB> already done [18:50:51 CET] <jamrial> huh, i didn't get anything [18:52:10 CET] <jamrial> there. it spent like five minutes stuck in the ml queue or something [18:52:26 CET] <JEEB> funky [19:42:54 CET] <cone-501> ffmpeg 03James Almer 07master:ddd0b19169dc: ffprobe: remove usage of deprecated getter functions [19:42:55 CET] <cone-501> ffmpeg 03James Almer 07master:5cc5130c813f: ffmpeg: remove usage of deprecated getter functions [19:42:56 CET] <cone-501> ffmpeg 03James Almer 07master:2245476e5c45: avdevice: remove usage of deprecated setter and getter functions [21:24:30 CET] <cone-501> ffmpeg 03Carl Eugen Hoyos 07master:59ceee5896af: fate: Fix some of the fitsdec tests on big-endian. [22:14:19 CET] <jkqxz> "Currently 709 or 601 is decided based on frame size." Good old BT.((frame.height>600)*108+601), always the best colourspace. [22:18:42 CET] <JEEB> :D [23:10:58 CET] <cone-501> ffmpeg 03Carl Eugen Hoyos 07master:4ccc1ef2a3b1: fate: Add bitexact flag to the invalid-elst test. [00:00:00 CET] --- Mon Oct 30 2017

1 0

ffmpeg.log.20171029
by burek 30 Oct '17

30 Oct '17

[03:45:31 CET] <dreamp> Hi there, how are you? I'm trying to build a simple decoder using libav but I couldn't without using deprecated methods to feed AVPacket ( av_read_frame ) [03:45:55 CET] <dreamp> Here's what I'm trying to build [03:45:57 CET] <dreamp> https://gist.github.com/leandromoreira/818962406b4cc53f44fbd7ab6422ad4b#fil… [03:46:56 CET] <dreamp> I used to feed Packets by looping with while(av_read_frame(pFormatCtx, &packet)>=0) { avcodec_decode_video2(pCodecCtx, pFrame, &frameFinished, &packet);} [03:47:55 CET] <dreamp> av_read_frame feed packet from AVFormatContext and then I call avcodec_decode_video2 to feed my frame... but this is now deprecated [03:48:19 CET] <dreamp> and I tried to use the new ways: avcodec_send_packet and avcodec_receive_frame [03:48:28 CET] <dreamp> but I couldn't :( [03:49:47 CET] <dreamp> It keeps failing on receiving frames, in fact I don't see how ( in this new way ) the connection between AVFormatContext and the packets being formed. [04:01:27 CET] <c_14> https://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/examples/decode_video.c [04:01:51 CET] <c_14> You can't just feed it an empty packet, that won't work [04:01:55 CET] <c_14> You need to parse the packet first [04:02:06 CET] <c_14> (check the call for av_parser_parse2) [04:07:02 CET] <c_14> actually [04:07:09 CET] <c_14> can't you just use av_read_frame to fill the packet? [04:08:09 CET] <c_14> I don't see any deprecation guards on that [04:08:25 CET] <c_14> And it'll fill the pkt before the call to send_packet [04:08:48 CET] <c_14> ^dreamp [04:09:28 CET] <dreamp> c_14: thanks I'll take a look [04:10:22 CET] <c_14> And if you get EAGAIN you have to send a new packet with send_packet [04:10:28 CET] <c_14> erroring out there isn't the correct action [04:10:37 CET] <c_14> Since some decoders will buffer packets etc [04:11:35 CET] <dreamp> c_14: I saw this example earlier =/ I'm using AVFormatContext and this example seems to be passing the data from the file itself to the `av_parser_parse2` [04:11:58 CET] <c_14> yeah, which is why I changed my mind and mentioned just using av_read_frame to fill the packet [04:12:59 CET] <dreamp> c_14: thanks a lot =) [04:13:22 CET] <dreamp> I made a smaller version which loops using `av_read_frame` [04:13:23 CET] <dreamp> https://gist.github.com/leandromoreira/818962406b4cc53f44fbd7ab6422ad4b [04:13:45 CET] <dreamp> now I'm getting [04:13:49 CET] <dreamp> [h264 @ 0x7fbe5d802c00] No start code is found. [04:13:56 CET] <dreamp> [h264 @ 0x7fbe5d802c00] Error splitting the input into NAL units. [04:13:59 CET] <dreamp> error sending packet [04:14:08 CET] <c_14> can you open the video with ffmpeg/ffplay or something? [04:14:25 CET] <dreamp> Yes, I downloaded the big bunny [04:14:30 CET] <dreamp> sample to work on. [04:16:02 CET] <c_14> Is the call to avcodec_open2 returning success or error? [04:16:44 CET] <dreamp> yes ;) I'll provide the full solution [04:16:50 CET] <dreamp> (witch all checks) [04:17:30 CET] <dreamp> *with https://gist.github.com/leandromoreira/131cfd8de665404b1cff6442d150ffe1 [04:18:14 CET] <dreamp> the only output for this code is the one I just paste [04:19:38 CET] <dreamp> I also tested with a small video I made (using ffmpeg itself with 3 png) [04:20:44 CET] <dreamp> and the error is the same I think it needs a step before av_read_frame but I couldn't find it on the documentation, I'm gonna check on source code. [04:29:55 CET] <dreamp> c_14: I think I fixed =D thank you very much! [04:30:14 CET] <dreamp> It seems it was very silly [04:30:25 CET] <c_14> what was it? [04:30:29 CET] <dreamp> response = avcodec_receive_frame(pCodecContext, pPacket); [04:30:49 CET] <dreamp> I think I should be receiving frames from the context not sending... [04:31:00 CET] <dreamp> now at least it goes until the end [04:31:09 CET] <dreamp> with no major issue [06:12:28 CET] <_Vi> Why I specify `-c copy` (or `-c:v copy`), but FFmpeg still transcodes `vp9 (native) -> vp9 (libvpx-vp9)`)? [06:16:47 CET] <_Vi> Answer: multiple input files, but missing `-i` option before the second one. [06:28:19 CET] <_Vi> Can `-o` option be added to FFmpeg meaning "specify output file here and overwrite only this file without confirmation"? `-y` and missed `-i` before input do not play well together. [06:40:34 CET] <te-te_> i want to make a audio stream system, which get some audio of wav from embedded device and send to android app. [06:41:30 CET] <te-te_> can i adopt ffmpeg? [06:43:45 CET] <te-te_> i hope the system can play aduio when the embedded device smaple data of audio. [06:53:36 CET] <c3r1c3-Win> te-te_: Why not use a proper audio streaming server? Something like icecast? [07:29:26 CET] <pupp> I tried to merge video with audio, but now audio is 6 seconds longer. How can I extend video with 6 seconds of white screen? [08:46:07 CET] <adgtl> Hello folks [08:46:43 CET] <adgtl> I have 2 files first is .mp4 (h264) and other is .opus... I want to create a combined mp4 file out of it... so I am just doing [08:48:09 CET] <adgtl> ffmpeg -i input.mp4 -i input.opus output.mp4 [08:49:11 CET] <adgtl> here is the log https://gist.github.com/352b571d8ec66a1a5ae7e3c9a4c4fa97 [08:49:42 CET] <adgtl> pls let me know if it right way [08:49:53 CET] <adgtl> thank you [08:50:15 CET] <utack> and you need "copy" as codec for both videos [08:50:28 CET] <utack> -c:a copy -c:v copy [08:51:41 CET] <utack> but seriously mkvmerge GUI would be easier unless it absolutely needs to be mp4..drag and drop and done [08:53:46 CET] <adgtl> utack hmm [08:54:03 CET] <adgtl> utack what is :a and :v? [08:54:18 CET] <utack> audio and video [08:54:31 CET] <utack> you want to copy both from the source file, without re-encode i guess [08:54:35 CET] <adgtl> utack do you mean ffmpeg -i input.mp4 -i input.opus -c:a copy -c:v copy -strict -2 output.mp4? [08:54:52 CET] <adgtl> utack right.. could you confirm if above command is right [08:55:23 CET] <utack> i have no idea..i'd need to test it. does it do the right thing? [08:58:23 CET] <adgtl> utack I just tried this [08:58:24 CET] <adgtl> ffmpeg -i output.mp4 -i output.opus -map 0:v -map 1:a -codec copy -strict -2 zing444.mp4 [08:58:44 CET] <adgtl> but I miss audio there also ..video gets black in between [08:59:13 CET] <adgtl> but ffmpeg -i input.mp4 -i input.opus -strict -2 output.mp4 seems fine [08:59:35 CET] <utack> yeah maybe you need to map...no idea about that. i was just pointing out that in any case you need to tell it to copy the streams isntead of re-encode [09:00:08 CET] <adgtl> utack here is the log when I do use codec copy https://gist.github.com/anildigital/725d35a07767dff992de00cda4a04b47 [09:00:22 CET] <adgtl> okay [09:00:51 CET] <utack> looks correct, what was wrong with hte result? [09:00:56 CET] <utack> Stream #0:0 -> #0:0 (copy) [09:00:56 CET] <utack> Stream #1:0 -> #0:1 (copy) [09:01:00 CET] <utack> isn't that what you wanted? [09:01:06 CET] <utack> both streams copied to one output file? [11:42:07 CET] <diqidoq> how to convert wav 32bit float / 96000 khz into a opus file playable in whatsapp? [11:44:07 CET] <diqidoq> ffmpeg -i session.wav -a:c libopus -b:a 256k session.opus ? is this correct or can I go higher in bitrate ? [11:52:39 CET] <sfan5> diqidoq: according to ffmpeg -h encoder=libopus 96kHz or 32-bit float is not supported by either ffmpeg or libopus [11:52:53 CET] <sfan5> but in theory that command is correct [11:54:01 CET] <sfan5> if you don't mind encoding 16-bit 48kHz you can just use that [11:54:36 CET] <diqidoq> sfan5: before or while converting to opus? [11:55:02 CET] <sfan5> ffmpeg will downsample automatically [11:55:14 CET] <diqidoq> sfan5: I was not sure if you where referring to the original file or to the end result (support) [11:55:30 CET] <sfan5> the end result will be 16-bit 48000Hz [11:55:51 CET] <diqidoq> sfan5: true. tested. [11:56:01 CET] <diqidoq> sfan5: ok, then I am fine I think [11:56:12 CET] <diqidoq> sfan5: thank you so much for chiming in! [11:56:26 CET] <sfan5> sure no problem [11:56:42 CET] <diqidoq> sfan5: Greetings from stormy Berlin ;) [11:57:08 CET] <sfan5> way less stormy here in NRW thankfully [11:57:20 CET] <diqidoq> sfan5: haah :) [11:57:45 CET] <diqidoq> sfan5: Dann einen schönen Sonntag wünsche ich Euch. :) [11:57:55 CET] <sfan5> gleichfalls :) [11:57:58 CET] <diqidoq> :) [13:00:16 CET] <lynn-dance> I am compiling chromaprint and it needs the ffmpeg libraries.... what *.h files need to be copied to /usr/include [13:09:30 CET] <JEEB> lynn-dance: make install installs things properly. during configure you can set prefix with --prefix=/your/prefix , and when you build the other thing you can set PKG_CONFIG_PATH=/your/prefix/lib/pkgconfig [13:12:26 CET] <lynn-dance> i doesn't install header files they need to be copied ..... CMake Error at src/cmd/CMakeLists.txt:27 (add_library): [13:16:22 CET] <JEEB> all public headers get installed with make install [13:17:58 CET] <JEEB> in theory it's possible it got broken but it is highly unlikely. there are other things that are more likely such as the other thing requiring an older FFmpeg or something. check that other library's actual failure point [15:02:40 CET] <livingbeef> I made a gif using ffmpeg (with paletteuse) and now ffprobe insists that pix_fmt=bgra, even though ffmpeg's gif encoder only claims to support rgb8 bgr8 rgb4_byte bgr4_byte gray pal8. Any idea what's happening here? [15:05:51 CET] <furq> it says that about all gifs [15:05:55 CET] <furq> you can probably just ignore it [15:08:18 CET] <livingbeef> Is that a bug or feature? It's bit of a problem when I wnat to find out the pixel format. [15:10:49 CET] <furq> i'm pretty sure gif is always pal8 [15:11:55 CET] <sfan5> i remember reading a blogpost about true color gifs but not sure how that worked [15:12:32 CET] <furq> you can have multiple blocks [15:12:39 CET] <furq> https://upload.wikimedia.org/wikipedia/commons/a/aa/SmallFullColourGIF.gif [15:12:54 CET] <furq> i don't think ffmpeg will let you do anything like that though [15:13:20 CET] <sfan5> then that's technically not pal8 is it? [15:13:35 CET] <furq> each block is pal8 [15:13:45 CET] <furq> idk how you'd describe the pixel format of the entire image or if it's useful to do so [15:14:12 CET] <furq> but that's probably why ffmpeg interprets it as bgra [15:15:21 CET] <livingbeef> Hmm... well, I didn't need it for anything important anywhy. Just curious. [16:04:12 CET] <CoreX> keep getting this on compile https://pastebin.com/raw/GdEaactM [16:04:20 CET] <CoreX> anybody think they can solve it [16:19:05 CET] <relaxed> CoreX: is this a recent git checkout of libx264? which ffmpeg version? [16:21:36 CET] <CoreX> relaxed compiled from sandbox never had a problem till now and ffmpeg is 2.7 [16:22:48 CET] <CoreX> i can compile x264.exe fine but when compile of ffmpeg it just doesnt want to get past that [16:24:39 CET] <furq> why are you building ffmpeg 2.7 [16:25:03 CET] <CoreX> everything i have configured for it is fine [16:25:21 CET] <furq> that's more than two years old [16:25:39 CET] <furq> i wouldn't be surprised if newest versions of external libs don't work properly with it [16:26:52 CET] <relaxed> you could checkout x264 from around 2.7's release if you really need that ffmpeg version [16:48:54 CET] <iive> CoreX: to me this error looks like your libx264 is too old [16:50:05 CET] <iive> CoreX: x264_bitdepth is constant defined in the system installed x264.h file. [16:50:29 CET] <iive> CoreX: x264_bit_depth [16:50:56 CET] <CoreX> yeah cleared everything out from lib/local folders where ever i could find x264.* and done it all again [16:51:21 CET] <CoreX> compile is in the t's now past l's [20:29:01 CET] <nick1234> hi, I am trying to convert a webm video to mp4 using -qscale 0 but the filesize reduces to almost 1/3. can anyone help me to convert the video without reducing the quality [20:29:30 CET] <durandal_1707> post full command [20:30:02 CET] <nick1234> ffmpeg -i "1.webm" -qscale 0 "1.mp4" [20:33:04 CET] <nick1234> it also says in output : "Please use -q:a or -q:v, -qscale is ambiguous". does it have anything to do with the issue? [20:37:08 CET] <DHE> if you're just converting formats, use "-c copy" instead of "-qscale 0" [20:37:25 CET] <DHE> though chances are you'll have a codec error somewhere. then you'll need to choose replacement codecs and options for them [20:39:17 CET] <nick1234> DHE, ok, I just wanted to concat my 6 seperate video files, 4 of them mp4 and 2 webm. coulnt do so. so then i tried to convert the webm to mp4 but i get the quality loss. Is there a way to concat all of them ? [20:39:49 CET] <nick1234> i tried -filter complex but it gives error [20:44:28 CET] <nick1234> and btw the -c copy is also giving error: "Could not find tag for codec vp8 in stream #0, codec not currently supported in container" [21:10:04 CET] <DHE> yep, mp4 doesn't support vp8. which also tells me that your existing mp4 files will have mixed up codecs [21:14:21 CET] <ErAzOr> Hi together. I try to add a logo to my transcoded channel (by vaapi) [21:14:32 CET] <ErAzOr> this is the command I'm using: [21:14:44 CET] <ErAzOr> "/usr/bin/ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -i $URL -vf 'format=nv12,hwupload,scale_vaapi=w=1280:h=720 [0:v]; movie=/home/hts/HD.png [1:v]; [0:v][1:v] overlay=0:0 [out]' -c:v h264_vaapi -b:v 4000k -minrate 4000k -maxrate 4000k -bufsize 4000k -preset fast -c:a copy -f mpegts pipe:1" [21:15:08 CET] <ErAzOr> But this is the error I get: Impossible to convert between the formats supported by the filter 'Parsed_scale_vaapi_2' and the filter 'auto-inserted scaler 1' [21:15:34 CET] <jkqxz> The overlay filter doesn't support GPU-side frames. You need to do the overlay before the upload. [21:15:37 CET] <ErAzOr> Can anyone give me a hint on how to fix this? :) [21:20:07 CET] <ErAzOr> hmm sorry I can't follow you. Can you provide me an example? [21:22:42 CET] <jkqxz> The hwupload filter is uploading frames to the GPU, but then they're being given to the overlay filter. It can only work on frames in CPU memory, hence your error. [21:23:23 CET] <jkqxz> If you need the scale before the upload then you probably want to just use the normal scale filter for that, then upload the result for the encoder. [21:23:45 CET] <sfan5> -vf 'movie=/home/hts/HD.png [1:v]; [0:v][1:v] overlay=0:0,format=nv12,hwupload,scale_vaapi=w=1280:h=720 [out]' [21:23:52 CET] <sfan5> should work unless i made a mistake [21:25:55 CET] <ErAzOr> Works! Thank you so much :) [22:28:55 CET] <geri> hi [22:29:33 CET] <geri> i capture an image from my screen with Height=1800 Width=2880, the size of 1 frame is 20736000 [22:29:45 CET] <geri> so i wonder how to compress the data in realtime and write to disk [22:30:25 CET] <Cracki> ^ 30 fps [22:30:58 CET] <Cracki> guessing codec recommendations are in order [22:35:33 CET] <furq> geri: -c:v ffv1 [22:35:39 CET] <furq> if that's too slow, try utvideo or ffvhuff [22:35:55 CET] <JEEB> or lossless x264 in ultrafast or so [22:36:05 CET] <JEEB> depends on which is actually fastest while giving you lossless [22:36:16 CET] <JEEB> (i never recalled ffv1 being too fast) [22:36:39 CET] <JEEB> utvideo recently got some patches on AVX2 SIMD which might have made it somewhat faster, but I haven't checked if they got merged nor benchmarked them yet [22:36:53 CET] <furq> utvideo is still much worse compression though isn't it [22:37:06 CET] <JEEB> yes, I mean the point was to make it simple [22:38:05 CET] <JEEB> it's basically some byteswaps, some sort of prediction function and huffman coding [22:38:16 CET] <Cracki> copying context: geri has an eyetracker and wants to record what the gaze falls on, alongside the gaze information [22:38:54 CET] <Cracki> so I'm guessing lossless (or full res) isn't even needed [22:40:29 CET] <JEEB> how much res you need is a separate thing [22:40:47 CET] <JEEB> but generally if you're under time constraints having one pass of lossless at first makes sense, unless you have size constraints [22:41:12 CET] <JEEB> so that you can always go back to the original if a re-encode is not good enough for any processing you have in mind [22:41:17 CET] <Cracki> ^ [22:56:51 CET] <geri> furq: is that part of opencv? [23:00:08 CET] <Cracki> you're mixing projects [23:00:14 CET] <geri> i refer to X264 [23:00:22 CET] <geri> video codec [23:06:00 CET] <geri> what is lossless x264 in ultrafast? [23:06:15 CET] <geri> i try to do it with c++ [23:06:26 CET] <geri> passing an usigned char* [23:06:43 CET] <geri> and not using command line to call ffmpeg [23:46:57 CET] <ZeroWalker> if i want to livestream for say survailance, what options do i have, is it RTP or? [23:47:34 CET] <Cracki> live viewing, on demand viewing, ...? [23:48:24 CET] <Cracki> what endpoints? [23:49:51 CET] <ZeroWalker> on demand i guess, it would be accessible from 1 device at a time currently [23:50:05 CET] <ZeroWalker> endpoints? [23:50:42 CET] <ZeroWalker> the server would be a orange pi, and the device that will be used to watch is an android mobile (though that Might change, but let's go with that for now) [23:55:00 CET] <furq> rtmp would probably work [23:55:07 CET] <furq> although maybe the latency would be too high [23:55:49 CET] <ZeroWalker> what kind of latency are we talking about? [23:56:01 CET] <ZeroWalker> seconds, minutes? [00:00:00 CET] --- Mon Oct 30 2017

1 0

ffmpeg-devel.log.20171028
by burek 29 Oct '17

29 Oct '17

[00:42:42 CEST] <cone-137> ffmpeg 03James Almer 07master:2d11218877a5: avcodec/audiotoolboxdec: fix ac3_parser header include [00:44:23 CEST] <jamrial> michaelni: could you add the folder fmvc and its samples from libav's fate samples suite to ours? [02:12:35 CEST] <michaelni> jamrial, uploaded [02:12:42 CEST] <jamrial> michaelni: thanks [02:27:46 CEST] <cone-137> ffmpeg 03Paul B Mahol 07master:95a8a03a1912: Add FM Screen Capture Codec decoder [02:27:47 CEST] <cone-137> ffmpeg 03Diego Biurrun 07master:4d4d7cf9d539: fmvc: Add FATE tests [02:27:48 CEST] <cone-137> ffmpeg 03James Almer 07master:b94eda7194c2: Merge commit '95a8a03a191204c3ca5c8cf6b69ab166765d5ff3' [02:27:49 CEST] <cone-137> ffmpeg 03James Almer 07master:3c4c092774e3: Merge commit '4d4d7cf9d539a053f531f662a972b23d335738eb' [03:22:23 CEST] <cone-137> ffmpeg 03Ganesh Ajjanagadde 07master:1fe858136b31: utvideodec: Prevent possible signed overflow [03:22:24 CEST] <cone-137> ffmpeg 03James Almer 07master:7f9de7b416c9: Merge commit '1fe858136b315796dd5349f3b4448a29d1bd6fa1' [05:14:32 CEST] <michaelni> jamrial, e0250cf3651e6417e0117486a7816b45fb2d34cd seems to break tools/probetest 256 4096 (segfault) [05:15:33 CEST] Action: michaelni has to go to bed now, ping me tomorrow if you need more info / gdb whatever [15:12:15 CEST] <cone-514> ffmpeg 03Carl Eugen Hoyos 07master:851829455889: lswr/swresample: Mention the actually supported formats when erroring out. [15:52:39 CEST] <jamrial> michaelni: https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/ac3dec.c;h=8ea7… [15:52:51 CEST] <jamrial> you're increasing the buf2 pointer and not checking it afterwards in a loop where the condition to run is buf2 < end [15:53:34 CEST] <jamrial> the change that started making probetest fail added a call to a function passing the amount of bytes that remain in the buffer using end - buf2 [15:55:26 CEST] <jamrial> i could change that "end - buf2" to a hardcoded 7 or 8, which is the max amount of bytes the function will read and seems to fix probetest [15:55:46 CEST] <jamrial> but the correct thing to do i think is making sure buf2 is still < end after the code in the link above [16:15:31 CEST] <michaelni> jamrial, ill add a check for buf2 [17:16:43 CEST] <cone-514> ffmpeg 03Bjorn Roche 07master:aba926e7d654: lavfi/paletteuse: fix to support transparency [17:16:44 CEST] <cone-514> ffmpeg 03Clément BSsch 07master:5c8e904eb386: lavfi/paletteuse: move "new" option before debugging options [17:42:07 CEST] <cone-514> ffmpeg 03Clément BSsch 07master:33e226f84d59: lavfi/paletteuse: simplify color get function prototypes [17:56:34 CEST] <cone-514> ffmpeg 03Paul B Mahol 07master:3729ae659fb2: avcodec: add MagicYUV encoder [17:58:19 CEST] <atomnuker> nice [18:03:58 CEST] <cone-514> ffmpeg 03Clément BSsch 07master:3d547c19c211: lavfi/paletteuse: fix debug_accuracy after aba926e7d [18:03:59 CEST] <cone-514> ffmpeg 03Clément BSsch 07master:157d08e971f4: lavfi/paletteuse: fix debug_mean_error after aba926e7d [18:16:03 CEST] <cone-514> ffmpeg 03James Almer 07master:26ad6df1ced7: avcodec: bump minor after addition of MagicYUV encoder [18:16:04 CEST] <cone-514> ffmpeg 03James Almer 07master:93a1aac44198: configure: add missing llvidencdsp dependency to MagicYUV encoder [18:28:59 CEST] <durandal_1707> abi is still unstable so bumping things is futile [18:30:04 CEST] <jamrial> perhaps, but it doesn't hurt either way [18:50:01 CEST] <cone-514> ffmpeg 03Clément BSsch 07master:1d348dd03fb4: lavfi/paletteuse: fix debug_kdtree after aba926e7d [19:03:26 CEST] <cone-514> ffmpeg 03Luca Barbato 07master:19c5fa9eea47: golomb: Simplify get_ur_golomb_jpegls [19:03:27 CEST] <cone-514> ffmpeg 03Luca Barbato 07master:9e4a5eb51b9f: avformat: Free the internal codec context at the end [19:03:28 CEST] <cone-514> ffmpeg 03James Almer 07master:f4bda7e30538: Merge commit '19c5fa9eea47d45b5eedce3bff4edeaf83fb3942' [19:03:29 CEST] <cone-514> ffmpeg 03James Almer 07master:1e5669457f60: Merge commit '9e4a5eb51b9f3b2bff0ef08e0074b7fe4893075d' [19:10:03 CEST] <atomnuker> how does video thread encoding work? [19:10:20 CEST] <atomnuker> does each thread get a different priv_context or a different avctx or different both? [19:14:23 CEST] <cone-514> ffmpeg 03Paul B Mahol 07master:c5230955640c: utvideodec: Support UQY2 [19:14:24 CEST] <cone-514> ffmpeg 03Paul B Mahol 07master:030c8be7a2c0: pixfmt: Add gbrap10 pixel format [19:14:25 CEST] <cone-514> ffmpeg 03Paul B Mahol 07master:f6a9c20a52d6: swscale: Add input support for gbrap10 pixel format [19:14:26 CEST] <cone-514> ffmpeg 03Michael Niedermayer 07master:ac29b82ec596: swscale: Add gbrap10 output [19:14:27 CEST] <cone-514> ffmpeg 03Paul B Mahol 07master:a93faf30d688: utvideodec: Support UQRA and UQRG [19:14:28 CEST] <cone-514> ffmpeg 03Paul B Mahol 07master:4f33d9d41a03: utvideodec: Support ULY4 and ULH4 [19:14:29 CEST] <cone-514> ffmpeg 03Paul B Mahol 07master:9227bd8ac2f2: utvideodec: Reuse the huffyuv add_left [19:14:30 CEST] <cone-514> ffmpeg 03Paul B Mahol 07master:378460fef1e5: utvideodec: Support for gradient prediction [19:14:31 CEST] <cone-514> ffmpeg 03James Almer 07master:4205e20c2222: Merge commit '378460fef1e563704bc5a307ba748a2b819cc09d' [19:30:21 CEST] <jamrial> michaelni: do you prefer how f56fa95cd1 (libav) handles left shift of negative value, or how we're currently doing it? [19:30:31 CEST] <jamrial> ours is cleaner looking, IMO [19:30:56 CEST] <ubitux> i agree [19:31:12 CEST] <ubitux> if we didn't forget any, i think this commit is better noop'ed [19:31:57 CEST] <jamrial> ubitux: we even have a bunch of other cases this commit doesn't handle that i'd have to manually change, so yeah, i'm leaning towards nooping it [19:32:58 CEST] <ubitux> SHIFT_LEFT not actually doing generating a shift instruction but a mult instead is absurd :p [19:33:18 CEST] <ubitux> the shift is not even the meaning of what the code wants, it's the optimization [19:33:35 CEST] <ubitux> it's a DO_OPTIMIZATION() ... // i lied [19:34:04 CEST] <michaelni> jamrial, +1, ours as its cleaner [19:34:05 CEST] <ubitux> and given we have these cases all over the codebase, i don't see why it should be local to that file [19:36:12 CEST] <cone-514> ffmpeg 03dxfhgwet 07master:b43d13144bdb: avfilter/zscale: fix segfault on library error [19:38:56 CEST] <cone-514> ffmpeg 03dxfhgwet 07master:ff763351e745: avfilter/zscale: fix memory leak [19:39:13 CEST] <cone-514> ffmpeg 03Luca Barbato 07master:f56fa95cd13f: swscale: Do not shift negative values directly [19:39:14 CEST] <cone-514> ffmpeg 03James Almer 07master:f361f15f362e: Merge commit 'f56fa95cd13f627891a1bfb66bf61b971b9e0238' [19:39:39 CEST] <jamrial> yikes, push race [19:40:09 CEST] <jamrial> cone says it's pushed but it was not [19:40:16 CEST] <ubitux> :D [19:40:53 CEST] <jamrial> oh, they are in the tree, just not as part of master, haha [19:41:04 CEST] <jamrial> nothing references them, so a git gc is in order [19:41:27 CEST] <jamrial> see https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=f361f15f362e [19:41:47 CEST] <nevcairiel> it happens, it should clean itself eventually [19:43:48 CEST] <cone-514> ffmpeg 03Luca Barbato 07master:f56fa95cd13f: swscale: Do not shift negative values directly [19:43:49 CEST] <cone-514> ffmpeg 03James Almer 07master:27050d4836b1: Merge commit 'f56fa95cd13f627891a1bfb66bf61b971b9e0238' [19:52:50 CEST] <jamrial> michaelni, ubitux: 37f573543c yay or nay? we don't have the warnings mentioned there because we cast the argument [19:54:09 CEST] <ubitux> i don't really see the improvement, no opinion [19:58:17 CEST] <atomnuker> JEEB: are you going to push the EOF patch? [20:00:08 CEST] <jamrial> atomnuker: he said he'd be mostly afk until tomorrow [20:04:14 CEST] <michaelni> jamrial, functions are better/cleaner than macros [20:04:20 CEST] <michaelni> IMHO that is [20:07:34 CEST] <cone-514> ffmpeg 03Luca Barbato 07master:37f573543c4f: swscale: Convert the check check_image_pointers helper to a macro [20:07:35 CEST] <cone-514> ffmpeg 03Luca Barbato 07master:5352802da81f: dca: Account for lfe when checking for the channel count [20:07:36 CEST] <cone-514> ffmpeg 03James Almer 07master:dea0f2b36b98: Merge commit '37f573543c4fd7f44339e04d8d15b95118493ddd' [20:07:37 CEST] <cone-514> ffmpeg 03James Almer 07master:7d829da3f919: Merge commit '5352802da81f2083e65d466612e639a4e6e5530e' [20:09:11 CEST] <cone-514> ffmpeg 03Luca Barbato 07master:4809781586d1: travis: Exclude gcc for the macOS target [20:09:12 CEST] <cone-514> ffmpeg 03James Almer 07master:16a17fb6b259: Merge commit '4809781586d1c956005f72946a2aab5915eab350' [20:28:32 CEST] <cone-514> ffmpeg 03Peter Große 07master:3606c114172e: dashenc: use av_dict_set_int instead of static function [20:28:33 CEST] <cone-514> ffmpeg 03Peter Große 07master:8edb9d457251: dashenc: move UTCTiming element to the end of the manifest [20:28:34 CEST] <cone-514> ffmpeg 03Sasi Inguva 07master:801375311395: lavf/mov.c: Fix parsing of edit list atoms with invalid elst entry count. [20:28:35 CEST] <cone-514> ffmpeg 03Michael Niedermayer 07master:eb54efc1e1aa: avformat/ac3dec: Check buf2 before adding 16 in ac3_eac3_probe() [20:30:09 CEST] <cone-514> ffmpeg 03Luca Barbato 07master:279e3aaa14da: flv: Validate the packet size [20:30:10 CEST] <cone-514> ffmpeg 03James Almer 07master:220603d0c83e: Merge commit '279e3aaa14daba6b7a37d75f3fb6e29c732d123f' [20:56:27 CEST] <jamrial> michaelni: can't reproduce the failure f2c469b73f is trying to "fix" [20:56:30 CEST] <jamrial> do we support what that commit claims is unsupported? [20:57:35 CEST] <jamrial> for that matter, avi error messages are funny [20:57:38 CEST] <jamrial> [avi @ 0000000002f27100] crazy start time, iam scared, giving up [20:58:59 CEST] <Compn> lol [21:56:54 CEST] <michaelni> jamrial, yes, we support lossless rgba [22:01:36 CEST] <cone-514> ffmpeg 03Marton Balint 07master:859144fb1fff: fate: change fate-ffmpeg-attached_pics to encode to pcm_s16le [23:10:08 CEST] <cone-514> ffmpeg 03Luca Barbato 07master:f2c469b73f8a: mjpeg: Report non-3 component rgb lossless as not supported [23:10:09 CEST] <cone-514> ffmpeg 03James Almer 07master:1232b349175c: Merge commit 'f2c469b73f8ac3dd6a98d38281f61b68ea6dd336' [23:18:09 CEST] <cone-514> ffmpeg 03Luca Barbato 07master:1731c3530bff: mm: Skip unexpected audio packets [23:18:10 CEST] <cone-514> ffmpeg 03James Almer 07master:495d3b2cc3fa: Merge commit '1731c3530bffb876deb9e00dfffdf9841a8412cd' [23:25:21 CEST] <cone-514> ffmpeg 03Martin Storsjö 07master:e00db9f78bb4: checkasm: hevc: Add a hevc_ prefix to the add_residual functions [23:25:22 CEST] <cone-514> ffmpeg 03James Almer 07master:f568d9d0baff: Merge commit 'e00db9f78bb475ed5103364f61892f4e75ef89ba' [23:32:24 CEST] <cone-514> ffmpeg 03Aaron Levinson 07master:b22094d74901: qsvenc: Use MFXVideoENCODE_Query() to update the parameters [23:32:25 CEST] <cone-514> ffmpeg 03Aaron Levinson 07master:8fd8f91e47f3: qsvenc: Make sure the interlaced encoding works [23:32:26 CEST] <cone-514> ffmpeg 03James Almer 07master:49fe0ecd405d: Merge commit '8fd8f91e47f33cd82371a97ac81afc476144964f' [00:00:00 CEST] --- Sun Oct 29 2017

1 0

ffmpeg.log.20171028
by burek 29 Oct '17

29 Oct '17

[01:46:01 CEST] <romano2k> hello! is there a recommended command line generator for ffmpeg? [01:46:31 CEST] <romano2k> or even a web ui? [02:06:04 CEST] <Johnjay> furq: so you have ff and ff dev also? my dev is 57 but my regular is still 56 [02:10:49 CEST] <furq> no i just have ff beta [02:20:27 CEST] <Johnjay> i did as you suggested and installed tampermonkey on my dev version [02:20:34 CEST] <Johnjay> now to figure out how to write scripts for it. [02:20:58 CEST] <Johnjay> my ultimate goal is rather modest. i just want certain image and pastebin sites to auto load images in this irc webchat window on mouse hover [02:41:01 CEST] <furq> http://www.blurayreviews.ch/reviews/screenshots/predator-ultimate-hunter-ed… [02:41:04 CEST] <furq> who here likes denoising [02:41:34 CEST] <DHE> rose, how could you not realize mickey was replaced by a plastic monster? [02:43:00 CEST] <furq> that's before and after he got hit by ivan drago [03:20:54 CEST] <iive> furq: the left side looks like it is from PAL capture [03:21:07 CEST] <furq> the original bluray is an m2v bd25 [03:21:10 CEST] <furq> so yeah, that's no good either [03:21:38 CEST] <furq> so you get to choose between macroblocking and madame tussauds [03:23:10 CEST] <iive> i definitely like the right part more, it doesn't look that much like a wax figure ;) [03:26:36 CEST] <iive> on the right image, the eyebrow looks like it is painted. [04:10:41 CEST] <AndrewMock> I need to do precise MXF work. Is ffmbc my best bet? [04:12:19 CEST] <AndrewMock> also, any buzz on implementing the CineForm SDK? [09:21:02 CEST] <Ahti333> in libavformat, is there a way to set output-format specific flags via the C api? in particular, i want to set FF_MOV_FLAG_FASTSTART on the mov output format [09:28:23 CEST] <Ahti333> nvm, just found the avoptions stuff [11:44:56 CEST] <danieel> relaxed: i could not manage with rawvideo, it only supports uncompressed formats [11:46:08 CEST] <danieel> relaxed: i did use MP4Box and the NHML format (xml description of what the frames sizes are) - created by hand / simple php based parser, to actually wrap the prores bitstream to mov [11:46:18 CEST] <danieel> then mov to png with ffmpeg of course [13:55:33 CEST] <aphirst> Hi guys! I'm trying to build ffmpeg-headless in the arch user repository, and have a question about the build error, the answer to which I'd like to be able to forward to the package 'maintainer' [13:55:51 CEST] <aphirst> for context, it's ffmpeg but with X (and maybe other?) dependencies removed [13:56:46 CEST] <aphirst> https://aur.archlinux.org/packages/ffmpeg-headless/#news My comment just now shows a build failure, and it seems related to openjpeg. My gut feeling is that maybe ffmpeg has now moved onto openjpeg instead of openjpeg2, but that this isn't incorporated into the PKGBUILD (build/package script) by the maintainer here on the AUR [14:02:42 CEST] <aphirst> oh I see, openjpeg is actually 1.5, openjpeg2 is 2.x [14:02:47 CEST] <aphirst> in my distro at least [14:03:03 CEST] <aphirst> in any case, the issue seems to be somehow to do with the build system and openjpeg [15:47:22 CEST] <cousin_luigi> Greetings. [15:47:30 CEST] <cousin_luigi> What's the story with ebur and ffmpeg? [15:50:06 CEST] <jeff_> hi [15:50:16 CEST] <jeff_> requesting for a help [15:50:26 CEST] <jeff_> anyone can spare few minute, [15:51:13 CEST] <jeff_> when i try to encode a stream it throw this error: non-existing PPS 0 referenced [15:51:19 CEST] <jeff_> this is because it cant find a valid key frame [15:51:24 CEST] <jeff_> the key frame comes too late [15:51:41 CEST] <jeff_> how to keep ffmpeg alive until it find a valid keyframe [15:54:34 CEST] <jeff_> guys [15:57:29 CEST] <jeff_> hello [15:59:21 CEST] <iive> jeff_: no idea sorry [16:00:11 CEST] <iive> jeff_: keep asking or even fill a bug. It's .ts stream, isn't it? sometime I workaround it by having -ss 1 , aka seek a second, but if you need it automated, that's not really a solution. [16:02:13 CEST] <jeff_> hmm [16:03:05 CEST] <jeff_> u seen this error: No longer receiving playlist 2 [16:03:20 CEST] <jeff_> A TLS packet with unexpected length was received.=2455.5kbits/s [16:03:50 CEST] <jeff_> its an m3u8 so yes inside it contains .ts files i assume [16:10:13 CEST] <iive> no idea. [17:22:18 CEST] <RedFlash> Hello, I can't figure out how to convert a bunch of pngs to a VP9 webm file. The PNGs aren' [17:24:14 CEST] <ChocolateArmpits> RedFlash, are they numerated ? [17:25:26 CEST] <RedFlash> Sorry about that.. They aren't sequenced like 1,2,3 more like 12_20,12_25,12_30 ... The command I'm using at the moment produces a webm file with the terminal literally listing every file specified. [17:26:45 CEST] <RedFlash> The command I'm using is here https://pastebin.com/mYmj53sj [17:28:46 CEST] <ChocolateArmpits> RedFlash, for sequences you should use image2 format https://pastebin.com/mYmj53sj you can specify particulars of the pattern used [17:30:37 CEST] <RedFlash> How does that work exactly? Could you point me to some examples? [17:30:52 CEST] <ChocolateArmpits> Open the link, it has examples and parameters specified [17:31:15 CEST] <RedFlash> ChocolateArmpits, you pasted my link [17:31:29 CEST] <ChocolateArmpits> oh snap sorry [17:31:36 CEST] <ChocolateArmpits> got confused, here it is https://ffmpeg.org/ffmpeg-formats.html#image2-1 [17:35:42 CEST] <RedFlash> ChocolateArmpits: Ahh now it works! Thanks for your help! Got it working with this https://pastebin.com/fmkhbfKY [17:36:06 CEST] <ChocolateArmpits> cool [17:44:20 CEST] <RedFlash> ChocolateArmpits: Got another question if you're up for it. The video works, but the framerate is kind of unstable. Is it possible to lock the framerate or make it more stable somehow? Video is ~300kb, accessible here https://mega.nz/#!GV1CVRDL!7HUf364l4mBUcg2LXLHJDkh_rAtiTuK3K_flOnp-5uw [17:46:51 CEST] <ChocolateArmpits> RedFlash, what do you mean unstable? [17:47:23 CEST] <ChocolateArmpits> You want to interpolate between frames? [17:48:47 CEST] <relaxed> RedFlash: this may help https://trac.ffmpeg.org/wiki/Slideshow [17:51:30 CEST] <RedFlash> Hang on, never mind. I think I got the wrong values. It just seemed a bit jittery on higher framerates [17:59:57 CEST] <RedFlash> Okay, something really weird is happening here. When I create the video from the PNGs as a WEBM with VPX9, it stutters on playback. When I create the video as an MP4 with libx264 with the EXACT same command, it plays smoothly. Commands: https://pastebin.com/ddxpkv1q [18:02:20 CEST] <relaxed> that should be, ffmpeg -framerate 10 ... [18:03:50 CEST] <RedFlash> Fixed it, but still no improvements [18:05:28 CEST] <relaxed> pastebin the command and output from both runs [18:06:43 CEST] <ChocolateArmpits> RedFlash, what are you using for playback [18:07:09 CEST] <RedFlash> VLC on Ubuntu [18:08:20 CEST] <ChocolateArmpits> RedFlash, do you have any other vp9 videos to try out ? [18:08:29 CEST] <ChocolateArmpits> besides the ones that you encoded now [18:08:40 CEST] <relaxed> or maybe test with ffplay or mpv [18:08:44 CEST] <RedFlash> I don't, unfortunately [18:08:46 CEST] <ChocolateArmpits> or those [18:08:50 CEST] <RedFlash> I'll test it with another player [18:10:29 CEST] <RedFlash> WOW. VLC can't play VP9 files very well :( Thanks for your time relaxed & ChocolateArmpits [18:10:56 CEST] <ChocolateArmpits> is it an old version? [18:14:31 CEST] <RedFlash> It's not too far behind. They're on v2.2.6, I'm on v2.2.2. [18:20:22 CEST] <blap> it's nice having a decent computer [20:34:11 CEST] <utack> Hi. I wanted to convert something HEVC HDR to a different resolution HEVC HDR. how does one keep/copy all that metadata required for correct playback? Thanks [20:35:22 CEST] <utack> do i have to use media info and pass that stuff to x265 manually? [21:02:22 CEST] <relaxed> utack: try encoding a small sample and see if it copies the metadata my default [21:04:49 CEST] <utack> relaxed thanks for the hint, unfortunately no. i guess i have manually pass all the options to x265 [21:11:40 CEST] <relaxed> utack: ffmpeg -i input .... -c:v hevc -x265-params "colorprim=bt2020:transfer=smpte2084:colormatrix=bt2020nc" output [21:16:42 CEST] <relaxed> utack: https://pastebin.com/raw/0TMgnuEM [21:17:55 CEST] <sfan5> that's not 1080p by the way [21:18:15 CEST] <relaxed> oh, my scale was backwards :) [21:18:31 CEST] <sfan5> looks correct to me though [21:18:44 CEST] <sfan5> if in doubt open both files in a media player at the same frame and compare [21:34:17 CEST] <utack> relaxed yeah it keeps these settings but not all that extra nonsense like mastering display metadata [21:39:59 CEST] <relaxed> from doom9, not sure if it's correct thought: -x265-params colorprim=bt2020:transfer=smpte2084:colormatrix=bt2020nc:master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)":max-cll="1000,400" [21:41:29 CEST] <utack> thanks for that, i guess i can stuff in the master display parameters mediainfo tells me on the source [21:42:51 CEST] <relaxed> good idea, you could probably script it for future conversions [21:45:12 CEST] <relaxed> utack: http://x265.readthedocs.io/en/default/cli.html [21:45:44 CEST] <utack> yeah i was looking at that, you found the missing piece (how the options are called in ffmpeg) in that doom9 command line [22:10:59 CEST] <utack> thanks relaxed, it works now [00:00:00 CEST] --- Sun Oct 29 2017

1 0

ffmpeg-devel.log.20171027
by burek 28 Oct '17

28 Oct '17

[00:46:29 CEST] <cone-366> ffmpeg 03Marton Balint 07master:cbcb8f5a22e8: fate: add fate test for ticket #6603 [00:46:30 CEST] <cone-366> ffmpeg 03Marton Balint 07master:61e25ab0bf9f: fate: add fate test for ticket #6375 [02:30:33 CEST] <cone-366> ffmpeg 03Steven Liu 07master:171adca696ee: Revert "flvdec: Check the avio_seek return value after reading a metadata packet" [02:30:34 CEST] <cone-366> ffmpeg 03Martin Storsjö 07master:15537c904ec9: flvdec: Check the avio_seek return value after reading a metadata packet [02:50:42 CEST] <cone-366> ffmpeg 03Marton Balint 07master:273f11969d1d: fate: fix ffmpeg-attached_pics test dependencies [05:15:51 CEST] <rcombs> jya: somewhat, what's up? [05:35:45 CEST] <cone-366> ffmpeg 03James Almer 07master:5834cba05efb: MAINTAINERS: add my GPG fingerprint [09:57:54 CEST] <jya> rcombs: remind me which of my questions it was about? One of the parser? [09:58:13 CEST] <rcombs> yeah, AAC parser [09:58:52 CEST] <jya> I got my answer there already :) the parser expects adts and I was feeding it raw aac [11:42:31 CEST] <fx159159> Hey, is there an internal ffmpeg function to convert three separate YUV420 buffers to one YUV420P buffer? [11:43:39 CEST] <BtbN> What do you mean? yuv420p always is 3 seperate planes [11:44:46 CEST] <nevcairiel> he probably wants it in a continous memory buffer for some third party consumption [11:45:15 CEST] <fx159159> I'm developing and indev for the android ndk camera 2 api, currently I'm getting an image from the apis that gives me three separate buffers for Y, U and V, now I want to put these buffers into one AVPacket [11:45:23 CEST] <fx159159> Yeah [11:45:49 CEST] <nevcairiel> you could use wrapped_avframe and just pass them on as-is [11:46:52 CEST] <nevcairiel> otherwise you can allocate a buffer and use av_image_fill_pointers to automatically get the proper pointers, and use av_image_copy afterwards to copy it into that [11:47:14 CEST] <nevcairiel> or av_image_fill_arrays, might be better [11:47:35 CEST] <nevcairiel> or perhaps even av_image_copy_to_buffer, which should do that mostly in one step, you just need to allocate it still [11:48:56 CEST] <fx159159> Ok, av_image_copy_to_buffer looks right [11:49:28 CEST] <fx159159> So I pass the pointers to the three buffers to av_image_copy_to_buffer and the function copies them into one buffer? [11:49:42 CEST] <nevcairiel> pretty much [11:50:10 CEST] <nevcairiel> you can use av_image_get_buffer_size to figure out the size of the buffer you need to allocate as well [11:50:18 CEST] <fx159159> Cool, thanks, will try that [11:50:42 CEST] <fx159159> I already know how big the buffer should be, the android api tells me the size for each buffer [11:52:49 CEST] <fx159159> Would calling av_new_packet with the buffer size and then calling av_image_copy_to_buffer with dst set to pkt->data work? [11:57:47 CEST] <fx159159> nevcairiel: What should align be for av_image_copy_to_buffer? [12:40:20 CEST] <nevcairiel> probably 1 if you're trying to make something compatible with RAWVIDEO [15:11:19 CEST] <fx159159> nevcairiel: Ok got to try it, but that does not seem to work... av_image_copy_to_buffer wants the source pixel format, it is YUV420 unpacked, but ffmpeg does not know unpacked YUV420? [15:12:11 CEST] <nevcairiel> YUV420P should be fine as a pixel format [15:12:39 CEST] <fx159159> Running the app results in greenish video frames [15:13:25 CEST] <fx159159> The camera continously delivers frame, I can see things moving, but the frames are greenish and distorted [15:17:38 CEST] <fx159159> nevcairiel: https://abload.de/img/distorted2ejxb.jpg see here [15:19:35 CEST] <jkqxz> Your pitch is wrong. Possibly by exactly 1/5 the width of the frame. [15:21:37 CEST] <nevcairiel> yeah that looks like wrong pitch/linesize [15:25:03 CEST] <fx159159> Excuse me... but whats is pitch? [15:25:39 CEST] <atomnuker> stride [15:26:14 CEST] <fx159159> Swapping height and width (linesize calculation?) it looks like this https://abload.de/img/distorted2uqjsv.jpg [15:26:42 CEST] <atomnuker> #bytes per line != width*sample_size [15:29:43 CEST] <fx159159> ah wait... android calls it YUV420_888, so 24 bpp? not 12 like YUV420P? [15:31:22 CEST] <JEEB> that's probably the bit depth for each sample, which is 8 in 8bit 4:2:0, the chroma subsampling probably isn't taken into account in that :P [15:33:14 CEST] <fx159159> it is described here: https://developer.android.com/ndk/reference/group___media.html#gga9c3dace30… [15:42:51 CEST] <Mavrik> Hmm, it's not really 24 bits per pixel is it? :) [15:43:05 CEST] <Mavrik> Since it's 4:2:0 subsampled - second two planes will be half of size [15:44:11 CEST] <fx159159> So it could be something like AV_PIX_FMT_YUV420P16LE ? [15:45:40 CEST] <Mavrik> No, it actually sounds very much like AV_PIX_FMT_YUV420P [15:45:55 CEST] <Mavrik> But your artifacts look like you missed stride/height/width [15:50:26 CEST] <fx159159> Android gives me 368512, 122688, 122688 as sizes for the lines? Does that sound correct? I would assume I'd need a buffer of the size 613888 then, but av_image_fill_linesizes suggests 460800? [15:50:28 CEST] <fx159159> Is that bytesß [15:50:30 CEST] <fx159159> ? [15:50:59 CEST] <fx159159> Ah, not av_image_fill_linesizes, I meant av_image_get_buffer_size [15:52:53 CEST] <Mavrik> Is that width or stride? [15:53:30 CEST] <Mavrik> Note that especially in hardware buffers, there might be an important difference between those two :) [15:54:26 CEST] <fx159159> I'm not quite sure, I'm using a function getPlaneData, it's documentation says "dataLength the valid length of data will be filled here if the method call succeeeds" [15:55:15 CEST] <fx159159> getPlanePixelStride / getPlaneRowStride are also available, could they be of any help? [16:04:01 CEST] <iive> linesize is byte offset [16:04:04 CEST] <Mavrik> You should almost certanly use those to fill up AVFrame properly ;) [16:12:19 CEST] <fx159159> So there could be some kind of padding by android? I'm new to these terms... trying to understand it [16:23:23 CEST] <jamrial> can someone help me come up with a idea/solution for 50a1c66cf6? (libav commit) [16:23:30 CEST] <jamrial> we're also calling avpriv_ac3_parse_header() in movenc, and looking at a lot more fields than the ac3 demuxer [16:25:30 CEST] <jamrial> making it pretty much impossible to not keep AC3HeaderInfo as part of the abi [16:28:49 CEST] <jamrial> that in itself wouldn't be a problem since it's more or less a fixed struct, but then movenc also uses the GetBitContext past the point avpriv_ac3_parse_header() leaves it at, making it also hard to remove its usage... [16:38:48 CEST] <fx159159> Android tells me row strides are 768, 512, 512, that means 512 * 480 should be 245760 but I'm getting only the half 122880? For 768 * 640 it's correct? 368512 [16:40:13 CEST] <jkqxz> The chroma planes are subsampled by a factor of two in both directions - they have half as many lines as well. [16:40:56 CEST] <fx159159> 768 * 640 is 368640, android says 368512, that is also off by 128 [16:41:20 CEST] <Mavrik> fx159159: the reason why you need to pass stride into APIs [16:41:37 CEST] <Mavrik> is because what you're seeing right now - lines may have padding between them [16:41:45 CEST] <Mavrik> this is why you're seeing difference between width and stride [16:42:15 CEST] <Mavrik> that's especially common in hardware decoders which tend need lines to be aligned to some certain size [16:42:17 CEST] <fx159159> then the chroma plane sizes are off by 192 [16:42:50 CEST] <fx159159> Yeah I understood that, a 640 pixel wide line gets rounded up to 768 [16:42:56 CEST] <Mavrik> This is why you need BOTH width and stride - width for actual size of picture data and stride for width + whatever buffer padding there is [16:43:49 CEST] <fx159159> So... how do I tell av_image_copy_to_buffer to respect the strides? [16:44:36 CEST] <fx159159> Is it linesizes ... ? [16:45:28 CEST] <JEEB> point in buffer + stride should always get you to the same point on the next line [16:45:40 CEST] <nevcairiel> linesizes is the stride, yes [16:47:15 CEST] <fx159159> awesome [16:48:20 CEST] <fx159159> https://abload.de/img/stridesntjqs.jpg [16:48:23 CEST] <fx159159> :))) [16:49:09 CEST] <fx159159> thank you [18:27:38 CEST] <durandal_1707> michaelni: congratulations for new fork, excelent work, keep going [18:29:34 CEST] <jamrial> durandal_1707: sounds more like the EOF thing in avio is the reason [18:29:53 CEST] <jamrial> nicolas' patch should be pushed already [18:30:13 CEST] <jamrial> it is an api break and has been in the tree for a few weeks now [18:30:56 CEST] <JEEB> it was a mix of things according to the discussions I've seen [18:31:02 CEST] <JEEB> since the same push contained the hwaccel thing [18:31:03 CEST] <jamrial> i don't get how it hasn't yet been pushed, or at least the change reverted until it was fixed [18:31:18 CEST] <jamrial> no, the hwaccel is unrelated to the avio EOF thing [18:31:23 CEST] <JEEB> yea it is [18:31:49 CEST] <JEEB> just that it was the thing that was unconditionally added to the code base IIRC when the switch was done to a custom repo [18:31:50 CEST] <jamrial> it is something wm4 and thilo need commited, but michaelni is blocking [18:32:06 CEST] <jamrial> a vote should be called or more devs should chime in already and tip the scales [18:32:22 CEST] <jamrial> it's stupid how long something like this can last without a solution [18:32:51 CEST] <JEEB> meh, sfan5 didn't test nicholas's patches [18:33:06 CEST] <JEEB> I will have to re-poke him I guess [18:33:46 CEST] <jamrial> nobody else here uses mpv to test it? [18:34:38 CEST] <JEEB> I'll while try to understand the change [18:34:46 CEST] <jamrial> maybe wm4, but i guess he's in a "fuck ffmpeg" mood atm [18:35:50 CEST] <JEEB> I can re-test it as well but I'll try to check the code first [18:36:39 CEST] <JEEB> huh [18:36:51 CEST] <JEEB> I think I don't understand what is meant with "stream protocols" [18:37:07 CEST] <JEEB> is giving your own AVIO a "stream protocol"? [18:38:29 CEST] <JEEB> trying to think what !s->max_packet_size has to do with it all [18:39:13 CEST] <JEEB> https://patchwork.ffmpeg.org/patch/5686/ [18:39:22 CEST] <JEEB> maybe I'm just stupid [18:41:04 CEST] <jamrial> just test it and reply yo the thread if it works [18:41:12 CEST] <jamrial> this crap should have been fixed or reverted long ago [18:58:37 CEST] <michaelni> jamrial, about hwaccel, i agree more people should chime in and especially people wth calm mood. There are 2 obvious options, using the opaque_ref field with wraping (iam against this), using a new field marton called it priv_ref (wm4 is against this) [18:58:52 CEST] <michaelni> its deadlocked atm [18:59:22 CEST] <JEEB> anyways, builing nicholas's patch on mingw-w64 right now [18:59:27 CEST] <JEEB> and will then test [18:59:46 CEST] <JEEB> although I still don't understand the if (!ret && !s->max_packet_size) => zero is EOF [18:59:49 CEST] <JEEB> part [19:01:47 CEST] <JEEB> lol [19:01:56 CEST] <JEEB> had already forgotten how long configure took on windowse [19:04:18 CEST] <iive> michaelni: i don't see what is the point of the wrapping, after all, what it does is move one variable to another. and then move it back.. [19:08:07 CEST] <JEEB> well you could say the same about side data [19:08:25 CEST] <JEEB> it's IIRC given to you as an opaque buffer stuck to a frame or a packet [19:08:55 CEST] <JEEB> or is it due to possibly the API client doing the sticking and pulling? [19:09:03 CEST] <JEEB> IIRC it was supposed to be lavc-internal? [19:12:08 CEST] <michaelni> side data has a type so any access will get the correct type or nothing. with opaque_ref the existing opaque data is put in a struct in a AVBufferRef and lavc internal data and the whole becomes the new opaque for AVFrame. And this then needs to be unwraped wheever the frame is passed back to the user [19:12:48 CEST] <JEEB> yes, the side data has a type variable next to it so you know how to "unwrap" the voidptr [19:14:37 CEST] <JEEB> aand configure finally finished [19:15:27 CEST] <jamrial> JEEB: what version of windows are you using? also, msys2 or something else? [19:15:51 CEST] <JEEB> msys2 with nev's known-to-work mingw-w64 toolchain [19:15:53 CEST] <JEEB> win10 [19:15:58 CEST] <jamrial> i noticed msys2's sh became much slower since i upgraded to the fall's creator win10 build [19:16:11 CEST] <JEEB> right, that's what I am on [19:16:19 CEST] <jamrial> figures [19:16:41 CEST] <JEEB> still thought this would be simpler to play video on than the development Fedora VM I have on this thing :) [19:17:18 CEST] <jamrial> you could try the ubuntu-in-windows thing win10 features since the creator's build [19:17:38 CEST] <jamrial> Gramner tried it, i think. i should give it a try as well [19:18:24 CEST] <JEEB> yea I know the windows subsystem for linux :) [19:18:56 CEST] <JEEB> but that IIRC isn't better than running a VM, since the only problem with the VM I have is the video playback part - which might even work nicely. I just haven't tested :) [19:19:04 CEST] <JEEB> just do development/android builds there [19:19:10 CEST] <Gramner> WSL is good enough for compiling stuff [19:19:13 CEST] <JEEB> yea [19:19:26 CEST] <Gramner> can even use msvc through it since some time ago [19:19:43 CEST] <JEEB> yea you can access windows files [19:20:08 CEST] <Gramner> need some configure/makefile modifications though since it requires you to use .exe suffixes when calling native windows binaries [19:20:15 CEST] <Gramner> e.g. cl.exe instead of cl [19:20:18 CEST] <JEEB> yup [19:20:58 CEST] <iive> JEEB: side data has been used to send things that are not accessible otherwise. for example, demuxer would send rgb palette as side data. If the aplications wants to use that data, it doesn't have other options. [19:21:15 CEST] <JEEB> yes [19:22:03 CEST] <iive> JEEB: there was also a hack, that wrapped sidedata into packets, in order to allow transparent passing from libavformat to libavcodec, for applications that doesn't handle side data [19:23:02 CEST] <iive> JEEB: and that was removed [19:23:26 CEST] <JEEB> yes, I recollect some things alright even if my brains aren't functioning properly :) [19:24:03 CEST] <jamrial> michaelni: does the updated patchset wm4 sent (the one i replied to just now) also have the issues with opaque_ref you dislike? [19:24:22 CEST] <BtbN> Gramner, any idea how I can load the msvc env in WSL? The bat script for it clearly doesn't work. [19:24:41 CEST] <JEEB> I think it was about adding the toolchain into PATH [19:24:50 CEST] <BtbN> It does more magic than that [19:24:58 CEST] <BtbN> A lot, its like a 1000+ line bat script [19:25:09 CEST] <Gramner> you need to uncomment some line in the msys2_shell.cmd batch script [19:25:19 CEST] <Gramner> it's documented near the top of the file [19:25:26 CEST] <Gramner> to make it keep PATH [19:25:26 CEST] <BtbN> Where is that file? [19:25:32 CEST] <Gramner> msys2 root dir [19:25:38 CEST] <BtbN> I don't have msys anywhere [19:25:39 CEST] <Gramner> oh wait, sorry [19:25:42 CEST] <Gramner> i misread [19:26:21 CEST] <BtbN> I have some magic for it in cygwin, but that method won't work for wsl [19:27:11 CEST] <Gramner> just run the msvc command prompt and launch bash.exe from there [19:27:25 CEST] <Gramner> should maintain PATH [19:35:04 CEST] <michaelni> jamrial, the one from 2017-10-13 looks like it contains the same opaque_ref wraping code [19:35:26 CEST] <jamrial> ok [19:37:42 CEST] <BtbN> Oh hey, AMD realized that we don't want an entire copy if ffmpeg in compat/ [19:37:53 CEST] <BtbN> This patch actually looks decent on a very first quick scroll-through [19:40:30 CEST] <durandal_1707> with 1k of compat nonsense? [19:42:26 CEST] <BtbN> we have 5k lines of nvidia stuff there [19:42:49 CEST] <durandal_1707> what? [19:43:00 CEST] <durandal_1707> who commited that? [19:43:18 CEST] <BtbN> granted, it's not only an encoder, so it makes sense it's more [19:44:13 CEST] <durandal_1707> rush, remove 5k of corporate code [19:44:35 CEST] <BtbN> Because everything coming from a company is bad, right [19:44:48 CEST] <durandal_1707> look at it [19:47:40 CEST] <BtbN> I did, it really does not look that bad. [19:50:19 CEST] <sfan5> ./libavutil/internal.h:122:5: warning: "HAVE_LOCAL_ALIGNED" is not defined, evaluates to 0 [-Wundef] [19:50:27 CEST] <nevcairiel> re-run configure [19:50:28 CEST] <sfan5> hmm this warning is new (maybe someone cares enough to fix it) [19:50:29 CEST] <sfan5> oh [19:52:26 CEST] <sfan5> works, thanks [19:53:09 CEST] <michaelni> BBB, can i push "avcodec/version: Postpone FF_API_DEBUG_MV" or do you want me to wait? you seemed to have objections to it [19:53:34 CEST] <BBB> Id prefer if you dealt with the objection first, yes [19:53:51 CEST] <BBB> IMO the objection is reasonable and is easily addressed [19:54:01 CEST] <BBB> what Im asking for is a plan and a commitment by someone to abide by that plan [19:54:23 CEST] <BBB> no plan? then it wont be fixed anyway, ffserver all over, so just get rid of it now, lets not be silly about this [19:54:44 CEST] <BBB> plan? make the plan, set a date; if the plan holds up, great, if not, well then ffserver all over anywya and we remove it, but at least we tried? [19:54:50 CEST] <jamrial> BtbN: it's a reduced version of the sdk headers, so what nevcairiel mentioned is probably still relevant: is this reduced header actually available and supported somewhere, or just made for this patch? [19:55:21 CEST] <BBB> the plan is based on a similar idea from jamrial [19:55:32 CEST] <BBB> the firs tpart is mine, the second part is his [19:55:37 CEST] <jamrial> what did i do now D: [19:55:40 CEST] <BBB> nothing [19:55:44 CEST] <BBB> you made a suggestion [19:55:53 CEST] <BBB> Im not blaming, just attributing [19:56:00 CEST] <jamrial> i know, just joking :p [19:56:05 CEST] <michaelni> BBB, then lets remove the code that i use for maintaining mpegvideo [19:56:12 CEST] <michaelni> if thats what you want [19:56:15 CEST] <BBB> ok [19:58:40 CEST] <nevcairiel> why is being deprecated such an absolute thing? we have plenty things that someone thought was a good idea to deprecate on a whim without having any plans for a replacement. Instead of blindly following some decision from 2 years ago, which we don't know the real thought-process of anymore (and perhaps wasnt even done in this project), maybe we should just judge it as it is today? [19:59:06 CEST] <sfan5> jamrial: patches 5685-5687 do fix the seeking issue mpv experiences; "[ffmpeg] av_log callback called with bad parameters (NULL AVClass)." appears though, that should be fixed [19:59:39 CEST] <michaelni> BBB, if you really want a plan, my plan would be to keep the code until someone moves it to a filter [19:59:41 CEST] <JEEB> yea, I noted that on the ML if it's an API client's issue or in that patch [19:59:51 CEST] <JEEB> sfan5: thanks for testing, so we now have two results which match :) [19:59:53 CEST] <nevcairiel> and as the thigns are today, I haven't heard a single person actually mention a real technical reason to remove it, the code seems relatively innocent enough [20:00:16 CEST] <nevcairiel> and since its actually in use.. [20:00:29 CEST] <jamrial> michaelni: the problem is that "until someone" tends to mean "never" [20:01:31 CEST] <BBB> so& [20:01:33 CEST] <BBB> attribute_deprecated uint32_t * mb_type [20:01:45 CEST] <BBB> thats not a big deal? [20:02:03 CEST] <BBB> I mean, I look at AVFrame and Im just dumbfounded [20:02:12 CEST] <BBB> Im sure every little hack in there has a particular reason why it exists [20:02:21 CEST] <BBB> but seriously, thats our expected quality? [20:02:29 CEST] <nevcairiel> you work in multimedia, if such things dumbfoundle you, maybe you should switch =p [20:02:51 CEST] <BBB> now now now thats not nice [20:03:21 CEST] <michaelni> BBB, i want quality but this isnt exactly a quality issue. decoder vissualization code fits very well into the decoder [20:03:39 CEST] <nevcairiel> in any case, removing code without replacement thats actually in use by our own developers is not something that should ever happen without good technical reasons beyond getting rid of one field in some struct [20:04:04 CEST] <BBB> and I guess thats where I disagree :-/ [20:04:19 CEST] <nevcairiel> you know how to get rid of it, though [20:04:28 CEST] <BBB> yeah, do nothing, bump major [20:04:28 CEST] <nevcairiel> codecview is waiting for a patch! [20:04:29 CEST] <nevcairiel> :D [20:04:30 CEST] <BBB> and its gone [20:04:35 CEST] <BBB> \o/ [20:05:01 CEST] <jamrial> well, technically that already happened, lol [20:05:27 CEST] <nevcairiel> thats not really how it works anyway, half of the deprecation macros are assigned random numbers and on a bump they all need to be re-evaluated [20:06:05 CEST] <BBB> ok, so lets not go crazy [20:06:08 CEST] <BBB> where do we go from here [20:06:15 CEST] <BBB> you know my pov, I know yours [20:06:17 CEST] <jamrial> yes, the number is meaningless. what matters is how long have things been deprecated [20:06:18 CEST] <BBB> whats next [20:07:04 CEST] <BBB> from what youre saying, I can basically extrapolate that youd prefer to just get rid of the deprecation of that feature and its related symbols altogether [20:07:05 CEST] <BBB> right? [20:07:21 CEST] <BBB> I mean, you say bump but theres no condition attached to it, so we can (and will) do it again next time [20:07:23 CEST] <BtbN> Deprecating something that's in active use, doesn't seem to have any serious issues and isn't in the way of anything seems a bit weird [20:07:28 CEST] <BBB> so effectively thats an undeprecation [20:07:32 CEST] <BBB> so you want to undeprecate? [20:07:41 CEST] <BBB> BtbN: the active us is an overstatement [20:07:45 CEST] <BtbN> I guess the deprecation was just merged from libav? [20:07:50 CEST] <jamrial> maybe durandal_1707 can write the filter to replace this feature [20:08:18 CEST] <BBB> BtbN: michaelni says he uses it once every blue moon to debug issues in mpegvideo; how often does that happen? can he do that in a release branch? or a personal branch? does it need to be upstream? etc [20:08:28 CEST] <BBB> nobody else seems to use it [20:08:39 CEST] <BBB> I understand and appreciate that linux is linus personal computer backup [20:08:46 CEST] <BBB> is ffmpeg michaels personal computer backup? [20:09:28 CEST] <BBB> thats not meant to be offensive, its just a question. what are the rules for undeprecating stuff? and deprecating stuff? if nobody uses a feature, can it go? what if only one person uses it but refuses to maintain it? what does maintain mean? etc. [20:09:37 CEST] <BBB> if he submitted the code as-is now, would we permit it to go in? [20:09:39 CEST] <BBB> etc. [20:09:46 CEST] <jamrial> i agree with BBB that if it's rarely used and it's so cleanly separate from the main codebase (as the preprocessor wrappers show), it can be applied as needed in a local branch for debugging purposes [20:12:51 CEST] <michaelni> The code is usefull to anyone debuging / analyzing mpegvideo videos, its really not my personal backup that is silly [20:13:34 CEST] <michaelni> but ultimatly sure you can remove everything i use or wrote, not sure this will help the project [20:13:57 CEST] <BBB> dont be dramatic [20:14:14 CEST] <michaelni> it was not intended to be [20:14:16 CEST] <BBB> ok [20:14:24 CEST] <BBB> so do you want to undeprecate it? [20:14:30 CEST] <BBB> that is a serious question [20:14:39 CEST] <michaelni> yes id like to keep it [20:15:04 CEST] <ubitux> i think it's better to have it in a filter though [20:15:35 CEST] <ubitux> in codecview filter to be more specific [20:15:49 CEST] <michaelni> ubitux, i am happy if its moved to a filter, i would even do the work but i have kind of too much to do atm [20:16:49 CEST] <ubitux> delaying the deprecation and setting up a reasonable removal deadline sounds sane to me [20:16:49 CEST] <jamrial> can the public symbols be removed at least? keep the debug code in mpegvideo.c but removing all the defines from avcodec.h and options_table.h? [20:17:27 CEST] <jamrial> maybe adding a private option to mpegvideo for this, until the filter is written [20:18:57 CEST] <ubitux> makes sense to me [20:19:26 CEST] <durandal_1707> wouldnt filter work demand new side data introduction? [20:19:33 CEST] <ubitux> yes [20:21:33 CEST] <atomnuker> for the daala decoder I used the text inserting function from that IBM PC codec, I wouldn't mind if that was a filter and you could pipe codec side data from decoder/encoders to it [20:21:54 CEST] <atomnuker> but an analyzer is more useful [20:27:24 CEST] <durandal_1707> this is literally 15 min of work [20:29:51 CEST] <atomnuker> for an analyzer? more than that [20:35:38 CEST] <durandal_1707> for vis mb type [20:36:13 CEST] <durandal_1707> and its already removed/disabled [20:36:49 CEST] <nevcairiel> in a perfect world it would be made more flexible then assuming 16x16 mbs, so it can support varying mb sizes for modern codecs, but thats probably outside of the scope for a simple port [20:37:31 CEST] <jamrial> durandal_1707: if you can write the port into a filter then by all means please do it, so the mpegvideo code doesn't need to be re-enabled [20:38:10 CEST] <BBB> my opinion here is that a permanent undeprecation is just not in the best interest of the project; either we get rid of it now, or itll be around forever& thats probably all I should say at this moment, I think weve discussed this ad nauseam and each side knows the others position & [20:39:38 CEST] <jamrial> BBB: yes, nobody is in favor of permanent undeprecation. at most postponing the non public parts (the public bits can remain removed) [20:39:53 CEST] <BBB> michaelni just said hes in favour of permanent undeprecation [20:40:10 CEST] <BBB> <BBB> so do you want to undeprecate it? [20:40:10 CEST] <BBB> <BBB> that is a serious question [20:40:11 CEST] <BBB> <michaelni> yes id like to keep it [20:40:12 CEST] <nevcairiel> he wants to keep the feature [20:40:23 CEST] <nevcairiel> he also said he would be happy with a proper replacement [20:40:28 CEST] <BBB> I didnt ask to keep, I asked to undeprecate; he said "yes" [20:40:46 CEST] <jamrial> and i was essentially talking about others in the discussion. you, me, ubitux, etc [20:40:52 CEST] <nevcairiel> lets not try to split hairs over an imprecise communication medium [20:40:59 CEST] <BBB> right but were now in the ad nauseam position that everyone likes a replacement but nobody wants to write one [20:41:12 CEST] <BBB> well, anyway, you know my position ;) [20:42:46 CEST] <JEEB> jamrial: ok, nicolas explained the things and it all makes sense (in addition to seemingly working \o/) [20:57:49 CEST] <durandal_1707> i will write this, but who will pay me my time? [21:00:31 CEST] <iive> what's the problem with keeping it, as it is? [21:02:22 CEST] <durandal_1707> its easy to say fuck off [21:02:45 CEST] <jamrial> symbols, no reusability, the like [21:02:59 CEST] <jamrial> plus it's a testament of how things are never done if there's no set goal [21:04:00 CEST] <JEEB> jamrial: feel to do the honors to the EOF fixup if it looks good to you, it seems to work according to a sample set of 2 and it seems to kind of follow precedent logic. I will be finally taking some food >_> [21:04:05 CEST] <JEEB> *feel free [21:04:18 CEST] <JEEB> (I LGTM'd the patch set since it WorksForMe) [21:05:06 CEST] <jamrial> JEEB: i can't test it, so if it works and you lgtm'd it then nicolas, you or anyone else can push it [21:05:23 CEST] <JEEB> ok [21:05:36 CEST] <JEEB> anyways, if it isn't pushed after I finish my meal I can do it :) [21:09:14 CEST] <jamrial> thanks [22:30:16 CEST] <BBB> durandal_1707: the mb_type is obviously part of the problem, maybe we can declare that part of the side-data api interface unstable so it can be developed further? [22:30:46 CEST] <BBB> (because as much as you dont export the macros like is8x8 into the header, the meaning becomes an implied part of the abi) [22:31:01 CEST] <BBB> we can also say its codec specific in which case it can be anything [22:32:40 CEST] <durandal_1707> this stuff is for mpeg2video only iirc [22:33:37 CEST] <BBB> how do we signal that the mbtype format in the side-data is mpeg2? [22:33:39 CEST] <BBB> do we want to? [22:33:42 CEST] <BBB> do we allow others? [22:33:46 CEST] <BBB> am I being a prick? [22:35:05 CEST] <durandal_1707> yes, its awfull [22:37:08 CEST] <adityabm77> Hey guys! I'm new here. I would like to contribute to ffmpeg. I'm good at C and C++. How should I start? [22:38:31 CEST] <durandal_1707> adityabm77: start by picking something you know about and work on it, just explore code [22:38:40 CEST] <JEEB> build FFmpeg with the basic configuration, then see some fault of it (lack of feature or a bug) and start hacking on it :) [22:39:18 CEST] <JEEB> maybe see how the API works with some basic app if you are interested in seeing how the external APIs work [22:41:19 CEST] <BBB> durandal_1707: do you agree its probably a good idea to make it explicit in the api of the side-data for block types that the interpretation of block type is codec-agnostic and will change over time? [22:42:52 CEST] <durandal_1707> is it agnostic? [22:44:45 CEST] <durandal_1707> it may be in future, but currently its mpeg2video [23:16:34 CEST] <cone-137> ffmpeg 03Anton Khirnov 07master:50a1c66cf6ab: ac3_parser: add a public function for parsing the data required by the demuxer [23:16:34 CEST] <cone-137> ffmpeg 03James Almer 07master:e0250cf3651e: Merge commit '50a1c66cf6ab7eb683daaa9e2da3869fa3a54609' [23:17:00 CEST] <jamrial> ^an acceptable compromise, i guess [23:17:08 CEST] <jamrial> still open to suggestions about AC3HeaderInfo usage in movenc [23:25:27 CEST] <cone-137> ffmpeg 03Alexandra Hájková 07master:89d9869d2491: hevc: Add NEON 16x16 IDCT [23:25:28 CEST] <cone-137> ffmpeg 03James Almer 07master:9840ca70e75d: Merge commit '89d9869d2491d4209d707a8e7f29c58227ae5a4e' [23:27:46 CEST] <JEEB> jamrial: will be pushing the EOF stuff since I see no NACK's for it [23:28:16 CEST] <jamrial> JEEB: maybe give nicolas a bit. it's his patchset after all [23:28:23 CEST] <JEEB> sure [23:29:39 CEST] <JEEB> then I will probably next look at these things towards end of Sunday, have to do a trip to the family in a less networked place tomorrow :) [00:00:00 CEST] --- Sat Oct 28 2017

1 0

ffmpeg.log.20171027
by burek 28 Oct '17

28 Oct '17

[00:01:04 CEST] <__jack__> mpv is simply better than mplayer, today [00:01:09 CEST] <Polochon_street> hi, is there a way to display a live spectrogram (like in ffplay) of something played in pulse? [00:02:02 CEST] <durandal_1707> no [00:02:44 CEST] <durandal_1707> you mean pulseaudio? [00:02:59 CEST] <Polochon_street> yep, like using the pulse sink and doing a « real-time » spectrogram [00:03:33 CEST] <durandal_1707> write pulse sink [00:03:52 CEST] <durandal_1707> i dunno if one exist already [00:05:27 CEST] <Polochon_street> hm, alright, because the idea was to have like a microphone input that could be handled by ffmpeg and display the real-time spectrogram of it [00:05:36 CEST] <Polochon_street> but I guess I'll have to put my hands in it and it's not trivial to do :D [00:06:00 CEST] <durandal_1707> Polochon_street: ffmpeg have filter already [00:08:56 CEST] <Polochon_street> durandal_1707: you mean to have a spectrogram? Yeah, I was just wondering whether I could do that directly on a « live » stream [00:09:49 CEST] <durandal_1707> there is A->V filter, [00:11:11 CEST] <durandal_1707> showspectrum [00:12:31 CEST] <Polochon_street> okay, I'll investigate there, if it's possible. Just wanted to know that, thanks :) [00:40:39 CEST] <Polochon_street> argh, almost there but 'ffplay -f pulse -i alsa_output.usb-DAC_FOR_USB_FOCAL_XS-00.analog-stereo.monitor -af showspectrum' complains about mismatches between audio/video [00:40:49 CEST] <Polochon_street> I'm missing something somewhere, but can't manage to find it :( [00:45:28 CEST] <Polochon_street> and without the -af showspectrum it shows the spectrum, weird [18:04:37 CEST] <danieel> how can i specify ffmpeg input for a uncontained compressed bitstream? (i have some prores raw data which i want to either embed to mp4 or decode do stills) [18:41:58 CEST] <relaxed> danieel: try the rawvideo demuxer, "ffmpeg -h demuxer=rawvideo", along with -vcodec prores [19:05:05 CEST] <kepstin> rawvideo is intended for uncompressed frames, I don't think that'll work. First just check with "ffmpeg -i filename" to see if it can probe the bitstream automatically, if it can, you're good [19:07:38 CEST] <kepstin> i didn't even know there was a raw prores bitstream format [19:07:49 CEST] <kepstin> i guess there is. [19:20:32 CEST] <kepstin> if the prores decoder can handle unparsed data, you could try with "-f data -c:v prores" and hope for the best [19:21:02 CEST] <JEEB> I've only seen prores in MOV to be honest, but since it's an intra only format... [20:18:41 CEST] <fauxton> Hello guys, I'm trying to transcode an audio file into a .qcp is there any easy way to do this? I have the source in wav and mp3 [20:19:56 CEST] <durandal_1707> no [20:20:10 CEST] <furq> fauxton: there's no encoder for any of the codecs it supports [20:20:32 CEST] <sfan5> ffmpeg does not seem to have a muxer for it either [20:22:22 CEST] <fauxton> hmm. I see a few sketchy standalone programs online but I don't trust them to be clean and honest [20:22:56 CEST] <JEEB> huh https://wiki.multimedia.cx/index.php?title=QCP [20:23:05 CEST] <JEEB> why requiring such a specific format? [20:23:08 CEST] <Johnjay> What's QCP? could an encoder be written for it? [20:23:09 CEST] <fauxton> I didn't see any plugins for audition either [20:23:30 CEST] <fauxton> its for an old cell phone, that's the only thing it will use [20:23:34 CEST] <JEEB> rip [20:23:44 CEST] <JEEB> and AMR in 3gp file doesn't work+ [20:23:45 CEST] <JEEB> ? [20:24:35 CEST] <fauxton> Haven't tried that [20:24:57 CEST] <JEEB> that's what my old old phone that supported any sort of non-MIDI audio files supported [20:25:14 CEST] <furq> it's some qualcomm format so i'm guessing there's not much if anything other than old phones that can create them [20:25:43 CEST] <JEEB> although to be honest if you renamed an mp4 "m4a" my old old phone would eat that, too [20:25:57 CEST] <furq> yeah it must be super old if it doesn't even take aac-lc in m4a [20:26:04 CEST] <furq> or m4a renamed to 3gp [20:27:10 CEST] <fauxton> true, yeah I used to change from 3gp to m4a back when you could pull youtube videos out of chrome's cache [20:27:15 CEST] <Johnjay> heh, my modern mp3 player I bought last week only takes wma, mp3, or wav. [20:27:22 CEST] <Johnjay> not even a .mp3 remaned as .mp4 [20:27:44 CEST] <fauxton> alright, trying the 3gp [20:28:38 CEST] <JEEB> Johnjay: what we talked about are things generally sharing structure, mp3 and mp4 are completely different structurally [20:28:47 CEST] <JEEB> mp3 is *raw* MPEG-1 Layer 3 audio [20:28:50 CEST] <JEEB> (no container) [20:28:57 CEST] <furq> usually with an id3 tag welded onto the front [20:29:17 CEST] <JEEB> mp4 is usually an ISOBMFF container (colloquially called "mp4") [20:29:26 CEST] <Johnjay> JEEB: oh ok. i was thinking in terms of, try to play anything ignoring the file extension. [20:29:26 CEST] <furq> usually? [20:29:27 CEST] <JEEB> (ISOBMFF = ISO Base Media File Format) [20:29:46 CEST] <JEEB> furq: in theory you could have someone do something stupid :P [20:29:58 CEST] <JEEB> or have a file that is not valid according to latest ISOBMFF spec [20:30:00 CEST] <furq> i guess we are talking about china MP4 players [20:30:02 CEST] <JEEB> but which was valid for mov [20:30:04 CEST] <JEEB> no [20:30:08 CEST] <furq> everything is possible when those guys are in town [20:30:08 CEST] <JEEB> that's a separate headache :D [20:30:19 CEST] <Johnjay> my mp3 player is from china. as is everything else we have in america. [20:30:22 CEST] <furq> including the beloved MP5 [20:30:23 CEST] <JEEB> it was mostly a technicality thing [20:30:34 CEST] <furq> i think i still have an MP5 PLAYER somewhere [20:30:41 CEST] <furq> or i might have given it to my old flatmate when i got a sansa fuze [20:30:56 CEST] <furq> it was actually reasonably competent [20:31:38 CEST] <fauxton> it's weird there are some online converters that will read QCP but only read and not write [20:31:47 CEST] <furq> ffmpeg will apparently read it [20:31:51 CEST] <furq> it at least has decoders for the codecs [20:31:52 CEST] <fauxton> the 3gp didn't work, at least the way I did it [20:31:59 CEST] <furq> so i'm guessing those guys are just using ffmpeg [20:32:05 CEST] <fauxton> haha [20:32:16 CEST] <furq> everyone else is anyway [20:32:24 CEST] <fauxton> might as well [20:33:39 CEST] <furq> if it's good enough for youtube, it's good enough for DANNYSOFT.RU MAGIC ONLINE MEDIA ", [20:34:55 CEST] <Johnjay> lol.. [20:35:49 CEST] <Johnjay> furq: that really underlies the significance of power struggles like the libav thing [20:36:04 CEST] <Johnjay> so many people use a thing like ffmpeg, even if it's free, that if it gets co-opted or taken over [20:36:16 CEST] <Johnjay> that could have bad effects over a lot of sites [20:36:33 CEST] <Johnjay> although you can always fork a GPL project i suppose [20:38:18 CEST] Action: Johnjay ponders firefox webextension and version 57 which will break tons of add-ons... [20:39:30 CEST] <furq> i'm already using 57 and it's fine [20:42:22 CEST] <thegrif> ffmpeg is kicking my ass...i have a big mp4 (140mb)...want to spit out a small mp4, ogv, and webm for use as a background video on a website...trying to get the individual files under 1mb...if anyone is around I'd gladly buy you a pizza :) [20:43:00 CEST] <sfan5> use 2pass encoding [20:43:09 CEST] <sfan5> and don't bother with ogv, webm+mp4 covers 99% of browsers [20:43:12 CEST] <furq> i don't think you need ogv any more [20:43:12 CEST] <furq> yeah [20:43:51 CEST] <furq> webm+mp4 covers all browsers released in the last several years [20:44:01 CEST] <furq> i think ogv was only ever needed for like two versions of firefox [20:45:04 CEST] <thegrif> i'm doing a two pass on the webm [20:45:27 CEST] <furq> there's not really much you can do to get the mp4 smaller other than preset and crf [20:45:38 CEST] <thegrif> I took the original mp4 and then dumbed that down to a 1.1mb mp4...then I'm generating the webm off of that [20:45:43 CEST] <furq> oh [20:45:44 CEST] <furq> yeah don't do that [20:45:54 CEST] <thegrif> I should generate it off the original? [20:45:56 CEST] <furq> yes [20:46:03 CEST] <furq> otherwise you're encoding compression artifacts [20:46:21 CEST] <furq> which ironically do not compress well [20:46:33 CEST] <thegrif> that makes sense [20:47:09 CEST] <furq> i guess you could also reduce the size and have the player stretch it [20:47:12 CEST] <thegrif> use VP9 for the webm? [20:47:14 CEST] <furq> that usually helps a lot [20:47:15 CEST] <furq> and yeah, vp9 [20:47:22 CEST] <furq> you don't really need webm iirc [20:47:51 CEST] <furq> everything supports mp4 by default but some weird browsers disable h264 decoding for patent reasons [20:48:01 CEST] <furq> vanilla chromium for one [20:48:06 CEST] <thegrif> i got a wordpress theme that is asking for the background video in the three formats [20:48:09 CEST] Action: thegrif shrugs [20:48:12 CEST] <furq> oh [20:48:22 CEST] <furq> well yeah you might as well give it any old ogv because nobody's going to see it [20:48:40 CEST] <furq> the webm should be smaller for the same quality so you might as well use that to save bandwidth [20:53:52 CEST] <fauxton> well guys I found an old qualcomm program for XP that let me convert my file to qcp but it mashes the 2.2 second clip into 4k and it sounds like crap. There's no real quality settings [20:54:32 CEST] <sfan5> unsurpising since qcelp is a codec meant for voice transmission at phone quality levels [20:54:58 CEST] <fauxton> I had some other program for my previous phone that did the conversion without saying anything and put it directly on the phone and that sounded better. Maybe there is some other file the darn thing will accept [20:55:22 CEST] <sfan5> it might accept other codecs that sound better [20:55:33 CEST] <thegrif> ok - so I have a 71s video that I want to get down to 1mb or smaller...so I target a bitrate of 115? does that make sense? [20:55:39 CEST] <thegrif> and then I'll run a two-pass job? [20:55:44 CEST] <fauxton> I wonder how I find out what codecs haha [20:57:12 CEST] <sfan5> thegrif: not sure which dimensions/content your video has but 115 is extremely low of a bitrate for any video [20:57:27 CEST] <sfan5> e.g. the average audio stream has more kbit/s than that [20:57:27 CEST] <thegrif> yeah - thats what I was thinking when I first saw it :-/ [20:58:01 CEST] <sfan5> you might want to target e.g. 10mb instead [20:58:23 CEST] <furq> 4MB is probably fine for a background video of that length [21:20:06 CEST] <DHE> unless you're at something tiny like 240x160 [23:18:38 CEST] <Johnjay> furq: I was thinking of things like greasemonkey and other extensions. Can you install GM? [23:19:16 CEST] <JEEB> https://docs.google.com/spreadsheets/d/1TFcEXMcKrwoIAECIVyBU0GPoSmRqZ7A0VBv… [23:19:20 CEST] <JEEB> this is a very useful document [23:20:00 CEST] <furq> Johnjay: no [23:20:05 CEST] <furq> but you can install tampermonkey [23:20:20 CEST] <furq> which has the same script api [23:21:11 CEST] <Johnjay> JEEB: I note about half of those haven't been fully ported yet [23:22:18 CEST] <furq> one of the reasons to switch was that extensions had pretty much free rein, which is a huge security nightmare [23:22:40 CEST] <furq> so it's no surprise that it won't always be possible to create APIs to make porting possible [23:22:41 CEST] <JEEB> yes, but basically it gives you an idea overall. it's a big change from "we don't have any API, we just let you play with our internals" to "now we define APIs, make experiments for additional capabilities" [23:22:44 CEST] <furq> cf. vimperator [23:22:58 CEST] <furq> there's no chance of that making a comeback [23:23:07 CEST] <JEEB> I thought vimperator generally got through pretty well? except for one bug and not being able to work on internal pages? [23:23:22 CEST] <JEEB> one bug being ack'd by mozilla and getting fixed, too [23:23:33 CEST] <JEEB> see the spreadsheet I linked [23:23:41 CEST] <furq> oh neat [23:23:50 CEST] <furq> i thought vimium was recommended now, which is not the same at all [23:24:33 CEST] <JEEB> it might be a different thing but bugs are actually getting ACK'd and if there are new APIs needed if you make an experiment they can get through rather quickly [23:24:46 CEST] <JEEB> for example the show/hide tab API for tab groups [23:25:09 CEST] <JEEB> that got an experiment and I think they're now working on actually integrating it [23:25:26 CEST] <furq> the main thing is that they ported the dark theme from ff dev before breaking all full thirdparty themes [23:25:39 CEST] <furq> if they'd have had a version with no dark theme i'd be long gone [23:25:58 CEST] <furq> so i can sort of understand why people are getting so pissy about tree style tabs and stuff [00:00:00 CEST] --- Sat Oct 28 2017

1 0

ffmpeg-devel.log.20171026
by burek 27 Oct '17

27 Oct '17

[04:36:04 CEST] <cone-773> ffmpeg 03Zhong Li 07master:984b882b769c: fate: fix mpeg2-ticket6677 faillures on some platforms [05:33:59 CEST] <rcombs> huh, I think https://trac.ffmpeg.org/ticket/6778#comment:1 is the same as an issue I'm investigating where dts/pts only advances by 960 after encoding a 1024-sample packet (with time_base==sample_rate) [05:39:02 CEST] <rcombs> https://gist.github.com/4be2a14b70a2eb4252ac73fa984f7d6d thanks matroska timestamps [05:40:00 CEST] <rcombs> packet durations indicate 480-sample packets; they're actually 512 [05:41:47 CEST] <rcombs> and wow this interleave is bad [05:51:41 CEST] <cone-773> ffmpeg 03James Almer 07master:6bd665b7c579: avcodec/tak: remove GetBitContext usage from avpriv_tak_parse_streaminfo() [05:51:42 CEST] <cone-773> ffmpeg 03James Almer 07master:ae100046ca32: avcodec/exif: remove GetByteContext usage from avpriv_exif_decode_ifd() [08:31:41 CEST] <cone-773> ffmpeg 03Tobias Rapp 07master:a07ac9302335: avformat/wavenc: skip writing incorrect peak-of-peaks position value [11:10:34 CEST] <arpu> [Parsed_amovie_0 @ 0x2044320] EOF timestamp not reliable [11:10:38 CEST] <arpu> what does this means? [11:10:54 CEST] <arpu> streams breaks after this message [11:12:44 CEST] <arpu> ok end of file :> [11:12:59 CEST] <arpu> i use a amovie with loop [11:13:14 CEST] <arpu> looks like the loop is ended ... [13:33:31 CEST] <J_Darnley> Gramner: will you give me permission adapt the AVX-512 cpu detection code from x264 into FFmpeg? Noting the change from GPL to LGPL? [17:08:19 CEST] <atomnuker> J_Darnley: x86inc is released under the ISC license, I don't think there's a need to ask [17:14:21 CEST] <J_Darnley> Not the abstraction layer [17:14:21 CEST] <J_Darnley> cpuid detection [17:23:46 CEST] <Gramner> J_Darnley: yes, I'm ok with LGPL:ing the avx-512 cpu detection code from x264 [17:25:35 CEST] <J_Darnley> Okay, thank you very much [17:25:38 CEST] <thardin> how is animated webp different from webm? [17:25:47 CEST] <thardin> what are even webdevs doing [17:25:57 CEST] <J_Darnley> No audio permitted? [17:26:15 CEST] <J_Darnley> Max of 15fps? [17:26:56 CEST] <jamrial> thardin: same as png vs animated png :p [17:27:52 CEST] <thardin> maybe there's less expectation to retain sync [17:30:11 CEST] <thardin> I can only guess it's OK to pause gifs and such when out of view [17:32:16 CEST] <thardin> webp is 4:2:0 only? yikes [17:33:27 CEST] <jamrial> thardin: webp is vp8, so yeah [17:33:47 CEST] <jamrial> there's also a lossless mode, which is rgb [17:34:13 CEST] <thardin> so jpeg is still better if you have high chroma contrast [17:34:15 CEST] <jamrial> and it can have alpha channel, so also rgba and yuva420 [17:34:20 CEST] <atomnuker> J_Darnley: are you going to write some avx512 asm? [17:34:36 CEST] <thardin> so close but still managing to mess it up [17:35:46 CEST] <jamrial> maybe they will update the spec to use vp9 or av1 eventually [17:36:07 CEST] <J_Darnley> atomnuker: yes [17:36:20 CEST] <thardin> I'm a bit amazed at the flexibility of the jpeg spec. I wonder if any decoder supports all its features [17:36:53 CEST] <J_Darnley> It will probably just be a length extension of existing avx2 first then maybe I will checkout newer instructions. [17:39:16 CEST] <atomnuker> J_Darnley: cool, what for? [17:45:24 CEST] <kierank> atomnuker: v210 and friends of course [17:48:01 CEST] <atomnuker> michaelni: what do *bits, *codes and *symbols mean in init_vlc? [17:48:43 CEST] <BBB> thardin: I believe webp is intra-only, no? [17:48:58 CEST] <BBB> thardin: so animated webp would be intra-coded images, it wouldnt actually have any inter coding [17:49:17 CEST] <michaelni> atomnuker, length of codewords, codeword length and int value associted with each codeword IIRC [17:49:49 CEST] <michaelni> s/codeword length/codeword bits/ [17:50:13 CEST] <thardin> BBB: sounds like that would be worse than gif even [17:50:25 CEST] <thardin> for the kind of graphics gif is intended for [17:50:30 CEST] <BBB> I dont think the goal of animated webp is to compress well [17:50:37 CEST] <BBB> if you wanted compression, youd use webm [17:51:04 CEST] <thardin> I guess [17:54:22 CEST] <thardin> I wonder if any RGBA / YUVA formats use alpha prediction [17:55:10 CEST] <atomnuker> michaelni: what's the difference between nb_bits and bits_size? [17:57:33 CEST] <atomnuker> oh is bits/codes_size the number of bits per each entry of *bits and *codes? [17:58:06 CEST] <atomnuker> (so the stride basically) [18:00:04 CEST] <michaelni> atomnuker, see ff_init_vlc_sparse() in libavcodec/bitstream.c that documents all the parameters [18:28:04 CEST] <atomnuker> btw michaelni, could you upload this file to samples? I'd like to add a fate test for it [18:28:05 CEST] <atomnuker> https://pars.ee/temp/zoneplate_1920x1080_legall_32x8x3_medium_1frames_1thre… [18:28:16 CEST] <atomnuker> (should go in the dirac directory) [18:28:49 CEST] <atomnuker> actually nevermind [18:28:55 CEST] <atomnuker> we already have a test for it [18:29:07 CEST] <atomnuker> (in fact a whole bunch in the vsynth stuff) [18:30:40 CEST] <cone-366> ffmpeg 03Carl Eugen Hoyos 07master:f2c867051c8f: lavc/avcodec: Constify the return value of av_bitstream_filter_next(). [18:33:01 CEST] <cone-366> ffmpeg 03Mateusz 07master:a4743d257425: avformat/yuv4mpeg: add gray9/10/12 support [18:39:37 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.3:bf6cd808bed4: avcodec/pngdec: Clean up on av_frame_ref() failure [18:39:38 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.3:4e341bd90411: avcodec/svq3: Fix overflow in svq3_add_idct_c() [18:39:39 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.3:6d1ebb9def18: avcodec/ffv1dec: Fix integer overflow in read_quant_table() [18:39:40 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.3:940659036f47: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_FIDELITYi*() [18:39:41 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.3:b5b52c0ca726: avcodec/takdec: Fix integer overflows in decode_subframe() [18:39:42 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.3:4bc16930efdb: avcodec/proresdec2: Check bits in DECODE_CODEWORD(), fixes invalid shift [18:39:43 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.3:ab845587d135: avcodec/takdec: Fix integer overflow in decode_lpc() [18:39:44 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.3:c54317a17e57: avcodec/jpeg2000: Check that codsty->log2_prec_widths/heights has been initialized [18:39:45 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.3:520daf8c0ec4: avcodec/hevcdsp_template: Fix undefined shift [18:39:46 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.3:6b9ffcdb2bac: avcodec/proresdec2: SKIP_BITS() does not work with len=32 [18:39:47 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.3:4768b30b5bdf: avcodec/aacdec_template: Clear tns present flag on error [18:39:48 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.3:ab43bc50c017: avcodec/truemotion2: Fix integer overflows in tm2_high_chroma() [18:39:49 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.3:0a231e7dd32b: avcodec/x86/lossless_videoencdsp: Fix handling of small widths [18:39:50 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.3:7cc854ce1531: avcodec/x86/lossless_videoencdsp: Fix warning: signed dword value exceeds bounds [18:39:51 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.3:0009272f943a: avcodec/mpeg4videodec: Use 64 bit intermediates for sprite delta [18:39:52 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.3:aa6c44c33399: avcodec/mpeg_er: Clear mcsel in mpeg_er_decode_mb() [18:39:53 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.3:d13d3feba2d0: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_53iL0() [18:39:54 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.3:48933f28c2a8: avcodec/ffv1dec: Fix out of array read in slice counting [18:39:55 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.3:20fd9217d8ae: avcodec/pafvideo: Check for bitstream end in decode_0() [18:39:56 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.3:e8fd32b69ffd: avcodec/snowdec: Check mv_scale [18:39:57 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.3:0ccb27e09427: ffserver: Fix off by 1 error in path [18:39:58 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.3:b33434ec62a4: tests/ffserver.regression.ref: update checksums to what ffserver currently produces [18:39:59 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.3:60b385a5bf9f: Update for 3.3.5 [18:45:14 CEST] <jamrial> michaelni: the id3v2 patch by Fredrik Hubinette needs to be applied to 3.3 before you tag the point release. i'll push it in a bit [18:45:46 CEST] <michaelni> jamrial, ok [18:49:26 CEST] <Gramner> J_Darnley: be aware that using zmm registers induces significant frequency drops which reduces performance of everything else, so if you want to use 512-bit vectors you better go all in on it to make up for it. you probably want to spend at least 20-30% of overall runtime in avx-512 code [18:50:00 CEST] <Gramner> the alternative is to stay in 256-bit mode and just leverage new instructions and opmasks [18:53:30 CEST] <cone-366> ffmpeg 03Fredrik Hubinette 07release/3.3:670d3189e9ef: avformat/id3v2: fix leak in chapter parsing [19:08:10 CEST] <jya> peloverde: ping [19:09:18 CEST] <cone-366> ffmpeg 03Martin Storsjö 07master:10f4511f14a4: libavutil: Make LOCAL_ALIGNED(xx be equal to LOCAL_ALIGNED_xx( [19:09:19 CEST] <cone-366> ffmpeg 03James Almer 07master:5de85c102988: Merge commit '10f4511f14a4e830c0ed471df4cd1cc2a18a481a' [19:13:15 CEST] <cone-366> ffmpeg 03Mark Thompson 07master:c2bebfc80128: pthread_frame: Propagate sw_pix_fmt across threads [19:13:16 CEST] <cone-366> ffmpeg 03Mark Thompson 07master:9aa251c98ce6: vf_deinterlace_vaapi: Add support for field rate output [19:13:17 CEST] <cone-366> ffmpeg 03Mark Thompson 07master:f64d1100a54d: avconv: Flush output BSFs when encode reaches EOF [19:13:18 CEST] <cone-366> ffmpeg 03James Almer 07master:b848eb834791: Merge commit 'f64d1100a54d12c78ce436181bb64229c56da6b3' [19:14:13 CEST] <jya> anyone familiar with the aac parser/decoder ? [19:14:28 CEST] <kierank> atomnuker probably [19:15:48 CEST] <atomnuker> I'm the worst possible person to ask, I know nothing about aac and aac dts packets [19:15:51 CEST] <cone-366> ffmpeg 03Vodyannikov Aleksandr 07release/3.0:8642322b9f23: avcodec/cfhd: Fix decoding regression due to height check [19:15:52 CEST] <cone-366> ffmpeg 03Brice Waegeneire 07release/3.0:d57345e8d076: doc/filters: typo in frei0r [19:15:53 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:d4bc7fc412ba: avcodec/aacdec_fixed: fix: left shift of negative value -1 [19:15:54 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:3fd54e444022: avcodec/aacps: Fix multiple integer overflow in map_val_34_to_20() [19:15:55 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:8c05ac89d353: avformat/oggparsecelt: Do not re-allocate os->private [19:15:56 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:665311ab1f96: avcodec/hevc_ps: fix integer overflow in log2_parallel_merge_level_minus2 [19:15:57 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:f31fc4755f69: avcodec/dnxhddec: Move mb height check out of non hr branch [19:15:57 CEST] <atomnuker> jya: but I think rcombs might know [19:15:58 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:654e157d2161: avcodec/diracdec: Fix integer overflow in signed multiplication in UNPACK_ARITH() [19:15:59 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:2954ce9dea00: avformat/rtmppkt: Convert ff_amf_tag_size() to bytestream2 [19:16:00 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:81c940b15101: avformat/rtmppkt: Convert ff_amf_get_field_value() to bytestream2 [19:16:01 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:43d7b1e42fd7: avcodec/takdec: Fix integer overflow in decode_subframe() [19:16:02 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:ac0fbaf8acd8: avcodec/diracdec: Fix integer overflow in divide3() [19:16:03 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:693db350dd0b: avcodec/dirac_dwt: Fix multiple integer overflows in COMPOSE_DD97iH0() [19:16:04 CEST] <cone-366> ffmpeg 03Steven Siloti 07release/3.0:a371850d58e0: avformat/utils: fix memory leak in avformat_free_context [19:16:05 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:b59d6183c4ff: avcodec/h264_slice: Fix overflow in slice offset [19:16:06 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:410f709bec2b: avcodec/aacdec_fixed: fix invalid shift in predict() [19:16:07 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:f91733e1415b: avcodec/dirac_dwt: Fixes integer overflows in COMPOSE_DAUB97* [19:16:08 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:e154826a2f02: avcodec/mpeg4videodec: Clear mcsel before decoding an image [19:16:09 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:9bfa8b692ebd: avcodec/diracdec: Check perspective_exp and zrs_exp. [19:16:10 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:f7509e9fce7a: avcodec/snowdec: Fix off by 1 error [19:16:11 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:689e97fcada5: avcodec/fic: Fixes signed integer overflow [19:16:12 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:2f49580e0329: avcodec/dirac_dwt_template: Fix integer overflow in vertical_compose53iL0() [19:16:13 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:c543ff526bba: avcodec/me_cmp: Fix crashes on ARM due to misalignment [19:16:14 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:2820ffe39236: avcodec/aacdec_template: Fix running cleanup in decode_ics_info() [19:16:15 CEST] <cone-366> ffmpeg 03Vitaly Buka 07release/3.0:616154a6a535: avcodec/utils: Fix signed integer overflow in rc_initial_buffer_occupancy initialization [19:16:16 CEST] <cone-366> ffmpeg 03Vitaly Buka 07release/3.0:64af458bb862: avformat/mov: Fix signed integer overflows with total_size [19:16:17 CEST] <cone-366> ffmpeg 03Vitaly Buka 07release/3.0:aadd7fbc14a3: avformat/aviobuf: Fix signed integer overflow in avio_seek() [19:16:18 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:9e98eee39dd3: avcodec/hevc_ps: Check delta_pocs in ff_hevc_decode_short_term_rps() [19:16:19 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:cf838b8fd263: ffprobe: Fix null pointer dereference with color primaries [19:16:20 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:ffdc430c4aeb: ffprobe: Fix NULL pointer handling in color parameter printing [19:16:21 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:b9fa2a86e6dd: avformat/hls: Fix DoS due to infinite loop [19:16:22 CEST] <cone-366> ffmpeg 03Yi and *®() 07release/3.0:39ddbd204aad: avformat/asfdec: Fix DoS due to lack of eof check [19:16:23 CEST] <cone-366> ffmpeg 03Yi and *®() 07release/3.0:adca94d65e5c: avformat/cinedec: Fix DoS due to lack of eof check [19:16:24 CEST] <cone-366> ffmpeg 03Yi and *®() 07release/3.0:81e6a95e54ff: avformat/rmdec: Fix DoS due to lack of eof check [19:16:25 CEST] <cone-366> ffmpeg 03Yi and *®() 07release/3.0:4c6bed6e3be1: avformat/rl2: Fix DoS due to lack of eof check [19:16:26 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:9a73a776816b: avformat/mvdec: Fix DoS due to lack of eof check [19:16:27 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:a5018026af1d: avcodec/sbrdsp_fixed: Fix undefined overflows in autocorrelate() [19:16:28 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:51ee15df5813: avcodec/hevc_ps: Fix undefined shift in pcm code [19:16:29 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:e89125faba1a: avcodec/snowdec: Fix integer overflow in decode_subband_slice_buffered() [19:16:30 CEST] <cone-366> ffmpeg 03Yi(SÑ) 07release/3.0:c6d3640cf71c: avformat/nsvdec: Fix DoS due to lack of eof check in nsvs_file_offset loop. [19:16:31 CEST] <cone-366> ffmpeg 03Yi(SÑ) 07release/3.0:74c067e95572: avformat/mxfdec: Fix DoS issues in mxf_read_index_entry_array() [19:16:32 CEST] <cone-366> ffmpeg 03Yi(SÑ) 07release/3.0:b2aa633d663d: avformat/mxfdec: Fix Sign error in mxf_read_primer_pack() [19:16:33 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:92f4341ed113: avcodec/diracdec: Fix integer overflow in INTRA_DC_PRED() [19:16:34 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:fd4500df5c87: avcodec/dirac_dwt: Fix multiple overflows in 9/7 lifting [19:16:35 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:d08abbd0bd16: avformat/mov: Fix DoS in read_tfra() [19:16:36 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:e4a9790bac92: avformat/asfdec: Fix DoS in asf_build_simple_index() [19:16:37 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:bed626f845cd: avcodec/diracdec: Fix overflow in DC computation [19:16:38 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:03d8e9fec5c1: avcodec/hevcdsp_template: Fix undefined shift in put_hevc_pel_bi_w_pixels [19:16:39 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:9bc5df5ec8b7: avcodec/jpeg2000dsp: Fix multiple integer overflows in ict_int() [19:16:40 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:791d06da1a00: avcodec/hevc_ps: Fix c?_qp_offset_list size [19:16:41 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:d54cc921a4b2: avcodec/pngdec: Clean up on av_frame_ref() failure [19:16:42 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:145fce8c4b2d: avcodec/svq3: Fix overflow in svq3_add_idct_c() [19:16:43 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:3386a57b086f: avcodec/ffv1dec: Fix integer overflow in read_quant_table() [19:16:44 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:977d6d8bffe3: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_FIDELITYi*() [19:16:45 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:a89a340e4f1b: avcodec/takdec: Fix integer overflows in decode_subframe() [19:16:46 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:09913c5ec4cc: avcodec/proresdec2: Check bits in DECODE_CODEWORD(), fixes invalid shift [19:16:47 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:2c84969cb4ae: avcodec/takdec: Fix integer overflow in decode_lpc() [19:16:48 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:d164c49af76b: avcodec/jpeg2000: Check that codsty->log2_prec_widths/heights has been initialized [19:16:49 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:9f2beced0a52: avcodec/hevcdsp_template: Fix undefined shift [19:16:50 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:fc1acb103dde: avcodec/proresdec2: SKIP_BITS() does not work with len=32 [19:16:51 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:d0e4c3410c90: avcodec/aacdec_template: Clear tns present flag on error [19:16:52 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:9825fcea99e4: avcodec/truemotion2: Fix integer overflows in tm2_high_chroma() [19:16:53 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:6fa58eabb18c: avcodec/x86/lossless_videoencdsp: Fix handling of small widths [19:16:54 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:789ad4d361e1: avcodec/mpeg4videodec: Use 64 bit intermediates for sprite delta [19:16:55 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:ad3b198f479a: avcodec/mpeg_er: Clear mcsel in mpeg_er_decode_mb() [19:16:56 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:87a8a4a507f0: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_53iL0() [19:16:57 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:df441441c552: avcodec/ffv1dec: Fix out of array read in slice counting [19:16:58 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:5422cdca42e7: avcodec/pafvideo: Check for bitstream end in decode_0() [19:16:59 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:abb3ec84bb7d: avcodec/snowdec: Check mv_scale [19:17:00 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.0:479e65ba47a1: Update for 3.0.10 [19:18:36 CEST] <peloverde> jya: pong [19:19:08 CEST] <jya> peloverde: I have a question about the aac_parser, what type of input is it expecting? raw aac or something encapsulated in adts? [19:19:33 CEST] <peloverde> It's expecting adts [19:19:58 CEST] <jya> ah that explains why it gives me rubbish answer when fed raw aac [19:20:10 CEST] <jya> thank you, that is what I had been expecting [19:21:26 CEST] <jya> peloverde: are you familiar with the flac parser too? [19:21:35 CEST] <peloverde> not at all, sorry [19:22:32 CEST] <jamrial> BBB: ping [19:22:38 CEST] <BBB> y0 [19:23:02 CEST] <jamrial> BBB: https://pastebin.com/NjxYqKxV [19:23:19 CEST] <jamrial> i'm merging the superframe bsf from libav. those are the changes they added on top of it [19:23:51 CEST] <jamrial> the do{} while(0) is good so i'm going to apply it, but i want your opinion on the rest [19:25:23 CEST] <peloverde> As long as we are talking about the superframe filter, is it possible to get it to properly set packet positions for the subframes? [19:25:39 CEST] <BBB> the functional change is wrong [19:25:51 CEST] <BBB> it allows recusrively packing superframes in superframes [19:26:31 CEST] <atomnuker> jamrial: the do { part should be on a new line IMO [19:26:39 CEST] <BBB> so I would ignore the remainder [19:27:10 CEST] <BBB> peloverde: what do you mean about packet positions of subframes? [19:27:20 CEST] <BBB> peloverde: you mean the splitter? or the merger? superframe=merger [19:28:32 CEST] <peloverde> I meant split, my bad [19:28:51 CEST] <BBB> we can probably do that for the splitter yes [19:35:30 CEST] <J_Darnley> :) avutil/tests/cpu now reports avx512 detected [19:38:46 CEST] <jamrial> BBB: ok, will skip the functional change and only apply the do while [19:41:53 CEST] <cone-366> ffmpeg 03Ronald S. Bultje 07master:0cf949a01193: vp9: Add bsf to merge superframes [19:41:54 CEST] <cone-366> ffmpeg 03James Almer 07master:4c0426c478dc: Merge commit '0cf949a01193dcf6f83fd95d46792dd94479b4e4' [19:47:54 CEST] <cone-366> ffmpeg 03Mark Thompson 07master:34e051d16850: vp9: Add bsf to fix reordering in raw streams [19:47:55 CEST] <cone-366> ffmpeg 03Mark Thompson 07master:0fd91e4bfc00: vaapi_encode: Add VP9 support [19:47:56 CEST] <cone-366> ffmpeg 03Mark Thompson 07master:41dda860870f: doc: Add VAAPI encoders [19:47:57 CEST] <cone-366> ffmpeg 03Mark Thompson 07master:4936a48b1e6f: qsv: Add ability to create a session from a device [19:47:58 CEST] <cone-366> ffmpeg 03Mark Thompson 07master:8848ba0bd6b0: qsvdec: Allow use of hw_device_ctx to make the internal session [19:47:59 CEST] <cone-366> ffmpeg 03Mark Thompson 07master:3d197514e613: qsvenc: Allow use of hw_device_ctx to make the internal session [19:48:00 CEST] <cone-366> ffmpeg 03James Almer 07master:4576ee100b9e: Merge commit '3d197514e613ccd9eab43180c0a7c8b09a307606' [19:48:03 CEST] <TD-Linux> thardin, that's why in practice, the spec of jpeg is "what libjpeg v6 implements" [19:51:29 CEST] <kierank> Gramner: hmmm [19:54:28 CEST] <Shiz> TD-Linux: unrelatedly https://twitter.com/enginetankard/status/894115533729087488 <-- very good but I've got two (hopefully-soon-networked) PC98s ;p [19:55:07 CEST] <TD-Linux> Shiz, a pc9821 is on my shopping list but I need a 24khz monitor as well [19:55:57 CEST] <Shiz> theres some specific LCD monitors that can do 24khz [19:56:13 CEST] <Shiz> theres a list of monitors that work with old ataris and the like -- if it goes down to 15khz, it can do 24khz as well [19:56:42 CEST] <Shiz> http://15khz.wikidot.com/ [19:56:44 CEST] <Shiz> here [19:56:52 CEST] <Shiz> i happen to luckily own a benq g2420hd :p [19:57:50 CEST] <iive> is that horizontal frequency? [19:58:23 CEST] <TD-Linux> yeah the monitors attached to the x68000s are of that variety. I also have a nice bvm but it's 15khz only. I wouldn't mind a 24khz crt, either. [19:58:36 CEST] <Shiz> yeah hsync [19:59:25 CEST] <Shiz> if you need pc98 shopping advice hmu anyway, it can be annoying to nail down the model you want which has everything [20:00:59 CEST] <Shiz> https://up.shiz.me/priv/2017-10-17%2021.27.39.mp4 setup [20:02:24 CEST] <Compn> jya : maybe alex converse ? [20:06:23 CEST] <TD-Linux> Shiz, thanks, I'll probably take you up on that offer later and maybe run some yaj links past you. [20:06:34 CEST] <Shiz> #o [20:06:39 CEST] <Shiz> \o * [20:21:41 CEST] <BBB> J_Darnley: nice [20:23:26 CEST] <cone-366> ffmpeg 03Diego Biurrun 07master:604fbb3132e8: mov: Move code shared with CAF to a separate file [20:23:27 CEST] <cone-366> ffmpeg 03James Almer 07master:4bb09bf5a04a: Merge commit '604fbb3132e88727e496c96c92cfe02748c25a1a' [20:34:57 CEST] <cone-366> ffmpeg 03James Almer 07master:c64800e976f9: configure: add optional zlib dependency to avformat [20:56:01 CEST] <atomnuker> michaelni: does the built-in ratecontrol system for snow/mpeg4 take VFR video into account? [20:59:51 CEST] <michaelni> atomnuker, if not then you have to maybe change a few lines of picture_number related code to use pts [21:11:41 CEST] <thardin> TD-Linux: so I've suspected [21:12:10 CEST] <thardin> I'm not even sure I've seen hierarchical jpegs anywhere [21:15:48 CEST] <cone-366> ffmpeg 03Diego Biurrun 07master:b62ed6873821: configure: Better names for functions that sanitize input [21:15:49 CEST] <cone-366> ffmpeg 03James Almer 07master:cdba33c45f79: Merge commit 'b62ed6873821c8fce8f7e2c2927ae54f86afeb22' [21:21:58 CEST] <cone-366> ffmpeg 03Sean McGovern 07master:6ac0e7818399: mpeg4videodec: raise an error if sprite_trajectory.table is NULL [21:21:59 CEST] <cone-366> ffmpeg 03James Almer 07master:af0505ed9515: Merge commit '6ac0e7818399a57e4684202bac79f35b3561ad1e' [21:22:36 CEST] <cone-366> ffmpeg 03James Almer 07n3.3.5:HEAD: Merge commit '6ac0e7818399a57e4684202bac79f35b3561ad1e' [21:35:10 CEST] <cone-366> ffmpeg 03James Almer 07n3.5-dev:HEAD: Merge commit '6ac0e7818399a57e4684202bac79f35b3561ad1e' [21:42:03 CEST] <cone-366> ffmpeg 03Luca Barbato 07master:d32d59bc977b: matroska: Read only the data written in the scratch buffer [21:42:04 CEST] <cone-366> ffmpeg 03James Almer 07master:ce9e07e6b675: Merge commit 'd32d59bc977b43031007bb2ab21e232f96d2ebcb' [21:47:34 CEST] <cone-366> ffmpeg 03Vittorio Giovara 07master:f5950b8fd61e: lavfi: Drop unused and empty header file [21:47:35 CEST] <cone-366> ffmpeg 03James Almer 07master:99ba85a0e24b: Merge commit 'f5950b8fd61ec85e0ad8790bea56b37ceea19436' [21:52:23 CEST] <cone-366> ffmpeg 03Vittorio Giovara 07master:839010aca971: filtfmts-test: Mark filter as const [21:52:24 CEST] <cone-366> ffmpeg 03Vittorio Giovara 07master:efddf2c09aed: decode: Initialize ret before using it [21:52:25 CEST] <cone-366> ffmpeg 03James Almer 07master:7066a92f87a4: Merge commit 'efddf2c09aed7400c73ecf327f86a4d0452b94b5' [22:01:49 CEST] <atomnuker> michaelni: it actually already does that, nice [22:10:55 CEST] <cone-366> ffmpeg 03Andreas Unterweger 07master:b200a2c8da40: examples: Fixed and extended Doxygen documentation [22:10:56 CEST] <cone-366> ffmpeg 03James Almer 07master:8a3d3b624075: Merge commit 'b200a2c8da403b5a5c8b50f8cb4a75fd4f0131b1' [22:14:06 CEST] <cone-366> ffmpeg 03Diego Biurrun 07master:193b09189004: thread: Define ff_mutex_* macros as stub functions when threads are disabled [22:14:07 CEST] <cone-366> ffmpeg 03James Almer 07master:00bfe8509c9b: Merge commit '193b09189004ede4a6998e69192d1a9f63602088' [22:30:14 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.2:ab2d991382c2: avcodec/pngdec: Clean up on av_frame_ref() failure [22:30:15 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.2:6b66cd8c40df: avcodec/svq3: Fix overflow in svq3_add_idct_c() [22:30:16 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.2:5cf5a1034c07: avcodec/ffv1dec: Fix integer overflow in read_quant_table() [22:30:17 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.2:720a44f3a327: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_FIDELITYi*() [22:30:18 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.2:397674a3fb1c: avcodec/takdec: Fix integer overflows in decode_subframe() [22:30:19 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.2:9e8a636551b2: avcodec/proresdec2: Check bits in DECODE_CODEWORD(), fixes invalid shift [22:30:20 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.2:04be199f8ea0: avcodec/takdec: Fix integer overflow in decode_lpc() [22:30:21 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.2:74b28c54d9af: avcodec/jpeg2000: Check that codsty->log2_prec_widths/heights has been initialized [22:30:22 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.2:2293e5a78a6a: avcodec/hevcdsp_template: Fix undefined shift [22:30:23 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.2:79bec49315ba: avcodec/proresdec2: SKIP_BITS() does not work with len=32 [22:30:24 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.2:d9630deca429: avcodec/aacdec_template: Clear tns present flag on error [22:30:25 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.2:2db9b3199641: avcodec/truemotion2: Fix integer overflows in tm2_high_chroma() [22:30:26 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.2:0eb0b21c7f4f: avcodec/x86/lossless_videoencdsp: Fix handling of small widths [22:30:27 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.2:16b07d59de97: avcodec/mpeg4videodec: Use 64 bit intermediates for sprite delta [22:30:28 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.2:b2c9771dd435: avcodec/mpeg_er: Clear mcsel in mpeg_er_decode_mb() [22:30:29 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.2:11f5a1319646: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_53iL0() [22:30:30 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.2:f052d1df3e59: avcodec/ffv1dec: Fix out of array read in slice counting [22:30:31 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.2:1959c0f9f921: avcodec/pafvideo: Check for bitstream end in decode_0() [22:30:32 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.2:70d0cc822161: avcodec/snowdec: Check mv_scale [22:30:33 CEST] <cone-366> ffmpeg 03Fredrik Hubinette 07release/3.2:b76dcd07868e: avformat/id3v2: fix leak in chapter parsing [22:30:34 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07release/3.2:4b1e87dc32b7: Update for 3.2.9 [22:59:03 CEST] <cone-366> ffmpeg 03James Almer 07n3.2.9:HEAD: Merge commit '193b09189004ede4a6998e69192d1a9f63602088' [23:43:50 CEST] <cone-366> ffmpeg 03Carl Eugen Hoyos 07master:693a11b8a269: lavf: Remove AVFMT_RAWPICTURE. [00:00:00 CEST] --- Fri Oct 27 2017

1 0

ffmpeg.log.20171026
by burek 27 Oct '17

27 Oct '17

[00:04:40 CEST] <dreamp> Hi there?! how are you? [00:05:49 CEST] <dreamp> When I run the command `ffprobe -show_streams -i "file.mp4"` it outputs the bitrate info... I'd like to know where the libav gets this information about the bitrate. Supposing it's an h264 coded video in a fmp4 container.. is this information on the container or the codec? or is it calculated? [00:09:57 CEST] <JEEB> it depends. in some cases lavf decides to read it from the container (which can't always be trusted), then in other cases it loads up the amount of data it uses for probing and averages over that, and then you have stuff like calculating the sizes of all samples over the duration of the clip [00:10:18 CEST] <JEEB> and sometimes there's just a single value over the whole file if the duration and file size are available [00:10:27 CEST] <JEEB> I think that might be in -show_format though :P [00:14:55 CEST] <blap> DID YOU JUST ASSUME MY BACTERIAL INFECTION? [00:17:03 CEST] <jarainf> blap, please provide the full output of your command [00:17:14 CEST] <blap> ;) [00:17:54 CEST] <blap> jarainf: join #blap, i'll share some good stuff [00:18:03 CEST] <dreamp> Thanks JEEB I think you just described my situation =/ I'm reading and cating and init.mp4 + segment1.mp4 (from one Delta packager) and when I run ffmpeg and ffprobe and mediainfo they give me different info, mediainfo gets right I guess by looking at the numbers. [00:18:22 CEST] <jarainf> blap, okay, whatever, I'm in. [00:18:51 CEST] <JEEB> dreamp: bit rate is really easy though [00:19:23 CEST] <JEEB> amount of bits / seconds => bits per second, and if you divide that by 1000 it'll be kilobits per second [00:19:50 CEST] <dreamp> JEEB: how can I force my AVFormatContex to give me the right number [00:19:55 CEST] <dreamp> owww you're right :D [00:20:18 CEST] <dreamp> do I have the total amount of bits from AVFormatContext or should I go further into the Stream? [00:21:31 CEST] <JEEB> dunno, it's not a field you can expect to have anyways and well -- stat'ing is easy :P [00:21:41 CEST] <JEEB> ftell I guess? [00:21:49 CEST] <JEEB> not sure what the way of getting a file's size was again :P [00:22:18 CEST] <JEEB> dreamp: another way is to with ffprobe -show_streams -show_packets and then use the packets' sizes and the overall duration [00:22:20 CEST] <dreamp> I was afraid to use the total file size [00:22:34 CEST] <dreamp> because it includes the container + streams [00:22:35 CEST] <JEEB> that way you can get the overall size of the stream in bytes :P [00:22:36 CEST] <dreamp> but in reality [00:22:41 CEST] <dreamp> it is the whole fieeeeD [00:22:46 CEST] <dreamp> *file [00:22:51 CEST] <JEEB> well container overhead is minimal generally [00:23:00 CEST] <dreamp> JEEB: You've opened my opens =D thanks [00:23:02 CEST] <JEEB> except with MPEG-TS I guess, where it can be 15% [00:23:15 CEST] <JEEB> or well, depends on muxer [00:23:35 CEST] <dreamp> anyway the bitrate should account these bits too! [00:24:00 CEST] <JEEB> but yea, -show_packets should get you the packet data [00:24:05 CEST] <JEEB> for each stream [00:24:13 CEST] <JEEB> and to match things you also want -show_streams [00:24:47 CEST] <dreamp> I'm using ffprobe just to know if I'm using the ffmpeg libav correctly! [00:24:51 CEST] <JEEB> ok [00:25:14 CEST] <dreamp> Thanks JEEB I wish every community had someone so helpful as you! :D [00:25:23 CEST] <JEEB> also I wonder if edit lists can fuck you up nicely [00:25:39 CEST] <JEEB> because google implemented them on the demuxer level [00:25:44 CEST] <JEEB> so it might try to feed you previous data again [00:26:57 CEST] <dreamp> I dunno what is "edit lists" [00:27:01 CEST] <JEEB> virtual timelines [00:27:07 CEST] <JEEB> a thing from the MOV roots of MP4 [00:27:08 CEST] <dreamp> PTS [00:27:17 CEST] <dreamp> ? [00:27:27 CEST] <dreamp> ohhh I see timeline [00:27:39 CEST] <JEEB> basically MOV used to be used as a "project file" format as well [00:27:40 CEST] <dreamp> (like the thing we use to know the real time ) [00:27:41 CEST] <JEEB> for editors [00:28:21 CEST] <JEEB> virtual time line like: "play 00:00-00:15" "play 00:30-00:45 at speed 2x" "play 00:15-00:30" [00:28:26 CEST] <JEEB> those are edit lists [00:29:10 CEST] <JEEB> and now you might understand why implementing them on the demuxer level is probably not the best idea (exporting them IMHO is a good idea) [00:29:38 CEST] <dreamp> yep [00:29:55 CEST] <JEEB> of course, you can disable edit list stuff in the demuxer I think [00:30:07 CEST] <JEEB> which should give you the packets A->B [00:30:19 CEST] <dreamp> this part of how audio and video are sync (the PTS and DTS) I'm still learning =/ do you have any material to point me? [00:31:13 CEST] <dreamp> (are sync in a player by using the info from the container + codecs (streams)) [00:31:31 CEST] <JEEB> PTS are just something to synchronize multiple tracks against each other. in MP4 DTS are used as the base, and then you have offsets for each sample to get the PTS for it. [00:31:52 CEST] <JEEB> some containers only contain fields for DTS, others only have PTS [00:32:12 CEST] <JEEB> DTS in some containers is used for broadcast timing [00:32:39 CEST] <JEEB> it's the time when the packet is supposed to hit the "decoder" [00:32:55 CEST] <dreamp> there must be a sync conversion between Frequency (audio) and FPS (video) to make them orderly timmed [00:33:04 CEST] <JEEB> yes, all streams have their own time base [00:33:51 CEST] <JEEB> with audio that tends to be the sample rate, with video it is anything that matches :P [00:34:06 CEST] <dreamp> I really need to use it to learn it =[ like programing it in C using libav [00:35:09 CEST] <dreamp> feel free to drop me any post/thing to read about it :D [00:35:13 CEST] <dreamp> Thanks a lot JEEB [00:35:56 CEST] <JEEB> I really don't think there's much special about it, PTS is what you generally care about in most cases, and you use it to synchronize multiple things together when utilizing whatever you're decoding [00:37:04 CEST] <JEEB> when you demux your AVPackets will have stuff in the container's stream time base, then when you decode the decoder can have its own time base so the AVFrames you get from the decoder are in that, and then if you do filtering that has its own time base as well [00:37:53 CEST] <JEEB> generally when you are doing transcoding you care about passing those numbers through correctly - that should be enough [00:38:29 CEST] <JEEB> *cough* MPEG-TS can GTFO with its random "I'm going to go back in time even if I didn't have an overflow btw!" *cough* [00:38:49 CEST] <JEEB> anyways, sleep for me :P [00:47:11 CEST] <dreamp> thanks JEEB I'll be experiencing it and if I have some doubts I'll be here! I'll sleep too! [00:57:09 CEST] <suNooBku> 420 users online [00:57:11 CEST] <suNooBku> legit [00:57:57 CEST] <suNooBku> guys, after installing last ffmpeg, i have problem with recording desktop via nvidia_hevc [00:58:07 CEST] <suNooBku> using simplescreenrecorder [00:58:28 CEST] <suNooBku> 90% of screen is black, i only see cursor and small blurry area around it [00:59:00 CEST] <suNooBku> using nvidia drivers [01:41:06 CEST] <jiffe> so reading https://medium.com/netflix-techblog/extracting-contextual-information-from-… it sounds like netflix does use some sort of fingerprinting to identify title/credit sequences [01:59:58 CEST] <thebombzen> I'm having trouble encoding two different libopus streams with ffmpeg.c at the same time [02:00:20 CEST] <thebombzen> if I try to do: ffmpeg -i temp.mkv -map 0 -c:a libopus -b:a 128k temp2.mkv, it produces an error [02:00:55 CEST] <thebombzen> https://0x0.st/srhP.log [02:08:09 CEST] <arog> Anyone here familiar with fdk aac [02:08:46 CEST] <arog> We are seeing issues where our data has weird glitches. When we put a sine wave through we see little portions where the amplitude increases then goes back to normal [02:08:59 CEST] <arog> Or the opposite, the amplitude decreases then goes back to normal. [02:09:39 CEST] <arog> Anyone know if this means if our input aac data is missing data and the decoder just guessed or is it another issue [02:13:45 CEST] <redrabbit> thebombzen: your site has an ipv6 adress however it doesnt seem to serve web on the ipv6 [02:14:05 CEST] <thebombzen> my website? [02:14:10 CEST] <thebombzen> 0x0.st is not mine [02:14:16 CEST] <redrabbit> ok ok [02:16:43 CEST] <redrabbit> curl -4 0x0.st > works [02:16:52 CEST] <redrabbit> curl -6 0x0.st > hangs [02:18:07 CEST] <thebombzen> don't bug me about that :P [03:12:28 CEST] <AndrewMock> Does the smptehdbars test filter not generate in 4:4:4? It default to yuv420p. I feel like that is not correct? [03:13:49 CEST] <AndrewMock> Can't seem to force it to 444 [03:14:08 CEST] <AndrewMock> i mean, i can convert after the fact but it is too late [03:22:44 CEST] <AndrewMock> just don't want chroma subsampling distorting my bars [06:05:42 CEST] <Shred00> when i try to map such as: [06:05:42 CEST] <Shred00> $ ffmpeg -y -i INPUT -map 0:0 -map 0:1 -map 0:1 -c:v copy -c:a:0 aac -ac:a:0 2 -af:a:0 "pan=stereo|FL=FC+0.30*FL+0.30*BL|FR=FC+0.30*FR+0.30*BR" -c:a:1 copy OUTPUT [06:05:42 CEST] <Shred00> i get an error: [06:05:42 CEST] <Shred00> Filtergraph 'pan=stereo|FL=FC+0.30*FL+0.30*BL|FR=FC+0.30*FR+0.30*BR' was defined for audio output stream 0:2 but codec copy was selected. [06:05:42 CEST] <Shred00> Filtering and streamcopy cannot be used together. [06:05:42 CEST] <Shred00> but i cannot see how what i am doing is any different than https://trac.ffmpeg.org/wiki/Map Example 1. [06:30:34 CEST] <thebombzen> Shred00: -af is an alias for -filter:a [06:30:42 CEST] <thebombzen> it will apply to all audio streams. you want -filter:a:0 [06:31:16 CEST] <thebombzen> the stream specifier on -af is ignored and it will be treated as -filter:a, even if you have -af:a:0 [06:31:36 CEST] <thebombzen> so it's applying to output a:1, the one you wanted to copy. [06:46:26 CEST] <Shred00> thebombzen: ahhh. thanks for the explanation. [06:52:09 CEST] <thebombzen> you're welcome :) [09:26:28 CEST] <Jutoms> Hi guys, can we use ffmpeg to convert 1 to multiple profiles ? [09:27:43 CEST] <Jutoms> or we have to run X time for X profiles ? [10:02:46 CEST] <inter123> Hello there. I need some help with ffmpeg on my linux vps, is there someone here to help me out? [11:00:00 CEST] <akkad> ok [11:35:59 CEST] <chriss4349347293> Hello all. I'm trying to capture from a pulseaudio device (actually a monitor of my main output) that has 8 channels. the (what I think is, please ask if you need more) important stuff from pactl list: [11:35:59 CEST] <chriss4349347293> Source #0 [11:35:59 CEST] <chriss4349347293> State: IDLE [11:35:59 CEST] <chriss4349347293> Name: alsa_output.pci-0000_00_1b.0.analog-surround-71.monitor [11:35:59 CEST] <chriss4349347293> Description: Monitor of Built-in Audio Analog Surround 7.1 [11:35:59 CEST] <chriss4349347293> Driver: module-alsa-card.c [11:35:59 CEST] <chriss4349347293> Sample Specification: s16le 8ch 44100Hz [11:36:00 CEST] <chriss4349347293> Channel Map: front-left,front-right,rear-left,rear-right,front-center,lfe,side-left,side-right [11:36:00 CEST] <chriss4349347293> Owner Module: 6 [11:36:01 CEST] <chriss4349347293> Mute: no [11:36:01 CEST] <chriss4349347293> when capturing, ffmpeg guesses Stereo layout, which is expected as far as I understood, because it's a raw stream, so I need to specify -ac 8 for ffmpeg [11:36:02 CEST] <chriss4349347293> but this gives error: [11:38:49 CEST] <durandal_1707> use pastebin [12:13:06 CEST] <_julian> do I need any modules except for rtp,mpegts and rtp_mpegts mux and rtp protocol to generate a mpegts in rtp stream for a h264+aac stream? I can't seem to get it working... [12:15:22 CEST] <DHE> trying to build a super-minimal version of ffmpeg? [12:15:28 CEST] <_julian> yes [12:15:42 CEST] <_julian> works fine for mpegts->udp, but can't get rtp_mpegts->rtp to work [12:16:09 CEST] <JEEB> make sure you have it working with normal configuration first [12:16:20 CEST] <JEEB> after verifying that you can start looking into which protocols etc you require [12:20:35 CEST] <_julian> hm, strange, I can get it to work with lavfi/testsrc input, but not with decklink input [12:20:55 CEST] <_julian> with decklink input it seems the pipeline is just stalled, and the decklink input fifo is constantly overflowing [12:28:01 CEST] <memeka> hi; how are decoded frames sent to the video drivers? profiling gstreamer and mpv+ffmpeg, I get very different results: on my arm board with no dmabuf-import gpu support, gstreamer spends most of the time doing memcpy, and less in the gpu driver, but mpv+ffmpeg spends most of its time in the driver: 72% libmali.so cobjp_neon_linear_to_block_8b_8x8, 16% libmali.so cobjp_neon_linear_to_block_16b_8x8, 7% [12:28:01 CEST] <memeka> memcpy [12:28:20 CEST] <memeka> JEEB, durandal_1707 ^^^ any idea? [12:29:23 CEST] <_julian> Any thoughs why decklink input could behave differently compared to lavfi? And why rtp_mpegts makes a difference to mpegts when connected to decklink input? [12:32:43 CEST] <durandal_1707> memeka: what are you actually doing? [12:33:53 CEST] <durandal_1707> comparing gs and mpv have little sense [12:35:18 CEST] <memeka> durandal_1707: decoding on my board is fast (ffmpeg -f null shows 120fps on 1080p video) but display is slow (no dmabuf-import) [12:35:29 CEST] <memeka> i was trying to see how i can speed things up [12:36:40 CEST] <memeka> for example, in gst, memcpy was taking a lot of time => by using the arm-mem library, memcpy is now faster and i can reach 45fps with gst on 1080p video (instead of 20fps) [12:37:19 CEST] <memeka> with ffmpeg, i am still at 20fps, and apparently libmali is taking a lot of time => you're copying buffers in a different way? [12:38:51 CEST] <Mavrik> Usually those devices have a way to bypass copying video surface to the main memory [12:38:57 CEST] <Mavrik> E.g. display it directly [12:38:57 CEST] <durandal_1707> for mpv you need to ask on mpv channel, i dunno about arm support [12:39:21 CEST] <memeka> durandal_1707: so it's not ffmpeg doing the copy? [12:39:25 CEST] <durandal_1707> mpv have dr option for some vo [12:39:40 CEST] <memeka> what's "dr" ? [12:39:59 CEST] <durandal_1707> memeka: ffmpeg is only doing decoding in hw or sw [12:40:11 CEST] <durandal_1707> memeka: direct rendering [12:41:19 CEST] <memeka> durandal_1707: mpv --list-options | grep dr shows no such option [12:42:37 CEST] <durandal_1707> too old version? [12:45:33 CEST] <memeka> durandal_1707: it's 0.26 (i think 0.27 it's the latest) .... [12:54:40 CEST] <chriss4349347293> ok, https://pastebin.com/ZNGy7Uzf [12:54:57 CEST] <chriss4349347293> want to record from pulseaudio device with 8 channels [12:55:08 CEST] <chriss4349347293> specifying -ac 8 gives error [12:55:23 CEST] <chriss4349347293> specifying -ac 6 works [12:55:32 CEST] <chriss4349347293> am I doing something wrong? [12:56:00 CEST] <chriss4349347293> the only change between the two ffmpeg commands is number of channels (see pastebin link) [12:56:44 CEST] <chriss4349347293> ffmpeg is v 3.3.4 [13:10:13 CEST] <ToffeeYogurtPots> Hey, I'm having some trouble with encoding using libvpx (both VP8 and VP9). The output appears noticeably blocky and the only way to eliminate it I've found is to lower the CRF value to the point where the output has a larger file size than the input. I have made a question on video.stackexchange.com ( https://video.stackexchange.com/q/22615 ) but I thought it's probably a good idea to check here too for suggestions. [13:15:40 CEST] <JEEB> ToffeeYogurtPots: you never compare to the input if it's already compressed [13:16:03 CEST] <JEEB> and second of all, there are some parameters in the webm wiki on VP9 encoding in FFmpeg, see that [13:16:09 CEST] <JEEB> for some parameters to tweak [13:16:21 CEST] <JEEB> libvpx has some "speed" parameter that can improve compression [13:16:39 CEST] <JEEB> but generally if you're compressing something already compressed you will end up with a larger file if you're trying to re-compress it [13:16:51 CEST] <JEEB> because you're not only compressing the original input, but also the artifacts etc [13:18:34 CEST] <Mavrik> Even though, usually that's not that noticable [13:19:06 CEST] <JEEB> well if he's got a heavily compressed file and then you re-compress it with random parameters in libvpx then I don't really know what you're expecting [13:19:27 CEST] <JEEB> you just can't expect "I recompress this piece of REDACTED and I will get a smaller file always for the same quality" [13:19:42 CEST] <JEEB> which is why I often do not re-compress old MPEG-1 encodes for which I don't have masters [13:19:53 CEST] <Mavrik> Yeah true [13:20:19 CEST] <Mavrik> But still, recompressing something to about the same filesize in most cases won't introduce noticable artifacts (for a decent SD input) [13:21:05 CEST] <JEEB> I try to drag people away from looking at the source bit rate altogether because it doesn't make any sense [13:21:27 CEST] <JEEB> because some people specifically set the bit rate to the same thing [13:21:31 CEST] <JEEB> it's just *dumb* [13:22:09 CEST] <ToffeeYogurtPots> JEEB: Yeah, I'm not hoping for a perfect output they are DVD's after all. Just wanting to minimise quality loss where possible, if it is possible. Thanks for the suggestions. [13:22:41 CEST] <Mavrik> JEEB: yeah, that's obvious I think :) [16:23:21 CEST] <zerodefect> I'm using an AVFilterGraph and programmatically setting it up using the C-API to insert/output video frames. I'm noticing what I think is the graph buffering a frame internally. I think this should probably be expected when using multithreading, right? [16:23:39 CEST] <zerodefect> I couldn't find too much in the docs about this behaviour [17:07:56 CEST] <Mavrik> zerodefect: yeah, it might buffer a frame. Also depends on filters [17:08:03 CEST] <Mavrik> E.g. I think fps filter does keep one frame around [17:08:12 CEST] <Mavrik> You also might get several or no frames out :) [17:08:33 CEST] <zerodefect> Yeah, using 'Yadif' filter...it probably does some interpolation. [17:08:41 CEST] <JEEB> yes [17:08:45 CEST] <JEEB> it also has required buffering [17:09:32 CEST] <zerodefect> Is there a way to hook into a func callback to receive a notification when a frame is available in the buffersink filter? [17:09:55 CEST] <JEEB> not yet, feel free to propose such [17:10:09 CEST] <JEEB> you basically have one function to push things in, another to try and fetch [17:10:39 CEST] <zerodefect> Yeah, I'm pushing a frame in and then immediately checking if a frame is available :) [17:11:54 CEST] <JEEB> the thing is kind of similar but not exactly compared to the feed/fetch API for decoding and encoding [17:12:00 CEST] <zerodefect> If I received a callback, I could make my code async. [17:12:02 CEST] <zerodefect> Yeah [17:12:53 CEST] <zerodefect> I'm guessing in a hardware de-interlacer, you would have the same sort of buffering too? [17:13:14 CEST] <JEEB> if the filter requires more than one picture of input then yes [17:13:27 CEST] <JEEB> I mean, it depends on what sort of filter you're making and what are the requirements [17:14:44 CEST] <zerodefect> Ok. The buffering is not a problem, so this is more for interest. Do you know if the bwdif and/or w3fdif have the same sort of buffering? [17:15:14 CEST] <Mavrik> Isn't there a PUSH flag that immediately forces processing through the whole chain? [17:16:29 CEST] <zerodefect> AV_BUFFERSRC_FLAG_PUSH, yes. Already set tht [17:16:32 CEST] <zerodefect> *that [17:25:26 CEST] <Johnjay> damn [17:25:43 CEST] <Johnjay> if I do ffmpeg -y -i file.mp3 -af aresample=48000 file.mp3 [17:25:48 CEST] <Johnjay> does that overwrite file.mp3 with 0 bytes? [17:26:10 CEST] <c_14> it will most probably trash your input, yes [17:27:00 CEST] <Johnjay> alright well i will reencode this entire directory then [17:28:18 CEST] <c_14> Maybe I should write something for ffmpeg.c that checks if the input and output files are the same... [17:30:50 CEST] <Johnjay> c_14: I think I had this problem before [17:31:04 CEST] <Johnjay> I downloaded a youtube playlist but the file formats were different. So i batch converted to mp3 with ffmpeg [17:31:15 CEST] <Johnjay> but concat didn't work properly because the samples rates were different [17:31:22 CEST] <Johnjay> so I had to make sure everything was 44.1khz I think [17:31:42 CEST] <Johnjay> I thought I could maybe fix it by transcoding the entire directory with aresample [17:32:24 CEST] <Johnjay> maybe a flag that specifically says you want to copy it in place? -noclobber or something lol [17:33:43 CEST] <c_14> Detecting the problem and aborting would be easier and should probably be enough [17:33:57 CEST] <c_14> Since you can handle the output to temporary file and then rename better in a surrounding shell script [17:34:21 CEST] <Mavrik> Note that you pass -y parameter, where you force the files to be overwritten without question :) [17:34:27 CEST] <Johnjay> it would at least not make all my files 0 bytes. lol [17:34:42 CEST] <Johnjay> i am getting errors when I try to concat the mp3 files together [17:34:44 CEST] <Mavrik> It wouldn't if you wouldn't tell it to with a switch :P [17:34:50 CEST] <Johnjay> i just don't understand what it means [17:35:16 CEST] <Johnjay> Mavrik: That's like saying I signed on the dotted line at the dentists, so i consented to having my teeth ripped out without question. lol [17:36:42 CEST] <Mavrik> Hrmf, not really. [17:36:48 CEST] <Mavrik> You explicitly pass a flag to clobber files :P [17:37:29 CEST] <c_14> Yeah, but most people will assume that it overwrites the file with the output of the encoding, not that it clobbers it's input and then soft-fails [17:37:44 CEST] <Johnjay> idk what it is about mp3 that concatenation fails utterly and produces a corrupt file when sample rates differ [17:38:00 CEST] <c_14> Johnjay: try the concat demuxer? [17:38:10 CEST] <c_14> though [17:38:13 CEST] <Johnjay> c_14: yes [17:38:19 CEST] <c_14> if the samplerate differs that won't help [17:38:40 CEST] <Johnjay> ffmpeg -f concat -i mylist.txt -c copy output.mp3 [17:38:48 CEST] <Johnjay> i think i had to pass -safe 0 too [17:38:59 CEST] <Johnjay> it also failed with -c mp3 [17:39:47 CEST] <Mavrik> c_14: yeah true, ffmpeg should probably fail fast on those "reading file while trying to write to it" condition [17:40:03 CEST] <Johnjay> c_14: you're right i guess, it still fails with error [mp3 @ 00000000004749a0] Application provided invalid, non monotonically increas ing dts to muxer in stream 0: 26337024 >= 12304071 [17:40:47 CEST] <zerodefect> Question about some of the private/internal opts on the encoders. Taking an example with the x264 encoder, does it matter if I set 'tune=zerolatency' before setting the values in the AVCodecContext? Is the order important? [17:40:49 CEST] <Johnjay> dammit, what did I do last time that fixed this [17:41:38 CEST] <zerodefect> My question is related to C-API now cmd line. [17:41:44 CEST] <zerodefect> *not [17:44:21 CEST] <Mavrik> zerodefect: check libx264.c for the order [17:44:39 CEST] <Mavrik> But probably text opts are set after the avcodeccontext params [17:44:45 CEST] <doublya> Is ffmpeg using ncurses or something for CLI output? Is there a switch to turn that off so it just writes new fps= speed= lines? [17:45:20 CEST] <c_14> doublya: try -v quiet -stats [17:45:31 CEST] <c_14> and it's not ncurses [17:45:41 CEST] <zerodefect> Mavrik: Thanks. I'll take a look at x264, but I was wondering if there was a sort of 'best practice'. [17:45:49 CEST] <zerodefect> I'll see what I can find [17:46:12 CEST] <Johnjay> c_14: ok i'm trying ffmpeg -f concat -i mylist.txt -c mp3 output.mp3 this time [17:46:22 CEST] <c_14> doublya: or do you mean the fact that it redraws the line instead of printing new lines? [17:46:57 CEST] <doublya> c_14: thanks. i'll try that. Yes exactly. I'd like to always print a new line instead of redrawing. [17:50:29 CEST] <Johnjay> c_14: ok i give up. i checked output.mp3 and it says it is about an hour long [17:50:37 CEST] <Johnjay> but input files total to about 2 hours of audio. [17:50:45 CEST] <Johnjay> and the output file doesn't sound corrupted, so not sure what's happening [17:52:10 CEST] <c_14> Johnjay: are some of the songs faster than they should be? [17:52:20 CEST] <c_14> Also, is it just the duration that's wrong maybe? [17:53:06 CEST] <Johnjay> c_14: not as far as i can tell. unless windows is lying about this directory of files being total 2 hours long [17:53:15 CEST] <Johnjay> listening to the first 5 minutes so far [17:53:32 CEST] <c_14> fast forward to close to the hour mark and see if it continues [17:53:59 CEST] <doublya> c_14: ffmpeg.c is_last_report ? '\n' : '\r'; [17:55:13 CEST] <Johnjay> c_14: total of directory is about 120MB, but file is only ~50MB [17:55:17 CEST] <Johnjay> so i don't think it's that [17:55:31 CEST] <Johnjay> nope it restarted [17:55:44 CEST] <c_14> doublya: yeah, if you get rid of the terminal and always use \n it'll use new lines [17:56:01 CEST] <c_14> I was trying to see if you could convince a terminal to treat CR as LF so you wouldn't have to recompile [17:56:03 CEST] <Johnjay> c_14: what does the non-monotonically dts to muxer mean in this context? it repeated that error a lot [17:56:30 CEST] <Johnjay> how do i capture the full debug output of ffmpeg, it took up my whole console with the dts-to-muxer messages [17:58:51 CEST] <c_14> I think regular file redirection works on windows, so &> file.txt [17:59:23 CEST] <c_14> at very least 2> should work [17:59:40 CEST] <Johnjay> that seems to be working [17:59:47 CEST] <Johnjay> it's not vomitting into the console now [18:05:38 CEST] <Johnjay> i wish they made these mp3 players as something other than mp3 [18:05:45 CEST] <Johnjay> i.e. ability to play ogg or webm or something [18:05:57 CEST] <Johnjay> i guess those formats are more modern and less prone to weirdness like this [18:09:46 CEST] <Johnjay> hrm [18:09:51 CEST] <Johnjay> it seems like it's working c_14 but very slowly [18:09:57 CEST] <Johnjay> the output file is 11MB after this time [18:14:38 CEST] <c_14> doublya: *ternary [18:19:43 CEST] <Johnjay> c_14: idk ffmpeg appears to be frozen [18:19:55 CEST] <Johnjay> and i can't access file.txt because it's in use by another process [18:20:15 CEST] <Johnjay> CPU activity is zero [18:20:48 CEST] <c_14> kill it with task manager and then check the file? [18:25:45 CEST] <Johnjay> oops I al ready deleted it [18:25:52 CEST] <Johnjay> you know some of these file names have ' in them that I somehow missed [18:25:57 CEST] <Johnjay> that might be the issue [18:30:16 CEST] <Johnjay> reencoding with libmp3lame [18:35:12 CEST] <Johnjay> hmm some of this is opus lol [18:36:59 CEST] <Johnjay> still getting that message [18:37:04 CEST] <Johnjay> idk what i'm doing wrong here [18:37:26 CEST] <Johnjay> output file this time around is 80MB though [18:40:04 CEST] <Johnjay> ok looks good. [18:40:11 CEST] <Johnjay> total input size 80.2 MB, output.mp3 is 80.3 MB [18:43:58 CEST] <Johnjay> oh crap. i might have left half the input files out [18:51:53 CEST] <Johnjay> hmm. ok i guess that whole problem was caused by ' in file names [19:00:18 CEST] <Johnjay> i'm confused now [19:00:37 CEST] <Johnjay> WMP plays the final file back fine, but VLC does not. it seems to chop off the last 10 second of sound [19:00:46 CEST] <Johnjay> and in VLC the playback time flashes up and down. wtf [22:56:27 CEST] <fella> hi there, my mplayer seems to be unable to play https streams, so i do 'mplayer ffmpeg://"STREAM-URL"' - is there a way to put this ffmpeg option to my ~/.mplayer/config ? [22:56:46 CEST] <durandal_1707> no [22:57:17 CEST] <fella> so? any other way to make mplayer play https? [22:57:30 CEST] <BtbN> you could just not use mplayer [22:58:32 CEST] <fella> lol - wrong channel :) [22:58:58 CEST] <fella> BtbN: ok, but ffplay is no alternative, is it? [22:59:08 CEST] <BtbN> but mpv and vlc are. [22:59:15 CEST] <fella> what would you suggest? [22:59:23 CEST] <BtbN> Generally, everything but mplayer. [22:59:30 CEST] <kepstin> if you like mplayer, then mpv is fairly similar. [22:59:36 CEST] <fella> i don't like vlc to much but i'ld have to try mpv [22:59:39 CEST] <durandal_1707> install windows media player [22:59:49 CEST] <fella> with wine? [23:00:18 CEST] <__jack__> mpv is awesome [23:00:32 CEST] <fella> installing it this very moment [23:01:11 CEST] <durandal_1707> fella: no.., in win 2k [23:04:42 CEST] <fella> __jack__: mpv vs mplayer make no difference when it comes to cpu usage, *but* - pulseaudio needs more than twice as much ressources with mpv compared to mplayer!? [23:07:50 CEST] <__jack__> dunno, I flushed pulseaudio away, as it sucks [23:10:54 CEST] <fella> so i've tested mpv, mplayer, vlc and ffplay now and it seems like, mplayer has the smallest footprint [23:11:31 CEST] <durandal_1707> mpv may use cache [23:12:03 CEST] <durandal_1707> so "footprint" is meaningless [23:16:47 CEST] <fella> i didn't mean memory footprint but cpu usage - it seems to be higher with mpv compared to mplayer [23:17:11 CEST] <durandal_1707> fella: how much? [23:18:17 CEST] <fella> about 10%+ with mpv [23:19:27 CEST] <durandal_1707> fella: what vo you use? [23:22:14 CEST] <fella> what do you mean? [23:23:51 CEST] <durandal_1707> fella: video output [23:25:41 CEST] <fella> some internal gpu chip [23:26:17 CEST] <durandal_1707> but vo as used by mpv and mplayer [23:26:47 CEST] <fella> default i guess - haven't changed that in config [23:28:11 CEST] <fella> vdpau is the first listed wiht mplayer -vo help - but i'm not sure if thats the one that gets used? [23:28:13 CEST] <durandal_1707> mae sure you are not comparing apples and oranges [23:28:32 CEST] <fella> so what would you suggest as vo? [23:31:34 CEST] <kepstin> mpv probably defaults to gl, which is recommended for best quality [23:31:43 CEST] <kepstin> mplayer usually uses xv by default on linux [23:32:02 CEST] <kepstin> the gl output has a bit more overhead, yeah [23:32:04 CEST] <durandal_1707> fella: same as mplayer for fair comparison [23:33:30 CEST] <fella> ok, good to know - thx :) [23:54:58 CEST] <Johnjay> isn't mpv just the continuation of mplayer? [23:55:20 CEST] <durandal_1707> its fork [23:57:28 CEST] <Johnjay> is it still considered a fork if the original project just stalls or stops updating? [00:00:00 CEST] --- Fri Oct 27 2017

1 0