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

[burek]

[00:00] <beastd> yes: ./configure --disable-stripping --enable-debug=1
[00:00] <SevereOverfl0w> Awesome
[00:00] <SevereOverfl0w> Aaannddd recompiling
[00:01] <beastd> Also I am tired and have no time to try things myself ATM. But from what I understand it should work that way.
[00:02] <SevereOverfl0w> Okay, :) Well, giving it a go :D
[00:02] <beastd> SevereOverfl0w: OK. Hope you will get debug symbols in your shared libs this time.
[00:03] <SevereOverfl0w> beastd: Your tip should work
[00:05] <beastd> SevereOverfl0w: Hang in there!
[00:06] <beastd> Going to sleep now. Bye...
[00:06] <SevereOverfl0w> beastd: Heh, thanks dude. Sleep well :) 
[00:11] <SevereOverfl0w> http://bpaste.net/show/ouFRojkk41iqIBSTqDgS/ ubitux? This looking good? 
[00:11] <ubitux> yes, now you can open a ticket with the sample and that backtrace :p
[00:12] <ubitux> > emu_edge
[00:12] <SevereOverfl0w> Awesome. 
[00:12] <ubitux> you might want to enable/disable it
[00:12] <ubitux> try without threading, with/without mmx/sse, ...
[00:21] <SevereOverfl0w> Hold on, I'm still adding my attachment fflogger!
[00:26] <SevereOverfl0w> ubitux: Shall I include my core file? 
[00:34] <BBB> ubitux: yes mc is always the primary bottleneck of any decoder
[00:35] <BBB> ubitux: so that's expected
[00:37] <cone-311> ffmpeg.git 03Michael Niedermayer 07master:71fe97a60ad7: avformat/nutdec: check avio_read() return code
[00:37] <cone-311> ffmpeg.git 03Michael Niedermayer 07master:ed1eb9602c96: avformat/rmdec: check that sub_packet_size fit in the packet for DEINT_ID_GENR
[00:40] <cone-311> ffmpeg.git 03Paul B Mahol 07master:63debaa74c9c: libopusenc: Change default frame duration to 20 ms
[00:40] <cone-311> ffmpeg.git 03Michael Niedermayer 07master:0bad50522d34: Merge remote-tracking branch 'qatar/master'
[00:44] <t355u5> Hey guys. I think we need a more precise definition for the metadata language code in the documentation. The doc states: ISO 639. Well there are 5 ISO 639 standards: 639-1 639-2/T 639-2/B 639-3 639-6. True the doc also says 3 letter code, which narrows it down to 639-2/T 639-2/B 639-3. So which is it?
[01:03] <michaelni> t355u5, are there any 3 letter codes that have more than 1 meaning ?
[01:04] <michaelni> if not then it shouldnt matter in theory
[01:04] <michaelni> also i think the code predated -3
[01:04] <michaelni> predateS
[01:04] <t355u5> michaelni: yes
[01:05] <t355u5> michaelni: e.g. german could be ger or deu 
[01:05] <michaelni> no, thats not what i asked
[01:05] <t355u5> so what shall someone use?
[01:05] <michaelni> either in that case
[01:05] <michaelni> the code should understand both for german (in theory)
[01:06] <michaelni> if it doesnt in practice thats a bug
[01:06] <t355u5> that's my point. do we know that the code understands 639-2/T and 639-2/B
[01:07] <t355u5> this should be clarified in the documentation
[01:07] <t355u5> which it is not at this point
[01:07] <michaelni> yes
[01:08] <t355u5> michaelni: yes to what? yes to that we know that the code understands 639-2/T and 639-2/B or yes to that it should be in the docs
[01:09] <michaelni> when the docs dont list either it kind of implies that both would have  to be ok but it should be clearly written there
[01:10] <michaelni> the code should work but no i dont know if it does work
[01:11] <t355u5> I'm just saying the docs should be more clear. actually iso 639 is only mentioned for -alang and -slang, which are deprecated afaik. 
[01:12] <michaelni> t355u5, hmm you seem very interrested in this, do you want to send  a patch clearing the docs up ?
[01:13] <t355u5> michaelni: sure, so both codes are valid? I'll update the docs and send a patch
[01:14] <michaelni> i belive both are valid yes / i dont see a reason why not
[01:14] <michaelni> also its more robust if the code can handle both
[01:14] <michaelni> so it should even if it doesnt work currently
[01:16] <t355u5> michaelni: shall I fork on github and send a pull request?
[01:16] <michaelni> how many patches do you want to send ?
[01:17] <michaelni> if its just one then its maybe quicker to use git send-email
[01:17] <t355u5> don't know. depends on where the language stuff is mentioned in the docs
[01:17] <t355u5> and there are html and man pages
[01:17] <michaelni> if its a dozen sure pull request might make sense
[01:17] <michaelni> some of this is generated
[01:18] <t355u5> ok, I'll look a the src tree and check what I can find
[01:35] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:21b25537fb8f: avcodec/mpeg4videodec: use av_fast_padded_malloc() for bitstream buffer
[02:03] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:edc6f3da0ed5: avfilter/vf_format: check that the format list is not empty
[03:47] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:2d16a88a9c60: avcodec: move end zeroing code from av_packet_split_side_data() to avcodec_decode_subtitle2()
[03:47] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:3ffd1c2e40b6: avcodec/jpeg2000dec: Check precno before using it in JPEG2000_PGOD_CPRL
[03:47] <cone-584> ffmpeg.git 03Jan Gerber 07release/2.1:95b5496dce82: lavf/matroska*: add support for signed integers
[03:47] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:d86930b8ff28: avformat/matroska: simplify signed int access code
[03:47] <cone-584> ffmpeg.git 03Jan Gerber 07release/2.1:aee36a7d16db: lavf/matroska*: DiscardPadding is a signed integer
[03:47] <cone-584> ffmpeg.git 03Jan Gerber 07release/2.1:73aa4518eec4: lavf/matroskadec ReferenceBlock is a signed integer
[03:47] <cone-584> ffmpeg.git 03Paul B Mahol 07release/2.1:04a4c4144ade: avcodec/libopusenc: change default frame duration to 20 ms
[03:47] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:1ecd1b4aeeb4: avcodec/g2meet: fix stride calculation, use correct format field
[03:47] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:cf6cf50ac689: do O(1) instead of O(n) atomic operations in register functions
[03:47] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:e779595dcae4: avutil/log: skip IO calls on empty strings
[03:47] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:08808084f6e9: swscale/utils: fill xyz tables only when they will be used
[03:47] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:061e94815322: configure: support raising major version in soname
[03:47] <cone-584> ffmpeg.git 03Dale Curtis 07release/2.1:dcf0f82d08e8: h264: Clear ERContext.cur_pic when unref'ing current picture.
[03:47] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:572ccbd299f0: Merge commit '6139f481ac9feb1bee4e7d04789fb15d7f24ebbf'
[03:47] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:3976c50fc1ff: Merge commit 'cec5ce49229d61e4eb1f331a6d0dff3aa24f6655'
[03:47] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:2d7f20d2bbb1: Merge commit 'a639ea7f4bc44bf6bfa452675558a342924a66a9'
[03:48] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:b7cb77a3228f: Merge commit '2d2a92f72199823a92e4e226c32e42a27ec801c0'
[03:48] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:2fe67ddb243e: Merge commit 'b7462a3904d71ff799584faf5b875cad59ca2f31'
[03:48] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:1dcf9de6e995: Merge commit '2e09096da912f563c4dd889a8f25c314529bbaa6'
[03:48] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:bfe4aa892a53: Merge commit 'a837c4f2df96a30bf9aa4115b426d608487c7101'
[03:48] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:dcb91e3dfe07: Merge commit '3c8ea9d4a74fd4d7493d40c818ca64ee492709f3'
[03:48] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:8c53cacbfd32: Merge commit '4a4841d4e0f0dc50998511bf6c48b518012024db'
[03:48] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:dbb4ff685135: Merge commit '508b37557bf36eae83c18e64d42f27b44a321d81'
[03:48] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:48c192c48c3c: Merge commit '730bac7bab3c7dcd9fcb7c70f154e5f4cfaef9a7'
[03:48] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:badb8e15ac00: Merge commit 'e4155f15b35c4272a235f5521d2dc6c2aabdd462'
[03:48] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:9ebe344166e0: Merge commit '0ea430c75b8d90449d2878ad84669a2da2ad3cbc'
[03:48] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:8a9f4f8800c1: Merge commit '45bde93eefa78c1bdb0936109fbd2e2fb27fbfe7'
[03:48] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:6133f450bb81: Merge commit '57e7b3a89f5a0879ad039e8f04273b48649799a8'
[03:48] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:4d373ee8e4c9: Merge commit '97168b204a0b6b79bb6c5f0d40efdf7fc2262476'
[03:48] <cone-584> ffmpeg.git 03Michael Niedermayer 07release/2.1:9918296a2df1: Merge commit 'ffe04c330335add4c6d70ab0bb98e6b3f4f7abfa'
[03:48] <Compn> oh lawd
[03:48] <Compn> michaelni : so what do you think of that playlist api ?
[03:48] <Compn> horribly outdated and useless ?
[03:48] <Compn> and broken ?
[03:57] <michaelni> Compn, if the comunity likes the API and theres someone who wants to update/rebase it to ffmpeg git master and it works then i dont see a problem with it
[03:58] <Compn> haha ok
[03:58] <Compn> j-b wont do it ... hmmm
[03:58] <Compn> who wants playlist support
[04:04] <Daemon404> why would we need it?
[04:04] <Daemon404> seems pretty silly... better handled by the user app
[04:23] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:b0517467c0b6: avformat/webvttdec: Dont skip over a never checked byte after -->
[05:33] <Compn> Daemon404 : playing files in .rar or .zip ?
[05:33] <Compn> which is what vlc uses playlists for
[08:40] <j-b> 'morning
[10:25] <ubitux> BBB: looking at "vp9/x86: idct_32x32_add_ssse3 sub-8x8-idct." i just realized %2==%3 all the time in the VP9_MULSUB_2W_2X calls
[10:25] <ubitux> we might want to simplify this
[10:30] <ubitux> too bad the scan doesn't allow more than eob=1 for 8x8
[10:31] <ubitux> that's probably why it's not significant
[10:31] <ubitux> you might want to mention it
[10:33] <ubitux> no more comment frome me on the simd, except what i said last time
[10:33] <ubitux> (like macrotizing the bunch of stores in the 2nd pass)
[11:34] <saste> nevcariel: do you have experience with M$ Visualstudio/VC?
[11:35] <saste> yesterday I was compiling an application against libav* libs
[11:35] <saste> any reason we don't install the generated *.lib files?
[11:36] <nevcairiel> they should be installed, without them you cant link against the dlls
[11:36] <nevcairiel> i dont use the install target myself, i have a custom script that grabs the files i need
[11:36] <nevcairiel> so i would never notice
[11:36] <saste> you can, but you have to add the source paths, or I have to manually copy the .lib files around (I did the latter)
[11:37] <nevcairiel> make install assumes linux/unix folder structure, thats usually not ideal for windows, so i dont use the install target much
[11:37] <saste> where are the lib files installed usually then?
[11:38] <nevcairiel> many cases you have following folders: bin, lib, include .. i suppose you can guess what goes where
[11:38] <nevcairiel> but there is no strict standard everyone follows
[11:38] <saste> I'd place them in lib
[11:38] <nevcairiel> of course
[11:39] <nevcairiel> dlls in bin, libs in lib
[11:42] <wm4> dlls in bin? wut
[11:42] <JEEB> yup
[11:43] <JEEB> not needed when linking but needed at runtime
[11:44] <nevcairiel> bin is usually what you put in PATH or something like that, it'll find the dlls then
[11:44] <nevcairiel> or if your application executable is also in bin, it'll also find the dlls without PATH
[11:44] <nevcairiel> it wouldnt if they are in lib
[11:44] <ubitux> so binary libraries in lib, and dynamic libraries in bin
[11:44] <ubitux> @_@
[11:45] <nevcairiel> lib files arent full libs, they just tell the linker which functions are available
[11:45] <nevcairiel> (well, .lib files also can be static libraries, but lets assume we're talking dynamic here)
[11:46] <nevcairiel> but as JEEB pointed out, the difference is really between needed for runtime (bin), and needed for compile time (lib)
[11:46] <nevcairiel> you dont even need th dll to link the app, just the lib
[12:09] <saste> uhm muxing.c PTS video handling is broken
[12:12] <saste> the encoder is supposed to fill packet PTS/DTS, but then they must be rescaled to the stream timebase, right?
[12:16] <saste> michaelni, ^ ?
[12:17] <saste> (and of course all of this is not documented)
[12:18] <ubitux> muxing.c is definitely broken yes
[12:34] <BBB> 2w_2x?
[12:35] <BBB> oh right
[12:35] <BBB> yes
[12:35] <BBB> we can change that I guess
[12:35] <BBB> it's just an internal macro
[12:35] <BBB> ubitux: are the other patches ok to merge?
[12:37] <BBB> let me rebase while I'm at it
[12:38] <BBB> ubitux: I've rebased and added your patch in my github vp9-simd branch
[12:40] <ubitux> i don't remember my other comments, but probably yes
[12:41] <ubitux> also see the comment on the ml for the fix you sent
[12:43] <ubitux> BBB: you didn't pick the commit from github
[12:43] <ubitux> (it is faster)
[12:43] <ubitux> also, don't you think it should be comitted along with the horizontal?
[12:43] <ubitux> i'll hopefully be done with the transpose in a few days
[12:43] <ubitux> so we could have it
[13:00] <BBB> I couldn't pick from github
[13:00] <BBB> because it conflicted with my 32x32
[13:00] <BBB> (they both touch the same lines in vp9dsp_init.c)
[13:02] <ubitux> i'll rebase on yours if you want :p
[13:09] <cone-113> ffmpeg.git 03Stefano Sabatini 07master:2503928a2f8b: examples/decoding_encoding: fix style nits
[13:16] <cone-113> ffmpeg.git 03Diego Biurrun 07master:794fcf79a89e: Rename CONFIG_FFT_FLOAT ---> FFT_FLOAT
[13:16] <cone-113> ffmpeg.git 03Michael Niedermayer 07master:7778979f6f9c: Merge commit '794fcf79a89eca2d4e889803b2c804a0b1defbb3'
[13:16] <cone-113> ffmpeg.git 03Michael Niedermayer 07master:99b6357f37b7: rename CONFIG_FFT_FIXED_32 -> FFT_FIXED_32
[13:21] <cone-113> ffmpeg.git 03Diego Biurrun 07master:9997cee04d6a: network.h: Add #endif comments to improve readability
[13:21] <cone-113> ffmpeg.git 03Michael Niedermayer 07master:77274d5c79a1: Merge remote-tracking branch 'qatar/master'
[13:25] <BBB> ubitux: fixed
[13:26] <BBB> (see github or ml)
[13:26] <BBB> I've pushed new tree to my github, I can remove your patch and then submit for merge if you're ok with it
[13:27] <ubitux> yes please don't merge my commit
[13:28] <ubitux> the one you picked really is outdated
[13:28] <ubitux> and i want to add horizontal
[13:29] <ubitux> BBB: VP56mv is used in various places in the decoder, not problematic?
[13:30] <ubitux> and so, you don't want to write a macro for the stores in the 2nd pass of the 32x32?
[13:52] <BBB> ubitux: we only use it for comparisons, we never read the struct as a whoile directly
[13:52] <BBB> ubitux: so I think it's safe
[13:53] <ubitux> k
[13:53] <BBB> oh macro for 2nd pass stores, ehm, nah, we only use it once
[13:53] <BBB> if there was a 64x64, I'd say yes
[13:53] <BBB> and removed your patch from my github branch
[13:55] <ubitux> once?
[13:55] <ubitux> you have 8x the same dozens lines
[13:56] <ubitux> https://github.com/rbultje/ffmpeg/commit/2e5e39ddbe849389d2e41fde0abc61167b43bb6a#diff-0baff159a80f40fd945c3dfe1f6d63a8R942
[13:56] <ubitux> i'm talking about those chunks
[14:07] <BBB> oh that
[14:07] <BBB> sorry, I misunderstood
[14:07] <BBB> hm, maybe not a bad idea
[14:07] <BBB> yes will change that
[14:13] <zozoh> Hi, did it possible copy AVCodecContext struct to a remote process ?
[14:14] <zozoh> I want to write two little program, one run on local, which open a Video, and reading AVPackets
[14:15] <cone-113> ffmpeg.git 03Michael Niedermayer 07master:8ca9a68f1905: avcodec/flacdec: check rice_order against blocksize
[14:16] <zozoh> @cone-113, sorry, response to me?
[14:18] <ubitux> cone-113 is a bot, displaying here the just recently pushed commit
[14:19] <zozoh> oh
[14:20] <zozoh> -_-!
[14:23] <BBB> zozoh: you need to serialize the avcodeccontext information from one machine to the next, see e.g. how gstreamer or so do it
[14:25] <zozoh> I had already send the AVCodecContext to remote, all fields had be recover, except the "thread_opaque"
[14:27] <wm4> zozoh: that won't work
[14:28] <wm4> you can try to recreate the AVCodecContext by initializing it in the same way
[14:28] <wm4> but you can't copy its state
[14:28] <wm4> not even if you copy all AVCodecContext fields
[14:28] <zozoh> so, I create another AVCodecContext instance, 
[14:29] <zozoh> and just set my "thread_opaque" to the created one, then it work
[14:29] <zozoh> just like this:
[14:29] <zozoh> dec->cc->get_buffer = avcodec_default_get_buffer;
[14:29] <zozoh>                 dec->cc->release_buffer = avcodec_default_release_buffer;
[14:29] <zozoh>                 dec->cc->get_format = avcodec_default_get_format;
[14:29] <zozoh>                 dec->cc->reget_buffer = avcodec_default_reget_buffer;
[14:29] <zozoh>                 dec->cc->draw_horiz_band = NULL;
[14:30] <zozoh>                 dec->cc->rtp_callback = NULL;
[14:30] <zozoh>                 dec->cc->execute = avcodec_default_execute;
[14:30] <zozoh>                 dec->cc->execute2 = avcodec_default_execute2;
[14:30] <wm4> this is horrible, unsupported, and will fail hard on the next possible occasion
[14:30] <zozoh> and the key is :
[14:30] <zozoh>           dec->cc->thread_opaque = cc2->thread_opaque;
[14:30] <wm4> thread_opaque is even deprecated and probably not used anymore
[14:31] <zozoh> en... I do think it is horrible too 
[14:31] <zozoh> this is a old version ffmpeg , maybe a year ago
[14:31] <wm4> if you want a remote AVCodecContext with the same state, all you can do is 1. initialize a second AVCodecContext using the same parameters (codec, extradata, etc.) and 2. call exactly the same operations on the second context
[14:31] <wm4> then it might work
[14:32] <zozoh> so , did it some formal way to copy the AVCodecContext to remote ?
[14:33] <zozoh> @wm4 thanks man :)
[14:34] <zozoh> and I think I really do lots of bad things in my code 
[14:35] <wm4> in parts, the ffmpeg API will make you do bad things, because it doesn't always make clear whether something is allowed or not
[14:37] <zozoh> refer the "avcodec_copy_context" , I spend few night to compare the bytes I dump from AVCodecContext one by one
[14:39] <zozoh> and finally, I find the big issue of "thread_opaque", seems it is wrong direction
[14:39] <wm4> what are you even trying to do?
[14:40] <zozoh> wm4  "2. call exactly the same operations on the second context"  <- the operations include "avcodec_open2" etc.. ?
[14:41] <wm4> yes
[14:42] <zozoh> I try to make many player  receive  same AVPackets at same time
[14:43] <zozoh> base on that, I can make frame leave sync cross machine
[14:43] <zozoh> and streaming base
[14:49] <wm4> yeah, then you probably just need to initialize all contexts in the same way
[14:49] <wm4> so you need a remote equivalent of avcodec_copy_context
[14:50] <wm4> looking at avcodec_copy_context isn't a good idea though
[14:50] <wm4> the way it does thing is not safe for applications
[14:50] <wm4> I don't know if the fields required for correct decoding are documented anywhere, maybe not
[14:52] <nevcairiel> its really not that many
[14:54] <zozoh> @wm4 if I play a 1G video, the video file save in local, I can hardly let remote to initialize the contexts in same way ...
[14:54] <zozoh> @nevcairiel sorry? 
[14:54] <wm4> this is my own list of fields that need to be copied for equivalent initialization: http://privatepaste.com/94f4abfb7e
[14:55] <nevcairiel> chroma_sample_location?
[14:55] <wm4> when I wrote this, this some demuxers set it, but it wasn't transferred over side data
[14:55] <nevcairiel> y4m sets it i suppose
[14:57] <nevcairiel> audio_service_type is also more informational then anything else, and personally i've never missed stream_codec_tag, but the others i use as well
[14:58] <zozoh> @wm4 it worked in same process, 
[14:59] <zozoh> but if you copy it to remote, same function pointer should be invalid, and make the segment fail
[14:59] <wm4> what function pointers?
[15:00] <zozoh> ->get_buffer
[15:00] <zozoh> ->->release_buffer
[15:00] <wm4> normal AVCodecContext initialization sets these
[15:01] <zozoh> you mean by "avcodec_get_context_defaults" ?
[15:01] <wm4> no
[15:02] <wm4> I think you should be calling avcodec_alloc_context3, then set your parameters (extradata etc.), then call avcodec_open2
[15:02] <zozoh> what I known is "avcodec_open2" will not change them
[15:02] <zozoh> oh~
[15:03] <zozoh> en ... let me try in this way
[15:03] <zozoh> thanks :)
[15:04] <zozoh> I gotta go for supper, @wm4, thanks again
[18:33] <cone-113> ffmpeg.git 03Michael Niedermayer 07master:2303b45112b4: avformat/segafilm: drop song and dance, this seems not to do anything anymore since a long time
[18:34] <cone-113> ffmpeg.git 03Michael Niedermayer 07master:8aead3ffa89a: avformat/adxdec: dont return random data on EOF
[19:55] <llogan> saste: did you see [PATCH] doc/filters/equalizer: add examples for equalizer
[20:06] <cone-113> ffmpeg.git 03Michael Niedermayer 07master:243b9fea90aa: avformat/takdec: zero padding area before use
[20:55] <saste> llogan, yes i was expecting a reply from the filter author
[20:55] <llogan> i haven't seen him around much
[21:07] <cone-113> ffmpeg.git 03Lou Logan 07master:2574d62d0dd3: tools/qt-faststart: add -movflags +faststart note
[21:12] <cone-113> ffmpeg.git 03Werner Robitza 07master:53df11eb73bd: doc/filters/equalizer: add examples for equalizer
[21:35] <cone-113> ffmpeg.git 03Michael Niedermayer 07release/2.1:7442aa20fad1: Merge commit 'd48c20630214a4effcc920e93a5044bee4e2002e'
[21:35] <cone-113> ffmpeg.git 03Michael Niedermayer 07release/2.1:345e2a2b4388: Merge remote-tracking branch 'qatar/master'
[21:36] <cone-113> ffmpeg.git 03Michael Niedermayer 07release/2.1:82ec6183bcad: Merge commit 'e2274aa555f023e4f4e4819bf29b2d7e0adec7d5'
[21:36] <cone-113> ffmpeg.git 03anatoly 07release/2.1:f448478a311f: Add support for picture_ptr field in MJpegDecodeContext
[21:36] <cone-113> ffmpeg.git 03Michael Niedermayer 07release/2.1:09965ae7d810: Merge commit 'afa21a12bf084f905187615706b0a8d92bc98661'
[21:36] <cone-113> ffmpeg.git 03Michael Niedermayer 07release/2.1:caf7db0c35e8: Merge commit 'b605b123ef1d3bac0e7c221d8d7fa74cd8c7253c'
[21:36] <cone-113> ffmpeg.git 03Michael Niedermayer 07release/2.1:117728cf8ff9: Merge commit 'd351ef47d0e0ccb7de96b37f137c16b2885580ac'
[21:36] <cone-113> ffmpeg.git 03Michael Niedermayer 07release/2.1:9f864bd3247b: Merge commit 'd4f1188d1a662fed5347e70016da49e01563e8a8'
[21:36] <cone-113> ffmpeg.git 03Michael Niedermayer 07release/2.1:ed621efb361b: avcodec/libutvideodec: use av_frame_move_ref()
[21:36] <cone-113> ffmpeg.git 03Michael Niedermayer 07release/2.1:304260a5722f: avcodec/utils: implement avcodec_alloc_frame() through av_alloc_frame()
[21:36] <cone-113> ffmpeg.git 03Michael Niedermayer 07release/2.1:fa220e730786: avcodec/diracdec: avoid depending on sizeof(AVFrame)
[21:36] <cone-113> ffmpeg.git 03Michael Niedermayer 07release/2.1:31c52cd44279: avcodec/msvideo1enc: drop dependancy on sizeof(AVFrame)
[21:36] <cone-113> ffmpeg.git 03Michael Niedermayer 07release/2.1:d2578f815237: avcodec/mjpegenc: drop dependancy on sizeof(AVFrame)
[21:36] <cone-113> ffmpeg.git 03Michael Niedermayer 07release/2.1:965eb42be03c: avcodec/libopenjpegenc: drop dependancy on sizeof(AVFrame)
[21:36] <cone-113> ffmpeg.git 03Michael Niedermayer 07release/2.1:ce675bd54a07: avcodec/j2kenc: drop dependancy on sizeof(AVFrame)
[21:36] <cone-113> ffmpeg.git 03Michael Niedermayer 07release/2.1:4d4a10cfa1ec: avcodec/flashsv2enc: drop dependancy on sizeof(AVFrame)
[21:36] <cone-113> ffmpeg.git 03Michael Niedermayer 07release/2.1:e0c3c612eb42: ffprobe: drop dependancy on sizeof(AVFrame)
[21:36] <cone-113> ffmpeg.git 03Michael Niedermayer 07release/2.1:d05858351094: avcodec/libvorbisenc: drop dependancy on sizeof(AVFrame)
[21:36] <cone-113> ffmpeg.git 03Michael Niedermayer 07release/2.1:ca22a2dec561: avcodec/utils: drop 2 dependancies on sizeof(AVFrame)
[21:36] <cone-113> ffmpeg.git 03Michael Niedermayer 07release/2.1:88058b4650f5: ffprobe: Dont clear AVFrame between uses.
[21:36] <cone-113> ffmpeg.git 03Nicolas George 07release/2.1:89205b637e23: lavc/ffwavesynth: fix dependency sizeof(AVFrame). (cherry picked from commit bcfcb8b8524dfcc1c37d520ccf3fba3b3a4c104d)
[21:36] <cone-113> ffmpeg.git 03Nicolas George 07release/2.1:a6ba0f7be91f: ffprobe: check av_frame_alloc() failure. (cherry picked from commit a55692a96099c40aabb25e1443890be99f9c845c)
[21:36] <cone-113> ffmpeg.git 03Nicolas George 07release/2.1:4d70639d536d: lavc/utils: check av_frame_alloc() failure. (cherry picked from commit 38004051b53ddecb518053e6dadafa9adc4fc1b2)
[21:36] <cone-113> ffmpeg.git 03Nicolas George 07release/2.1:4c3cd8814411: lavc/diracdec: check av_frame_alloc() failure. (cherry picked from commit a91394f4de63ae5c2e21c548045b79393ca7fea1)
[21:36] <cone-113> ffmpeg.git 03Nicolas George 07release/2.1:4b25b5a8a3c0: lavc/libopenjpegenc: check av_frame_alloc() failure. (cherry picked from commit 97af2faaba70c866ae4c11459a79a16d4a014530)
[21:36] <cone-113> ffmpeg.git 03Nicolas George 07release/2.1:9189a0a71ba4: lavc/mjpegenc: check av_frame_alloc() failure. (cherry picked from commit 19a2d101acc0260bb310e79010a8491b10716189)
[21:36] <cone-113> ffmpeg.git 03Nicolas George 07release/2.1:3dae9d13e51c: lavc/mjpegenc: use proper error codes. (cherry picked from commit 2ebaadf35c9387610ca1eb7e94c171050562a77c)
[21:51] <wm4> hm vobsubs in mp4 seem to be broken
[21:51] <wm4> though I have only one sample
[21:51] <nevcairiel> those evil vobsubs
[21:52] <wm4> on libav it works, on ffmpeg it behaves as if extradata is missing or broken
[21:52] <nevcairiel> i think i did something to fix them
[21:52] <nevcairiel> oh right
[21:52] <nevcairiel> mp4 has its own extradata format
[21:52] <Compn> since when can you mux vobsub in mp4
[21:53] <nevcairiel> it stores the palette data in YUV without the vobsub header
[21:53] Action: Compn runs away
[21:53] <nevcairiel> so i wiped up some quick code to convert it into a normal vobsub header
[21:55] <wm4> here's a sample https://dl.dropboxusercontent.com/u/3219541/gundam_sample.mp4
[21:56] <wm4> seems to have multiple subtitle tracks, of which the second shows something 10 seconds in
[21:56] <wm4> the extradata parser in dvdsubdec.c expects text (.idx style), but the first byte is \0
[21:57] <nevcairiel> yeah like i remembered, it probably contains a palette in yuv, and in binary - not text
[21:58] <nevcairiel> at least thats how a file looked i had before
[21:58] <wm4> even if it does, how come it works on Libav?
[21:58] <nevcairiel> no idea, i dont see any special handling
[21:58] <nevcairiel> maybe their dvd decoder simply copes better with the lack of a palette?
[21:59] <wm4> it looks too correct for that
[21:59] <wm4> the file is 1080p, and 1080p vobsubs is rare
[21:59] <nevcairiel> so HD vobsubs?
[21:59] <wm4> yes
[21:59] <nevcairiel> those contain a in-band palette
[21:59] <wm4> hm
[21:59] <nevcairiel> or can, at least
[21:59] <wm4> what about resolution?
[22:00] <wm4> the resolution is wrong on ffmpeg too, and right on Libav
[22:00] <wm4> dvdsubdec.c looks like this can't be in-band
[22:00] <nevcairiel> no clue about that
[22:01] <nevcairiel> maybe it inits the sub decoder with the video resolution
[22:01] <nevcairiel> or something is indeed broken in the mov demuxer
[22:02] <wm4> I can't seem to find anything vobsub specific in the mov demuxer, other than the ID mapping on isom.c
[22:03] <nevcairiel> interestingly, the MOVStreamContext says 1920x1080 for the sub stream
[22:04] <nevcairiel> (in ffmpeg)
[00:00] --- Wed Jan  8 2014