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

[burek]

[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=529a7a1af65af87e4655497fe123a0e3f5dbe734
[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