[00:02] <funman> michaelni: i see coded_picture_number is broken [00:02] <funman> even with threds=1 [00:02] <funman> (testing h264) [00:05] <funman> michaelni: any advice where to look to fix it? [00:09] <michaelni> funman, what do you need cpn for ? how is it broken ? [00:10] <funman> i need it for closed captions [00:10] <funman> i store them before decoding (in coded order) and associate them to decoded picture using cpn but they come out in the wrong order [00:12] <funman> it's easy to see that cpn changes depending the number of threads also [00:14] <michaelni> funman, did you look at reordered_opaque ? maybe its what you are searching for [00:16] <funman> yeah i saw it [00:16] <funman> vlc uses it already though [00:16] <j-b> Any G.729 samples? [00:16] <funman> ah to store pts/dts... ? [00:18] <michaelni> reordered_opaque could hold a pts or a number or a pointer to a struct or many other things [00:18] <funman> http://git.videolan.org/?p=vlc.git;a=commitdiff;h=529a7a1af65af87e4655497fe1... [00:19] <funman> yeah anything, but it's already busy hmmm [00:20] <funman> i also tried pkt_pts/dts [00:20] <michaelni> fixing cpn is surely fine too, but i cant guess where its wrong, probably something missing in h264*c or mpegvideo*c [00:21] <michaelni> you could check if cpn works with mpeg4 asp and then look at what is different to h264 [00:21] <funman> hm not sure how i can check order at output [00:23] <funman> mpeg4 asp is not used with captions but i think mpeg2 is broken as well [00:23] <funman> let me check [00:24] <j-b> michaelni: you lost your @ ? that is weird :) [00:24] <j-b> funman: salut poulet! [00:24] <funman> oh hai [00:24] <durandal_1707> j-b: why you have @ and not ' ' ? [00:25] <michaelni> also you didnt yet say how cpn is broken exactly ? [00:26] <funman> michaelni: if you print cpn it won't show the same order with != number of threads [00:26] <j-b> durandal_1707: no idea :) [00:26] <funman> also if i trust this sample, cpn isn't correct even with 1 thread [00:28] <durandal_1707> j-b: you have g718 files? [00:30] <funman> michaelni: pkt_pts seems to work, just compare it with cpn [00:32] <durandal_1707> also what is poing in supporting ID3v2 chapters if our api does not allow hierarchical ones [00:42] <funman> michaelni: it seems it was just off by one .. :/ [00:44] <funman> perhaps the problem is my sample hmmm damn [00:45] <funman> with AVPacket.pts starting from 0 and increasing, AVFrame->pkt_pts = AVFrame->coded_picture_number - 1 [00:46] <funman> yet i still see unordered captions [00:46] <cone-126> ffmpeg.git 03Michael Niedermayer 072aecfd4f2096: vf_showinfo: check return code of av_image_get_linesize() [00:55] <funman> hmm... pkt_pts and coded_picture_number always match but they are returned in the wrong order... [00:56] <funman> i don't expect vlc to feed avcoded with NALs in random order [01:04] <ubitux> thegeek: ./ffmpeg -f lavfi -i 'aevalsrc=0:0' -t 5 -ac 1 -f null - [01:04] <ubitux> does this crash for you as well? [01:04] <thegeek> let me check [01:05] <thegeek> hm no [01:05] <thegeek> should there be any output? [01:06] <ubitux> nope [01:06] <ubitux> if you replace "-f null -" with out.mp3? [01:06] <thegeek> still no crash [01:07] <ubitux> what is the decoder output? [01:07] <ubitux> s16le? [01:07] <funman> i'll try with ffplay tomorrow to see if the problem is in vlc [01:07] <thegeek> Stream #0:0 -> #0:0 (pcm_f64le -> pcm_s16le) [01:07] <thegeek> that's what you mean? [01:07] <thegeek> on the null example [01:08] <ubitux> i mean with your audio input [01:08] <ubitux> ffmpeg -f lavfi -i 'aevalsrc=0:0,aformat=sample_fmts=s16' -t 5 -ac 1 -f null - [01:08] <ubitux> does this trigger it? [01:08] <thegeek> yes [01:09] <thegeek> no full backtrace with gdb [01:09] <thegeek> just crash in ff_mix_2_1_a_int16_sse2 [01:22] <ubitux> movd (%r9,%r11,4),%xmm6 ’ r11 0xea6400000001 257715217629185 [01:22] <ubitux> sounds fishy [01:23] <ubitux> movd m6, [coeffpq + 4*index2q] [01:23] <ubitux> so index2 looks wrong [01:23] <ubitux> something like a 32/64 issue [01:24] <ubitux> index1 and index2 are int [01:24] <ubitux> is it ok to access it as "q"? (double word right?) [01:25] <thegeek> unfortunately my asm-fu is not very strong so I can't comment;P [01:26] <ubitux> i must say i sucks as well too [01:26] <ubitux> michaelni can likely comment on this issue [01:27] <ubitux> that 'q' suffix looks weird to me, but it's used everywhere so i wonder... :p [01:28] <thegeek> hum, well I'm going to bed now, good night [01:29] <ubitux> 'night :) [02:14] <cone-126> ffmpeg.git 03Michael Niedermayer 07d23e8f53ad01: swr: use 64bit index/len for x86_64 mix [02:20] <ubitux> oh i was right about the issue @_@ [02:56] <cone-126> ffmpeg.git 03Michael Niedermayer 078edf9b1fa44d: sws: rgb has no range, avoid random results if the user tries to mess with it anyway. [03:39] <Compn> ohsix : did you see carls comment > https://ffmpeg.org/trac/ffmpeg/ticket/1853#comment:4 [03:40] <Compn> nevcairiel : you too ^ [03:40] <Compn> he reads irc on the mailing list :) [03:40] <Compn> hi carl! /me waves [04:00] <izaakschroeder> carl sounds like an exceellent guy :> [04:02] <Compn> everyone in the project is excellent :) [04:02] <Compn> lots of friendly people [04:02] <Compn> few trolls :) [04:08] <cone-126> ffmpeg.git 03Michael Niedermayer 07c4a36b6f70f3: lpc: check that lpc_type is valid in ff_lpc_calc_coefs [04:21] <izaakschroeder> what's the neatest project you've seen using libav-n-friends? [04:34] <Compn> you mean that switched to libav fork ? [04:57] <izaakschroeder> sure; just looking for neat projects using your work :) [06:13] <Compn> i dunno [06:13] <Compn> nasa uses ffmpeg to convert some if its files [06:14] <Compn> i think thats pretty neat [06:15] <Compn> oh by libav you mena libavcodec and friends. confusing me :) [06:15] <Compn> anytime ffmpeg is used for science! its interesting to me. [06:17] <Compn> i saw some research about mri images that used ffmpeg and imagemagick to convert/analyze files [10:14] <cone-199> ffmpeg.git 03Nicolas George 07b0e2f4a757d6: lavfi/concat: implement unsafe mode. [10:14] <cone-199> ffmpeg.git 03Nicolas George 0714f69a0516e4: fate: add a test for scale with variable input format. [12:07] <funman> so current_picture_number looks fine after all [13:10] <cone-199> ffmpeg.git 03Michael Niedermayer 07f9f79cb0ecb6: fate: make sure the global sws flags are set to be bitexact for scalenorm [13:28] <cone-199> ffmpeg.git 03Mans Rullgard 076b776c61da26: buffersink: remove stray semicolon after function definition [13:28] <cone-199> ffmpeg.git 03Mans Rullgard 0767a68dcec227: af_channelmap: remove stray enum declaration [13:28] <cone-199> ffmpeg.git 03Mans Rullgard 079efbfe57e082: network: use HAVE_THREADS instead of local hack [13:28] <cone-199> ffmpeg.git 03Mans Rullgard 07be2efe0c7b6a: udp: use socklen_t where appropriate [13:28] <cone-199> ffmpeg.git 03Mans Rullgard 07cc64ec570c92: avserver: use socklen_t where appropriate [13:28] <cone-199> ffmpeg.git 03Mans Rullgard 074521645b1aee: avio: fix pointer type mismatches in avio_enum_protocols() [13:28] <cone-199> ffmpeg.git 03Michael Niedermayer 078943ad40146d: Merge commit '4521645b1aee9e9ad8f5cea7b2392cd5f6ffcd26' [14:06] <saste> michaelni, fate breakage [14:08] <michaelni> saste, what is broken ? [14:29] <cone-199> ffmpeg.git 03Mans Rullgard 0750be207759aa: amrwbdec: fix invalid pointer arithmetic [14:29] <cone-199> ffmpeg.git 03Mans Rullgard 07c4cccc8d3f66: h264: fix invalid pointer arithmetic [14:29] <cone-199> ffmpeg.git 03Mans Rullgard 074471a2420717: vp8: fix memset() crossing array boundary [14:29] <cone-199> ffmpeg.git 03Mans Rullgard 074cd217c065e9: configure: detect sparc64 automatically [14:29] <cone-199> ffmpeg.git 03Mans Rullgard 074cbae57cef65: assdec: fix qsort() callback signature [14:29] <cone-199> ffmpeg.git 03Luca Barbato 07fce4450dec2f: nutenc: K&R formatting cosmetics [14:29] <cone-199> ffmpeg.git 03Luca Barbato 07424b1e764263: yuv4mpeg: reject unsupported codecs [14:29] <cone-199> ffmpeg.git 03Michael Niedermayer 07c73fcc8de3e3: Merge remote-tracking branch 'qatar/master' [14:43] <cone-199> ffmpeg.git 03Michael Niedermayer 07ac090fa68c62: lavu: keep context size variables [14:43] <cone-199> ffmpeg.git 03bbraun 07d72aef4e922b: movenc: add more metadata types [14:52] <cone-199> ffmpeg.git 03Carl Eugen Hoyos 0796fac764fa8e: Add an additional AAC TwoCC. [15:47] <cone-199> ffmpeg.git 03Carl Eugen Hoyos 073f4480941560: Synchronize libmpcodecs: Support 16bit yuv in telecine filter. [15:57] <saste> michaelni, f9f79cb0ecb68546e6de3db6072f631bb3fbcff8 [15:58] <saste> it works only by chance, since sws_flags is not a valid scale option [15:59] <saste> uhm it was 14f69a0516e4a505eaa65236b919023ecd146d95 [16:10] <cone-199> ffmpeg.git 03Paul B Mahol 0707ed191b15fb: parse ID3v2 chapters [16:11] <cone-199> ffmpeg.git 03Michael Niedermayer 07d8246d475cde: vc1dec: mark by assert that the default path cannot occur [16:23] <durandal_1707> j-b: VLC does not support wav tags? [16:25] <durandal_1707> wtf [16:27] <ohsix> supporting arbitrary sizes doesn't have to make it slow for actual video style dimensions (though compn raises an interesting point; what use is it if nothing can do anything with it after scaling it) [16:29] <ohsix> that's not a reason for it not to work, though, i guess; but you can probably agree that scaling to 1x1 pix and bothering with libswscale to do it is useless; and you can probably walk that up to 8x8 : [16:31] <durandal_1707> wouldn't same happen with bigger dimensions and targeting, say 300x200 ? [16:31] <ohsix> eh, i'm just referring to the original report, the bug seemed to change after michael marked it fixed [16:31] <divVerent> ohsix: why is scaling e.g. 16x16 to 6x6 sure useless? [16:32] <divVerent> the original report affects using libswscale to scale DVD subs [16:32] <divVerent> which are the size of their bounding box [16:32] <ohsix> nowhere does it say that [16:33] <divVerent> sure [16:33] <divVerent> that's how we encountered in mpv [16:33] <ohsix> and the subpictures aren't subject to the same restriction as the video format restrictions? [16:33] <divVerent> nope [16:33] <divVerent> a DVD subpicture can be quite small [16:33] <divVerent> ffmpeg somewhat circumvents it [16:33] <ohsix> right [16:33] <divVerent> by padding them to full screen size first [16:33] <divVerent> in that subpicture-to-video hack [16:34] <ohsix> i accept that, i just thought it would have the same sort of size restrictions [16:34] <divVerent> also, the issue happens for destination size [16:34] <divVerent> so if your subpicture is 8x8, but you display 720x480 on a 640x480 screen [16:34] <divVerent> then you already go below 8x8 on output side [16:35] <divVerent> that's what makes it a bit hard for us to pad subpictures while decoding [16:35] <divVerent> because we don't know the on-screen size yet at that point [16:35] <ohsix> you could probably un-derail the bug with that information [16:36] <divVerent> but thing is, wm4 provided a test case (AFAIK) that uses pure ffmpeg usage [16:36] <divVerent> by just scaling to a tiny size explicitly [16:36] <divVerent> but now you know WHY we want to do that [16:36] <ohsix> need [16:36] <divVerent> the other issue, which seems hard to track down (not sure about status) [16:37] <divVerent> for OSD rendering, we convert a subrectangle of the screen to YUV444P [16:37] <divVerent> alpha blend subs to that [16:37] <divVerent> then convert it back right on the screen buffer [16:37] <divVerent> and this sometimes encountered writing into the place between end of row and start of next row [16:37] <divVerent> as workaround, we tried ensuring the width is always a multiple of 16 bytes for the format, but that failed, but 32 worked fine [16:37] <ohsix> heh, seems that the bug reporting guidelines might have done disservice to what you actually intend to do :D [16:38] <divVerent> but that one IIRC we failed to reproduce with a short test program [16:38] <divVerent> in our code, it led to a black stripe at the right side of the subpicture [16:38] <divVerent> and with aligning width to 32 bytes multiples, that went away [16:39] <ohsix> so who is gjdfgh [16:39] <divVerent> also, whenever the stride is NOT a multiple of 16, we get the bad alignment warning of libswscale but the output is fine [16:39] <divVerent> no idea [16:39] <divVerent> so the suspicion on that issue is that libswscale may in some cases actually need a 32 byte alignment [16:39] <divVerent> which would be fine, but should be documented then ;) [16:39] <ohsix> ok, cuz the black stripe thing sounded like another bug we were talking about from the same guy, reported at almost the same time yesterday [16:39] <divVerent> yes, that is it [16:40] <divVerent> so the MAIN issue about this is that ideally, there should be an API (function, or macro) to get libswscale's alignment requirements [16:40] <divVerent> and then POSSIBLY the 16 bytes requirement as currently "documented" by the warning when it is not met is wrong [16:40] <ohsix> needing 32 bit alignment in some cases without a slow path to handle when it isn't is probably an oversight [16:41] <divVerent> the main problem here is IMHO that the alignment requirements aren't even documented in the header [16:41] <divVerent> ideally, there should be a function that returns the alignment libswscale wants for stride and pointers [16:41] <divVerent> which currently probably would just have a { return 16; } body [16:41] <ohsix> the library i have in my head wouldn't have any, but if they were it would probably operate more efficiently on those pictures; but that library isn't libswscale, i don't know anything about it [16:42] <divVerent> here the biggest problem I see is that if ffmpeg introduces such an API, libav will do it different and then that gets merged back into ffmpeg [16:42] <divVerent> ;) [16:42] <divVerent> well, even if libswscale is changed to not have any such "hard requirements" any more (currently they're not really requirements, because not meeting them results in a warning and a slow but correct path [16:42] <divVerent> ) [16:43] <divVerent> even then a function to query the "desired" alignment would be good [16:43] <divVerent> but this one is probably really something to first coordinate with libav [16:43] <ohsix> you might not be able to do that, the fast scalers are specializations and you'd have a fun time making a composite bit of information just for the alignment [16:44] <divVerent> composite? [16:44] <divVerent> just a constant value would be fine [16:44] <divVerent> setting it too high won'tz do much damage [16:44] <divVerent> the main reason for it to possibly be a function and not just a SWS_DESIRED_ALIGNMENT macro would be so it can depend on the CPU [16:44] <divVerent> e.g. so when SSE is not detected, it could return less [16:45] <ohsix> right, but how do you ask all the specialized scalers behind the api to report that, you may end up getting 2 different scalers based on the alignment, you can align for one of them [16:45] <divVerent> no, not ask them all [16:45] <divVerent> I thought about setting it to fixed 16 now [16:45] <divVerent> and whenever one writes a scaler that requires 32 [16:45] <divVerent> he bumps the constant to 32 [16:46] <ohsix> i'd think that might be worse than guessing [16:46] <divVerent> it'd sort of be the "smallest alignemnt for which all scaling calls (different formats, sizes, etc.) run the fastest possible path" [16:46] <divVerent> or "the biggest alignment of all the scaling paths" [16:46] <divVerent> a constant might be worse than guessing? [16:46] <divVerent> currently it IS a constant, it's just not exposed by an API [16:46] <divVerent> but merely a condition for a warning message [16:47] <ohsix> it comes down to more than the alignment, stride and stuff are in play for fast path [16:47] <divVerent> ah, interesting [16:47] <divVerent> because that is all the warning cares for [16:47] <divVerent> that's BTW a nice hint as for why our test case didn't work ;) [16:47] <divVerent> as it may even e.g. depend on the sizes themselves or stuff like that [16:48] <divVerent> an alternative may be adding a fucntion to libswscale that allocates a picture of given size and format with optimum alignment for best scaling [16:48] <ohsix> that's what most things do [16:49] <ohsix> buffer is provided by the element that uses it, or a generic allocator if it doesn't matter [16:49] <ohsix> when i say most, i mean gstreamer [16:50] <divVerent> but anyway, I have to go now... feel free to quote me from here if necessary [17:09] <cone-199> ffmpeg.git 03Michael Niedermayer 07991db6395166: frame_thread_encoder: fix packet memleak [17:09] <cone-199> ffmpeg.git 03Michael Niedermayer 07f472d01c25a8: frame_thread_encode: fix context memleak [17:21] <cone-199> ffmpeg.git 03Stefano Sabatini 0774e81b4de181: tests: do not set bogus scale sws_flags option in the scalenorm test [17:34] <Compn> ohsix / divVerent : so the reason for small res is dvd subs ? [17:34] <Compn> but still 16x16 is way too small for a line of subtitles [17:35] <Compn> 14pt font barely fits ... ::) [17:35] <ohsix> a period at a 14pt font is still going to be pretty narrow [17:36] <Compn> yes, one period [17:36] <nevcairiel> considering dvd subs can only have a singel rect active at a time, thats not much of a subtitle [17:37] <ohsix> if it's a valid thing to do, even if it's silly or exceedingly rare you still have to do it :p [17:37] <Compn> yeah [17:37] <Compn> but the answer may be 'use imagemagick' :P [17:37] <ohsix> there are probably empty subpictures with random sizes too, nevermind text [17:38] <Compn> at least we finally got a use case :P [17:38] <ohsix> not that you need one to make something work, for new features, sure [17:39] <Compn> ohsix : use case is good for prioritizing bugs/features tho [17:39] <Compn> if the use case is some stupid crap, it can be safely ignored ;) [17:39] <Compn> but converting subtitles has a slightly more important priority :p [17:40] <ohsix> but you organize the things they represent, things you can do or not do; heh [17:40] <ohsix> technically you're already doing it, just not in a way that works [17:40] <Compn> like i said, most codecs didnt support that resolution [17:41] <Compn> image compressors do :) [17:41] <Compn> so i prioritized codec support over image support [17:41] <Compn> but this was in my head , i dont mark bugs as unimportant or anything [17:42] <Compn> also most people are working with hd content now [17:42] <Compn> so its not good idea to slow swscale for small res, when hd content needs all the optimization it can get [17:43] <Compn> of course, allowing the user to slow it down for corner cases is always a good idea [17:43] <Compn> maybe some day we'll get to argue about a different bug :) [18:08] <kierank> there are some impressively trollish bug reports [18:17] <durandal_1707> kierank: for example? [18:18] <kierank> the one about swscale and widths < 8 [18:20] <michaelni> saste, you broke fate [18:28] <cone-199> ffmpeg.git 03Michael Niedermayer 07d41c019da041: fate/scalenorm: unbreak fate [18:29] <michaelni> saste, fixed [18:32] <saste> michaelni, I tested before pushing, how was it broken? [18:32] <saste> also aren't sws_flags in the filtergraph enough? [18:33] <michaelni> i guess its only used for auto inserted filters [18:33] <michaelni> maybe this should be changed if its the case [18:33] <michaelni> it definitly failed straight here without anything special [18:35] <michaelni> saste, checksum before i fixed it: +scalenorm 556560ff83e9c884fbd28a006520ae18 [19:19] <saste> michealni: http://fate.ffmpeg.org/report.cgi?time=20121028133215&slot=x86_32-ubuntu-mingw32-gcc [19:19] <saste> still borken, possibly due to some sscanf trouble [19:22] <saste> please review my scale patch so we finally have sane parsing [19:25] <michaelni> saste, that look at the revission that box tested, this is 6h ago [19:25] <michaelni> that predates fixes [19:26] <saste> it should not change with the current test, though, since it is a parsing problem [19:26] <saste> i'm reading the spec, trying to understand where the bug is [19:27] <saste> but i'd bet that Mingw/Windows is wrong even in this case [19:30] <saste> michaelni, anyway scale=::flags=+foo-bar is wrong/undefined anyway, according to the current docs [19:30] <michaelni> saste, your patch still breaks plain make fate [19:30] <durandal_1707> what docs ? [19:31] <saste> michaelni, that's because for a reason or another the code affecting that patch changes every few hours [19:33] <saste> michaelni, i tested against my fix, but I don't mind to fix fate, i'm just waiting for a design review [19:33] <saste> durandal_1707, scale filter docs [19:33] <saste> as usual there are many overlapping bugs here [19:34] <saste> our docs underspecifies what to do with scale=::flags=foobar [19:34] <durandal_1707> and what code do? [19:34] <saste> the correct interpretation would be set first and second params to "" (void string) [19:35] <saste> but our parsing is not robust enough, and just ignore the string and leave the default values [19:36] <saste> mingw sscanf is different, so that it sets the values (following the most "natural" interpretation), and cause a parsing failure [19:36] <saste> in other words mingw parsing is correct, but for the wrong reason [19:37] <michaelni> saste is that patch available in some public git repo where one can check it out and test it ? [19:37] <nevcairiel> C string parsing is just such a headache to begin with =p [19:37] <michaelni> i mean if it breaks when being rebased ... [19:40] <saste> michaelni, no just locally [19:40] <saste> i'm going to rebase and resend the patch in a moment [19:40] <michaelni> saste, this patch really eats too much of my time this way [19:40] <michaelni> every time i test it its broken in some way [19:43] <saste> michaelni, it's wasting my time as well, that's why i want to get rid of it [19:43] Action: michaelni is happy that we agree [19:44] <michaelni> ill try to review it, but i want to test it before its applied [19:45] <michaelni> and i would prefer if i could checkout a version that works from your git repo instead of getting the timing right on applying a patch [20:42] <cone-199> ffmpeg.git 03Clément BSsch 073d6a246b4b92: lavf/srtenc: add AVFMT_TS_NONSTRICT flag. [21:37] <cone-199> ffmpeg.git 03Paul B Mahol 07c2e2b3029e7f: cafdec: fix parsing of chunks which may have unused data [22:06] <j-b> durandal_1707: I fear I do not understand the quesiton [22:14] <durandal_1707> j-b: what question? [22:14] <j-b> 16:23 #ffmpeg-devel: <@durandal_1707> j-b: VLC does not support wav tags? [22:14] <durandal_1707> j-b: wav tags - INFO riff chunk [22:15] <j-b> We do, partly, I think. Why? [22:16] <durandal_1707> no reason [22:16] <j-b> If you mean Metadata, mainly in 2.1 [22:40] <Compn> durandal_1707 : you going to add all of the twocc from wiki list ? :) [22:43] <durandal_1707> Compn: that is just not possible: I need files and program which produce such files - i'm not wasting time on dead stuff, dead stuff should rip [22:44] <Compn> ehe [22:44] <Compn> too bad vlc doesnt save samples :P [22:55] <durandal_1707> michaelni: one of the the asf demuxer bugs is that it puts multiple frames in single packet [23:14] <saste> michaelni, what about scale=s=qcif? [23:14] <saste> scale=qcif => this would break syntax [23:15] <saste> anyway i'll test again the patch and apply [23:18] <michaelni> scale=s=qcif does not make michaelni happy ... he wants scale=qcif ;) [23:19] <michaelni> and our users will not understand the "s=" in there either [23:20] <ubitux> we can do just like *movie [23:20] <ubitux> movie=xxx:extra_avopts [23:21] <ubitux> or movie=f=xxx:... [23:21] <ubitux> but without breaking the current syntax... [23:22] <Daemon404> http://pastebin.com/3HFFChQh [23:22] <Daemon404> this look familiar to anybody here too? [23:23] <saste> ubitux, no way without breaking the current syntax [23:24] <saste> scale=size=qcif is an alternative [23:25] <saste> or a new filter with the same code but with an alternative syntax, but seems overkill [23:26] <michaelni> saste, scale=qcif fails currently so the syntax "slot" is unused and can be used for qcif [23:27] <saste> michaleni: with the new syntax we switch to the shorthand system [23:28] <saste> so the first options if the keys are not specified specify the so called "shorthand" options [23:28] <saste> so the syntax is: scale=w:h:... [23:28] <saste> thus scale=qcif will be the equivalent of scale=w=qcif [23:28] <saste> which doesn't make much sense [23:29] <michaelni> you can add support for w=qcif then or if(!strncmp("qcif") ... [23:29] <michaelni> or improve the shorthand system [23:29] <saste> unless we add a new rule of the kind: if you fail to parse the expression, read it like the w/h of a size [23:29] <saste> but i'm not sure i like it [23:30] <saste> the more clever the adopted rules are, the most brittle they are [23:30] <saste> to me scale=s=qcif looks good enoug, and is just two characters more [23:31] <saste> in a future version of scale you could do: scale=qcif (where size is the first option), but in that case then you have to do: scale=w=...:h=... [23:32] <michaelni> saste, do you volunteer to take over vf_scale maintaince ? [23:32] <michaelni> i will not continue doing it if this contzinues [23:32] <michaelni> its just madness [23:33] <saste> michaelni, i'm not the most qualified with libswscale [23:33] <saste> what madness you talk about? [23:33] <michaelni> scale=qcif is clear so is scale=123:345 not supporting one while pointing to a rigidly defined shorthand nonsense is madness [23:34] <michaelni> what is the whole new system good for anyway if you cant do anything like this in it ? [23:34] <saste> what is good for? [23:35] <saste> consistent parsing, no more ad-hoc parsing [23:35] <saste> introversion and extroversion throuhg the avoptions system (check ffmpeg -h full to see filter options) [23:35] <saste> and yes the trick scale=qcif can be done, although is not very robust [23:35] <michaelni> the ad hoc works, and its a 1 line addiition to get it to handle "scale=qcif and such" [23:37] <michaelni> the biggest problem avfilter has is its insane user interface and this is a step in the wrong direction [23:37] <saste> "the biggest problem", i won't say that [23:38] <michaelni> ok, so lets call it a "big problem" [23:38] <saste> that syntax was not really designed to embed arbitrary strings [23:38] <saste> it was adopted after mpcodecs, which has no filters with the same complexity of, say drawtext [23:39] <saste> having a consistent syntax and parsing engine helps [23:39] <saste> it helps at least me, since I suck (as most everyone else) at remembering and reading positional parameters [23:39] <michaelni> also about introspection and all that, the option list is in swscale and vf_scale duplicate it after the patch and needs a update for each addition to sws [23:40] <saste> yes, but how many times that happens in a year? [23:40] <michaelni> not often [23:40] <saste> there is just one option, i'm not saying that it shouldn't be fixed, but that i plan to do that later [23:40] <michaelni> but how many are still missing after all the years ? [23:41] <michaelni> btw why can shorthand not handle 1param = size, 2 param=w:h ? [23:42] <michaelni> such support would fix the qcif / w:h issue at least and might be usefull for other filters too [23:43] <saste> so you want a map of the kind [23:43] <saste> for one param: size [23:43] <saste> for two params: w, h [23:43] <saste> for three params: w, h, flags [23:43] <saste> seems overly complex [23:43] <michaelni> well, after 5 seconds thinking about it yes ... [23:45] <michaelni> a simple if(!strcmp()) still fixes the issues nicely, whats do you have against that ? [23:46] <michaelni> a simple loop with a table of standard names and sizes ? [23:46] <saste> if (!strcmp(qcif) || !strcmp(cif) || !strcmp(vga) || !...) [23:46] <saste> names and sizes are not exposed externally [23:46] <saste> the only interface is av_parse_video_size [23:47] <saste> but right let's add the ad-hoc rule [23:48] <saste> if can be parsed as a size and av_parse_video_size() then read it as a size [23:48] <saste> that would be acceptable [23:49] <michaelni> ok, fine with me too [23:49] <saste> but it fails if you want to do: scale=qcif:flags=... [23:50] <michaelni> why would that fail ? [23:52] <saste> what about: read string until ":", parse as a size, if you fail then parse the usual way, otherwise set the size and read the rest of the args like an option list [23:53] <michaelni> possible but theres a problem i think [23:53] <michaelni> av_parse_video_size() is too fuzzy it will success of 123+456 i think [23:54] <michaelni> succeed on [23:55] <saste> indeed... [23:58] <michaelni> factorizing a av_parse_video_abbr() out of av_parse_video_size() seems the cleanest solution [23:58] <michaelni> and making sure that returns some information about how far it parsed so it can be matched against ':' [00:00] --- Mon Oct 29 2012