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

[burek]

[00:00] <cone-409> ffmpeg.git 03Derek Buitenhuis 07master:d48f22195203: cllc: Implement YUV support
[00:00] <cone-409> ffmpeg.git 03Derek Buitenhuis 07master:61c82214afac: cllc: Use outbuf in RGB and ARGB functions
[00:14] <cone-409> ffmpeg.git 03Matthew Heaney 07master:bc35df29c123: lavf: add AV_DISPOSITION flags for WebVTT text track kinds
[00:14] <cone-409> ffmpeg.git 03Matthew Heaney 07master:1029822a91c2: lavf/webvttdec: use private option to specify WebVTT kind
[00:21] <wm4> so can ffmpeg mux webvtt into webm yet?
[00:21] <ubitux> not yet
[00:21] <ubitux> there is a patch, matthewjheaney_ needs to rebase and maybe rework it i don't remember
[00:22] <ubitux> then someone needs to make a translation of the chaptering in webm through webm
[00:22] <ubitux> that's gonna get funny...
[00:22] <Daemon404> doesnt everyone use mkvmerge to make webm anyway?
[00:22] Action: Daemon404 runs
[00:23] <wm4> ubitux: chaptering?
[00:24] <ubitux> yeah well you know there is chapters in mkv
[00:24] <ubitux> in webm it seems to use... a webvtt thing
[00:24] <ubitux> but maybe i misunderstood something
[00:24] <Daemon404> eh?
[00:24] <Daemon404> why not just use matroska chapters
[00:24] <Daemon404> other than idiocy
[00:24] <ubitux> don't take my word on this
[00:25] <ubitux> but the patch above are all about a "kind" of webvtt
[00:25] <Daemon404> they all sounds horribly scary to me
[00:27] <beastd> Wasn't part of the WebVTT idea to *not* mux the subtitles (erm captions they say) into the file but have them as separate files on the webserver. Not that I would really understand that because subtitles are usually the smaller problem in size compared to everything else in a movie file...
[00:28] <Daemon404> beastd, thats what we plan to do
[00:28] <Daemon404> since we plan to use webvtt with h264/mp4
[00:28] <ubitux> honestly, having them muxed is a good thing
[00:28] <ubitux> Daemon404: wat
[00:28] <Daemon404> html5 -> h264
[00:28] <Daemon404> nobody gives a shit abou vp8
[00:28] <ubitux> soon vp9
[00:29] <Daemon404> indeed
[00:29] <ubitux> and you're gonna help for that in august afaiu
[00:29] <Daemon404> im not helping cause i think vp9 will go anywhere
[00:29] <Daemon404> i helping out of interest
[00:29] <Daemon404> :P
[00:29] <ubitux> also webvtt into mp4 ’ update your flashplayers, hf
[00:29] <Daemon404> that doesnt allow users to easily change captions.
[00:29] <Daemon404> its worse in every conceivable wa
[00:29] <Daemon404> y
[00:30] <Daemon404> not to mention mp4 doesnt officially support webvtt.
[00:30] <Daemon404> (iirc)
[00:31] <ubitux> of course it doesn't :P
[00:40] <kierank> Daemon404: it will soon
[00:40] <kierank> mpeg is standardising it
[00:40] <Daemon404> oci
[00:40] <Daemon404> er
[00:40] <Daemon404> oic
[00:40] <Daemon404> doesnt make it any less insane (dat inline css)
[00:40] <wm4> Daemon404: put webvtt in movtext lol
[00:40] <wm4> this webm thing seems to turn into some "how to make matroska even worse" thing
[00:42] <ubitux> Daemon404: up-rounded shift
[00:42] <Daemon404> ubitux, the negative int trick is a bit confusing
[00:43] <Daemon404> if you havent seen it before
[00:43] <ubitux> it's doxy commented in the pix desc
[00:43] <Daemon404> well thats in pix desc :P
[00:43] <Daemon404> not BB's patch
[00:43] <Daemon404> BBB*
[00:43] <ubitux> it's all over the code base as FF_CEIL_RSHIFT() now
[00:43] <Daemon404> yeah but its commented by FF_CEIL_RSHIFT
[00:44] <Daemon404> where it should be, no?
[00:44] <ubitux> that's why i suggested the macro
[00:44] <Daemon404> yeah
[00:44] <Daemon404> im agreeing with you here man.
[00:44] <ubitux> i like to argue with the agreeing
[00:44] <ubitux> it doesn't sound good otherwise
[00:44] <Daemon404> lol
[00:45] <BBB-work_> omg macros
[00:45] <BBB-work_> I recall someone recently trying to add a macro to libvpx to test whether a number is odd or not
[00:46] <BBB-work_> you guys want to update the patch for me, or you need me to spoonfeed it?
[00:46] <Daemon404> i can update and push
[00:46] <BBB-work_> ty
[00:46] <Daemon404> if ubitux or w/e is ok w/ it
[00:46] <wm4> <Daemon404> ubitux, the negative int trick is a bit confusing <- isn't that undefined behavior in C?
[00:47] <Daemon404> shifting a negative?
[00:47] <BBB-work_> no, it's perfectly well-defined
[00:47] <BBB-work_> (right-shifting)
[00:47] <BBB-work_> I think left-shifting could be an issue, although sufficiently many people use it that no compiler would ever want to break it in practice
[00:47] <ubitux> Daemon404: assuming that change, i have no other comment on the patch, i don't know if that's correct or not
[00:48] <Daemon404> maybe michaelni can say.
[00:48] <wm4> huh, so right-shifting a negative is well defined
[00:48] <kierank> BBB-work_: it surprises me how many people don't know what x&1 does
[00:48] <kierank> it's probably the first ever idiom you learn
[00:48] <ubitux> haha
[00:49] <wm4> the C standard reads: "If E1 has a signed type and a negative value, the resulting value is implementation-defined."
[00:49] <wm4> so it's not exactly undefined
[00:49] <ubitux> < BBB-work_> omg macros // you don't like FF_CEIL_RSHIFT()? :(
[00:49] <wm4> but still platform dependent
[00:53] <durandal11707> convert all macros to inline functions?
[00:55] <BBB-work_> ubitux, for me, it falls in the category of #define INCREMENT(x) x++
[00:56] <Daemon404> BBB-work_, i wholeheartedly disagree
[00:56] <BBB-work_> ubitux, but that's just a personal opinion, it's fine if you guys like it more
[00:56] <Daemon404> it's a non-straightforward thing
[00:56] <Daemon404> which is used in many places
[00:56] <BBB-work_> it's fine, I don't mind
[00:56] <BBB-work_> I wouldn't do it myself, as you can see, but I can live with it
[00:58] <beastd> i think macros are overused in ffmpeg. for that particalur example i think it is OK though.
[00:58] <BBB-work_> kierank: I can say nothing more but just "eek"
[01:00] <Daemon404> dude
[01:00] <Daemon404> the vast majority of programmers dotn even know the difference between the stack and heap
[01:01] <Daemon404> if we're gonna go dont the incompetence road... ;)
[01:01] <BBB-work_> the vast majority of programmers dont code in c :)
[01:02] <Daemon404> i havent been coding much C myself lately
[01:02] <Daemon404> a lot of Go
[01:02] <Daemon404> hurr durr
[01:03] <ubitux> BBB-work_: this macro has multiple purpose; biggest one being that it documents what this bithack does, second one is that it allows a fast path in some cases (and another one might be to make a new version of that bithack if the neg shift appears to be badly supported)
[01:04] <j-b> The amount of stupidity this WebVTT thing is, is beyond anything else...
[01:05] <ubitux> haters gonna hate
[01:05] <Daemon404> j-b, i agree
[01:07] <BBB-work_> ubitux, sure, I'm fine with it, will you guys update my patch for me ? :) y4m is still broken for odd yuv sizes
[01:07] <ubitux> i thought Daemon404 was doing it
[01:07] <Daemon404> well i can update it
[01:07] <ubitux> but it seems he's busy messing the libav tree right now
[01:08] <Daemon404> shhhhhhhhhhh
[01:08] <Daemon404> leave my fuckups alone
[01:08] <Daemon404> :(
[01:08] <ubitux> ;)
[01:08] <BBB-work_> should I go check what he did this time?
[01:08] <BBB-work_> this can only be fun
[01:08] <Daemon404> BBB-work_, i pushed a fate test patch too early
[01:08] <Daemon404> by accident
[01:08] <j-b> ubitux: you can justify that 4 different tracks type?
[01:09] <ubitux> j-b: nope
[01:09] <ubitux> i'm mostly concerned about the way it's muxed in webm right now
[01:09] <ubitux> like "let's use \n as a binary field separator"
[01:13] <wm4> uh what
[01:13] <beastd> good night...
[01:14] <ubitux> wm4: each "cue" in webvtt can contains an identifier, timestamps, settings, and payload
[01:14] <ubitux> in a standalone .vtt, it's like that:
[01:14] <ubitux> identifier
[01:14] <ubitux> timestamp - settings on same line
[01:14] <ubitux> payload
[01:14] <ubitux> so basically you have AVPacket with a payload and classing timestamp in pts
[01:14] <ubitux> and 2 side data for identifier and settings
[01:15] <ubitux> but in webm, it muxed like this: identifier\nsettings\npayload
[01:15] <wm4> so why is that stuff in side data and not the packet itself?
[01:15] <ubitux> so basically it's reconstructing a strange string like thing
[01:15] <ubitux> wm4: it doesn't really belong in the payload
[01:16] <ubitux> having identifier\0settings\0payload or something like that would make more sense in webm IMO
[01:16] <Daemon404> BBB-work_, new patch sent then
[01:16] <BBB-work_> \o/
[01:17] <ubitux> wm4: assuming a muxer is muxing webvtt differently (like using an appropriate fields placement for identifier or settings), this weird string representation doesn't make much sense
[01:17] <wm4> I don't understand why it can't be in the payload
[01:17] <ubitux> we could have use it from the beginning for packets going out of WebVTT demuxer, but how could we guess webm was going to mux it as such
[01:18] <ubitux> well, we could do it, but that's not that intuitive; you might have sometimes payload with 2 \n or stuff like that
[01:18] <wm4> and...
[01:18] <ubitux> the payload is supposed to contains the text, the other things are extra
[01:19] <ubitux> you don't know how that info is going to be muxed in different containers
[01:19] <wm4> ASS also has additional things in the payload
[01:19] <ubitux> basically .vtt and .webm mux them differently
[01:20] <ubitux> wm4: i couldn't have guess that the formats of the packets should be as such when i added the demuxer
[01:20] <ubitux> it also makes the muxers need to split those string again
[01:20] <ubitux> which is counter productive
[01:20] <ubitux> (and would introduce a behaviour break btw)
[01:23] <BBB-work_> ubitux, can you ok and push derek's patch, given you're the CEIL_RSHIFT expert?
[01:23] <BBB-work_> you seem like the ultimate dude to review that patch
[01:23] Action: ubitux ceil rshift expert yay
[01:24] <BBB-work_> better watch out, before you know it you're the threading expert :)
[01:24] <wm4> I just find it strange how matroska did without side data all the time, and now it suddenly requires many side data types
[01:24] <BBB-work_> oh right I was going to write a blog post about that
[01:24] <Daemon404> there
[01:24] <Daemon404> michael ok'd it
[01:24] <Daemon404> ill push it bbb
[01:25] <BBB-work_> \o/
[01:25] <BBB-work_> ty guys
[01:25] <Daemon404> running FATE first
[01:26] <Daemon404> (do we even have y4m tests?)
[01:26] <ubitux> wm4: bitstream filters, ugly string hacks (remembers srt?), ... ?
[01:26] <BBB-work_> they probably don't use odd frame sizes :(
[01:26] <ubitux> we don't have 'nuff odd size tests
[01:26] <BBB-work_> that's b/c many media formats don't support odd frame sizes
[01:27] <ubitux> especially with some cool pixfmt where chroma shift mismatches
[01:27] <BBB-work_> e.g. h264 :)
[01:27] <Daemon404> BBB-work_, even 4:4:4?
[01:27] <BBB-work_> true
[01:27] <Daemon404> or its faux RGB
[01:27] <BBB-work_> heh :)
[01:27] <BBB-work_> I meant 420 obviously, but yes you're right
[01:27] <Daemon404> ;P
[01:27] <cone-409> ffmpeg.git 03Ronald S. Bultje 07master:cea8a0077fc5: yuv4mpeg: correctly handle chroma for odd luma sizes.
[02:40] <wm4> durandal11707: would this an acceptable patch? http://sprunge.us/MTIV
[03:27] <durandal11707> wm4: it works?
[03:27] <wm4> yes
[03:28] <wm4> of course it requires the application to go out of its way to use it
[03:28] <durandal11707> how?
[03:28] <wm4> it first has to enable icy by setting the option
[03:29] <wm4> then it has to read icy_meta_header and icy_meta_packet per option API
[03:29] <wm4> for icy_meta_packet it has to poll frequently
[03:29] <wm4> to see whether it has been updated
[03:31] <durandal11707> hmm, send it to ml, i really don't have opinion on this
[03:32] <wm4> ok will do so tomorrow or so
[10:11] <j-b> BBB: BBB-work_: I am in SF starting today.
[11:10] <michaelni> git.videolan.org is down
[11:14] <michaelni> until videolan is up again my work is at: https://github.com/michaelni/FFmpeg.git/
[11:15] <michaelni> feel free to send me pull requests as usual
[11:15] <michaelni> ill merge / push it all to videolan once that is up again
[13:03] <JT-EC> Is --disable-swscale supposed to work and when it does should an ffmpeg binary be produced or does the actual ffmpeg binary depend on swscale so doesn't build without it?
[13:09] <nevcairiel> i think it depends on it
[16:05] <superware> I have a H.264 TS over UDP, "vlc.exe udp://@:1234" works while "ffplay udp://127.0.0.1:1234" shows nothing but lots of errors such as "fPES packet size mismatch" etc, any ideas?
[16:13] <kierank> probably a slightly out of spec ts
[16:17] <av500> superware: have a sample?
[16:19] <superware> +av500: will be difficult. should ffplay show a h264-ts-udp stream?
[16:19] <av500> probably
[16:20] <superware> because VLC's syntax that works is udp://@:1234 but ffplay doesn't
[16:20] <superware> VLC doesn't work with udp://127.0.0.1:1234 ...
[16:21] <superware> maybe I'm missing ffplay's syntax for VLC's udp://@:1234
[16:21] <av500> it works
[16:21] <av500> you are getting the stream
[16:22] <av500> otherwise you would see no " "fPES packet size mismatch" errors
[16:22] <superware> you have a point there
[16:23] <superware> I can show you the log, ok?
[16:23] <superware> it's all errors, it deosn't seem it recognizes anything
[16:24] <av500> log is no help
[16:24] <av500> captured stream would be help
[16:24] <superware> is it possible with ffmpeg.exe?
[16:24] <superware> to capture..
[16:27] <superware> +av500: can I send you the .ts file?
[16:28] <superware> +av500: ffplay can play the .ts ... wtf?
[16:30] <superware> +av500: please..
[16:31] <ubitux> superware: http://ffmpeg.org/bugreports.html
[16:32] <ubitux> in the case of PAL8, sws needs palette in data[1], right? what about linesize[1]? is 0 fine?
[16:32] <superware> ubitux: the raw TS data is playing with ffplay, but when I try directly from UDP it doesn't.
[16:33] <ubitux> then debug it, or report a bug
[16:36] <superware> say, for VLC the url that works is udp://@:1234 but udp://127.0.0.1:1234 doesn't. which is the correct one for ffplay?
[17:55] Action: michaelni stares at cone
[17:55] <michaelni> where is cone ?
[17:59] <JuxTApose> Can anyone link me to some source code that efficiently handles video playback caching at the frame level from the ffmpeg linked libraries? thanks
[18:00] <JuxTApose> i am working on a side effect in blender's video game engine video texture playback file...
[18:01] <JuxTApose> it's linking to ffmpeg and looping in seconds not frames so a seamless animation does not loop properly
[18:01] <JuxTApose> the offending line looks like #768 in http://www.letworyinteractive.com/blendercode/d1/d9a/VideoFFmpeg_8cpp_source.html
[18:01] <JuxTApose> it looks like it tests seconds instead of frames so the last few frames are skipped making the animation loop not seamless...
[18:02] <JuxTApose> this is not noticeable in loops that are not seamless
[18:04] <michaelni> JuxTApose, ffplay has fifos between the threads if thats what you are searching for
[18:05] <JuxTApose> michaelni: ya, that is just where I started looking...
[18:05] <JuxTApose> it looks promising...
[19:20] <BBB-work_> j-b, cool!
[20:20] <llogan> what OS are missing from FATE currently that we may want?
[20:56] <llogan> 93 comments. is that the record?
[21:00] <durandal_1707> michaelni: please don't merge pcm stuff from fork
[21:15] <michaelni> llogan, we want all from https://en.wikipedia.org/wiki/List_of_operating_systems on which ffmpeg could be build & run
[21:18] <michaelni> or said difefrently "all os" that can be supported and arent yet on fate and that have a vulunteer willing to setup fate
[21:18] <Daemon404> plan9.
[21:19] <Daemon404> mru ported lbav to plan9, and its in platform.html
[21:19] <Daemon404> i dont think anyone tried ffmpeg.
[21:19] <Daemon404> and there is no FATE iirc
[21:19] <Daemon404> for either
[21:19] <Daemon404> http://ffmpeg.org/platform.html#Plan-9
[21:35] <superware> this http://pastebin.com/bFUvBwHU is what I get when trying to ffplay an h.264-ts-udp stream, which actually plays nicely in VLC (udp://@:1234), any ideas?
[21:42] <saste_> how are we supposed to handle the case when the av_log buffer is too short?
[21:47] <superware> saste_: mine is short? :)
[22:05] <Daemon404> https://vimeo.com/69111871
[22:10] <ubitux> write a batch script!
[22:12] <Daemon404> lol
[22:12] <Daemon404> i assume you saw the emails i get ubitux 
[22:12] <Daemon404> the very useless vague ones
[22:12] <ubitux> yes
[22:13] <ubitux> the print in cmd.exe is particularly fast haha
[22:13] <Daemon404> you mean the end of the configure?
[22:13] <Daemon404> its actually instantanious
[22:13] <Daemon404> but virtudub slowed it down whe ncapturing
[22:13] <ubitux> ok
[22:14] <Daemon404> im still bothered by how bad the chroma subsampling went
[22:14] <Daemon404> libutvideo's yv12 subsample algo is so bad
[22:19] <durandal_1707> thats why assembly optimizations are still missing in native version
[22:21] <Daemon404> durandal_1707, ?
[22:21] <Daemon404> for what?
[22:22] <durandal_1707> i read from time to time on doom9 how native utvideo is slow
[22:22] <Daemon404> oh
[22:22] <Daemon404> native utvideo (upstream) has ASM
[22:22] <Daemon404> but it also has its own color conversion algos
[22:23] <Daemon404> which are terrible.
[22:23] <Daemon404> all of its asm is for huffman and stuff
[22:23] <durandal_1707> libavcodec/utvideoenc.c ?
[22:24] <Daemon404> yeah but i captured using virtualdub
[22:24] <Daemon404> which needs VFW codecs
[22:24] <Daemon404> bascially, i should have just captured in RGB.
[22:25] <JEEB> that's the nr1 rule in screen capture
[22:25] <JEEB> if you're going to do it, do it in RGB
[22:25] <Daemon404> yeah
[22:25] <JEEB> you can then proceed to raping it in any way you want
[22:25] <durandal_1707> what a mortal sin, using virtualdub for capturing....
[22:25] <Daemon404> actually
[22:25] <Daemon404> it has the best capture code of anything
[22:26] <Daemon404> http://www.virtualdub.org/blog/pivot/entry.php?id=356 <--
[22:26] <Daemon404> dxgi is great
[22:50] <superware> I have an h264-ts-udp stream being played by VLC --demux ffmpeg udp://@:1234 but not by ffplay udp://127.0.0.1:1234 (log at http://pastebin.com/4navfRNM)
[23:11] <saste_> #define AVERROR_EXPERIMENTAL       (-0x2bb2afa8) ///< Requested feature is flagged experimental. Set strict_std_compliance if you really want to use it.
[23:11] <saste_> this is soo libav: it is experimental, ergo is an error
[23:13] <Daemon404> saste_, its used for -strict
[23:13] <Daemon404> and yes that SHOULD error unelss explicitly told "i want broken things
[23:13] <Daemon404> "
[23:14] <wm4> it's always nice if libavcodec tells users to use certain flags, even though the host application has completely different command line options
[23:16] <saste_> an error code which tells the user to use a flag... not so a good idea
[23:16] <saste_> especially if you have no idea where you are supposed to set that option
[23:16] <Daemon404> sorry, it should not allow use of shit like the vorbis or aac encoders by default
[23:16] <Daemon404> that just asking for trouble
[23:17] <wm4>                "The %s '%s' is experimental but experimental codecs are not enabled, "
[23:17] <wm4>                "add '-strict %d' if you want to use it.\n",
[23:17] <wm4> ^this message
[23:17] <saste_> Experimental feature => since when an experimental feature should be considered like an error?
[23:17] <saste_> it is because of bullshit like this that user interfaces and feedback tend to be shitty
[23:17] <Daemon404> i cant tell if youre arguing semantics, or if you really truly think we should allow users to use it without issue
[23:18] <saste_> (not to mention the most silly option name ever: -strict)
[23:18] <Daemon404> the interface and message are silly, the concept is correct
[23:18] <Daemon404> personally i dont even think we should enable or include such broken garbage
[23:18] <Daemon404> but hey. you guys want it.
[23:19] <wm4> Daemon404: I agree
[23:19] <wm4> and this should be done for bad quality encoders as well
[23:19] <wm4> even if they're stable
[23:19] <Daemon404> there already under experimental
[23:19] <Daemon404> because theyre so shitty
[23:19] <wm4> and while we're talking about default settings
[23:19] <wm4> I think ffmpeg.c by default still produces really... bad results
[23:20] <Daemon404> low quant terrible mpeg4? :)
[23:20] <Daemon404> yeah i dont know why.
[23:20] <Daemon404> er
[23:20] <Daemon404> high quant.
[23:22] <Daemon404> http://xiphmont.livejournal.com/51160.html
[23:22] <Daemon404> there it is.
[23:22] <Daemon404> i knew monty wrote something on it.
[23:22] <wm4> ow
[23:23] <wm4> so... just why does ffmpeg's build system not detect dependencies by default
[23:23] <Daemon404> actually i kind of like that
[23:23] <Daemon404> auto-enablign deps wa the bane of my existence
[23:23] <wm4> this is impractical enough that I consider to write a script on top of ffmpeg to detect and enable these automatically
[23:23] <Daemon404> its actually a terrible idea IMHO
[23:24] <wm4> every other build system in existence does it
[23:24] <Daemon404> and it has cause no shortages of MASSIVE headaches
[23:24] <Daemon404> for distro and package maintainers
[23:24] <Daemon404> when i did stuff for #oe it wa te problem 99% of the time
[23:24] <Daemon404> for parallel build issues
[23:25] <Daemon404> nondeterinistic behavior depending on when optional autodetected/enabeld deps are buily
[23:25] <Daemon404> built*
[23:26] <saste_> Daemon404, i'd like to be able to set policy like configure --set-enable-policy=auto
[23:26] <Daemon404> saste_, that seems reasonable
[23:26] <wm4> yes, even so, it would be nice if autodetection could be enabled
[23:26] <Daemon404> but should not be default
[23:27] Action: Daemon404 enables x64 ICL FATE for ffmpeg
[23:43] <superware> how should I ffplay a h264-ts-udp stream?
[00:00] --- Wed Jun 26 2013