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

[burek]

[00:00] <Paranoialmaniac> michaelni: i'm not ok because hvcC format may be changed on a draft as the divx and my l-smash use configurationVersion==0. the point is parameter sets are placed at the end of hvcC. the change may change their offsets. it is hard to support all draft version hvcC
[00:02] <Paranoialmaniac> there is no clue to distinguish them
[00:03] <michaelni> Paranoialmaniac, there are no offsets in your patches
[00:03] <Paranoialmaniac> ?
[00:03] <Paranoialmaniac> ahhh
[00:04] <Paranoialmaniac> sorry, i misunderstand :P
[00:04] <Paranoialmaniac> and you pushed with my nalff support?
[00:05] <Paranoialmaniac> with the hevc decoder
[00:05] <michaelni> i pushed the hevc decoder patch, it wasnt split up based on authors 
[00:05] <michaelni> so i dont know what parts from what authors are in it
[00:06] <Paranoialmaniac> hevc_decode_extradata is written by me
[00:06] <j-b> funny how the hevc commit did not go through the ml
[00:07] <Paranoialmaniac> sad
[00:09] <michaelni> j-b, it got stuck on vlc side or ffmpeg side ? or maybe it will turn up later ...
[00:09] <j-b> michaelni: that's a great question
[00:09] <j-b> I guess it is a huge patch
[00:09] <michaelni> yes
[00:10] <j-b> so either git hook said "no way" or the ml said "fuck you" :)
[00:10] <j-b> I don't know, and well, I do not care much :)
[00:10] <Paranoialmaniac> michaelni: apply as you want...
[00:11] <j-b> s/want/can
[00:11] <michaelni> Paranoialmaniac, domo arigatou gozaimas
[00:13] <wm4> I found a mail by mini containing a hevc patch in my spam filter
[00:13] <wm4> google decided it was spam
[00:13] <Paranoialmaniac> michaelni: https://github.com/VFR-maniac/libav/commits/hevc_nalff <-- feel free to pick patches if you need. some patches are already applied though
[00:15] <wm4> (I wonder whether google's spam filter decision are the same for every account?)
[00:15] <michaelni> Paranoialmaniac, thanks
[00:23] <Compn> its in ?!
[00:23] <Compn> ehe
[00:23] <cone-770> ffmpeg.git 03gcocherel 07master:cf49d0156dfd: valgrind cleanup(cherry picked from commit 0d5efa40b94c0de92a1fe5091b21e0e2d36bae3d)
[00:23] <cone-770> ffmpeg.git 03Yusuke Nakamura 07master:53f903b7c542: lavf/mov: Support HEVC demuxing.
[00:23] <cone-770> ffmpeg.git 03Yusuke Nakamura 07master:16b6839de676: lavf/matroskadec: Support HEVC demuxing.
[00:23] <Compn> did you check mailman ?
[00:24] <michaelni> didnt check anything except my cvslog mailbox
[00:41] Action: llogan increases cvslog message size limit
[00:41] <j-b> now, I got it
[00:41] <j-b> 550K
[00:41] <j-b> no wonder it did not get through
[01:28] Action: kierank wonders if he has the guts to add avx2 to swscale
[01:29] <iive> you can do it!
[01:42] <cone-770> ffmpeg.git 03Michael Niedermayer 07master:f58cb772d966: avformat/mov: fix "correctly" typo
[01:42] <cone-770> ffmpeg.git 03Guillaume Martres 07master:fb3cea4be339: FATE: add HEVC tests
[01:42] <cone-770> ffmpeg.git 03Michael Niedermayer 07master:48e1114abf77: fate: fix DBLK_A_MAIN10_VIXS_2 on big endian
[01:44] <michaelni> smarter, hevc fate tests pass on big endian mips now as well as little endian (same 2 tests failing)
[01:44] <smarter> I think right now there's one test failing on ppc
[01:44] <michaelni> little endian x86_64 that is
[01:45] <michaelni> smarter, i just fixed a big endian bug
[01:45] <michaelni> maybe that was it ?
[01:45] <smarter> oh
[01:46] <smarter> ah I think elenril found that fix too
[01:48] <smarter> mraulet fixed one test a few hours ago: https://github.com/OpenHEVC/libav/commit/19c5d9ed28606e7a166d180fc9f1517cb174146f
[01:51] <kierank> I need to find something small to port to avx2
[01:51] <kierank> in swscale
[01:51] <kierank> then work on bigger stuff
[01:52] <j-b> why need?
[01:52] <michaelni> some of the simple unscaled converters might be an option
[01:53] <kierank> j-b: porting some of the big yasm functions to avx2 seems hard
[01:53] <kierank> lots of macros
[01:54] <michaelni> stuff in: rgb2rgb_template.c should be easy to play, not sure how usefull optimizing them to avx2 is though
[01:55] <michaelni> s/to play/to play with"
[01:55] <kierank> i think output.asm might be easiest
[01:56] <kierank> yuv2plane1
[01:57] <cone-770> ffmpeg.git 03Mickaël Raulet 07master:64b3aaf8f6c2: hevc: fixing TSCL_A_VIDYO_5 decoding output order(cherry picked from commit 19c5d9ed28606e7a166d180fc9f1517cb174146f)
[09:32] <dol> hi all. Yesterday I asked a question about a sws_scale artefact here, which I have already posted in detail with pictures in http://forum.doom9.org/showthread.php?t=169036
[09:33] <dol> there is something wrong with my settings I guess because if I decode it with the cli, I don't see the issue anymore
[09:33] <dol> so, could anyone help me to go through the code? it is just couple of lines
[09:38] <saste> dol pastebin
[09:40] <dol> @saste, ok I will.
[09:45] <dol> @saste, here is the code
[09:45] <dol> http://pastebin.com/dTGZbdJj
[09:45] <dol> it's now more than couple of lines but it's pretty common code I believe
[09:46] <dol> so, the problem occures in line 252
[09:47] <dol> you see that I call sws_getCachedContext with the current settings
[09:48] <dol> if I set there, decodedpic->width + 1, everything works perfect without any issue
[09:48] <dol> so I believe that the sws_scale works good if it does scaling
[09:48] <dol> if I don't set it to +1, it means that srcW = dstW and it doesn't do any scaling
[09:48] <dol> but I couldn't verify this with cli.
[09:49] <dol> so I think there is a small trick that I forget
[09:53] <dol> @saste ?
[09:54] <saste> dol, no if dst pix_fmt != src_pix_fmt it will convert
[09:55] <dol> yes, this is the problem. in my application I don't do any scaling. Therefore always the pix_fmt = src_pix_fmt
[09:55] <dol> but I see the effect that you can see from the pictures in http://forum.doom9.org/showthread.php?t=169036
[09:55] <dol> however, if I set srcW+1, meaning that pix_fmt != src_pix_fmt, I don't see the problem anymore
[09:56] <dol> but I believe that it scales the image which is not necessary. I am trying to find out why it works perfect with dstW = srcW and not with srcW = srcW+1
[09:57] <saste> i suspect the avpicture_fill() may be wrong
[09:57] <saste> since it always assumes alignment of 1, which may not be the case
[09:59] <dol> what can I try instead?
[10:00] <saste> what is mvSize[0] and mvSize[1]?
[10:01] <saste> look like linesizes, but you're using them as width/height
[10:01] <dol> mvSizes are coming from the encoder, actualyy they are width and height of the source
[10:02] <saste> are you sure the data is aligned to 1
[10:02] <saste> usually image data lines contain padding at the end
[10:03] <saste> something like RGBRGB...RGBPPPP where PPPP are padding bytes
[10:03] <dol> well, I don't know anything about alignment
[10:03] <dol> can you tell me how to check?
[10:03] <saste> usually you need both w/h and linesize to be able to render the image correctly
[10:03] <dol> I can easily try out 
[10:03] <saste> i explained you, it's not complicate at all
[10:05] <dol> I will debug the decoded image and see that it contains
[10:07] <dol> @saste, decodedpic->data[0] has different values at the end of the array
[10:07] <dol> they are not the same like PPPP
[10:08] <saste> what is av_pic?
[10:08] <saste> is it a global?
[10:08] <dol> no it is AVFrame declared in the class
[10:08] <dol> it contains the decoded frame
[10:14] <dol> @saste, do you see any problem in the flow ? 
[10:14] <dol> or any weird thing?
[10:20] <saste> no seems correct
[10:20] <dol> this issue happens only in some weird resolutions
[10:21] <dol> if it is for example, 800x500 resolution, no problem
[10:21] <dol> but if it is 1382 x 864 or whatever vertical resolution, I see that a black bar comes on top of the image at the right hand side
[10:24] <saste> dol again i suspect you're confusing linesize with width
[10:24] <saste> this would explain the issue
[10:25] <dol> you mean the destination linesize?
[10:25] <saste> no in the source
[10:25] <dol> in the avpicture_fill?
[10:25] <dol> aha
[10:26] <dol> but what should I use instead?
[10:26] <dol> should I create the linesizes myself?
[10:27] <dol> but then the constructed image will be distorted because linesize is coming from the decoding and if I choose smaller linesize, the next line will be shorter?
[10:27] <dol> couldn't explain it well 
[10:29] <saste> what if the problem is really the source?, that is the encoding process?
[10:30] <saste> anyway this is not really related to ffmpeg development, move to #ffmpeg
[10:34] <JEEB> while you are technically correct, you know how many people related to ffmpeg are in there :P
[10:35] <JEEB> for example, this guy had no response for about 6 or 8 hours or so
[10:35] <JEEB> and thus I just decided to tell him to try here yesterday
[10:35] <JEEB> #ffmpeg is generally OK for command line help and such, that's true though
[10:35] <JEEB> just my five cents
[10:48] <dol> @saste, encoding part is eliminated because I checked the encoded stream myself, which contains no black border at all
[10:48] <dol> also, I can't reproduce it if I use ffmpeg cli with the follwoing command ffmpeg.exe -i 1.264 1.yuv -v debug
[10:49] <dol> and yuv file doesn't show up any black border
[10:49] <dol> so, I believe that I make a mistake during avpicture_fill or whatever call but I am unable to find it
[10:53] <dol> @saste, when I have jsut realized  that ffmpeg doesn't use swscale  since the output is yuv file in the following command
[10:53] <dol> ffmpeg.exe -i 1.264 1.yuv
[10:53] <dol> can you guys tell me how I can export them to bmp so that it will use swscale?
[10:55] <dol> ok, I tried ffmpeg.exe -i 1.264 -f image2 image-%3d.bmp
[10:55] <dol> and the output bmp images doesn't show any border as well
[10:56] <dol> I mean black border
[11:00] <dol> still waiting for a push?
[11:04] <cone-159> ffmpeg.git 03Derek Buitenhuis 07master:884fd4d2590c: tableprint: Fix use of a size_t print with MSVC
[11:04] <cone-159> ffmpeg.git 03Derek Buitenhuis 07master:bc31a7a3b6bc: tablegen: Don't use cbrtf in host tools
[11:04] <cone-159> ffmpeg.git 03Derek Buitenhuis 07master:479a52795526: cos_tablegen: Don't use lrint
[11:04] <cone-159> ffmpeg.git 03Derek Buitenhuis 07master:c0085f94fea8: mpegaudio_tablegen: Don't use llrint
[11:04] <cone-159> ffmpeg.git 03Michael Niedermayer 07master:12e9821042b7: Merge commit 'c0085f94fea89b180e5727b193484a83586d3490'
[11:18] <cone-159> ffmpeg.git 03Diego Biurrun 07master:3b4fa54866f5: cavs: more K&R formatting cosmetics
[11:18] <cone-159> ffmpeg.git 03Michael Niedermayer 07master:3a8b52c0113b: Merge commit '3b4fa54866f58bf3d8a8dcc460c73ef6564c0ad8'
[11:22] <michaelni> dol, does that ffmpeg that works use the same flags and linesizes and w/h as you do ?
[11:24] <dol> michaelni, I can't see the linesize information if I run the ffmpeg with -v debug option
[11:24] <dol> what I see is the following
[11:24] <michaelni> you can add a printf
[11:24] <michaelni> or av_log
[11:25] <dol> http://pastebin.com/Pm4Sq3Ee
[11:26] <dol> yes but I need to compile it and I don't have my linux machine with me 
[11:27] <dol> Setting 'flags' to value '0x4', I think this is SWS_BICUBLIN
[11:27] <dol> what is? w:iw h:ih flags:'0x4' interl:0
[11:28] <dol> width = iw?
[11:28] <michaelni> bicublin is 0x40
[11:28] <dol> ah sorry SWS_BICUBIC
[11:29] <michaelni> its using bgr24 you use rgb32 or something else IIRC
[11:29] <michaelni> try -pix_fmt rgb32
[11:30] <dol> tried: http://pastebin.com/VPyWUyv4
[11:31] <dol> output show no artefact again
[11:31] <dol> thanks a lot for your help btw.
[11:39] <cone-159> ffmpeg.git 03Diego Biurrun 07master:29c455ce3daf: bitstream: Check the result of av_malloc()
[11:39] <cone-159> ffmpeg.git 03Michael Niedermayer 07master:8895b71d6fc1: Merge commit '29c455ce3daf7fb369ba20cf77c74bd8e3b43b55'
[11:46] <michaelni> dol, if you think thats a bug in sws (which is possible), you could try to write a minimal testcase that is like a c file that creates a small yuv420 pic with some pattern and runs sws over it and dumps the result or so, and then open a bugreport on trak
[11:47] <michaelni> the code snippet you posted doesnt look like it would built on its own
[11:47] <dol> michaelni, it's written in Qt but I will try to write a minimal code in pure C
[11:47] <dol> my workaround solution is just to set the width to width+1
[11:48] <michaelni> thanks
[11:48] <michaelni> should make testig/debuging easier
[11:48] <dol> michaelni, do you think that it can be a bug in swscale even if it is not reproducable with cli?
[11:50] <michaelni> dunno, they might use different linesizes or something
[12:12] <cone-159> ffmpeg.git 03Anton Khirnov 07master:dd33637c1862: tiny_psnr: switch f32 handling to floating point
[12:12] <cone-159> ffmpeg.git 03Michael Niedermayer 07master:6659eb711674: Merge commit 'dd33637c18629c3e554ebb146bbeb45c9745a5cf'
[12:17] <cone-159> ffmpeg.git 03Anton Khirnov 07master:68edd5be0980: FATE: use proper comparison mode in the lavr tests
[12:18] <cone-159> ffmpeg.git 03Michael Niedermayer 07master:8778c49aceb9: Merge commit '68edd5be0980941924ae633d98589d56a8091bbd'
[12:38] <cone-159> ffmpeg.git 03James Almer 07master:6b081eff4dfc: fate: add vorbiscomment cover art test
[12:38] <cone-159> ffmpeg.git 03Michael Niedermayer 07master:83bfcc3ce255: Merge commit '6b081eff4dfc3c899960f69f30cb567266b7dca3'
[12:44] <cone-159> ffmpeg.git 03Yusuke Nakamura 07master:b81dbd6cb752: h264_parser: Fix POC parsing for the case where MMCO_RESET is absent.
[12:44] <cone-159> ffmpeg.git 03Michael Niedermayer 07master:91248f081f34: Merge commit 'b81dbd6cb7522bea96d78a52f8a4c25a47b820c9'
[13:00] <cone-159> ffmpeg.git 03Yusuke Nakamura 07master:4baba6c813b7: h264_parser: Fix POC parsing for the case where MMCO_RESET is present.
[13:00] <cone-159> ffmpeg.git 03Michael Niedermayer 07master:f7f74a37b82d: Merge commit '4baba6c813b7a1f27370e20fb1a87b05fcb39208'
[13:00] <Daemon404> michaelni, just fyi for trac #3048, you should refer to TheRyuu 
[13:01] <Daemon404> since he wrote the icl support
[13:01] <Daemon404> he's working on inline asm too (supposedly) in ffmpeg
[13:17] <cone-159> ffmpeg.git 03Ronald S. Bultje 07master:93f305473f88: lavc: Convert some remaining strides to ptrdiff_t
[13:17] <cone-159> ffmpeg.git 03Michael Niedermayer 07master:10c6d1b28cbd: Merge commit '93f305473f880729d18b5e42067f19d2106cb2e5'
[14:01] <cone-159> ffmpeg.git 03Luca Barbato 07master:a84616b736fc: mpegvideo: K&R formatting cosmetics
[14:01] <cone-159> ffmpeg.git 03Michael Niedermayer 07master:8610751d07bc: Merge commit 'a84616b736fca5ebd6b87489dd41bc06ccdf7860'
[14:17] <dol> michaelni, I have spotted the problem
[14:17] <dol> well let say I have an idea
[14:17] <dol> but still I need some help to figure out why
[14:18] <ubitux> BBB: did you see any functional changes in the vp9 port?
[14:18] <dol> so what I do is that, I increase the resolution of the frame at the encoder side and see what resolution the decoder provides me
[14:18] <ubitux> BBB: or that's just random cosmetics, rename etc?
[14:18] <dol> the strange thing is, I see no black border thing if the srcW = c1->coded_width
[14:19] <dol> I see the effect when the srcW != c1->coded_width
[14:21] <dol> or another saying is that, I see the effect when c1->width != c1->coded_width
[14:21] <dol> I see no effect when c1->width == c1->coded_width
[14:24] <dol> could anyone tell me in what cases coded_width is different from width?
[14:39] <cone-159> ffmpeg.git 03Luca Barbato 07master:a90905db2e6a: ffv1: Assume bitdepth 0 means 8bit
[14:39] <cone-159> ffmpeg.git 03Michael Niedermayer 07master:ab16d5b7b56e: Merge commit 'a90905db2e6ab1840890f3a88bfd3bf008b9d886'
[15:06] <cone-159> ffmpeg.git 03Luca Barbato 07master:95587859cc69: mpegvideo: Move obmc in a separate function
[15:06] <cone-159> ffmpeg.git 03Michael Niedermayer 07master:8210e3846129: Merge commit '95587859cc69e5abe37c9e3af48008032d98e262' into HEAD
[15:14] <cone-159> ffmpeg.git 03Luca Barbato 07master:825c7c62bb66: mpegvideo: Move 8x8 in a separate function
[15:14] <cone-159> ffmpeg.git 03Michael Niedermayer 07master:4d41a25d3940: Merge remote-tracking branch 'qatar/master'
[15:17] <dol> 2nd try: could anyone tell me how the coded_width is calculated from width information?
[15:18] <dol> or where is the related code?
[15:19] <michaelni> TheRyuu, Daemon404 says you wrote ICL support
[15:20] <michaelni> first thanks for doing that :)
[15:20] <michaelni> and maybe you want to comment on https://trac.ffmpeg.org/ticket/3048 ?
[15:20] <Daemon404> he said the patch wasnt complete when i asked in here yesterday
[15:20] <Daemon404> but didnt elaborate
[15:21] <dol> michaelni, could you please comment on what I have said?
[15:21] <dol> I see the effect when coded_width != width
[15:22] <dol> and it will be a solution if I somehow how much pixels it has added at the end and substract that much from the srcW in the sws context
[15:23] <dol> so apparently, in such resolutions, the width already contains the padding
[15:23] <michaelni> dol, iam not sure what and where coded_width and width are related to the swscale issue
[15:23] <michaelni> do you have a issue with swscale or a decoder ?
[15:24] <dol> well, I am trying to figure out if it is an issue or not. but I have a problem with both decoder and swscale
[15:24] <michaelni> Daemon404, hmm, ok, thx, i guess ill copy and paste a few lines from here to trak then so the others who look at trak are aware
[15:25] <michaelni> dol, so maybe first find seperate the 2 and find out which of them is the problem
[15:25] <iive> without looking at the code, I think that coded_width should be the width rounded up by macroblock size. 
[15:28] <dol> @iive, michaelni, look at this example. input resolution is 1124x702. When I debug the decoder, I see that the coded_width=1136 , therefore I see a black line at the right side. 
[15:29] <dol> however, if I use sws_getContext(c1->width - 1, c1->height, ....
[15:29] <dol> I see the frame that I supposed to see without any black line
[15:30] <dol> so somehow I need to create a logic between coded_width and width so that it will give me 1
[15:30] <dol> I know it is not an optimal solution but it is a solution
[15:31] <dol> and the question is, why does it round up even if 1124 is perfectly dividable to 16?
[15:32] <dol> so why does the decoder add 12 more? where does it come from :)
[15:32] <michaelni> Daemon404, the patch in the ticket is incomplete and ugly yes (i assume that patch was what was meant)
[15:32] <Daemon404> TheRyuu, has a WIP
[15:32] <Daemon404> i think
[15:32] <Daemon404> on HEAD
[15:32] <Daemon404> and some ffmpeg-specific changes
[15:33] <michaelni> ok, that would be great :)
[15:33] <Daemon404> but he's lazy, so feel free to stab him
[15:35] <iive> dol, video codecs work on (macro)blocks. this is why they always round up the resolution to a MB size. Some encoders put black bars, most recent just repeat the edge pixels. Usually to simplify calculation stride/line_size is used. It is the offset in bytes between two vertical pixels.
[15:36] <iive> in other words, you add it to get the next line. it might be different than coded_width if you have higher sampling formats (9,10,12bit)
[15:37] <iive> now, about swscale... it could be a bug in one of the code paths, but it could be a bug in calculation of image parameters. 
[15:37] <saste> dol: why do you read coded_width rather than width?
[15:38] <iive> for example, if input and output widths are the same, then a faster color-format conversion only path is used.
[15:38] <dol> @iive, I know some basics about encoding decoding and I know what the padding or linesize or stride does. but this problem is a bit different
[15:38] <dol> @saste, I have realized that my issue happens when the coded_width is NOT equal to width
[15:39] <dol> that's why I read it
[15:39] <saste> dol: ok
[15:39] <iive> just make sure that line_size is not smaller than any width 
[15:39] <saste> dol: what decoder?
[15:39] <dol> @iive have you read my post in doom9? http://forum.doom9.org/showthread.php?t=169036
[15:39] <dol> @saste h264
[15:40] <saste> dol starts to make sense
[15:40] <saste> that's new code and probably not very much tested
[15:40] <saste> i mean when the coded_w/h changes
[15:40] <saste> i bet it's a decoder issue
[15:41] <dol> @saste, so you say that it is probably a bug that I need to report
[15:41] <saste> but, it should be reproducible with ff* tools as well
[15:41] <dol> yes that's the most strange part
[15:41] <dol> i tried ffmpeg cli and didn't see the effect over there
[15:41] <saste> do you have a sample?
[15:42] <dol> what sample do you want? I can immediately produce
[15:42] <saste> a sample triggering the issue, h264 content with changing h/w
[15:42] <saste> (well it should not be hard to create using ts)
[15:42] <dol> ok I will create encoded bitstream
[15:43] <dol> yes indeed
[15:43] <dol> but I don't know how to use it
[15:43] <dol> so I will use my own tools :)
[15:45] <saste> dol, ffmpeg -f lavfi testsrc=s=1124x702 -c:v libx264 -t 5 out1.ts
[15:46] <saste> dol, ffmpeg -f lavfi testsrc=s=1124x600 -c:v libx264 -t 5 out2.ts
[15:46] <saste> cat out1.ts out2.ts > out12.ts
[15:46] <dol> @saste, this won't help since we won't be able to reproduce it with cli
[15:47] <dol> I tried it with the same resolution and didn't pop up
[15:47] <dol> so there is really a problem either with my code or the code path in the library
[15:48] <saste> dol, try to write a selfcontained c program showing the problem
[16:02] <saste> michaelni, willing to comment on the swscale filter patch?
[16:42] <durandal_1707> michaelni: have you looked at gbra16 swscale patch?, now you can test it with fate samples
[16:44] <michaelni> durandal_1707, not yet
[16:56] <michaelni> saste, which patch ? 
[16:57] <michaelni> i see some sws channel layout patches but filter
[16:57] <saste> michaelni: [PATCH] swscale: Support setting filters through AVOptions
[16:58] <cone-159> ffmpeg.git 03Paul B Mahol 07master:4413dcc03524: avcodec/exr: piz decompression
[17:02] <michaelni> saste, IIRC srcFilter is applied "before" scaling" and dst after 
[17:03] <michaelni> and it should be possible to apply them without scaling 
[17:04] <saste> michaelni, but in practice?
[17:04] <durandal_1707> michaelni: why hevc/h265 is not in changelog?
[17:05] <michaelni> saste, it should work unless theres a bug
[17:05] <saste> also, what filter is used if noone is specified?
[17:05] <michaelni> "1"
[17:09] <michaelni> also the patch shuld be ok from a quick look, that is if wm4 is ok with it too
[17:24] <cone-159> ffmpeg.git 03Ronald S. Bultje 07master:734ccf378588: avcodec/vp9: fix band_counts array size / padding
[18:00] <cone-159> ffmpeg.git 03Carl Eugen Hoyos 07master:d0b7d24b80b3: Support HEVC in transport streams.
[18:33] <cone-159> ffmpeg.git 03Timothy Gu 07master:b4da1fa550db: doc/utils: rewrite doc for time duration syntax
[18:33] <cone-159> ffmpeg.git 03Timothy Gu 07master:155a5ff00d61: doc/utils: reformat doc for color syntax and add list of supported colors
[18:33] <cone-159> ffmpeg.git 03Timothy Gu 07master:586b8ea24856: doc/filters: reference ffmpeg-utils manual for color and sizes options
[19:25] <wm4> what's that talk about avcodec_decode_subtitle3?
[19:27] <ubitux> multi frame, single packet
[19:28] <wm4> I thought this idea fell into disuse
[19:28] <wm4> not used with video anymore, and barely for audio
[19:28] <wm4> and introducing avcodec_decode_subtitle3 would be retarded because AVSubtitle is still retarded
[19:28] <ubitux> it's not
[19:28] <wm4> so... just split your multi-frame packet into multiple packets?
[19:29] <ubitux> check the commit, marton seems to need it
[19:31] <TheRyuu> Daemon404: I haven't really looked at any ffmpeg specific changes that would be needed, my inline asm patch is against libav
[19:31] <TheRyuu> if that's what you were referring to
[19:41] <Daemon404> TheRyuu, there was something you were poking in ffmpeg
[19:42] <TheRyuu> icl failing at preprocessing in one of the "make check" things?
[19:42] <TheRyuu> that's really the only ffmpeg specific thing I have
[20:17] <Daemon404> 300 get
[20:23] <wm4> ubitux: someone wants to use AV_PKT_DATA_STRINGS_METADATA to update mid-stream ogg metadata, would this be ok?
[20:23] <Daemon404> someone is using ogg?
[20:23] <Daemon404> poor bastards.
[20:23] <ubitux> good question, i wanted to have something like this a while ago
[20:23] <ubitux> Daemon404: i do, especially for web radio
[20:24] <ubitux> ogg/vorbis is stilly better than mp3/icy, and even saner
[20:24] <Daemon404> i use aac
[20:24] <wm4> yeah, web radio shit
[20:24] <wm4> not sure what type of metadata is used with aac
[20:24] <Daemon404> tho really, i use nothing
[20:24] <wm4> maybe id3v2?
[20:24] <Daemon404> because i dont do podcasts
[20:24] <Daemon404> or radio
[20:25] <ubitux> i stream my music to listen it from outside @home
[20:25] <ubitux> wm4: anyway, dunno, send a patch? :p
[20:26] <wm4> I know it's your standard reply, but I'm not quite following here, patch for what?
[20:26] <ubitux> for what you were talking about?
[20:26] <ubitux> did i misunderstand something, as usual?
[20:26] <wm4> someone is interested in implementing this
[20:27] <ubitux> why isn't he asking here / on ffmpeg-devel?
[20:28] <ubitux> BBB: i'm going (and already doing actually) make extensive use of ssse3, is it ok?
[20:29] <wm4> ubitux: mathstuf is the guy who wants to implement this
[20:30] <wm4> and I guess he wants to know whether using AV_PKT_DATA_STRINGS_METADATA is the right approach
[20:30] <ubitux> i've attempted several broken approach
[20:30] <ubitux> like watching for changes in metadata in ffplay
[20:31] <wm4> that wouldn't be too bad as long as there's some way to signal the application that metadata was updated
[20:32] <ubitux> yes
[20:32] <ubitux> and which meta as well
[20:32] <ubitux> you could hack like i was doing the pointer values
[20:32] <ubitux> but this is extremely awful ;)
[20:33] <ubitux> the strings metadata actually sounds like a nice way to work around the problem
[20:33] <ubitux> > side data 
[20:34] <mathstuf> ubitux: i have log messages stating that it sees the metadata and that its being put into the side_data
[20:34] <mathstuf> but the app (mpv) doesnt get any packets with strings metadata side_data in it
[20:34] <mathstuf> its probably being filtered out somewhere; havent traced it yet
[20:35] <ubitux> ah erm, yeah the meta will be in the frame
[20:35] <ubitux> (see add_metadata_from_side_data in lavc/utils)
[20:35] <ubitux> meh i dunno
[20:36] <mathstuf> yeah, but mpv only gets AVPacket structures, so AVFrame isn't extremely useful at that point
[20:36] <ubitux> yes indeed
[20:36] <ubitux> so those side data won't do
[20:37] <mathstuf> i might get some time tonight to see where the packet gets dropped between the codec and the app tonight
[20:39] <Daemon404> it amazes me that they still use trac
[20:39] <Daemon404> rather than irc or eail
[20:39] <Daemon404> email*
[20:40] <mathstuf> well, bugs get lost easily on irc
[20:40] <Daemon404> this isnt a bug thread
[20:40] <Daemon404> it's a WIP aac improvement
[20:40] <mathstuf> ah
[20:40] <wm4> mathstuf: AVFrame is after-decoder, so indeed not really the right layer for metadata IMO
[20:42] Action: Daemon404 loves how dimmu borgir are one of his standard tests
[20:43] <Daemon404> although it makes perfect sense from an audio standpoint
[20:44] <wm4> ubitux: the teletext problem is that each AVSubtitle is a separate teletext page, right?
[20:45] <wm4> or how does this shit work
[20:45] <ubitux> Daemon404: that's what he call white noise i presume?
[20:45] <ubitux> wm4: i don't know ©
[20:46] <Daemon404> always ask ubitux about subttles
[20:46] <Daemon404> he loves subtitles
[20:47] <ubitux> :(
[20:49] <wm4> he knows best
[20:49] <wm4> and also doesn't care
[20:50] <wm4> also avcodec_decode_subtitle3 is impending, and barely solving any problems
[20:50] Action: wm4 sigh
[20:50] <cone-159> ffmpeg.git 03Michael Niedermayer 07master:9ec9d4636507: swscale/swscale_unscaled: fix alpha pointer & stride for planarRgb16ToRgb16Wrapper()
[20:50] <cone-159> ffmpeg.git 03Paul B Mahol 07master:37d6b2b4e6f8: swsscale/swscale_unscaled: add GBRAP16
[20:50] <wm4> uh or am I getting this wrong, and it's just about modifying avcodec_decode_subtitle2
[20:50] <wm4> whatever
[20:51] <ubitux> wm4: i suggested avcodec_decode_subtitle to avoid changing the behaviour :p
[20:52] <Daemon404> wm4, solving?
[20:52] <Daemon404> i read it as causing
[20:52] <Daemon404> :>
[20:52] <wm4> damn right
[20:52] <wm4> because now you'd need a decode loop and save the current subtitle AVPacket to get all AVSubtitles
[21:54] <durandal11707> ubitux: what should i use now to see FATE code coverage?
[21:54] <Daemon404> gcov
[21:55] <durandal11707> in other words i need it to do myself
[21:55] <Daemon404> i think configure has support
[21:55] <Daemon404> to do it automatically
[21:56] <durandal11707> as i already stated i'm not interested in doing it myself
[21:56] <ubitux> erm 404 mmh
[21:56] <ubitux> lemme check what's wrong
[21:57] <ubitux> ah
[21:57] <ubitux> doc is broken
[21:58] <ubitux> it prevents the build
[21:58] <ubitux> i'm going to disable doc for that one as a workaround
[21:59] <durandal11707> what is error?
[21:59] <ubitux> see fate
[21:59] <ubitux> they're all in red
[21:59] <durandal11707> RED ALERT
[22:00] <beastd> C&C
[22:00] <ubitux> :)
[22:01] Action: JEEB plays Hell's March
[22:02] <ubitux> durandal11707: a new reports will be available soon; meanwhile you can lurk in http://lucy.pkh.me/ffmpeg-coverage-snapshots/
[22:04] <ubitux> durandal11707: coverage.ffmpeg.org fixed
[22:07] <ubitux> it's fun, if i run the make again the make error goes away
[22:09] <durandal11707> ubitux: since when coverage.ffmpeg.org appeared?
[22:10] <ubitux> quite a while ago now
[22:10] <beastd> JEEBsv: would sure be fun to play that song on a bass guitar now. unfortunately i don't have one at hand :(
[22:11] <durandal11707> ubitux: i have never been informed
[22:13] <ubitux> now you are
[22:20] <durandal11707> too late, you have been fired
[22:20] <ubitux> :(
[22:27] <michaelni> is @samp{@@} correct texi syntax ?
[22:28] <ubitux> probably not
[22:28] <michaelni> what is the correct syntax ?
[22:28] <ubitux> michaelni: do you have the issue as well or do you want me to test?
[22:29] <michaelni> ill push a fix in a moment, though i cant reproduce it here
[22:30] <michaelni> if you want to test @samp{@@ }
[22:30] <michaelni> but iam pretty sure it will pass
[22:31] <ubitux> the issue was indeed from here (replacing with just @@ fixed it)
[22:32] <ubitux> michaelni: yeah that works
[22:32] <ubitux> michaelni: but that's visible
[22:32] <ubitux> possibly followed by @ 
[22:32] <ubitux> :ugly:
[22:33] <ubitux> - at code{[0x|#]RRGGBB[AA]} sequence, possibly followed by @samp{@@} and a string
[22:33] <ubitux> + at code{[0x|#]RRGGBB[AA]} sequence, possibly followed by '@@' and a string
[22:34] <ubitux> i'd better do something along those lines
[22:34] <cone-159> ffmpeg.git 03Michael Niedermayer 07master:9a63a45e48ac: doc/utils: fix docs build
[22:34] <ubitux> good enough
[22:34] <ubitux> :)
[22:34] <ubitux> thanks
[23:02] <llogan> why would @samp{@@} cause any issues?
[23:03] <Compn> in code? url? xml ?
[23:03] <llogan> 9a63a45
[23:05] <Compn> i dont know how to access that 
[23:05] <Compn> $ git log -p  9a63a45
[23:05] <Compn> fatal: ambiguous argument '9a63a45': unknown revision or path not in the working
[23:07] <llogan> git pull first
[23:07] <llogan> Move!
[23:07] <Compn> oh there it is
[23:08] <Compn> who knows
[23:08] <Compn> maybe it broke on some old version 
[23:08] <Compn> of docs thing
[23:10] <llogan> author: Compn, commit: "docs thing: fix @@ junk"
[23:51] <llogan> saste: did i even mention that the SPI check arrived and it deposited fine?
[23:51] <llogan> i thought i did, but i couldn't find any email that i did
[00:00] --- Thu Oct 17 2013