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

[burek]

[00:17] <amalia> How do I submit test results ?///
[00:23] <michaelni> amalia,  (https://ffmpeg.org/fate.html)  "When you have everything working properly you can create an SSH key pair and send the public key to the FATE server administrator who can be contacted at the email address fate-admin at ffmpeg.org." 
[00:24] <amalia> Hmmm
[00:51] <amalia> michaelni, my problem is writing a config file which will be called from fate.sh and generate configure.log, compile.log test.log report and version
[00:52] <amalia> I would greatly appreciate if you could give me a sample config file I could adapt for my system since I think will be necessary in submitting my fate results right?
[00:54] <michaelni> amalia, tehers one on https://ffmpeg.org/fate.html (you can probably drop all the lines that are marked as optional which is 2/3 of the file)
[00:55] <amalia> michaelni, alright thanks
[01:07] <cehoyos> nevcairiel: For gcc, the default is -O0, --disable-optimizations for gcc removes -fomit-frame-pointer and leaves -O at the default (-O0)
[01:22] <cehoyos> thardin: Can we get rid of the "Field dominance 0 support is not implemented"? I really believe we have enough samples...
[01:28] <cone-231> ffmpeg.git 03Michael Niedermayer 07master:f3c0e0bf6f53: avcodec/dnxhddec: treat pix_fmt like width/height
[02:08] <amalia_> michaelni, just finished running the fate tests on my Fedora 20 localhost, generated a public key pair and sent to the administrator for fate 
[02:08] <amalia_> I'm trying to connect with ssh to the fate server and looks like it's asking for a password? i'm I to kill the process at this process since I think I've enabled public authentication with the fate server for my system?
[02:12] <michaelni> amalia_, just added the key
[02:12] <michaelni> should work now without pw
[02:12] <amalia_> ok
[02:13] <amalia_> michaelni, still asking for password?
[02:13] <amalia_> so what should i do
[02:13] <michaelni> fate at fate.ffmpeg.org
[02:13] <amalia_> michaelni, is that the password?
[02:15] <michaelni> no its the username and server, you dont need a password unless theres a password on the ssh private key
[02:15] <amalia_> no there's none, 
[02:16] <amalia_> michaelni, i'm a bit confused here I don't know if the private key i sent should correspond to the details in ~/.ssh/id_rsa? 
[02:16] <amalia_> because i generated a new key-pair and sent to you probably i'll need to use it some how to login
[02:17] <michaelni> you did sent corerctly a public key
[02:17] <michaelni> what does ssh fate at fate.ffmpeg.org say ?
[02:17] <amalia_> michaelni, it says fate at fate.ffmpeg.org's password: 
[02:19] <michaelni> maybe ramiro has an idea, he is here
[02:21] <amalia_> michaelni, ramiro looks like i created the key and stored in the a different directory from ~/.ssh/ so looks like i'll have to use the key to setup my identity in ~/.ssh/?
[02:21] Action: amalia_ wondering how that's done
[02:23] <michaelni> you could just create a seperate account for fate and put the key in  its ~/.ssh
[02:23] <cehoyos> Could a native speaker please read this: http://pastebin.com/EsMa9Y1e
[02:23] <cehoyos> Is it just me or did they completely misunderstood the GPL?
[02:25] <amalia_> well michaelni i just added the new authentication to ~/.ssh/ so it's working now
[02:26] <amalia_> so my question is how to submit my result whether to uncomment the 'fate_recv' part of the config file and re run the tests? 
[02:30] <michaelni> when you run "tests/fate.sh /path/to/fate_config" and the ssh command is not commented out in the config then the data shoud get submitted, make sure you choose a unique slot name before
[02:31] <amalia_> michaelni, well i ran it the first time with that part commented out
[02:31] <amalia_> so I've successfully authenticated with fate
[02:31] <amalia_> so I don't know if I'll have to rerun the same command again with that part uncommented or I run the example in 4.3 at the bottom of the wiki?
[02:32] <kierank> cehoyos: yes misunderstanding the gpl
[02:32] <kierank> as far as I can tell
[02:32] Action: amalia_ seeing that running it again tries to fetch those code repos again
[02:32] <cehoyos> This is the followup to Rhozet:
[02:32] <cehoyos> Rhozet apparently removed FFmpeg from their product
[02:33] <michaelni> 4.3 is for locally running fate
[02:33] <cehoyos> A German company sells a plugin for Carbon Coder now
[02:33] <cehoyos> This is an excerpt of their EULA.
[02:33] <cehoyos> I have a suspicion that they charge a lot of money but I don't know yet.
[02:35] <cehoyos> http://www.x-dream-media.com/index.php/de/produkte/harmonic-rhozet-carbon-ffmpeg-exporter-plugin
[02:35] <amalia_> michaelni, Ok will rerun the fate.sh with the config script together with the uncommented part, was not really understanding why it still had to try to clone the code repos again
[02:36] <michaelni> it shouldnt clone them new but just update them
[02:36] <amalia_> ok thanks
[02:37] <kierank> cehoyos: of course they charge a lot
[02:47] <amalia_> michaelni, just ran the tests enabling submission of results to fate
[02:47] <amalia_> but don't know how to determine if the process was successful or not
[02:48] <michaelni> amalia_, look at fate.ffmpeg.org do you see the resuts =
[02:48] <michaelni> ?
[02:48] <amalia_> michaelni, ramiro http://paste.kde.org/puiodl6xo this is what i saw on my terminal
[02:51] <amalia_> I am not seeing any thing on fate
[02:53] <michaelni> it doesnt submit results if it was run withe the same revission last time, thats probably it
[02:55] <amalia_> i keep on getting this same error:
[02:55] <amalia_> [root at localhost ffmpeg]# tests/fate.sh /home/amalia/fate-config.sh
[02:55] <amalia_> HEAD is now at f3c0e0b avcodec/dnxhddec: treat pix_fmt like width/height
[02:55] <amalia_> [root at localhost ffmpeg]# 
[02:55] <j-b> root?
[02:55] <amalia_> j-b, yeah
[02:55] <cone-231> ffmpeg.git 03Carl Eugen Hoyos 07master:26122145559f: Do not set the lame quality if the user didn't request it.
[02:55] <cone-231> ffmpeg.git 03Carl Eugen Hoyos 07master:19a6431ec247: Print a warning if a subtitle demuxer changes utf16 to utf8.
[02:55] <cone-231> ffmpeg.git 03Andrey Utkin 07master:b608fba67265: Use v4l2 input format automatically if filename starts with "/dev/video"
[02:55] <cone-231> ffmpeg.git 03Carl Eugen Hoyos 07master:238ed47faead: Mention in the documentation that fieldmatch needs cfr input.
[02:55] <cone-231> ffmpeg.git 03Michael Niedermayer 07master:5b864470808a: Merge remote-tracking branch 'cehoyos/master'
[02:55] <amalia_> cloned and did everything as root
[02:56] <j-b> this is dangerous.
[02:56] <j-b> You should not do that.
[02:56] <michaelni> dont use root unless you have to and fate does not need root
[02:57] <michaelni> also as i just pushed a few changes the next fate client run should/might work
[02:59] Action: amalia_ is changing the permssions of ffmpeg_sources to normal user
[03:00] <michaelni> amalia_, also make sure ~/.ssh contains the correct keys for the user under which fate runs
[03:00] <amalia_> michaelni, already added the new key with ssh-add
[03:24] <amalia_> michaelni, tried adding the generated key to ~/.ssh i get this error saying the key is unprotected. I'll like to generate another key and send for you to add to the list of hosts and delete the other one
[03:28] <jamrial> use chmod on the key ssh complains about
[03:29] <amalia_> jamrial, just decided to create a new key which I've added to ~/.ssh/
[03:29] <amalia_> trying to upload and send to fate at fate....
[03:30] <jamrial> there was no need for that. ssh was simply complaining about the key file permissions
[03:31] <jamrial> "chmod 600 yourkey" is probably all you needed to do
[03:37] <amalia_> did that jamrial and it worked
[03:37] <amalia_> just trying to get the test authenticate with the fate server perfectly
[03:37] Action: amalia_ feels sleepy already
[03:47] <amalia_> jamrial, looks like the new key i generated seems to prevent the previously authenticated key from working even though I used ssh-add to add the public key to ~/.ssh
[05:06] <cone-231> ffmpeg.git 03Michael Niedermayer 07master:c1e035ea89c1: avformat/mxfdec: fix null pointer dereference
[08:26] <thardin> cehoyos: if they work then sure, I suppose
[09:32] <rcombs> <sub2video go away plz>
[09:46] <wm4> WHAT THE FLYING FUCK
[09:46] <wm4> seriously what
[09:47] <wm4> someone please explain this shit to me http://git.videolan.org/?p=ffmpeg.git;a=commit;h=19a6431ec247e4842236292cc5f8cfc8f87da11e
[09:49] <thardin> the subtitle rendering uses utf-8 maybe?
[09:49] <wm4> it's bullshit for ffmpeg.c
[09:50] <rcombs> wm4: meant to inform the user that passing "utf-16" as the sub charenc won't work as expected?
[09:50] <wm4> it "informs" every user, even players like mpv
[09:50] <wm4> why the fuck would I want every user to see this useless message
[09:51] <nevcairiel> plenty warnings get added for some dumb ffmpeg case, no matter that the libs are much more often used by other things than ffmpeg.c
[09:51] <wm4> I know... and fuck this
[09:51] <wm4> I'm considering completely disabling any log message from ffmpeg because it's so useless
[09:51] <rcombs> same reason you'd want every user to hear about some struct's time_base member being deprecated as a hint (or whatever that one message is)
[09:51] <rcombs> (one day I might find out what that reason is!)
[09:53] <rcombs> does mpv ever actually hit that message?
[09:54] <cehoyos> The message is only shown on encoding.
[09:55] <cehoyos> thardin: What I meant was: Could you remove the message? Or do you believe it has some benefit?
[09:55] <wm4> rcombs: why wouldn't it
[09:55] <thardin> not sure since I didn't write that stuff
[09:55] <wm4> cehoyos: it was definitely added to the decode path, not encode
[09:55] <cehoyos> Ok, sorry
[09:55] <thardin> I can take a look though
[09:56] <cehoyos> Actually, I don't think you are right: Why would decoding ever trigger this message?
[09:56] <thardin> well, if there's a zero in there
[09:56] <thardin> which usually means "unknown"
[09:57] <cehoyos> Yes, every second sample uplaoded by users contain "0" and ask the user to upload the sample.
[09:57] <thardin> well, the field order can be parsed from the video essence
[09:57] <rcombs> oh, actually, I don't think that commit does what it was meant to do
[09:58] <thardin> I wonder what mediainfo says..
[10:00] <rcombs> cehoyos: I think it'd make more sense to put that message around https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/utils.c#L1665
[10:00] <cehoyos> How would libavcodec know that the original file (before "handled" by libavformat) contained utf-16?
[10:01] <wm4> by not having a shit API?
[10:01] <wm4> you don't know the same for matroska either
[10:01] <rcombs> the point of the message is to tell the user not to unnecessarily send `-sub_charenc utf-16`, right?
[10:01] <wm4> so you'd happily corrupt utf-8 if the user specified something other than utf-8
[10:01] <cehoyos> But please feel free to send a patch improving (or even reverting) my patch: From the discussion, I did not see that it was controversial at all.
[10:01] <cehoyos> rcombs: Yes, you did see the ticket?
[10:02] <rcombs> yeah
[10:02] <rcombs> cehoyos: so, why not just warn if avctx->sub_charenc matches "utf-16" or similar, which IIUC is what the user should actually be warned about?
[10:03] <rcombs> that's what I thought you were going to do, looking at the ticket
[10:03] <wm4> yep, utf-16 packets should never happen
[10:03] <cehoyos> I am surprised about this argument but please see above: Just send a patch to improve the situation.
[10:04] <rcombs> I hope I don't sound argumentative; I'm just trying to understand the problem properly
[10:04] <cehoyos> And if reducing the log level of the message, please feel free to do it: As said, I didn't see any controversy about the actual patch yesterday.
[10:04] <ubitux> cehoyos: please fix 238ed47faeadf4ed0008da774cf61d6b224e4254
[10:04] <cehoyos> I removed the part that you were objecting to, no?
[10:05] <ubitux> the filter doesn't work for cfr input
[10:05] <ubitux> +only
[10:05] <ubitux> i think we agreed on that
[10:05] <ubitux> fieldmatch doesn't care about cfr or no
[10:05] <ubitux> it's just field matching, and it works just fine with vfr
[10:05] <rcombs> wm4: also, thoughts on how to handle a case where the file has UTF-16 without a BOM?
[10:06] <ubitux> the issue lies into decimate
[10:06] <ubitux> if any
[10:06] <rcombs> (or, are those rare enough to ignore?)
[10:06] <cehoyos> But the documentation states that you have to add decimate to fieldmatch or do I misremember?
[10:06] <ubitux> maybe, still you're saying in fieldmatch something plently wrong
[10:07] <cehoyos> ... it needs to be followed by decimation...
[10:07] <ubitux> people can use mpdecimate of even a select or whatever
[10:07] <cehoyos> Neither work.
[10:07] <cehoyos> For real samples.
[10:07] <ubitux> well, your text is wrong for fieldmatch, period
[10:08] <ubitux> "The filter currently only works for constant frame rate input." this is not true
[10:08] <cehoyos> Why did you write on the mailing list "that you don't care but that you don't understand why pullup works better"?
[10:08] <cehoyos> Sorry, I tried to make the message clear to users:
[10:08] <ubitux> it was before our discussion
[10:08] <cehoyos> It dimply doesn't work.
[10:08] <cehoyos> At the same time I didn't want to imply that anything is better or similar.
[10:09] <ubitux> oh well whatever, i'm just saying your sentence is just wrong
[10:09] <cehoyos> Yes, the discussion explained the technical issue better, but for users, this is what "fieldmatch" does (even if not true).
[10:10] <ubitux> well feel free to mislead the users then :)
[10:14] <cehoyos> ubitux: Patch sent, please comment
[10:15] <ubitux> cehoyos: OK
[10:17] <ubitux> you can apply
[10:17] <cehoyos> Thank you!
[10:19] <cone-751> ffmpeg.git 03Carl Eugen Hoyos 07master:fd1652b3ba6c: Improve the fieldmatch documentation about mixed telecined content.
[10:46] <ubitux> cehoyos: regarding #3968, pullup is doing a better job?
[10:47] <ubitux> if you can show me a working cli for pullup, and a non working one for fieldmatch+decimate, i'd like to know
[10:49] <ubitux> (and if you have the sample somewhere...)
[11:32] <cehoyos> ubitux: Yes, but definitely not perfect, it is dropping random frames.
[11:32] <cehoyos> The command line from ticket #3968 is sufficient.
[11:34] <cehoyos> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket3968/
[12:26] <cone-751> ffmpeg.git 03Thomas Mundt 07master:2114e8843256: avformat/mxfenc: AVC Intra support
[13:20] <cone-751> ffmpeg.git 03Michael Niedermayer 07master:0c42f47e383f: avcodec/libutvideodec: Try to fix build failure with old libutvideo
[14:44] <alexvf> hi, i've tried in #ffmpeg but got no response, hope i can get a response here
[14:45] <alexvf> is it possible in the current ffmpeg state to use custom I/O in a non blocking way to read from a network stream? i've tried but it is not working
[14:46] <alexvf> i want to know if i can fix the issue or i would be banging my head against a wall
[14:46] <wm4> no
[14:46] <wm4> all demuxers do blocking access
[14:47] <wm4> nothing in the API would even allow non-blocking things
[14:48] <alexvf> just to be sure we are talking about the same
[14:48] <alexvf> i'm returning AVERROR(EAGAIN) in my read callback
[14:48] <wm4> no
[14:49] <wm4> won't work in general
[14:49] <alexvf> and i suspect it is causing av_read_frame to return an incomplete frame (cause i see noise in the decoded frames)
[14:49] <alexvf> is it what is happening?
[14:55] <alexvf> wm4: can you confirm my guess?
[14:55] <wm4> no
[14:56] <wm4> if you don't return the complete read, libavformat assumes there was an error or EOF
[14:57] <alexvf> yes, but i reset eof_reached and error to 0 after av_read_frame if it returns AVERROR(EAGAIN)
[14:58] <alexvf> but the next av_read_frame that returns without error seems to return an incomplete frame
[14:58] <alexvf> is it discarding buffered data when the callback returns an error?
[14:58] <wm4> why do you expect that this works?
[14:58] <wm4> libavformat reads bytes from avio, not packets
[14:59] <wm4> and I'm not sure what it does (depends on the exact demuxer), but generally it will try to recover from an error if this happens
[15:02] <alexvf> well, av_read_frame could just return an error and keep the buffered data, and when it is called again (and the callback works) could return a valid frame
[15:02] <alexvf> i'm sure i'm missing something but that was the behaviour i expected
[15:17] <wm4> alexvf: no, that would be very complicated
[15:17] <wm4> alexvf: also, it would call the callback in a loop, which would not result in the "non-blocking" behavior you want
[15:18] <wm4> alexvf: I believe you can return short reads from the callback, but only if you return at least 1 byte
[15:22] <alexvf> wm4: yep i have checked that
[15:22] <alexvf> wm4: when i can get one byte from the network it works ok
[15:23] <alexvf> wm4: but if there is no data at all i have to return some error
[15:24] <alexvf> wm4: since 0 is interpreted as eof, i chose AVERROR(EAGAIN) which, looking at the code at a first glance, seemed the more sensible return
[15:27] <alexvf> wm4: i think that there should be an error meaning "ok, there is no data yet, but there will be soon" and av_read_frame should just return immediately and let the caller manage that situation
[15:27] <alexvf> wm4: then, avoid blocking behaviour would be responsability of the caller
[15:34] <alexvf> wm4: he could call av_read_frame until it reads a frame, posibly with a sleep and a timeout or make whatever he wants
[15:35] <alexvf> wm4: i think i can workaround the issue by calling some function that tells me if it has something to read before calling av_read_frame, although it is a bit hackish in my current design
[15:36] <alexvf> wm4: thanks for the help
[15:38] <wm4> alexvf: no, lavf does not avoid or allow to avoid blocking behavior
[15:39] <wm4> move it to a thread, problem solved
[15:42] <alexvf> yes, that is another solution, posible cleaner, although a little longer because it does not fit very well right now :)
[15:42] <alexvf> thanks for your time
[16:23] <cone-751> ffmpeg.git 03Michael Niedermayer 07master:df74811cd53e: avcodec/utils: Align dimensions by at least their chroma sub-sampling factors.
[16:23] <cone-751> ffmpeg.git 03James Almer 07master:931da6a5e9dd: lavd/v4l2: don't use avpriv_ prefix for internal functions
[18:10] <cone-751> ffmpeg.git 03James Almer 07master:faa9d2982969: lavu/atomic: add support for the new memory model aware gcc built-ins
[18:11] <wm4> kierank: is "[FFmpeg-devel] [Patch]support more AVC Intra formats without SPS/PPS header" more of "bad thing"?
[18:11] <kierank> of course
[18:11] <kierank> it's trying to unwind vendor lockin
[18:11] <wm4> what vendor lockin?
[18:12] <wm4> vendors doing out of spec shit with their hw?
[18:12] <Daemon404> yes
[18:12] <Daemon404> under an NDA too
[18:12] <Daemon404> in the guise of an 'open spec'
[18:12] <kierank> technically it's not out of spec
[18:12] <kierank> technically
[18:12] <kierank> you are allowed to signal headers by *any* means in h264
[18:12] <kierank> one of those is out of band
[18:12] <Daemon404> yeah but it requires e.g. a special string in the SEI
[18:12] <Daemon404> UMID or w/e
[18:12] <kierank> to decode no
[18:12] <Daemon404> some editors did
[18:13] <Daemon404> theyd just crash
[18:13] <kierank> yes but that doesn't change the fact the file is legal h264
[18:13] <kierank> the decoders are illegal
[18:13] <Daemon404> sure, it's legal
[18:13] <Daemon404> the end result is the same though
[18:13] <Daemon404> NDA etc
[18:13] <kierank> wm4: it's some bullshit game panasonic and now sony play
[18:13] <kierank> they can advertise open standards but you need secret stuff to play it
[18:14] <wm4> nice
[18:15] <kierank> wm4: read http://thomasberglund.no/post/76262479496/we-have-never-been-closer-to-a-standard
[18:15] <kierank> if you particularly care
[18:15] <kierank> esp my comments at the bottom
[18:30] <cone-751> ffmpeg.git 03wm4 07master:e5813d96d67b: avformat/subtitles: reduce log level of UTF-16 warning
[18:42] <cone-751> ffmpeg.git 03Michael Niedermayer 07master:a0528d9ddd65: avformat/mpjpeg: make boundary tag user customizable
[19:01] <wm4> ubitux: is this code familiar? https://github.com/popcornmix/omxplayer/blob/master/OMXSubtitleTagSami.cpp
[19:01] <wm4> appears to convert sami to ass
[19:01] <ubitux> not really
[19:02] <ubitux> is it better than the one in ffmpeg?
[19:02] <wm4> don't know
[19:02] <wm4> but considering they have explicit support, while ffmpeg only has it because mplayer did, maybe
[19:02] <wm4> maybe point the next person who's interested in improving sami support to this code
[19:03] <wm4> or wait
[19:03] <wm4> I'm stupid
[19:03] <wm4> it parses ass in sami (?)
[19:03] <wm4> not generate it
[19:03] <wm4> (wat...)
[19:06] <ubitux> it seems to look for srt and ass tags into sami
[19:06] <ubitux> :P
[19:07] <wm4> so yeah... WHAT THE FUCK
[19:07] <wm4> I assume vsfilter is to blame again
[19:07] <wm4> also accepts ass tags in srt
[19:07] <rcombs> vsfilter is usually to blame
[19:08] <wm4> but even worse that someone would use that... with sami
[19:08] <wm4> of all things
[19:08] <rcombs> "subtitles support dumb things!" VSFilter
[19:08] <rcombs> "the wrong tags are in the wrong formats!" VSFilter
[19:09] <rcombs> "subtitle APIs are becoming overly complicated!" VSFilter
[19:09] <rcombs> "ebola is spreading to Texas!" VSFilter
[19:09] <rcombs> etc. etc.
[19:10] <wm4> "I just spilled by coffee" VSFilter
[19:11] <rcombs> from #ffmpeg: "ASS subtitles aren't supported in MP4" VSFilter
[19:12] <rcombs> "libav's API is incompatible with ffmpeg in subtle ways!" VSFilter
[19:15] <JEEB> fuck-vsfilter.vsfilter-sucks.vsfilter-is-dying.vsfilter-hit-wtc
[20:04] <Compn> rcombs : erm, no subtitles are supported in mp4
[20:04] <Compn> because mp4 is a shitty format
[20:05] <Compn> only timed_text, cc , 
[20:05] <Compn> something else
[20:09] <cone-751> ffmpeg.git 03Thomas Mundt 07master:1700fa013ef5: avformat/utils: support more AVC Intra formats without SPS/PPS header
[20:11] <Compn> kierank : i'd love to see your comments at the bottom of that blog post, but disqus is so bad it wont even load :P
[20:13] <Compn> maybe i just need to upgrade my web browser, seems to work in chromium
[20:19] <wm4> Compn: what browser?
[20:47] <Compn> wm4 : opera before the chrome rebrand. 12.16 or something. sometimes disqus works sometimes not
[20:47] <wm4> ok
[20:48] <wm4> in konqueror (hilariously broken by now), it only works with the webkit backend
[20:49] <cone-751> ffmpeg.git 03Luca Barbato 07master:a9179b5bd6f1: configure: Check only for xcb
[20:49] <cone-751> ffmpeg.git 03Michael Niedermayer 07master:363effbb99f7: Merge commit 'a9179b5bd6f143b4a7ff48bb0d00c8f0a7cafb4b'
[20:52] <Compn> html standards have gone out the window
[20:52] <wm4> this has nothing to do with html
[20:52] <wm4> it's all about js
[20:52] <Compn> stupid js yes i know
[20:52] <Compn> disqus can actually be setup to do html comments though
[20:53] <Compn> ive seen it on one or two pages
[20:53] <JEEB> also I never thought I'd see this day http://arstechnica.com/information-technology/2014/10/html5-specification-finalized-squabbling-over-who-writes-the-specs-continues/
[20:55] <Compn> This has led W3C to take work done by WHATWG and use it as the basis for its own work. WHATWG's specs all explicitly permit such usage, but a number of WHATWG contributors have nonetheless complained that W3C has exercised that ability.
[20:55] <Compn> lol ^^^^ remind you of anything ?
[20:55] <wm4> revolutionary
[20:56] <Compn> or any project...
[20:56] <iive> well, the only thing that w3c added was the DRM
[20:56] <cone-751> ffmpeg.git 03Michael Niedermayer 07master:b3d11437ca55: oggenc: remove unneeded null check
[20:56] <cone-751> ffmpeg.git 03Michael Niedermayer 07master:e08ff208c793: Merge commit 'b3d11437ca55d81eeb10c923343ad69b73895fa8'
[21:03] <wm4> michaelni: how hard would it be to add packed 4:4:4 formats to libswscale?
[21:03] <wm4> in particular I'd be interested in this: " * This plane is an array packed 32-bit pixel data. Within each       * 32-bit pixel, bits [31:24] contain A, bits [23:16] contain V,         * bits [15:8] contain U, and bits [7:0] contain Y."
[21:04] <wm4> that's what vdpau uses
[21:05] <michaelni> probably not hard, just needs to be added to all relevant codepathes
[21:08] <Compn> wm4 : samples would be useful.
[21:14] Action: wm4 throws a nvidia card on Compn's head
[21:15] <wm4> michaelni: that sounds hard
[21:36] <cone-751> ffmpeg.git 03Vittorio Giovara 07master:f64d7e919eab: mtv: improve header check and avoid division by zero
[21:36] <cone-751> ffmpeg.git 03Michael Niedermayer 07master:9a534eda4608: Merge commit 'f64d7e919eabd427f3e6dd4a1219e448c78deb42'
[21:56] <cone-751> ffmpeg.git 03Luca Barbato 07master:043ea6f7bfc5: fbdev: Use av_strerror
[21:57] <cone-751> ffmpeg.git 03Michael Niedermayer 07master:265c4771cc76: Merge commit '043ea6f7bfc59399b6b3659da785ec4cc68a008e'
[21:57] <cone-751> ffmpeg.git 03Michael Niedermayer 07master:7729f4331296: avdevice/fbdev_dec: use errno instead of ret for av_log
[22:06] <cone-751> ffmpeg.git 03Luca Barbato 07master:2cd28693a590: jack: Use av_strerror
[22:06] <cone-751> ffmpeg.git 03Michael Niedermayer 07master:66b2a3fa31bd: Merge commit '2cd28693a59050717cb7da6cb229e606b1dee356'
[22:21] <cone-751> ffmpeg.git 03Vittorio Giovara 07master:e9ba3098319f: assdec: check av_new_packet return value
[22:21] <cone-751> ffmpeg.git 03Michael Niedermayer 07master:a3b1e42ec4f4: Merge commit 'e9ba3098319f78c91470c05da988d865491852c5'
[22:49] <cone-751> ffmpeg.git 03Vittorio Giovara 07master:84bf64d3598c: bethsoftvid: simplify return handling
[22:49] <cone-751> ffmpeg.git 03Michael Niedermayer 07master:a8605be30fdd: Merge commit '84bf64d3598c98a748e609195358ea04b0cfd140'
[23:50] <cone-751> ffmpeg.git 03Thomas Mundt 07master:d1b5ad396776: mxfenc: fix indentation after last commit
[00:00] --- Thu Oct 30 2014