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

[burek]

[00:04:34 CET] <kierank> can't get it in hex
[00:05:27 CET] <kierank> I can see it in hex editor
[00:05:30 CET] <kierank> but hopper doesn't want to see it
[00:08:11 CET] <kierank> durandal_1707: size is in bytes?
[00:09:08 CET] <durandal_1707> size is in pixels
[00:09:21 CET] <kierank> ah size is 1024*576 / 4
[00:10:56 CET] <durandal_1707> it's usually in bigger bands with chunk of zeroes
[00:11:21 CET] <kierank> yeah, i wonder if there is a state where you just say the rest of the block is zero if it terminates early
[00:11:31 CET] <kierank> durandal_1707: can you send me hexrays dump of function?
[00:12:21 CET] <durandal_1707> tomorrow maybe, now sleeping
[00:12:32 CET] <kierank> note that kostya's code says "show_unary
[00:12:35 CET] <kierank> your code does get_unary
[00:13:33 CET] <durandal_1707> yes, but it consumes those 8 bits
[00:14:34 CET] <durandal_1707> there are integer overflows if one use unsigned
[00:14:56 CET] <kierank> ok
[00:15:02 CET] <kierank> can't see anything then
[00:16:20 CET] <durandal_1707> usually second part of low coeffs are not reached
[00:16:46 CET] <durandal_1707> *low coeffs function
[00:17:02 CET] <durandal_1707> used lcov coverage tool
[01:20:13 CET] <kierank> michaelni: can you explain
[01:20:14 CET] <kierank>     int (*decode_mb)(struct MpegEncContext *s, int16_t block[6][64]); // used by some codecs to avoid a switch()
[01:20:25 CET] <kierank> how does one implement codecs with 4:2:2 and 4:4:4
[01:24:08 CET] <kierank> ret = s->decode_mb(s, s->block);
[01:24:13 CET] <kierank> but then s->block isn't of the right type?
[01:26:46 CET] <michaelni> the type chould be changed if thats the only issue
[01:27:07 CET] <michaelni> mpeg2 support 422 /444 but uses a  diferent codepath so iam not sure that helps
[01:27:24 CET] <kierank> yes, i'm asking how to modify mpeg-4 to support 4:2:2 and 4:4:4
[01:28:06 CET] <kierank> I guess I should submit that patch and get people to fate test it alone
[01:28:11 CET] <kierank> there's tons of code that assumes 4:2:0
[01:29:59 CET] <kierank> weird, nothing complains
[01:30:11 CET] <kierank> I guess it's a valid cast
[02:49:22 CET] <kierank> michaelni: so yeah the mpeg-4 framer is totally broken
[02:49:25 CET] <kierank> parser
[02:49:30 CET] <kierank>             if ((state & 0xFFFFFF00) == 0x100) {
[02:49:32 CET] <kierank> that's a legal startcode
[02:49:35 CET] <kierank> for other stuff
[02:50:51 CET] <kierank> in fact that doesn't work at all
[02:53:02 CET] <kierank> I get one call to ff_mpeg4_decode_picture_header with 1500000 bytes available
[02:53:04 CET] <kierank> from the parser
[02:53:11 CET] <kierank> then I get one from the decoder with 256 bytes! available
[02:53:13 CET] <kierank> and then I overread
[03:15:21 CET] <kierank> hmm seems to be sourced from extradata
[03:15:29 CET] <kierank> but where the hell does it get the extradata from
[03:21:17 CET] <kierank> is there a way to find out where extradata is set?
[03:23:34 CET] <kierank> in the parser it has no extradata
[03:23:38 CET] <kierank> but suddenly in the decoder it does
[03:23:41 CET] <kierank> this is crazy
[03:42:09 CET] <kierank> oh wow that's a fucking awful hack
[03:42:11 CET] <kierank> oh my god
[03:42:33 CET] <kierank> wm4: the parser calls the decode function, consumes bytes, then the data is put into extradata
[03:42:43 CET] <kierank> but the decoder expects a continuous data stream
[03:42:48 CET] <kierank> what.the.fuck
[16:49:38 CET] <BBB> ubitux: ping
[19:59:39 CET] <cone-984> ffmpeg 03Michael Niedermayer 07master:99af260d0b07: doc/examples/decoder_targeted: Limit max pixels for fuzzing
[21:15:13 CET] <wm4> does does ffmpeg produce mkv files with aac tracks that have no a single packet marked as keyframes
[21:15:31 CET] <wm4> why does ffmpeg include a shitty hack to make seek "work" in such files too
[21:15:42 CET] <wm4> this project is so fucking irresponsible
[21:17:00 CET] <durandal_1707> wm4: please post patch
[21:17:31 CET] <wm4> what would that even look like? should I av_assert0(false) if it muxes an aac packet with keyframe=false?
[21:17:45 CET] <durandal_1707> do anyone know utility like vritual dub which doesn't crash?
[21:18:02 CET] <RiCON> vdfiltermod?
[21:21:20 CET] <nevcairiel> wm4: the keyframe flag isnt even documented in the matroska spec as far as i can see, so what can a muxer do
[21:21:49 CET] <wm4> nevcairiel: that's bullshit
[21:23:56 CET] <durandal_1707> RiCON: thanks
[21:26:08 CET] <nevcairiel> but what is a muxer supposed  to do, you don't want to hardcode codec-based checks into a muxer, so it has to somewhat rely on getting valid input - but on the other hand not all containers carry such a flag, so its easy to lose it, i don't think we have any way to identify keyframes and mark them if the container didnt do so
[21:26:37 CET] <nevcairiel> (although for audio iirc all packets are assumed key frames in demuxing, unless someone changed that)
[21:26:38 CET] <wm4> so why does the ffmpeg _demuxer_ do that
[21:27:06 CET] <nevcairiel> who knows, the demuxer has all sort of funny issues
[21:27:34 CET] <wm4> hm I also wanted to change my demuxer to always assume keyframes for all audio packets
[21:27:55 CET] <wm4> but AFAIK libavformat leaves this to the parser to determine
[21:28:29 CET] <nevcairiel> the only audio codec i can even come up with that has non-keyframes is truehd
[21:28:47 CET] <wm4> that's usually broken beyond repair anyway
[21:29:08 CET] <nevcairiel> and the frames are so tiny that just skipping ahead is usually not a problem
[21:29:20 CET] <nevcairiel> .833ms frames yoo
[21:51:07 CET] <llogan> what does tools/ffbisect do? IIRC something to do with merges?
[21:51:45 CET] <llogan> ...when bisecting.
[22:20:43 CET] <cone-984> ffmpeg 03Pavel Koshevoy 07master:4240e5b04737: lavfi/atempo: avoid false triggering an assertion failure
[22:43:31 CET] <nevcairiel> llogan: it allows to skip results from the libav side of the merge commits since those w ouldnt really work
[22:51:51 CET] <JEEB> -32
[23:08:28 CET] <ubitux> BBB: pong
[23:11:14 CET] <cone-984> ffmpeg 03Chen Meng 07master:25e35b34365e: avformat/mov.: Make the process of uuid-xmp atom faster.
[23:25:20 CET] <llogan> nevcairiel: thanks. just "ffbisect start" then "ffbisect need ffmpeg"?
[23:26:55 CET] <nevcairiel> first need i imagine
[23:27:14 CET] <nevcairiel> hm or maybe not
[23:27:49 CET] <nevcairiel> yeah first start then need
[23:28:05 CET] <nevcairiel> and then ffbisect good/bad/skip as appropriate
[23:51:49 CET] <llogan> thanks again
[00:00:00 CET] --- Tue Dec 20 2016