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

[burek]

[00:07] <pettter> Compn: no, the transcoding is supposed to happen serverside
[00:07] <bcoudurier> Skyler_, if any work is needed, definitely :)
[00:07] <pettter> XBMC on the Pi is simply a client (in theory)
[00:07] <Skyler_> I'll poke you if they need more stuff done
[00:07] <bcoudurier> grazie mille
[00:07] <Skyler_> in the meantime I said "ffmpeg already does that" XD
[00:15] <cone-902> ffmpeg.git 03Carl Eugen Hoyos 07master:5ce023b790e5: Fix color filter example.
[00:29] <gnafu> I know I have been loving OpenELEC on my Pi, though I have mostly been using it for online content that is already H.264 and viewing live TV from a MythTV backend on another machine (and viewing the raw MPEG-2 streams; I did pay for the decoder license).
[00:29] <gnafu> Still the cheapest solution to accomplish what I wanted, so...
[00:31] <Compn> pettter : then why dont you want to install xbmc on the server side? lol
[00:38] <gnafu> Compn: Might want something headless.  Can XBMC perform those functions without its GUI?  (I don't really know, but it seems like it wouldn't.)
[00:38] <Compn> is html gui , headless ?
[00:39] <Compn> if you're watching films, you should have a head, somewhere :P
[00:39] <gnafu> You have a point.  I don't know if you can install, configure, run, and maintain XBMC without running its main interface, and he might want to avoid that.  I know I didn't like having to run GUI setup applications to get MythTV up and running :-P.
[00:40] <Compn> bah got me there
[00:40] <Compn> installs are hard to do without a head :P
[00:40] <Compn> course, what server comes autoconfigured?
[00:40] <Compn> not ssh, http, ftp, irc, nfs, samba etc...
[00:40] <gnafu> I had to wait until I got home from work to set it up, because running mythtv-setup with ssh -CX was painfully slow and not as inconspicuous as just a terminal with vi.
[00:41] <gnafu> I like installing packages with sane default configurations, and then editing config files to suit my needs :-D.
[00:41] <Compn> an html installer would be awesome
[00:41] <Compn> for many programs
[00:41] <gnafu> That's what I did with things like httpd, munin, and almost everything else running at home.
[00:41] <gnafu> That is very true.
[00:41] <Compn> maybe that would be useful, create some kind of html wrapper to x11/gnome 
[00:42] <Compn> so they render with html instead of window effects
[00:42] <Compn> or maybe just a remote install option 
[00:42] <gnafu> Ooh, and name it something flashy, like /Broadway/.
[00:43] <gnafu> ;D
[00:43] <Compn> broadway 2.0
[00:43] <gnafu> I agree with you, though.  And hopefully things like GTK+'s Broadway backend will enable it.
[00:46] <saste> [video4linux2,v4l2 @ 0x7fb5200042d0] Cannot find a proper format for codec_id 0, pix_fmt -1.
[00:47] <saste> ^^ why it is not auto-selecting the format (like before)?
[00:47] <wm4> did elenril break it? or the merge?
[00:48] <saste> wm4, dunno, hard to say without bisecting
[00:48] <saste> it was since some time i wasn't using it, may be a local problem
[00:48] <saste> but the command ffplay -f video4linux2 /dev/video0 usually was working fine
[00:48] <cehoyos> saste: ffmpeg -f v4l2 -i /dev/video1 works fine here
[00:49] <cehoyos> Same with ffplay
[00:49] <saste> cehoyos, uh carl?
[00:49] <cehoyos> Yes
[00:50] <saste> you're not usually on irc
[00:50] <saste> maybe it's the first time i see you here
[00:50] <cehoyos> So should I go?
[00:50] <cbsrobot> wut just hapend
[00:50] <cbsrobot> am I dreaming ?
[00:50] <saste> cehoyos, you're welcome ;-)
[00:50] <saste> and we lost ubitux since a few days
[00:51] <cbsrobot> no ubitux was here a few hours ago
[00:51] <saste> good, so he's still alive :)
[00:51] <cbsrobot> hi carl
[00:52] <cehoyos> Hi
[01:06] <michaelni> Daemon404, Is the latest "[PATCH] Fix compilation with libutvideo version 12.0.0" patch ok ?
[01:10] <Daemon404> the latest one seemed fine
[01:15] <cone-902> ffmpeg.git 03Stephen Hutchinson 07master:df4203ac6f00: Fix compilation with libutvideo version 12.0.0
[02:52] <Compn> oooooooo carl was online
[02:52] <Compn> missed him! 
[05:37] <cone-169> ffmpeg.git 03Michael Niedermayer 07master:8ac8f04993e5: mpegvideo: Fix long standing race condition with frame threads
[07:53] <highgod> Hi, I want to ask a question. How can I know the VC1 video format is 420 or 444 in VC1Context
[07:56] <funman> highgod: hello
[07:57] <highgod> hi funman
[07:59] <nevcairiel> VC1 is always 420
[07:59] <funman> highgod: you're working on dxva2 standalone decoder, right? (using hwaccel internally)
[07:59] <j-b> funman: t'es debout ma caille?
[08:00] <funman> on dirait que oui
[08:00] <highgod> funman:yes,I'm fixing the patch now
[08:00] <highgod> nevcairiel:Thanks
[08:00] <funman> highgod: btw about vlc attribution you can just copy the Copyright lines from vlc files
[08:04] <highgod> Thanks,funman,I have copy the copyright lins form vlc.Should I copy all the lines on the top of the files?
[08:06] <funman> highgod: no I think that is enough
[08:08] <highgod> OK,thanks.
[09:01] <highgod> Hi, I want to ask a question again, can I use the chroma_format in MpegEncContext to know whether the mpeg2 video is 420 or 422 or 444? Thanks
[13:46] <Darkarnium> Hey there, a quick question regarding acceptable standards for passing arbitrary information to modules. I've seen a few mail list posts regarding HLS cookies, and I'm working on a project which requires the abillity to provide a cookie in fetching the AES keys - where applicable - or when grabbing the TS URLs. However, I've seen a few applications where the cookie / authentication data is actually provided before the M3U8 request is f
[13:47] <Darkarnium> Although the application is broken, the abillity to provide customer header data - such as User-Agents, etc - might be a welcome addition to HLS? Or is this something that shouldn't be implimented for a given reason? If not, I'd be happy to give it a shot :)
[13:48] <saste> Darkarnium, hi think Micah Galizia is working on something similar
[13:48] <saste> right now I'm not sure how HTTP options are propagated to the HLS muxer
[13:49] <saste> but sure patches are welcome
[13:50] <Darkarnium> Ah, very cool. I did some testing with some static cookies - temporary, very temporary, to confirm behaviour. I can confirm that the AVDictionary passed to ffurl_open in hls.c supports the addition of a headers option. This propagates through into the HTTP call - for both HTTP and HTTPS protocols - confirmed with a couple of packet captures.
[13:50] <Darkarnium> So, that might be a useful hook. I'll have a bit more of a read, and see how I go. Once I have something workable, that's to spec, I'll ask for a review. What's the best method for the latter, a pull request, or otherwise?
[13:51] <Darkarnium> If there's a document regarding code standards or development standards process, I'd be more than happy to shut up and read it :P
[13:56] <saste> Darkarnium, http://ffmpeg.org/developer.html
[13:56] <saste> patches created with git-format are usually fine
[13:56] <Darkarnium> Fantastic. Thanks for your time saste, much appreciated :)
[13:58] <pross-au> Darkarnium: just on arbitary information. do you mean supplied by the user? like a decrypt key?
[14:01] <Darkarnium> pross-au: at this stage, just cookie data. I say arbitrary as the HLS streaming providers I've had a look at so far all differ in their A/V names for cookie data - as is to be expected. decryption keys are still fetched as per the HLS draft RFC, I wouldn't be tampering with that, as I'd end up breaking the proposed standard
[14:01] <saste> Darkarnium, anyway, I'm going to push the cookie stuff tonight
[14:02] <Darkarnium> Oh, cool, is it available to the world currently? Or private channels only before it's incorporated
[14:03] <pross-au> ok. for the pcoip demuxer (working in progress) i use an av_url type option to pass cookie-like info to the decoder.
[14:04] <Darkarnium> Interesting, is PCoIP it's own protocol, or wrapped around another? As the reason I was thinking of exposing '-headers' was that it'd allow for easy addition of extra HTTP headers in the case that they're required - in line with HLS and HTTP standards of course.
[14:05] <pross-au> it is 'two' protocols, one to initialise the session, the other encapsulated in ssl.
[14:07] <pross-au> correction: the session initialisation is encapsulated in ssl, the second protocol (carry a/v/kvm) is salsa20/aes128/aes256 encrypted udp (tcp optional)/
[14:08] <Darkarnium> Ah cool
[14:08] <Darkarnium> I assume the authentication data for the latter is provided as part of the session setup, via SSL?
[14:08] <Darkarnium> Thus the need to pass between modules?
[14:09] <pross-au> no
[14:09] <Darkarnium> Hah, you know what they say about assumptions :p
[14:09] <pross-au> there is some additional salt-like data, that needs to be supplied seperately
[14:09] <pross-au> hence the av_url argument
[14:09] <Darkarnium> Ahh
[14:10] <pross-au> IIRC, the url was looking like pcoip://destination:port?ssl_options=foo&salt=bar
[14:12] <pross-au> the salt data is communicated through another (third) channel, called the broker.
[14:12] <pross-au> its more of a vdi protocol, than a multimedia streaming protocol.
[14:12] <Darkarnium> Fair enough.
[14:14] <Darkarnium> This HLS implementation I'm working to write a client for is rather awful. Client authenticates via web service, is provided with a loginToken, and a set of allowed 'channels'. From there additional HTTP calls are performed, which yield XML back from the provider, containing a custom XML schema with cookie data and an M3U8 URL. I'm not sure why the cookie data wasn't returned using set cookie, but what can you do.
[14:15] <Darkarnium> So the juggling act is to ensure it can be implimented, as per HLS standard, but flexible enough to be standards compliant and able to be distributed.
[14:15] <Darkarnium> So the abillity to pass the relevant data via CLI may work out to be the best method of doing so
[14:17] <Darkarnium> I should rephrase, the client itself is Python, but ffmpeg is used to handle the hls streams - in line with the HLS standard. Not cowboying things up :P
[14:19] <Darkarnium> Anyway, it's late here, so about time for me to get some sleep
[14:19] <Darkarnium> Cheers for all the assistance and suggestions :)
[14:19] <Compn> Darkarnium : to answer your question, its a patch on the mailing list
[14:19] <Compn> saste is either going to ping it or commit it :)
[14:33] <cone-169> ffmpeg.git 03Ronald S. Bultje 07master:f6badba1859f: h264: don't clobber mmco opcode tables for non-first slice headers.
[14:40] <cone-169> ffmpeg.git 03Martin Storsjö 07master:62761934b024: rtpdec: Remove a woefully misplaced comment
[14:40] <cone-169> ffmpeg.git 03Martin Storsjö 07master:d0fe217e3990: rtpdec: Simplify insertion into the linked list queue
[14:40] <cone-169> ffmpeg.git 03Michael Niedermayer 07master:eaf1f0116935: Merge commit 'd0fe217e3990b003b3b3f2c2daaadfb2af590def'
[14:46] <cone-169> ffmpeg.git 03Martin Storsjö 07master:30b50f79aea3: rtpdec: Handle more received packets than expected when sending RR
[14:46] <cone-169> ffmpeg.git 03Diego Biurrun 07master:ba0c72a9ae1e: build: Remove stray Makefile entry for non-existent VCR1 encoder
[14:46] <cone-169> ffmpeg.git 03Michael Niedermayer 07master:8686b6c68bac: Merge commit 'ba0c72a9ae1e2954e5dcf920f7b4e9a8f8a22f3e'
[15:13] <cone-169> ffmpeg.git 03Martin Storsjö 07master:d596f2b32264: rtpdec: Make variables that should wrap unsigned
[15:13] <cone-169> ffmpeg.git 03Tom Finegan 07master:66aabd76a9c0: mkv: support vp9 tag
[15:13] <cone-169> ffmpeg.git 03Luca Barbato 07master:23a610b9d66a: nut: support vp9 tag
[15:13] <cone-169> ffmpeg.git 03Luca Barbato 07master:dab1f543fcac: libvpx: support vp9
[15:13] <cone-169> ffmpeg.git 03Luca Barbato 07master:3f111804eb5c: libvpx: make vp8 and vp9 selectable
[15:13] <cone-169> ffmpeg.git 03Michael Niedermayer 07master:353dbaa29714: Merge commit '3f111804eb5c603a344706b84b7164cbf7b4e0df'
[15:21] <cone-169> ffmpeg.git 03Ronald S. Bultje 07master:bad446e25140: h264: don't clobber mmco opcode tables for non-first slice headers.
[15:21] <cone-169> ffmpeg.git 03Giorgio Vazzana 07master:39403c6c1baf: oggparsetheora: fix comment header parsing
[15:21] <cone-169> ffmpeg.git 03Maximilian Seesslen 07master:055b37308080: libtheoraenc: fix granularity of video quality
[15:21] <cone-169> ffmpeg.git 03Sean McGovern 07master:5e753ed502d3: suncc: Replace more GCC flags by their equivalents in suncc_flags()
[15:21] <cone-169> ffmpeg.git 03Michael Niedermayer 07master:24d06cb2089f: Merge commit '5e753ed502d3597077d8675ca1438e1bcade1459'
[15:30] <cone-169> ffmpeg.git 03Anton Khirnov 07master:ea382767ad21: h264: fix ff_generate_sliding_window_mmcos() prototype.
[15:30] <cone-169> ffmpeg.git 03Rémi Denis-Courmont 07master:171f1446f054: vdpau: Remove av_unused attribute from function declaration
[15:30] <cone-169> ffmpeg.git 03Diego Biurrun 07master:51969a652c2e: x86: ABS2: port to cpuflags
[15:30] <cone-169> ffmpeg.git 03Diego Biurrun 07master:99853cb8d423: configure: Make warnings from -Wreturn-type fatal errors
[15:30] <cone-169> ffmpeg.git 03Diego Biurrun 07master:d8c772de53d2: nutdec: Always return a value from nut_read_timestamp()
[15:30] <cone-169> ffmpeg.git 03Michael Niedermayer 07master:cfc40a6aff8d: Merge commit 'd8c772de53d29afb1bada88afa859fce8489c668'
[15:55] <cone-169> ffmpeg.git 03Luca Barbato 07master:bff3607547fd: lavc: set the default rc_initial_buffer_occupancy
[15:55] <cone-169> ffmpeg.git 03Luca Barbato 07master:47812070a267: libx264: use the library specific default rc_initial_buffer_occupancy
[15:55] <cone-169> ffmpeg.git 03Michael Niedermayer 07master:9aeffb3c2a0d: Merge commit 'bff3607547fdbb6e32b3830a351e6a33280c1e0d'
[15:55] <cone-169> ffmpeg.git 03Michael Niedermayer 07master:e074fe2962df: Merge commit '47812070a267cbdf74164e154d03d99bf8ced100'
[16:03] <cone-169> ffmpeg.git 03Martin Storsjö 07master:8ee288d2586f: lavu: Add an API for calculating HMAC (RFC 2104)
[16:04] <cone-169> ffmpeg.git 03Martin Storsjö 07master:ab2ad8bd5688: lavf: Add functions for SRTP decryption/encryption
[16:04] <cone-169> ffmpeg.git 03Michael Niedermayer 07master:e7e0186eeb0a: Merge commit 'ab2ad8bd56882c0ea160b154e8b836eb71abc49d'
[16:12] <cone-169> ffmpeg.git 03Martin Storsjö 07master:424da308302b: rtsp: Support decryption of SRTP signalled via RFC 4568 (SDES)
[16:12] <cone-169> ffmpeg.git 03Martin Storsjö 07master:2f3bada63e57: lavf: Add a protocol for SRTP encryption/decryption
[16:12] <cone-169> ffmpeg.git 03Michael Niedermayer 07master:b52925d2cde9: Merge commit '2f3bada63e57345329c4f9b48e9b81b5cfc03d05'
[16:16] <cone-169> ffmpeg.git 03Martin Storsjö 07master:611bf39bde60: sdp: Include SRTP crypto params if using the srtp protocol
[16:16] <cone-169> ffmpeg.git 03Diego Biurrun 07master:094a7405e5d8: x86: ABSB: port to cpuflags
[16:16] <cone-169> ffmpeg.git 03Michael Niedermayer 07master:77041e2474a1: Merge commit '094a7405e5d8463d7d167d893e04934ec1a84ecd'
[16:20] <cone-169> ffmpeg.git 03Diego Biurrun 07master:320e1d0df3df: x86: ABSB2: port to cpuflags
[16:20] <cone-169> ffmpeg.git 03Michael Niedermayer 07master:b7ede94bbd29: Merge remote-tracking branch 'qatar/master'
[16:28] <cone-169> ffmpeg.git 03Michael Niedermayer 07master:918b41163671: rtpdec: support CSRC
[20:18] <michaelni> bcoudurier, following patch should fix the chunked duration issue: "[FFmpeg-devel] [PATCH 2/2] mux: fix chunked interleaver"
[20:18] <llogan> siretart: do you expect the ffmpeg package to be dropped by raring? i couldn't tell in the "Intending to..." thread
[20:27] <michaelni> bcoudurier, review and comment if it works for you are welcome!
[20:28] <siretart> llogan: well, let's say I still have hope. but I don't have the time to fix all packages in the archive, which needs to be done by feature freeze for that. my hope is that other packagers can jump in
[20:28] <bcoudurier> let me see
[20:28] <cone-169> ffmpeg.git 03Michael Niedermayer 07master:778069c83255: vorbisdec: support freeing partially allocated contexts.
[20:28] <cone-169> ffmpeg.git 03Michael Niedermayer 07master:c5cf58d4b9b0: oggdec: resync from the last page.
[20:28] <cone-169> ffmpeg.git 03Michael Niedermayer 07master:e9ffee23f372: vorbisdec: handle midstream parameter changes
[20:28] <cone-169> ffmpeg.git 03Michael Niedermayer 07master:c994bb2fb772: oggdec: Leave treatment of serial changes to the decoder.
[20:29] <llogan> siretart: i see. thanks.
[20:29] <siretart> as you can see, the fallout is much larger than expected.
[20:30] <bcoudurier> ah you fixed it in a way I was investigating :)
[20:31] <cehoyos> llogan : You see, this is not about providing users with a working A/V converter that is not exploitable out-of-the-box but about finding more packagers who support hostage-taking...
[20:32] <llogan> cehoyos: hell hath frozen over when cehoyos appears on IRC!
[20:32] <durandal11707> @_@
[20:34] <llogan> siretart: obviously i'd like to see an ffmpeg package with FFmpeg as upstream..even if it is just a binary and libraries with no depends. assuming we have the manpower to provide this, do you see this as a possibility?
[20:35] <llogan> and obviously i don't know the details and work involved in package sponsorship, mantaintaing, etc
[20:35] <llogan> yet
[20:52] <llogan> ...i was just about to do that
[21:08] <Daemon404> should really add threading to utvideoenc.c and just drop libutvideo*.cpp
[21:14] <cone-169> ffmpeg.git 03Michael Niedermayer 07release/1.1:66a311210008: oggdec: resync from the last page.
[21:14] <cone-169> ffmpeg.git 03Michael Niedermayer 07release/1.1:dc3349024a06: vorbisdec: support freeing partially allocated contexts.
[21:14] <cone-169> ffmpeg.git 03Michael Niedermayer 07release/1.1:9636266cbdab: vorbisdec: handle midstream parameter changes
[21:14] <cone-169> ffmpeg.git 03Michael Niedermayer 07release/1.1:1c373456f638: oggdec: Leave treatment of serial changes to the decoder.
[21:18] <durandal11707> why ffmpeg -h full does not show default option?
[21:45] <wm4> are the symbols in libavcodec/vda.h public? is it a public header? are the ff_vda_ functions in it public?
[21:46] <durandal11707> generally * is private except av*
[21:47] <durandal11707> so it is big mess that vda stuff
[21:47] <wm4> VLC uses ff_vda_ symbols
[21:48] <durandal11707> it may use own hacked version or statically linked
[21:49] <durandal11707> i did not do that mess, so this is guessing on my side...
[21:56] <cehoyos> Afaict, vda.h is an installed header, so although the functions are not av* but ff* they are public
[21:57] <durandal11707> but ff_ in that header is not in libavcodec.v
[21:58] <durandal11707> it is deprecated function btw
[21:59] <cone-169> ffmpeg.git 03Stefano Sabatini 07master:1b325ce91ab7: lavd/v4l2: extend error/debug feedback in case of invalid codec/pix_fmt
[21:59] <cone-169> ffmpeg.git 03Stefano Sabatini 07master:fce165027fd8: lavd/v4l2: fix misc messages
[21:59] <cone-169> ffmpeg.git 03Stefano Sabatini 07master:aa359d3808e3: lavd/v4l2: return meaningful error code from device_init()
[21:59] <cone-169> ffmpeg.git 03Stefano Sabatini 07master:d012059e7ba6: lavd/v4l2: apply grammar/consistency fixes to options help fields
[22:29] <cone-169> ffmpeg.git 03Micah Galizia 07master:0b80a12184ef: lavf/http: add HTTP protocol cookie support
[22:29] <cone-169> ffmpeg.git 03Micah Galizia 07master:10315b1cb817: doc/protocols: document HTTP protocol cookie support
[22:48] <Darkarnium> hehe, thank god for time zones.
[22:50] <Darkarnium> Just got up, ready for work and saw that Micah has pushed the cookie support, which supports passing of cookies via -cookies as well as via set cookie.
[22:50] <Darkarnium> That makes my life easy! :)
[22:51] <cone-169> ffmpeg.git 03Stefano Sabatini 07master:c92b6f347dca: tools: add plotframes script
[22:58] <Compn> Darkarnium : you said something about adding features to hls ?  only if its in the spec
[23:05] <Darkarnium> Compn: it was, then again, the spec for HLS is a bit light currently. The feature was to do with authentication for grabbing AES keys. The spec specifies that HTTP session cookies and SSL should be used; the only questionable element is how the cookies are set. The expected way would be via a Set-Cookie header, however, an override may be appropriate to cover the use cases where the provider is specifying the session cookie in another 
[23:06] <Darkarnium> I should probably say proposed spec / RFC
[23:12] <kierank> <troll>as if HLS and friends follow specs</troll>
[23:12] <Daemon404> lolapple
[23:12] <Daemon404> lolakamai
[23:13] <Darkarnium> kierank: I know -__
[23:13] <Darkarnium> The RFC is so damned open to interpretation.
[23:13] <kierank> that's a significant reason i don't work on that web stuff
[23:13] <kierank> people will just assume iDevices are correct
[23:14] <Darkarnium> HURR, let's allow AES for key delivery! That way X provider can decide to use the most OBSECURE HTTP header they can find, munge it into only *JUST* being compliant and then deploying it.
[23:14] <Darkarnium> Err, HTTP that should be
[23:15] <JEEB> gentlemen, welcome... to the internets
[23:15] <Daemon404> kierank, we've successfully reported bugs to apple before
[23:15] <Daemon404> it /is/ possible.
[23:15] <Darkarnium> Just painful?
[23:16] <Daemon404> i wasnt involved in it, so i cant say
[23:16] <Darkarnium> Ahh
[23:18] <Darkarnium> The only platform I've found HLS to work on, well, out of the box is an iDevice. Probably because apple submitted the RFC, and now it's being picked up and used. However, Android doesn't like HLS with certain attributes - such as cookies as part of key retreival - so you're pretty much backed into a corner until there is significant demand enough for it to be implimented, or you write a patch and submit it yourself.
[23:18] <Darkarnium> Anyway, I should probably stop ranting...
[23:18] <Daemon404> well
[23:19] <Daemon404> also, services all are built around iDevice
[23:19] <Daemon404> bent to apples possibly broken impl
[23:20] <Darkarnium> Exactly. The reason I wrote a tentative patch for cookies to HLS - which I'm canning and now using Micah's as it's much better written - is for a cable provider in Australia who have an iDevice application for live streaming. Until their broken HLS implimentation is supported on Android, I doubt we'll see it released across platforms. Hopefully, the implimentation of it inside ffmpeg, and more adoption of this method of 'securing' key 
[23:21] <Daemon404> (you got cut off)
[23:21] <Darkarnium> Oh :(
[23:24] <Darkarnium> Anyway, it's off to work I go
[23:38] <cone-169> ffmpeg.git 03Angelo Haller 07master:e7a39e163ddb: examples/demuxing: free AVPacket after usage
[00:00] --- Wed Jan 16 2013