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

[burek]

[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-sse2-loop-vectorization-issue-miscompilation
[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-msvc.patch
[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-icl.patch
[14:58] <Daemon404> http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751(v=vs.85).aspx#SSIZE_T
[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-icl.patch
[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