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

[burek]

[00:21:11 CEST] <jsebechlebsky> Hello guys, do you know some tool for mpegts analysis (which I can run on linux). I have two mpegts files - they should be the same but there is a small diference (4bytes), I would like to find out what exactly the difference is...
[00:28:30 CEST] <jkqxz> cmp, then hexdump the two files and compare the bytes at the given address?  What sort of analysis do you want?
[00:29:27 CEST] <jsebechlebsky> I've done this, I just wondered if there is not some tool which would tell me which field of mpegts packet it is... 
[00:30:22 CEST] <jsebechlebsky> Something similar to what wireshark does...
[00:35:20 CEST] <jkqxz> What is your offset to the difference?  (In particular, is it zero mod 188?)
[00:36:09 CEST] <jsebechlebsky> yes it is - 588!
[00:40:39 CEST] <jkqxz> It's not very difficult to decode yourself.  See <http://www.itu.int/rec/T-REC-H.222.0-201206-S/en> section 2.4.3 for precise definitions (or just read wikipedia).
[00:42:32 CEST] <jsebechlebsky> thanks, I've noticed just now that mpegts packets are 188B fixed length :)
[01:31:42 CEST] <DHE> no really, open a .ts file with wireshark
[01:31:53 CEST] <DHE> oh you have
[01:35:31 CEST] <Compn> isnt there bindiff program...
[01:43:57 CEST] <jsebechlebsky> Oh, it really works with wireshark! :-D
[01:44:07 CEST] <jamrial> Compn: daemon404 was writting one
[04:25:57 CEST] <chovy> hello
[04:26:19 CEST] <chovy> is there a shorter way to do this: -map 0:a:9 -map 0:v:9 ?
[04:26:35 CEST] <chovy> i tried -map 0:9 but i get an error
[04:31:26 CEST] <jamrial> chovy: not really. one chooses the 10th audio stream and the 10th video stream, the other chooses exactly the 10th stream alone regardless of type
[04:35:40 CEST] <chovy> jamrial: -map 0:9 doesn't work
[04:37:57 CEST] <chovy> i get no audio
[04:38:38 CEST] <chovy> when i use -map 0:a:9 -map 0:v:9 it works but the audio fades in and out.
[09:49:40 CEST] <andrey_turkin> chovy: if you are still on that hls issue - ffmpeg converts each variant into its own program. map 0:p:9 will select all streams related to a program 9
[11:33:14 CEST] <cone-434> ffmpeg 03Benoit Fouet 07master:2234566cfb11: hls muxer doc: clarify segment splitting option
[13:01:46 CEST] <ubitux> anyone going to fix the FATE memleak in mkv remux?
[13:02:02 CEST] <ubitux> it's leaking since $forever
[13:02:19 CEST] <nevcairiel> i think there is a patch on the ml for that
[14:27:13 CEST] <cone-434> ffmpeg 03dsmudhar 07master:7a2b9dd060b6: vf_codecview: added new options
[14:33:27 CEST] <cone-434> ffmpeg 03Benjamin Steffes 07master:5b95b4616aae: avfilter/af_hdcd: Use int32_t instead of int for gaintable in hdcd filter.
[15:19:32 CEST] <ubitux> what am i reading :))
[15:36:53 CEST] <Shiz> what the actual fuck am i reading
[15:44:12 CEST] <nevcairiel> i updated my own code for codecpar today (finally), and i could've probably sed scripted that, everything just fits :)
[15:46:18 CEST] <nevcairiel> now i just need to use the new decode api
[16:44:31 CEST] <BBB> ubitux: that was exactly what I was thinking too
[16:45:10 CEST] <BBB> nevcairiel: is that rcombs patch?
[16:45:27 CEST] <cone-434> ffmpeg 03Matthieu Bouron 07master:e452abc5c244: lavc/mediacodec: refactor ff_AMediaCodecList_getCodecByType
[16:45:28 CEST] <cone-434> ffmpeg 03Matthieu Bouron 07master:346b3c5c415a: lavc/mediacodec: re-indent after previous commit
[16:46:15 CEST] <nevcairiel> BBB: part of the series i think
[16:53:18 CEST] <ubitux> rcombs: i never remember, you have write access to git, right?
[17:46:48 CEST] <cone-434> ffmpeg 03Carl Eugen Hoyos 07master:aec96e233f60: lavc/dpx: Support decoding 12 bit colourspace with transparency information.
[18:20:51 CEST] <BBB> so now that everyone is talking about bans anyway
[18:20:56 CEST] <BBB> what are we going to do about carl vs. derek?
[18:29:03 CEST] <ubitux> BBB: derek didn't left because of carl
[18:29:14 CEST] <ubitux> i don't think there is anything to do for now anyway
[18:29:36 CEST] <ubitux> they are (retroactively wtf) banned currently, that clears everything for now
[18:29:45 CEST] <BBB> who is banned?
[18:29:46 CEST] <ubitux> let's wait for new problems and move on
[18:29:56 CEST] <ubitux> didn't you read the mail?
[18:30:01 CEST] <BBB> oh he actually did it?
[18:30:04 CEST] <BBB> thats ridiculous
[18:30:09 CEST] <ubitux> he didn't?
[18:30:12 CEST] <BBB> he cant just randomly ban people because he feels like it
[18:30:16 CEST] <ubitux> "After writing this mail i will"
[18:30:33 CEST] <BBB> I think its bad to ban people without any discussion
[18:30:40 CEST] <ubitux> sure
[18:30:59 CEST] <ubitux> everyone was whinning constantly and nothing was happening, especially since we don't know who is in charge of the ban or whatever
[18:31:12 CEST] <ubitux> so i guess that's the reason
[18:31:14 CEST] <BBB> like, let me say it like this: I think fewer people agree with the way michael banned himself, derek and carl than people agreed with any other proposal put forward so far
[18:31:47 CEST] <ubitux> i don't really care tbh
[18:33:01 CEST] <ubitux> anyway, wanna help with the merges BBB? :D
[18:33:10 CEST] <BBB> no :-p
[18:33:47 CEST] <ubitux> :(
[18:36:00 CEST] <BBB> the whole fork and merge business is stupid
[18:36:26 CEST] <BBB> (imo)
[18:36:44 CEST] <BBB> Im all supportive if other people want to do it, but not me
[18:37:54 CEST] <ubitux> of course it's stupid
[18:38:06 CEST] <ubitux> but that's the best we can do so far afaict
[18:40:03 CEST] <ubitux> well the positive thing is that it's somehow an opportunity to learn a bit about all kind of things in the codebase :p
[18:40:43 CEST] <Shiz> ... is that positive?
[18:40:45 CEST] <Shiz> ;p
[18:41:17 CEST] <ubitux> always need to find a meaning to something that hasn't :(
[18:41:27 CEST] <ubitux> it's like life
[19:16:54 CEST] <Compn> hah i thought michaelni's mail was good
[19:17:14 CEST] <Compn> no one is happy about anything
[19:17:19 CEST] <Compn> what are you all so mad about?? :D
[19:26:09 CEST] <cone-434> ffmpeg 03Muhammad Faiz 07master:f92b56de9664: fate: add swr-resample_exact_async tests
[19:35:42 CEST] <rcombs> ubitux: yeah and I'm just timid about using it
[20:32:19 CEST] <durandal_170> Who have controls he have power
[20:39:34 CEST] <DHE> so if I get a frame out of a video buffersink in a filter, that will not be modified in the future, right? I ran into a problem...
[20:42:24 CEST] <durandal_170> what problem?
[20:46:12 CEST] <DHE> after a frame came out of av_buffersink_get_frame_flags(buffersink, outframe, 0);   // and I run mprotect on the data to disallow writes, the program segfaults when writing to the data in the filter
[20:47:32 CEST] <DHE> I'm trying to figure out how and why...
[20:49:48 CEST] <durandal_170> is frame writtable, because of reference counting?
[20:50:07 CEST] <DHE> the frame I get back has frame->buf[0] through [2] (yuv) defined.
[20:50:21 CEST] <DHE> I know it violates the API convention, but that's how I'm getting the addresses to mprotect()
[20:51:45 CEST] <durandal_170> you can't do protect to reference counted frame, iirc
[20:52:45 CEST] <DHE> if a frame is reference counted, it should be read-only. but if I mprotect(frame->buf[0]->data, frame->buf[0]->size, PROT_READ); then the program will segfault
[20:53:12 CEST] <DHE> (actual call to mprotect fixes the parameters to make them all page-aligned)
[20:53:53 CEST] <DHE> and yes, I round up to ensure I only write to the center of the frame rather than risk write-protecting bytes outside the array
[21:01:25 CEST] Action: DHE realizes it could be his own fault, gotta check first
[21:12:07 CEST] <DHE> okay, yeah. just because it's a big allocation doesn't mean free() returns it to the kernel. and I've marked it as read-only now... crap...
[23:48:25 CEST] <cone-434> ffmpeg 03Michael Niedermayer 07master:eaa11437a47e: doc/APIchanges: Fill in some missing things
[00:00:00 CEST] --- Thu Jun 16 2016