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

[burek]

[00:02] <Timothy_Gu> ubitux: pretty sure now I know who made this possible :) http://imgur.com/vidgif
[00:02] <ubitux> sorry, not me
[00:03] <ubitux> and it was before i did the work in ffmpeg
[00:03] <ubitux> not working for imgur, even though i spend a lot of time on it :p
[00:10] <ubitux> also iirc they use a palette per frame (and they are huge)
[00:11] <ubitux> last gif i looked at was something like 150M for a few seconds of video
[00:13] <cone-325> ffmpeg.git 03Thomas Volkert 07master:c99915f7c74c: rtpdec: DV depacketizer (RFC 6469)
[00:13] <cone-325> ffmpeg.git 03Michael Niedermayer 07master:db4a2976f6af: Merge commit 'c99915f7c74ce1249d8633cb6fd09035b8d84db7'
[00:15] <Timothy_Gu> ubitux: oh ok
[00:30] <cone-325> ffmpeg.git 03Martin Storsjö 07master:e2220e734f3d: rtpenc_h264: Aggregate multiple NAL units into one RTP packet, if possible
[00:30] <cone-325> ffmpeg.git 03Michael Niedermayer 07master:17c52d746cad: Merge commit 'e2220e734f3d01145ef9aefbd7b6ff29a89ae159'
[00:41] <cone-325> ffmpeg.git 03Martin Storsjö 07master:a388e72d1a6b: rtpenc_hevc: Aggregate multiple NAL units into one RTP packet, if possible
[00:41] <cone-325> ffmpeg.git 03Michael Niedermayer 07master:fab8b88a5ebc: Merge commit 'a388e72d1a6b0888cc1591cb699f61a9c1089cf4'
[02:26] <cone-325> ffmpeg.git 03Andreas Cadhalpun 07master:39e4ed7c1d8d: avcodec/a64multienc: use av_frame_ref instead of copying the frame
[02:26] <cone-325> ffmpeg.git 03Michael Niedermayer 07master:d96142e9af92: avcodec/a64multienc: don't set incorrect packet size
[02:26] <cone-325> ffmpeg.git 03Andreas Cadhalpun 07master:ab759f8f4a3f: avcodec/a64multienc: initialize mc_meta_charset to zero
[02:26] <cone-325> ffmpeg.git 03Andreas Cadhalpun 07master:87513d654546: avcodec/a64multienc: fix use of uninitialized values in to_meta_with_crop
[02:26] <cone-325> ffmpeg.git 03Michael Niedermayer 07master:4da351ff0cff: avcodec/a64multienc: simplify frame handling code
[02:27] <cone-325> ffmpeg.git 03Michael Niedermayer 07master:29bbc1be488e: avcodec/a64multienc: Assert that the Packet size does not grow
[07:21] <j-b> 'morning
[09:10] <guruqu> Hi All
[09:10] <guruqu> I have a question about how FFMpeg handle Mpeg TS
[09:10] <guruqu> I currently have a program that receives a Mpeg TS (mjpeg) stream in UDP
[09:10] <guruqu> And streamlined those packets into a http TCP connection
[09:10] <guruqu> On the ffplay, picture looks fine
[09:11] <guruqu> however when I tried the same thing on x264 instead of mjpeg
[09:11] <guruqu> Picture looks very jitterish
[09:11] <guruqu> If I revert back to use the UDP TS on x264, everyting works fine again
[09:12] <guruqu> Just wondering is it a good practice to push UDP Mpeg TS directly into a TCP?
[10:16] <cone-692> ffmpeg.git 03Clément BSsch 07master:b0f522755899: avfilter/paletteuse: fix error dithering accuracy
[10:16] <cone-692> ffmpeg.git 03Clément BSsch 07master:92b7f5619361: avfilter/paletteuse: add diff_mode
[10:17] <ubitux> if anyone wants to make the (error) dithering faster, patch very welcome
[10:39] <Guest73671> BtbN, yuv->rgb with the render kernels are suboptimal as the shader code would also check for video format on each fragment (if nv12,i420,yv12)
[10:40] <Guest73671> never measured it, but I presume it could have a performance it
[10:40] <Guest73671> yuv->rgb occurs when you transfer from the VA surface to the X pixmap
[10:41] <Guest73671> several other encoding APIs have been proposed, for a much more simplified usage, and in view to supporting future generations easily
[10:42] <__gb__> BtbN, the VA/EGL API, as it is currently included in the libva/API set is useless, not used, and not going to be implemented on Intel HD Graphics
[10:43] <__gb__> the modern approach is to use dma_buf and let you manage your own shader code, or support that right into Mesa (OES_image_external)
[10:43] <__gb__> I had already pointed you to several examples, ffvademo is one such simplified test case
[10:43] <__gb__> libgstvaapi is another one
[10:44] <__gb__> note: the existing VA/EGL API still needs to be removed actually to avoid further confusion
[10:44] <__gb__> actually a cleaned up/refreshed libva2 api is much needed
[10:45] <__gb__> in my ideals, you don't need any render api on top of the decode ones, there are pretty much rendering options around already...
[11:02] <wm4> show me one that can be used in practice
[11:02] <wm4> which means broad support for backends and hw
[11:04] <__gb__> broad support for backends? if proprietary, you won't have much luck beyond GLX_EXT_texture_from_pixmap
[11:04] <__gb__> however, if you want to support open source drivers, that's pretty much possible
[11:05] <__gb__> or are you talking about rendering APIs?
[11:06] <wm4> GL interop
[11:07] <__gb__> in this case, the answer was supplied :)
[11:10] <michaelni> ubitux, i think the palette filters need some fate tests
[11:10] <ubitux> michaelni: yeah, agreed :)
[11:10] <ubitux> i'll try to do that this week
[11:11] <ubitux> it's a bit tricky because one depend on the other, but i guess i'll make 2 independant tests, if you allow me to upload a small palette to fate (a 16x16 png)
[11:12] <michaelni> sure
[11:18] <cone-692> ffmpeg.git 03Vittorio Giovara 07master:f7cc6627c01a: configure: Use pkg-config for libdc1394 discovery
[11:19] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:69c32456a045: Merge commit 'f7cc6627c01ad3f5bc6ea2d0e6f8adb3a0b490d7'
[11:39] <cone-692> ffmpeg.git 03Vittorio Giovara 07master:521979e6b1e7: configure: Properly fail when libcdio/cdparanoia is not found
[11:39] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:0425e16d96cc: Merge commit '521979e6b1e7a89751aebc285a40d6508f8af48f'
[11:47] <__gb__> btw, if you want to experiment yourself with a few lines of code in the VA driver and a new enough driver, and if you really insist on persuing on GLX, then there may be a possibility to (i) use a PBO and map it as writable, (ii) use that address to import into a VA surface with mem_type == userptr (support code to be added in VA driver < 20 lines) + layout == linear, then you can use vpp to transfer from a VA surface in native format (nv12 
[11:47] <__gb__> tiled) to a GL texture in GLX world
[11:47] <__gb__> s/btw/& wm4/
[11:48] <__gb__> iirc, that'd need kernel >= 3.16 + one of chris' patch to fixup lookup of page [assumed then for 3.17]
[11:50] <wm4> thanks, but the only reason I was sticking to GLX was because it appeared to be sufficiently efficient and portable
[11:50] <wm4> but both of these hopes have been sort of disappointed
[11:51] <wm4> reading back to system RAM seems like the best option now
[11:52] <cone-692> ffmpeg.git 03Vittorio Giovara 07master:e570f895cdcc: libschroedinger: Check memory allocations
[11:52] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:96b495f44383: Merge commit 'e570f895cdccf2535a71fec1c607751ddb94fd5a'
[12:01] <cone-692> ffmpeg.git 03Carl Eugen Hoyos 07master:36a6fb989b01: hevc_deblock: Fix compilation with nasm
[12:02] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:c0f02b220182: Merge commit '36a6fb989b017898041703025ef20028146675a8'
[12:06] <ubitux> michaelni: i'm afraid of the different behaviour differences between implementations of qsort()
[12:07] <ubitux> like, we sort only according to one dimension, so there are cases where multiple values can have different positions
[12:07] <ubitux> (for the segmentation in palettegen)
[12:07] <ubitux> i'm not sure if these equalities will cause any change in the final output though
[12:08] <michaelni> can AV_QSORT or AV_MSORT be used ?
[12:14] <ubitux> michaelni: it could, but there are several calls
[12:14] <ubitux> i'll try without first
[12:14] <ubitux> if it causes problem i'll switch to the macro
[12:14] <ubitux> btw, is fate-samples/zerocodec/sample-zeco.avi rotated on purpose?
[12:15] <michaelni> the macro likely will also be faster
[12:16] <ubitux> i don't think speed will be relevant in the case of palettegen
[12:16] <michaelni> i dont know why sample-zeco.avi is as it is
[12:18] <ubitux> Daemon404 might know
[12:20] <wm4> ubitux: rotated? you mean flipped?
[12:20] <ubitux> yeah, sorry
[12:21] <wm4> some codecs-in-avi do this
[12:21] <wm4> mplayer "fixes" this by having a flip flag in codecs.cfg
[12:21] <ubitux> mplayer, mpv or ffplay have it flipped here
[12:22] <ubitux> s/or/and/
[12:22] <wm4> search for "flip" in mplayer's codecs.conf
[12:23] <wm4> most are for the vfw driver
[12:23] <wm4> but some are for ffmpeg too
[12:23] <wm4> and they probably forgot to set it for this codec?
[12:23] <ubitux> the question is more like, is it supposed to be flipped all the time, and where should this be fixed; avi demuxing? decoder?
[12:24] <ubitux> anyway, i'll just wait for Daemon404 since he added the decoder and the test
[12:25] <wm4> hm not just avi
[12:25] <wm4> e.g. Film_200_zygo_pro.mov
[12:25] <wm4> it's flipped h263
[12:25] <wm4> mplayer can flip it because it uses a special fourcc
[12:26] <wm4> never cared about this, because it's too obscure
[12:26] <wm4> vlc also plays it incorrectly
[12:27] <Daemon404> [11:14] <@ubitux> btw, is fate-samples/zerocodec/sample-zeco.avi rotated on purpose? <-- there is no correct orientation of zeco
[12:27] <Daemon404> the vfw encoder/decoder works differently on different windows versions
[12:27] <Daemon404> some flipped. some not.
[12:27] <Daemon404> shitty codec has shitty implementation
[12:27] <Daemon404> who knew?
[12:27] <ubitux> and no version bit?
[12:27] <Daemon404> lolno
[12:28] <Daemon404> what do you think this is, a not shit codec
[12:28] <Daemon404> ?
[12:28] <Daemon404> this is a impl bug for upstream, which is dead
[12:29] <cone-692> ffmpeg.git 03Vittorio Giovara 07master:35c6ce76b107: Canopus HQX decoder
[12:29] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:2cf521718d94: Merge commit '35c6ce76b107225a19eb33aea38857d2405882af'
[12:29] <ubitux> Daemon404: do you know how it was muxed?
[12:30] <ubitux> maybe there is a different codec tag or something? :(
[12:30] <Daemon404> no.
[12:30] <Daemon404> there is NOTHING
[12:30] <Daemon404> this has come up numerous times.
[12:30] <Daemon404> i must reiterate: there is NO correct way to handle it
[12:31] <ubitux> ok ok :)
[12:31] <wm4> one more reason not to care about these things
[12:31] <Daemon404> last time we discusse it, we decided to leave it as-is
[12:32] <Daemon404> since the way the decoder is matches behavior on xp, which is still newer than the last time anyone used this codec IRL
[12:32] <ubitux> maybe carl broke it in 66dc3ba356e6651e85098e6aab048c6680ea2845 though
[12:33] <Daemon404> wm4, if i didnt explain it, youd see like 10 commits from carl going: fix sample #1, fix sample #2, etc
[12:33] <Daemon404> changing and reverting
[12:33] <wm4> wow
[12:33] <Daemon404> oh speak of the devil.
[12:34] <Daemon404> ubitux, in 66dc3ba356e6651e85098e6aab048c6680ea2845 it matches XP now
[12:34] <Daemon404> i really dont care though, nobody uses it
[12:34] <Daemon404> go read the thread from 3 years ago ;)
[12:34] <ubitux> or maybe it was changed and reverted, no idea
[12:34] <ubitux> yeah that's what i'm doing
[12:34] <wm4> anyway, there are some more samples on samples.mplayerhq.hu that are flipped
[12:35] <Daemon404> some people probably wont accept there is no correct way
[12:35] <Daemon404> hence we'll get cycical commit/revert
[12:35] <Daemon404> :D
[12:35] Action: Daemon404 runs
[12:35] <ubitux> :)
[12:37] <wm4> Daemon404: shouldn't this make it have correct behavior on average?
[13:52] <ubitux> michaelni: can you add http://b.pkh.me/anim.mkv and http://b.pkh.me/anim-palette.png into fate-suite/filter? 
[13:52] <ubitux> 57dccb9610d45cbc0df45ee72ab308c4  /home/ux/fate-samples/filter/anim.mkv
[13:52] <ubitux> 04a56c063dd4be9185da8af03f734e85  /home/ux/fate-samples/filter/anim-palette.png
[13:53] <ubitux> sending the patches for the test in a moment
[13:59] <kierank> lol that boris guy
[14:00] <cone-692> ffmpeg.git 03Clément BSsch 07master:c3d40e305cb7: avfilter/palette{gen,use}: add Copyright
[14:27] <Daemon404> wm4, this = ?
[14:27] <nevcairiel> flipping it on a monthly basis =p
[14:28] <wm4> Daemon404: so you have option A and option B, neither is correct... but if you have option A for half a year, and then option B for the second half, it's correct on average
[14:28] <wm4> and yes, it's a bad joke, and it gets even worse when explaining it
[14:28] <nevcairiel> if neither is correct, then wouldnt swapping between both still result in it always being wrong? :D
[14:30] <ubitux> that's called time dithering
[14:31] <nevcairiel> temporal makes it sound more fancy
[14:33] <michaelni> ubitux, uploaded
[14:34] <ubitux> michaelni: thx :)
[14:34] <Daemon404> ubitux, i mean, an option could be added, but it's silly
[14:34] <Daemon404> and noone uses zeco
[14:34] <ubitux> the option exists, it's -vf flip
[14:34] <ubitux> +v
[14:36] <Daemon404> ;)
[14:41] <ubitux> michaelni: can you try with -pix_fmt bgra? what is the simplest for you to test? a new patch on top? a completely new patch? a remote branch?
[14:42] <michaelni> patch or branch is fine
[14:42] <ubitux> on top or replacement?
[14:43] <ubitux> well i'll give you a branch
[14:44] <ubitux> michaelni: remote git at github.com:ubitux/FFmpeg.git branch palette-tests; can you try fate-palettegen again?
[14:48] <ubitux> if it still fails i'll try the qsort
[14:50] <michaelni> works but theres some other problem 
[14:50] <michaelni> iam getting "make: *** No rule to make target `fate-filter-paletteuse-nodither'.  Stop."
[14:52] <ubitux> mmh running what exactly?
[14:53] <ubitux> both fate-filter-paletteuse and fate-filter-paletteuse-nodither works here
[14:53] <ubitux> fate-filter-palettegen and fate-filter-palettegen-1 as well
[14:59] <michaelni> they arent in make fate-list
[15:00] <ubitux> they are in mine; do you lack one of the dep?
[15:00] <michaelni> who knows
[15:00] <ubitux> there are 4 deps, matroska demux, h264 decoder, image2 demuxer, png decoder
[15:01] <ubitux> one of them isn't on mips?
[15:01] <ubitux> ah, and paletteuse filter, obviously
[15:02] <ubitux> i suppose you have the first 2 if palettegen works
[15:05] <michaelni> #define CONFIG_PNG_DECODER 0
[15:06] <ubitux> no png dec on mips? :p
[15:06] <ubitux> oooh zlib maybe
[15:11] <michaelni> yes this is a issue on my side
[15:13] <ubitux> i suspect paletteuse will have a similar problem btw
[15:13] <ubitux> it's outputting pal8, where the palette entry are native endianess
[15:14] <ubitux> it's probable the checksum will fail as well, assuming it takes into account the palette plane
[16:04] <cone-692> ffmpeg.git 03Paul B Mahol 07master:665916ffa2ad: avcodec/hqx: remove superfluous log message
[17:00] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:6c9537b807e5: avformat/hlsenc: Warn if a non file protocol is used
[17:36] <saste> michaelni, do you want me to fill the missing backup mentor positions in the gsoc wiki page?
[17:37] <michaelni> saste, yes, please do
[17:37] <saste> michaelni, BM is missing for the HW accel task, DTS / DCA, and MXF demuxer
[17:42] <saste> michaelni, done
[17:44] <michaelni> saste, thanks alot
[17:44] <kierank> you know that dts/dca is pretty much done
[17:45] <saste> michaelni, are all the projects verified? I mean the mentors know they are listed as mentors?
[17:46] <saste> also the subtitles project should be moved to unmentored projects
[17:46] <michaelni> saste subtitles should be moved yes
[17:47] <michaelni> feel free to do so
[17:50] <michaelni> about verification, all listed people volunteered last year, i posted to ffmpeg-devel a few days ago and i asked some people in private, i intended to double check the in case we do get accepted
[17:52] <saste> michaelni, OK, I aksed because I found the bcoudurier involvement a bit weird
[17:52] <jamrial> kierank: dts-ma is the biggest thing we're missing afaik
[17:53] <kierank> yes and someone wrote most of it
[17:53] <j-b> yes
[17:53] <michaelni> kierank, feel free to update dts/dca, i do not know which exact features exist and who implemented what already
[17:53] <j-b> almost everything is in FFmpeg now
[17:53] <j-b> except XXLL
[17:53] <j-b> and it's implemented, but not bitexact (like we care)
[17:54] <nevcairiel> the implementation is quite lacking beyond the bitexactness still
[17:55] <j-b> nevcairiel: I thought it was more than OK, sorry.
[17:56] <wm4> what's the difference between coded_width and width again?
[17:56] <kierank> cropping
[17:56] <nevcairiel> indeed
[17:56] <wm4> also did you see this: https://github.com/foo86/xlldec
[17:56] <wm4> so what do you need to set when opening a codec for decoding? width or coded_width? or both in some situations?
[17:58] <nevcairiel> setting coded_width should be fine
[17:59] <nevcairiel> if there is no cropping info, avcodec should set width/height to the same values as coded_*
[18:12] <wm4> nevcairiel: makes sense, thanks
[19:03] <iive> isn't coded_width supposed to be MB aligned?
[19:15] <llogan> i tohught the standard subtitle format for MP4 was "streaming text format", not 3gpp timed text. or are they exactly the same thing?
[19:17] <llogan> 14496-17 is easy to find. Thanks, China.
[19:43] <compn> llogan : "theres a standard" ? :P
[19:43] <compn> mostly we deal with them anime pirated copyright infringers files
[19:44] <compn> only a few broadcast people in here
[19:44] <compn> which might have subs in mp4
[19:44] <compn> seen closed captions in mp4, and timed text
[19:44] <compn> mostly apple.com originated files
[19:48] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:96e7c9cbfc9a: avcodec/roqvideoenc: Allocate and reference coded_frame correctly
[19:48] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:34a8de866f88: avcodec/snowenc: Allocate and reference coded_frame correctly
[20:55] <jamrial> michaelni: any idea why your openbsd systems are randomly failing the tak test like this? http://fate.ffmpeg.org/history.cgi?slot=x86_64-openbsd5.6-gcc4.2 http://fate.ffmpeg.org/history.cgi?slot=x86_64-openbsd5.6-gcc4.8
[21:12] <cone-692> ffmpeg.git 03Martin Storsjö 07master:fe208ca54b0d: rtpdec_hevc: Skip 1 byte (DOND) instead of 2 (DONL) between aggregation units
[21:12] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:596f81c75b67: Merge commit 'fe208ca54b0d3b6bbe1c660d371bb2cc6cf40ffc'
[21:29] <cone-692> ffmpeg.git 03Federico Tomassetti 07master:161442ff2c4b: mdec: check for out of bounds read
[21:29] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:92ec34707ff5: Merge commit '161442ff2c4b0dd8a5072c6bbe6bf55303fffccf'
[21:33] <michaelni> jamrial, it crashes in scalarproduct_int16_c, dont know the line number yet
[21:39] <cone-692> ffmpeg.git 03Federico Tomassetti 07master:061c489895d2: eamad: check for out of bounds read
[21:39] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:cce8f750d91c: Merge commit '061c489895d29049a88dc6118e4b639a273b31d6'
[21:46] <michaelni> jamrial, 85              res += *v1++ **v2++; <-- *v1 is segfaulting
[21:49] <cone-692> ffmpeg.git 03Gilles Chanteperdrix 07master:cdcc370293a1: rtsp: punch holes again after pause
[21:49] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:83f18410bdcf: Merge commit 'cdcc370293a159c321e41af7f0eef141c62d698d'
[21:51] <rcombs> michaelni: that line looks like it could use some parens
[21:53] <jamrial> ok, so it's not an alignment problem with AV_ZERO
[21:53] <jamrial> i still wonder why it sometimes fails and sometimes doesn't
[21:55] <michaelni> dont know either but i had to run it twice to get the error
[21:56] <michaelni> order=16 according to gdb btw
[21:57] <cone-692> ffmpeg.git 03Diego Biurrun 07master:cb4cb7b0ea12: qsv: Skip qsv.h compilation if qsv is not enabled
[21:57] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:9ad8f55edaf2: Merge commit 'cb4cb7b0ea12b791dde587b1acd504dbb4ec8f41'
[22:06] <cone-692> ffmpeg.git 03Diego Biurrun 07master:ce52869c2273: fate: Rename fate-dts test to fate-dca-core
[22:06] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:8f140a8ec3b8: Merge commit 'ce52869c22738ad584995d48103ce3aa2301736b'
[22:25] <jamrial> michaelni, kurosu: valgrind seems to complain about it as well. invalid read size errors
[22:27] <jamrial> with both the sse2 or c versions of scalarproduct_int16
[22:27] <jamrial> i'm going to revert the commit for the time being
[22:30] <cone-692> ffmpeg.git 03James Almer 07master:03616af2c913: Revert "takdec: pad filter coeff buffer for DSP functions"
[22:59] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:4d1b017c380e: avformat/mov: Check av_add_index_entry() return value
[00:00] --- Tue Feb 24 2015