[01:12] <BBB> michaelni__: planning to apply emulated_edge patch? [01:25] <michaelni__> BBB, why you drop emuedge_linesize_type ? [01:26] <michaelni__> also did anyone review the asm ? [01:31] <cone-114> ffmpeg.git 03Michael Niedermayer 07master:fb45de779c8d: avformat/omadec: simplify checks in nprobe() [01:31] <cone-114> ffmpeg.git 03Michael Niedermayer 07master:15d4965239a3: avcodec/mjpegenc: dont store DQT for LJPEG [01:36] <michaelni__> also ill retest the patch on mips & arm [01:46] <BBB> michaelni__: I replaced it with ptrdiff_t, which is the correct type [01:47] <BBB> I'm not sure what emuedge_linesize_type is, I didn't add it, but it didn't seem to do anything meaningful afaics [01:47] <BBB> C automatically sign-extends anyway, and the AVFrame API means we're limited to 32bit for a long while so no risk of overflows [01:47] <michaelni__> the issue is that IIRC some callers use int stride and do some calculations [01:48] <BBB> right, the ptrdiff_t isn't to make calculations fit [01:48] <BBB> that's a caller's own issue [01:48] <BBB> ptrdiff_t merely makes assembly easier to handwrite since you don't have to sign-extend [01:48] <BBB> we've had several bugs related to that [01:48] <BBB> enforcing ptrdiff_t in the function signatures prevents that [01:48] <BBB> that's the only reason it's using ptrdiff_t vs int [01:49] <michaelni__> there is no question that ptrdiff_t is correct, but if the caller uses int and emu edge reverts these calculations using ptrdiff then the resulting pointers csn point outside to where they should [01:55] <michaelni__> fate on mips-qemu seems to pass now [02:04] <chocolate> I'd like to modify ffmpeg's mpeg1 video encoder (mpeg12enc.c) for personal use to encrypt the sign bits (for demonstrating the paper at www.cs.purdue.edu/homes/bb/security99.ps). But I can't figure out how to tell whether the current block is Y, Cb, or Cr, or if the encoder even distinguishes. Maybe I'm looking in the wrong spot. [02:05] <BBB> michaelni__: that makes little sense, all int values can be represented in a ptrdiff_t, how could anything change after such a cast? [02:10] <michaelni__> consider mv_y*stride - mv_y*(int64_t)stride, it wont be 0 when the first overflows [02:11] <michaelni__> and yes iam fully aware this is undefined in C [02:13] <michaelni__> i dont remember exactly where and what but ive seen an actual out of arary access from such type mismatch from emu edge [02:13] <michaelni__> a while ago that is [02:29] <BBB> well it's undefined in c so I'm not sure what you expect to get from it :) [02:43] <michaelni__> I expect the patch not to add cases where the binary excutable crashes. [02:44] <BBB> if you find any, let me know and I'll fix them [04:47] <Compn> chocolate : try asking on libav-user list ? :) [04:47] <Compn> or sticking around [10:15] <ubitux> "scale='st(0,floor(iw*min(320/iw,240/ih)+.5));ld(0)-mod(ld(0),2)':'st(0,floor(ih*min(320/iw,240/ih)+.5));ld(0)-mod(ld(0),2)'" [10:15] <ubitux> i wonder if this is correct mmh [10:15] <ubitux> maybe i should take into account the sar [10:20] <ubitux> then mmh [10:20] <ubitux> scale='st(0,floor(iw*min(320*sar/iw,240/(ih*sar))+.5));ld(0)-mod(ld(0),2)':'st(0,floor(ih*min(320*sar/iw,240/(ih*sar))+.5));ld(0)-mod(ld(0),2)' [10:20] <ubitux> eval e [10:58] <BoR0> if I were to implement a "video buffering" indicator, where should I put this in ffplay? I firstly tried to wrap it around packet_queue_get but it isn't working as expected [11:24] <cone-294> ffmpeg.git 03Martin Storsjö 07master:8812a8057f53: h263dec: Remove a hack that can cause infinite loops [11:24] <cone-294> ffmpeg.git 03Michael Niedermayer 07master:17513f4fb3c0: Merge remote-tracking branch 'qatar/master' [12:41] <prk> ffmpeg tool doesn't use av_seek_frame anymore? [12:46] <ubitux> avformat_seek_file [12:58] <wm4> ubitux: any news about your vobsub bug fix? [12:59] <ubitux> yes i'm still working on it [12:59] <ubitux> wm4: i need to rewrite a small mpeg parser [12:59] <wm4> oh dear [12:59] <ubitux> very basic, but still [12:59] <ubitux> so i'm mostly reading the specs to understand what's going on [13:00] <wm4> sure turned out to be a nasty bug [13:00] <ubitux> mpegps_read_pes_header() is not really a nice way to learn about the standard [13:00] <JEEB> at least MPEG-2 Part 1 is available for free [13:01] <ubitux> it's still a bit of reading [13:01] <wm4> btw. are there any specs for transport streams around? [13:02] <ubitux> afaik, yes, since recently [13:02] <JEEB> that's mpeg-2 part 1 [13:02] <wm4> oh [13:02] <JEEB> http://www.itu.int/rec/T-REC-H.222.0-201206-I/en [13:02] <JEEB> also known as H.222 [13:02] <JEEB> it has both MPEG-PS and TS [13:03] <wm4> JEEB: thanks [13:03] <ubitux> ah it's a better version than what i have. [13:04] <wm4> also, are there any programs (open or closed) around that can analyze or dump transport streams? [13:05] <iive> dvbsnoop is text one. [13:06] <iive> i mean, cli [13:07] <ubitux> JEEB: it's fun, i have the iso one, but it's smaller (from 2000 though) [13:07] <JEEB> yeah, that one has less stuff etc. :) [13:10] <ubitux> i'm curious about the differences [13:10] <ubitux> they look the same, except the formatting and somehow re-shaped the diagrams (no content change) [13:11] <JEEB> well, a lot will be the same of course [13:11] <JEEB> then there's the addition of AVC/MVC and stuff [13:11] <JEEB> as well as possible other backwards-compatible additions [13:12] <ubitux> http://ubitux.fr/pub/pics/mspecs.png [13:14] <JEEB> oh, they already had BIFS in there then o_O [13:14] <JEEB> anyways, major things ain't going to have changes in them naturally [13:49] <TheRyuu> was there any investigation into why msvc fails filter-metadata-ebur128 with SSE2 enabled? [13:50] <nevcairiel> msvc bug [13:50] <kierank> 12:10:03 <"ubitux> i'm curious about the differences --> everything in mpeg after 2000 :) [13:50] <nevcairiel> misoptimization in the loop vectoring that initializes one of the ebur tables [13:51] <nevcairiel> https://connect.microsoft.com/VisualStudio/feedback/details/783101/vs2012-ss... [13:52] <nevcairiel> i still have hope they are addressing it for update 4 [14:01] <TheRyuu> lul [14:02] <JEEB> http://support.microsoft.com/kb/2872520 I don't see that exact thing on the U4 RC3 "C++ " changes list [14:02] <JEEB> but there's some other miscompilation thing that got in [14:02] <nevcairiel> thats why you still need hope [14:02] <nevcairiel> if it was on the list, you wouldnt need hope :p [14:02] <JEEB> indeed [14:02] <ubitux> nevcairiel: you want to add a temporary workaround in the code? [14:03] <nevcairiel> i could pragma the loop to disable the loop optimizer [14:03] <nevcairiel> but pramas are so ugl [14:03] <nevcairiel> ugly [14:03] <nevcairiel> pragma [14:03] <nevcairiel> cannot type today [14:04] <TheRyuu> it's still probably worth adding, if anything to make fate play nice [14:09] <wm4> there's currently no way to participate in lavfi format negotiation using buffersrc/sink, is there? [14:09] <wm4> I mean things like if I pass in a specific format, which formats will lavfi accept for output [14:10] <wm4> the only way is to actually build the filter graph, which is going to be too slow for all formats [14:13] <BBB> michaelni__: so you want me to go through the whole codebase and s/int linesize/ptrdiff_t linesize/ all over the place basically? [14:17] <michaelni__> the obvious and simple solution is to leave the type and order of calculations in emu edge so it matches the ones outside [14:18] <michaelni__> iam not against all to be changed to ptrdiff_t but it seems somehow unrelated [14:19] <Daemon404> it also seems like overkill [14:19] <Daemon404> given the massive amount of places its used [14:42] <cone-393> ffmpeg.git 03Alex Smith 07master:d6d27f3e58e6: configure: Enable -Qansi-alias for icl 14+ [14:42] <cone-393> ffmpeg.git 03Michael Niedermayer 07master:ab0b1fdd176c: Merge commit 'd6d27f3e58e6980bce4a490e7d8cc0f6a84521fe' [14:47] <TheRyuu> https://warpsharp.info/libav/0001-lavf-Workaround-for-misoptimization-with-m... [14:48] <nevcairiel> that sure is ugly [14:51] <Daemon404> id rather just wait [14:51] <Daemon404> they fixed our other bug(s) [14:57] <kierank> put it in as a troll [14:57] <TheRyuu> https://warpsharp.info/libav/0001-tools-Fix-compilation-of-ffhash-with-msvc-... [14:58] <Daemon404> http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751(v=vs.85).as... [14:58] <Daemon404> @ TheRyuu [14:59] <TheRyuu> I originally had it use that but then you said read returns an int [14:59] <Daemon404> _read() on windows indeed returns an int [14:59] <Daemon404> i dont knw if we /use/ _read() [14:59] <nevcairiel> what else is there? :p [14:59] <TheRyuu> don't the POSIX names just map to those [14:59] <TheRyuu> but are deprecated? [15:00] <Daemon404> i was fairly sure we had our own special read() [15:00] <Daemon404> but i was just thnking of open( [15:00] <Daemon404> ) [15:00] <TheRyuu> ssize_t size = read(fd, buffer, SIZE); [15:01] <Daemon404> in general i disliked scattering checks for _MSC_VER [15:01] <Daemon404> :/ [15:02] <cone-531> ffmpeg.git 03Martin Storsjö 07master:5f24fe82e5fc: mpegvideo: Initialize chroma_*_shift and codec_tag even if the size is 0 [15:02] <cone-531> ffmpeg.git 03Michael Niedermayer 07master:0ebc3728561c: Merge commit '5f24fe82e5fcf227abb5ebf62aa9bc246fda8c0d' [15:03] <Daemon404> i really do dislike that there is literaly separate merge for every commit now [15:03] <Daemon404> 1/4 of the git history is merge <hash> i swear [15:03] <nevcairiel> yeah its quite spammy [15:04] <TheRyuu> Daemon404: well what would you have me do? [15:04] <TheRyuu> -Dssize_t=intptr_t? [15:04] <Daemon404> not sure [15:04] <Daemon404> thnking [15:05] <nevcairiel> what do the other read calls do? [15:05] <nevcairiel> ie file protocol in avformat [15:06] <TheRyuu> they just use int [15:06] <nevcairiel> then do that [15:06] <nevcairiel> :D [15:06] <Daemon404> i agree [15:06] <Daemon404> file.c is nice [15:06] <Daemon404> modifying function params [15:07] <Daemon404> very nice indeed. [15:07] <Daemon404> return (-1 == r)?AVERROR(errno):r; [15:07] <Daemon404> gotta love fabrice code [15:09] <cone-531> ffmpeg.git 03Vittorio Giovara 07master:26179964ff3f: h264_sei: log unknown sei messages [15:09] <cone-531> ffmpeg.git 03Michael Niedermayer 07master:9c2e31c3b3a2: Merge commit '26179964ff3fa1173e6f512c5735ba8223e2395d' [15:11] <TheRyuu> https://warpsharp.info/libav/0001-tools-Fix-compilation-of-ffhash-with-msvc-... [15:13] <nevcairiel> its just one of the test tools, so it will hopefully not produce a big outcry over lol-not-posix [15:13] <Daemon404> i'd change te message to: [15:13] <Daemon404> ffhash: Change size to an int [15:13] <Daemon404> This fixes compilation with MSVC and ICL, and makes ffhash [15:13] <Daemon404> consistent with how the rest of the codebase uses read(). [15:13] <Daemon404> and send [15:14] <TheRyuu> ok [15:18] <TheRyuu> https://warpsharp.info/libav/fix-icl-preproc-failure.diff [15:19] <nevcairiel> icl doesnt do varargs? [15:20] <TheRyuu> it does, it just fails there [15:27] <TheRyuu> is there really any reason to be using varargs there? [15:36] <cone-531> ffmpeg.git 03Vittorio Giovara 07master:edaba18021e4: h264: log extradata skip only for non-ignored NALs [15:36] <cone-531> ffmpeg.git 03Michael Niedermayer 07master:af2bb83dffb7: Merge commit 'edaba18021e4793116f0f266e65077578a5e742e' [15:43] <cone-531> ffmpeg.git 03Rainer Hochecker 07master:71cabb521ac3: h264: do not discard NAL_SEI when skipping frames [15:43] <cone-531> ffmpeg.git 03Michael Niedermayer 07master:d195e6e410e4: Merge commit '71cabb521ac397db3903011d2de7afd3e0fc7ab6' [15:52] <cone-531> ffmpeg.git 03Michael Niedermayer 07master:84df6d6a85e2: h264_sei: check SEI size [15:52] <cone-531> ffmpeg.git 03Michael Niedermayer 07master:a454dec19aa6: pixdesc: fix NV20* descriptors [15:52] <cone-531> ffmpeg.git 03Michael Niedermayer 07master:1fb0d961149f: Merge commit 'a454dec19aa6666b555deec431bc42eda391d7b6' [16:19] <cone-531> ffmpeg.git 03Kieran Kunhya 07master:58894ab3f94d: lavc: add support for interleaved chroma formats to libx264. [16:19] <cone-531> ffmpeg.git 03Michael Niedermayer 07master:4fdf2fa94a3f: Merge remote-tracking branch 'qatar/master' [16:45] <cone-531> ffmpeg.git 03Alex Smith 07master:2599a62fbb31: ffhash: Change size to an int [17:53] <ubitux> durandal_1707: maybe we could add an avoption flag for reconfigurable options? [17:54] <durandal_1707> please elaborate [17:54] <durandal_1707> some filters need to call extra code [17:54] <ubitux> you would do init in the config_props [17:54] <ubitux> s/init/it/ [17:54] <ubitux> basically you add flag for each option you want it reconfigurable [17:55] <wm4> instead of filter commands? [17:55] <ubitux> and you adjust your config props to handle this [17:55] <ubitux> that way you can make an automatic process command wrapper [17:55] <ubitux> and think about a better interface [17:55] <durandal_1707> hmm add some "testcase" and send patch to ml? [17:55] <wm4> can external programs inspect avoptions of filters yet? [17:56] <ubitux> wm4: we could imagine a process_command v2 taking an avdict [17:56] <ubitux> which would be compatible with the avoptions of the filter [17:56] <ubitux> and thus work as well [17:56] <wm4> that's marginally better [17:56] <wm4> what would be really good is if you could inspect the filter graph as well as options filters provide [17:57] <ubitux> dunno [17:57] <ubitux> that was just a suggestion [17:58] <wm4> what you suggest sounds good though (a flag for dynamic options) [17:58] <wm4> I wanted to do this in my mplayer fork too: make properties normal options that are more dynamic [18:31] <durandal_1707> why when pressing 'c' to type command with ffmpeg, it starts to use all cpu? [18:31] <durandal_1707> do people care about quality of such hacks? [18:32] <durandal_1707> and why i can't see command i'm typing? [18:37] <wm4> ffmpeg supports user input? [18:38] <durandal_1707> yes, press c [18:38] <durandal_1707> its just crude hack [18:39] <durandal_1707> what is point of sendcmd filters if you can't use it at any point of time in filtergraph [18:47] <GoaLitiuM> where do you need user input? [18:55] <wm4> so, I'd say there should be two extensions to the avoption api: 1. add a flag that tells whether a value can be changed at runtime, and 2. a callback that e.g. filters can use to reconfigure if an option value was changed [18:55] <wm4> then you can get rid of the process_command and sscanf() crap [19:28] <saste> durandal_1707, i won't be online in the next two days, i'll review your patches as soon as I'll be back [19:28] <saste> or other people can review them of course [19:29] <saste> durandal_1707, sendcmd is for static scripting, the zmq filters can be used to send commands instantly [19:30] <Daemon404> 30 [19:30] <Daemon404> woops [19:30] <durandal_1707> you have 30 open windows? [19:31] <Daemon404> irssi has 54 windows (including PMs) right now [19:31] <durandal_1707> WOW [19:38] <durandal_1707> j-b: why you was sad? [19:39] <ubitux> he isn't anymore [19:39] <ubitux> so it doesn't matter! [19:39] <ubitux> sadness is a bad memory, let it die [19:40] <gnafu> Death makes me sad. [19:41] <durandal_1707> death is cure for life [19:42] <ubitux> we should rename nullsink to death [19:42] <ubitux> to be consistent with life source filter [19:43] <durandal_1707> no death is rm -rf ffmpeg tree.... and etc [19:43] <gnafu> Death is cold. Death is inviting. Death is the resolution of all things. Death is the beginning of all things. Burma Shave. [21:41] <cone-906> ffmpeg.git 03Michael Niedermayer 07master:dcc7686ae7ce: avcodec/mpegvideo: drop emu edge check from chroma_4mv_motion_lowres() [22:02] <ubitux> so no one wants to fix the broken examples? [22:26] <durandal_1707> what is point of forums if only noobs use them? [22:27] <ubitux> isolate them [22:28] <durandal_1707> u evil [00:00] --- Wed Sep 25 2013