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

[burek]

[01:44] <cone-976> ffmpeg.git 03Lukasz Marek 07master:7d75a399a4d2: lavc/options: fix rc_eq leak
[01:44] <cone-976> ffmpeg.git 03Lukasz Marek 07master:ab922f9ef1e4: lavu/dict: add av_dict_get_string
[03:44] <cone-976> ffmpeg.git 03Michael Niedermayer 07master:f0ae0354d3f0: avformat/avidec: fix handling dv in avi
[07:59] <xxthink> how to display detailed info of the ffmpeg compile command ?
[07:59] <xxthink> now it displays CC libavcodec/x86/vc1dsp_mmx.o
[07:59] <xxthink> YASM ...
[07:59] <xxthink> I want to display the compile command in detail
[08:00] <xxthink> I have forgot how to modify the makefile
[08:01] <[mbm]> usually "make V=1"
[08:01] <xxthink> ok
[08:56] <wm4> do I understand this right that v4l now provides yet another hw decoding API??
[10:02] <j-b> wm4: maybe
[10:04] <j-b> Yes, my codec outputs something noone can play, but it's GOOD!
[10:10] <wm4> arm soc something something blabla
[10:11] <j-b> So?
[10:11] <wm4> apparently socs mean you are allowed to write terrible software
[10:11] <j-b> There are already too many PIXFMT for no good reasons
[10:11] <wm4> also this is a weird format
[10:11] <j-b> adding one that will stay for the next 10 years, because of some obscure format got in v4l is stupid
[10:11] <wm4> it'd be the first tiled one
[10:11] <j-b> yes
[10:12] <j-b> and it should not be a precedent
[10:12] <j-b> So, basically, noone can display it, reencode or do anything with it, without the filter.
[10:15] <j-b> seriously...
[10:18] <wm4> I agree
[10:18] <wm4> the main problem is that it breaks too many assumptions
[10:29] <cone-758> ffmpeg.git 03Michael Niedermayer 07release/2.1:2d0b2db27e84: avformat/avidec: fix handling dv in avi
[10:29] <cone-758> ffmpeg.git 03Michael Niedermayer 07release/2.2:bf219a564c42: avformat/avidec: fix handling dv in avi
[10:29] <cone-758> ffmpeg.git 03Michael Niedermayer 07release/2.3:b6ff3acafcc9: avformat/avidec: fix handling dv in avi
[10:29] <cone-758> ffmpeg.git 03Michael Niedermayer 07release/2.4:944570906b74: avformat/avidec: fix handling dv in avi
[10:34] <cehoyos> thardin: The patch was already merged: http://ffmpeg.org/pipermail/ffmpeg-devel/2014-November/165532.html
[10:34] <cehoyos> Thank you for looking at it, I wondered how reliable the information is...
[10:35] <thardin> yeah, I recall doing something similar so.. :)
[10:36] <cehoyos> Do you have an idea about the sample in http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2345/
[10:36] <cehoyos> Iirc, you said that it is possible to detect the "JPEG 2000 pictures" string in the file
[10:38] <thardin> it's probably possible to detect, but I've been somewhat less than enthusiastic about supporting files from broken muxers
[10:39] <cehoyos> That's how FFmpeg works...
[10:39] <thardin> it may be better to mail the muxer devs if they're actually doing the wrong thing( I don't recall what the problem here was)
[10:39] <cehoyos> When demuxing I mean!
[10:39] <nevcairiel> there is a degree of broken where you should just refuse instead of piling hacks on top of hacks
[10:39] <nevcairiel> otherwise muxers never get fixed, since it "works"
[10:40] <cehoyos> And it is not less broken imo to store a h264 stream with a wrong SAR and expect that the player reads the DAR
[10:40] <thardin> but that's the way it's supposed to work
[10:40] <thardin> at least in the MXF world
[10:40] <cehoyos> I am not convinced this applies here: The file contains "JPEG 2000" iirc, so it can hardly be something else.
[10:41] <thardin> I should say that I don't actually know if the file has any problem or just that mxfdec doesn't have the corresponding codec UL added
[10:42] <cehoyos> Is it possible that there is no UL (sorry, I am not 100% sure I remember correctly)
[10:42] <cehoyos> ?
[10:43] <thardin> that's possible
[10:43] <thardin> one thing: [mxf @ 0x7fc2d40008c0] "OPAtom" with 2 ECs - assuming OP1a
[10:43] <benoit-> j-b: I don't think it's *that* stupid
[10:43] <thardin> is because mxfdec doesn't derive WrappingKind from codec UL like it should
[10:43] <j-b> benoit-: I do think, it's extremly bad.
[10:44] <thardin> I've been wanting to somehow bring parts of libbmx in for that stuff
[10:44] <benoit-> j-b: i can understand that it opens a door, which is what is bad, right?
[10:44] <thardin> but alas the NIH runs deep
[10:44] <benoit-> because on itself, the format introduction is not
[10:47] <j-b> benoit-: yes.
[10:49] <benoit-> (I forgot the "from your point of view")
[10:51] <j-b> So?
[10:52] <j-b> Adding total crap, because of one specific device that is already obsolete is really a bad thing
[10:54] <j-b> Can any of you, explain, out of his head, what is NV12 ?
[10:54] <j-b> I guess the answer is yes for most of you.
[10:55] <j-b> Can any of you, explain, out of his head, what is this format ?
[10:55] <j-b> I guess the answer is no for almost everyone of you.
[10:55] <wm4> the question _what_ this format is is slightly unrelated, but I still wonder
[10:56] <j-b> it's not.
[10:56] <wm4> i.e. the exact representation
[10:56] <j-b> If you cannot explain what the representation is, then it shouldn't be a non-opaque PIX_FMT
[10:56] <wm4> AV_PIX_FMT_UYYVYY411 is my favorite pixfmt
[10:57] <wm4> I wish we could at least remove the endian-swapped formats
[10:58] <j-b> or the 9bits formats...
[10:58] <j-b> AV_PIX_FMT_YUVA420P9BE
[11:00] <nevcairiel> if you want to remove 9, you should also remove 10, 12 and 14
[11:00] <wm4> what about the 10, 12, 14 ones
[11:00] <nevcairiel> its all two-byte formats
[11:01] <wm4> so, apparently these odd bit widths make it easier to process the data, because you can keep them in a 16 bit register without the danger that intermediate results overflow
[11:02] <wm4> but as far as that argument goes, wouldn't a 14 bit format be enough?
[11:03] <nevcairiel> that doesnt change their pixfmt representation
[11:03] <nevcairiel> obviously  there would need to be another flag that identifies the actual number of used bits
[11:03] <wm4> like with audio?
[11:03] <nevcairiel> (especially since libav* has them in the lower bits, not the higher bits)
[11:03] <cehoyos> The 9, 10, 12 and 14 bit formats were added by x264 for performance reasons, see Reimar's explanation a few weeks ago.
[11:05] <cehoyos> Only nine and ten, sorry
[11:06] <j-b> nevcairiel: 10 could make sense, because of 30bits inside 32 bits
[11:06] <nevcairiel> but thats packed
[11:06] <cehoyos> That's not what "10" means in pixfmt.h
[11:10] <wm4> and, uh, what's up with these Bayer formats?
[11:11] <j-b> same remark, sorry :)
[11:11] <j-b> but it's less bad
[11:25] <benoit-> j-b: I really like the "less bad" view :)
[15:19] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:367c9d33d6dd: avformat: replace some odd 30-60 rates by higher less odd ones in  get_std_framerate()
[15:24] <Daemon404> michaelni, ping, re: 367c9d33d6dd
[15:25] <Daemon404> i dont think tha taxtuall fixes slomo mov from iphone (QT uses metadata to detect it)
[16:08] <michaelni> Daemon404, the commit was intended to fix the regression. if the file is intended to play differently, then i didnt realize this, i might look into that too but i think it would be ideal if these 2 issues would be seperate tickets
[16:09] <Daemon404> apple has a "special" way to flag "slomo" videos from iphone
[16:09] <Daemon404> and quicktime more or less plays ix 10x slower during playback
[16:46] <michaelni> Daemon404, do you know where/how that metadata is stored ?
[16:46] <Daemon404> not 100%, but mostly. it's a hack from apple.
[16:47] <Daemon404> i wasnt the one who figured it out, ill wait on them.
[16:47] <Daemon404> at best it should be sidedata anyway.
[17:25] <cone-758> ffmpeg.git 03Benoit Fouet 07master:33acebd3ccfc: avcodec/pngdec: add APNG support.
[17:25] <cone-758> ffmpeg.git 03Benoit Fouet 07master:5d37d70b0b7c: avformat/apngdec: add APNG demuxer.
[17:47] <jamrial> guess we can remove that from the GSoC template
[17:48] <jamrial> oh, Compn already edited the wiki, haha
[18:28] <cehoyos> michaelni: The sample from ticket 4012 works fine with versions 2.1 and earler. Should I backport your change to 2.2., 2.3 and 2.4 (assuming it is possible) or better not?
[18:28] <cehoyos> Daemon404: Hi, did you have time to find out "ffmpeg -i" info about the Prores sample?
[18:46] <michaelni> cehoyos, not sure, maybe wait a week or so in case it causes any regressions but if no regressions then yes backport is ok if no conflicts
[18:51] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:c05310d4699c: avdevice/pulse_audio_common: Use av_freep(), avoid leaving stale pointers
[18:51] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:883f85fa8ffd: avdevice/fbdev_common: Use av_freep(), avoid leaving stale pointers
[18:51] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:6995be43aee5: avdevice/avdevice.c: Use av_freep(), avoid leaving stale pointers
[18:51] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:2ae2c60554c2: avcodec/vp6: Use av_freep(), avoid leaving stale pointers
[19:32] <rcombs> benoit-: why, re: comment on dash patch?
[20:20] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:d96d8e121f1e: avcodec/libspeexdec: support zygoaudio
[20:20] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:018ce902840a: avcodec/libspeexdec: more verbose error message
[20:49] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:0c3ebbf6a54d: Changelog: add zygoaudio
[21:27] <cone-758> ffmpeg.git 03Martin Storsjö 07master:aa8b39d99958: lavc: Move the libtwolame encoder registration to the list for external libraries
[21:27] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:5af0a701a1c0: Merge commit 'aa8b39d999589154f79300de9038994d0093cd34'
[21:39] <cone-758> ffmpeg.git 03Luca Barbato 07master:fd9badd3cb3b: xwma: Do not leak on failure path
[21:39] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:15ed7ca437a8: Merge commit 'fd9badd3cb3b60f5c54dcea35523e1ecca2f67a6'
[21:41] <ubitux> https://launchpad.net/ubuntu/+source/ffmpeg/7:2.4.3-1 so... we're now back on ubuntu?
[21:44] <kierank> interesting
[21:57] <kierank> can we make our opw crypto student work on aes-ni :)
[22:25] <cone-758> ffmpeg.git 03Vittorio Giovara 07master:863ee8a855b8: lavfi: clean memory on error in ADD_FORMAT()
[22:25] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:42f3cb419aa0: Merge commit '863ee8a855b8ce27ffef41479eb66da58763faed'
[22:25] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:75819fafd821: avfilter/formats: free the correct pointer in ADD_FORMAT()
[22:25] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:b9ffafbfcc0f: avfilter/formats: Alloc NULL fmts in SET_COMMON_FORMATS()
[23:03] <cone-758> ffmpeg.git 03Vittorio Giovara 07master:a42d5c861fea: libtwolame: prevent a NULL pointer dereference
[23:03] <cone-758> ffmpeg.git 03Luca Barbato 07master:d466d82faaf6: dvdsubdec: Do not leak on failure path
[23:04] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:ad2424e6b298: Merge commit 'a42d5c861fea8d18d997c6ba3f4a1d8aa95a288b'
[23:04] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:ac967ad8724e: Merge commit 'd466d82faaf6e0e57a3a4be5e38e3902ef251ac3'
[23:11] <rcombs> anyone have thoughts on using dlopen/dlsym to load AVFoundation, so a binary that supports it could still be 10.6-compatible?
[23:15] <rcombs> &actually, would that even work for obj-c stuff?
[23:37] <cone-758> ffmpeg.git 03Luca Barbato 07master:312daa15891d: vp9: Use the correct upper bound for seg_id
[23:37] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:a82f3de053a7: Merge commit '312daa15891dc7abb77a404fe927d5ee35c52a71'
[23:56] <cone-758> ffmpeg.git 03Vittorio Giovara 07master:1f80742f49a9: qdm2: avoid integer overflow
[23:56] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:70e3fae88d59: Merge commit '1f80742f49a9a4e846c9f099387881abc87150b2'
[00:00] --- Sat Nov 22 2014