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

burek burek021 at gmail.com
Thu Jan 17 03:05:04 EET 2019


[00:09:55 CET] <cone-418> ffmpeg 03Carl Eugen Hoyos 07master:06f65a17a38a: lavf/rtpproto: Use the correct patch when including poll.h
[00:14:29 CET] <cone-418> ffmpeg 03Carl Eugen Hoyos 07master:70c68e654d14: lavd/iec61883: Fix the include path for poll.h.
[00:50:43 CET] <nevcairiel> anyone know what audio files starting with "MEM0" are supposed to be?
[00:55:08 CET] <jamrial> nevcairiel: not really. did you check wiki.multimedia.cx?
[00:55:44 CET] <nevcairiel> I think these files are just random data garbage at this point
[00:56:38 CET] <jamrial> did a user submit one?
[00:57:14 CET] <nevcairiel> yeah all files i got from a user
[00:57:20 CET] <nevcairiel> but my guess is they got corrutped somehow
[01:12:11 CET] <jamrial> JEEB: does https://pastebin.com/3gECMfyV fix it?
[01:25:52 CET] <Compn> nevcairiel : sounds like voice memo , probably from a personal pen recorder or somethin
[01:26:03 CET] <Compn> i dont have any formats, just a guess
[01:26:54 CET] <Compn> some horrible 8kz mono codec no doubt
[01:31:22 CET] <cone-418> ffmpeg 03Michael Niedermayer 07master:19dc5cdaa7c4: avcodec/lzw: Check for end of input
[01:31:23 CET] <cone-418> ffmpeg 03Michael Niedermayer 07master:6dde65d7c0ac: avcodec/ac3dec: Optimize frame start search
[01:31:24 CET] <cone-418> ffmpeg 03Michael Niedermayer 07master:6ed3d0e01c20: avcodec/diracdec: Propagate errors from dirac_get_arith_uint()
[01:31:25 CET] <cone-418> ffmpeg 03Michael Niedermayer 07master:51978aefe807: avcodec/dirac_arith: Treat overread as error
[02:25:38 CET] <Compn> mov wrapped wmv3 reminds me so much of avi wrapped ogm/ogg
[02:25:52 CET] <Compn> e.g. unplayable everyone ignores it
[10:29:36 CET] <cone-033> ffmpeg 03Paul B Mahol 07master:282a4718576d: avformat/hcom: check probe buffer size
[12:47:40 CET] <thardin> hrm, palettegen is behaving wrong
[12:48:27 CET] <durandal_1707> thardin: how so?
[12:48:33 CET] <thardin> the combination of palettegen and paletteuse makes encoding gif use too much pure black
[12:48:39 CET] <thardin> when doing say 64 colors
[12:48:48 CET] <thardin> because palettegen fills the image with black rather than the last color
[12:49:38 CET] <thardin> so I get a whole bunch of black specks that shouldn't be there
[12:50:38 CET] <durandal_1707> full uncut ffmpeg output missing
[12:50:57 CET] <thardin> myeah this isn't that kind of bug :)
[12:51:27 CET] <durandal_1707> can not reproduce, issue closed
[12:51:46 CET] <thardin> I'll see if I can come up with a patch and submit it to the list with an accompanying ticket
[12:54:31 CET] <thardin> hah, one-line change
[12:54:33 CET] <JEEB> :)
[12:54:50 CET] <thardin> -                pal[x] = 0xff000000; // pad with black
[12:54:50 CET] <thardin> +                pal[x] = last_color; // pad with last color
[12:55:03 CET] <JEEB> meanwhile, I have learned how "fun" it is when a library doesn't tell you if it successfully went through the data or if it failed
[12:55:19 CET] <durandal_1707> thardin: can't be
[12:55:25 CET] <JEEB> basically a library has a parse() function, which is void :D
[12:55:59 CET] <JEEB> and then you can receive data from the parser, which can return nullptr - but it also returns nullptr when alles gut :)
[12:56:13 CET] <JEEB> (as in, successfully parsed but nothing came out)
[12:56:22 CET] <JEEB> *nothing to output
[12:57:14 CET] <thardin> woop, it works
[12:58:19 CET] <durandal_1707> how changing unused palette colors fix anything?
[12:58:37 CET] <thardin> because the paletteuse + gif encoder combo doesn't seem to have a concept of number of colors used
[12:58:57 CET] <thardin> to work properly the "I want 64 colors" intent needs to be passed along
[12:59:05 CET] <durandal_1707> yes
[12:59:25 CET] <thardin> the generated palette has 65 unique colors (despite what the stats say)
[12:59:33 CET] <thardin> since it's filled with black
[13:00:10 CET] <thardin> compare http://www.härdin.se/output-64-sierra4.gif  and http://www.härdin.se/output-64-sierra2-patched.gif
[20:59:55 CET] <BBB> let's have a fast_memcpy function also
[21:00:01 CET] <BBB> then rename ourselves to mplayer
[21:00:04 CET] <BBB> and live will be good :)
[21:00:35 CET] <durandal_1707> this is memset_bytes function for shorts
[21:01:03 CET] <durandal_1707> and any serious project have own memcpy under fancy name
[21:01:38 CET] <nevcairiel> the only memcpy you need is for gpu mapped memory
[21:01:41 CET] <nevcairiel> anything else is just silly
[21:01:54 CET] <nevcairiel> (or you need a better libc)
[22:02:51 CET] <atomnuker1> damn, no deal brexit is getting likelier
[22:03:39 CET] <atomnuker1> 2 months to go but thankfully the pound hasn't tanked yet
[00:00:00 CET] --- Thu Jan 17 2019


More information about the Ffmpeg-devel-irc mailing list