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

[burek]

[00:28:19 CET] <JEEB> michaelni: thanks for the review. some of those mistakes were just plain stupid
[00:29:13 CET] <michaelni>  JEEB, np, glad it was useful
[00:30:04 CET] <JEEB> like how on earth did I miss the entry part of the struct (or how did I miss av_bprint_finalize)
[00:30:41 CET] <JEEB> possibly having a narrow vision when looking at specific parts of other subtitle decoders
[00:35:38 CET] <iive> JEEB, this is why we have review, because seeing other people's mistakes is easier than seeing our own. :D
[00:35:48 CET] <JEEB> yes
[00:36:36 CET] <JEEB> I did attempt to call for reviews, but unfortunately at the time I did get I think three (and then I think I did four revisions by myself after noticing some things)
[00:37:00 CET] <JEEB> like noticing that I was applying RGB colors onto BGR ASS
[00:37:13 CET] <JEEB> (although that I was kindly told of by a tester to be honest)
[01:03:00 CET] <cone-201> ffmpeg 03James Almer 07release/4.1:33c800977350: avcodec/cbs_av1: don't call cbs_av1_read_trailing_bits() when no bits remain in the OBU
[02:07:03 CET] <JEEB> there we go
[02:09:33 CET] <JEEB> now, good night. and for the record, I will not be able to push anything during the day so if there's some really clear ones feel free to push them instead.
[05:44:28 CET] <cone-922> ffmpeg 03Reto Kromer 07master:6174686bc346: doc/faq: update macOS and URLs
[12:16:56 CET] <rcombs> jkqxz: dunno if you saw this: https://github.com/intel/libva/pull/266
[13:41:15 CET] <shivamgoyal> I want to contribute to ffmpeg. I know C lang but has a little experience with multimedia. I need some guide about from where to start. 
[13:45:27 CET] <durandal_1707> shivamgoyal: for example, write PSF (Portable Sound Format) playback support 
[15:14:49 CET] <robUx4> is there a place to report security issues ? (ie without it going too public)
[15:15:40 CET] <robUx4> and/or who is maintaining the Matroska demuxer ?
[15:22:58 CET] <iive> robUx4, there used to be a security maillist, that is not public. not sure if it is still relevant.
[15:24:04 CET] <iive> robUx4, https://www.ffmpeg.org/security.html
[15:28:47 CET] <robUx4> ok, thx
[20:12:23 CET] <durandal_1707> what is AC-4 name under ATSC ?
[20:12:45 CET] <JEEB> https://www.atsc.org/atsc-30-standard/a342-part-2-ac-4-system/ ?
[20:14:03 CET] <durandal_1707> ATSC A/342 Part 2 ?
[20:14:20 CET] <JEEB> röbäbly. I didn't look into the PDF
[20:14:32 CET] <JEEB> ah, it's usage
[20:14:48 CET] <JEEB> so it's basically a spec for AC-4 within ATSC
[20:15:21 CET] <JEEB> it does describe the high level bit stream tho
[20:15:27 CET] <JEEB> like the TOC etc
[20:16:06 CET] <JEEB> it then points towards ETSI TS 103 190-1/2
[21:00:01 CET] <cone-474> ffmpeg 03James Almer 07master:00fd38f1846a: avformat/mov: don't rescale mastering display values from the SmDm atom
[22:01:56 CET] <feliwir> Hey, on a scale from 1-10 how hard would it be to write a vp6 encoder?
[22:02:20 CET] <feliwir> We already have the vp6 decoder stuff
[22:02:36 CET] <cone-474> ffmpeg 03Charles Liu 07master:aa25198f1b92: avformat/mov: fix hang while seek on a kind of fragmented mp4
[22:02:37 CET] <cone-474> ffmpeg 03Marton Balint 07master:0c3333faf6b7: configure: warn about disabled explicitly enabled components
[22:06:09 CET] <atomnuker> feliwir: a bad one?
[22:06:59 CET] <atomnuker> a week maybe, if you had inverse transforms (longer if you ripped them out of some binary)
[22:07:59 CET] <atomnuker> afaik the entropy coding system is the same as in vp9 so you could reuse that code (or just do the inverse of decoding, they were simple enough iirc)
[22:10:18 CET] <durandal_1707> ==28102== Conditional jump or move depends on uninitialised value(s)
[22:10:18 CET] <durandal_1707> ==28102==    at 0x5710CC1: append_packet_chunked (utils.c:282)
[22:10:18 CET] <durandal_1707> ==28102==    by 0x5657F35: mov_read_packet (mov.c:7724)
[22:10:18 CET] <durandal_1707> ==28102==    by 0x5711D28: ff_read_packet (utils.c:856)
[22:10:18 CET] <durandal_1707> ==28102==    by 0x57133C1: read_frame_internal (utils.c:1582)
[22:10:21 CET] <durandal_1707> ==28102==    by 0x5717D19: avformat_find_stream_info (utils.c:3772)
[22:10:23 CET] <durandal_1707> ==28102==    by 0x408D35: open_input_file (ffmpeg_opt.c:1126)
[22:10:26 CET] <durandal_1707> ==28102==    by 0x4083A9: open_files (ffmpeg_opt.c:3273)
[22:10:28 CET] <durandal_1707> ==28102==    by 0x4081BB: ffmpeg_parse_options (ffmpeg_opt.c:3313)
[22:10:31 CET] <durandal_1707> ==28102==    by 0x41BAAD: main (ffmpeg.c:4869)
[22:10:36 CET] <durandal_1707> FIX THIS CRAP ASAP!!!
[22:13:16 CET] <JEEB> did the hcom probing thing get fixed btw? I remember posting about valgrind complaining about it at some point
[22:14:50 CET] <durandal_1707> JEEB: yes it have been fixed
[22:14:54 CET] <JEEB> cool
[22:16:47 CET] <cone-474> ffmpeg 03Marton Balint 07release/4.1:110eff79caf4: avformat/async: fix assertion condition when draining buffer
[22:16:48 CET] <cone-474> ffmpeg 03Charles Liu 07release/4.1:53f3f5233f38: avformat/mov: fix hang while seek on a kind of fragmented mp4
[22:19:16 CET] <jamrial> durandal_1707: was that introduced recently?
[22:20:00 CET] <durandal_1707> jamrial: dunno, happens with audio and video files that comes from AC-4 site
[22:23:09 CET] <durandal_1707> jamrial: http://dash.akamaized.net/dash264/TestCasesMCA/dolby/5/1/
[23:02:51 CET] <feliwir> @atomnuker, a bad one would be enough yes :D
[23:02:57 CET] <feliwir> But i doubt that would get accepted
[23:03:32 CET] <feliwir> Is there any reason why noone ever bothered to write an encoder?
[23:07:41 CET] <rcombs> because why would you want to
[23:07:58 CET] <rcombs> I can't think of a practical use-case
[23:11:43 CET] <rcombs> durandal_1707: huh, I don't see any obvious issue there; could you run with --track-origins=yes?
[23:15:28 CET] <durandal_1707> ==10769==  Uninitialised value was created by a heap allocation
[23:15:28 CET] <durandal_1707> ==10769==    at 0x4C2FA3F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
[23:15:31 CET] <durandal_1707> ==10769==    by 0x4C31D84: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
[23:15:34 CET] <durandal_1707> ==10769==    by 0x810E543: av_realloc (mem.c:144)
[23:15:37 CET] <durandal_1707> ==10769==    by 0x810E543: av_fast_realloc (mem.c:488)
[23:15:39 CET] <durandal_1707> ==10769==    by 0x5661DCE: mov_read_trun (mov.c:4784)
[23:15:42 CET] <durandal_1707> ==10769==    by 0x56564E4: mov_read_default (mov.c:6865)
[23:15:49 CET] Last message repeated 2 time(s).
[23:15:49 CET] <durandal_1707> ==10769==    by 0x5656B72: mov_read_header (mov.c:7405)
[23:15:52 CET] <durandal_1707> ==10769==    by 0x57114CB: avformat_open_input (utils.c:631)
[23:15:54 CET] <durandal_1707> ==10769==    by 0x408BB9: open_input_file (ffmpeg_opt.c:1104)
[23:15:57 CET] <durandal_1707> ==10769==    by 0x4083A9: open_files (ffmpeg_opt.c:3273)
[23:15:59 CET] <durandal_1707> ==10769==    by 0x4081BB: ffmpeg_parse_options (ffmpeg_opt.c:3313)
[23:16:26 CET] <durandal_1707> rcombs: just download video files from link above and try to reproduce
[23:33:00 CET] <feliwir> @rcombs we could need it: https://github.com/OpenSAGE/OpenSAGE
[23:33:24 CET] <feliwir> The old EA games used vp6 and there isn't an opensource encoder around (or any good encoder at all)
[23:46:44 CET] <atomnuker> feliwir: we have a bad jpeg2000 encoder, sure it would be merged
[23:48:12 CET] <atomnuker> though can't you implement support for a more modern codec as well? low bitrate vp8 will look just as bad, maybe worse
[00:00:00 CET] --- Tue Feb 12 2019