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

[burek]

[01:26] <Zeranoe> Could it be possible there is a bug in FFmpeg that is processor specific? This user is reporting a crash with libass: http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=1484
[01:27] <BBB> could be optimization that is mislabeled
[01:27] <BBB> happens regularly
[01:28] <BBB> need backtrace to confirm
[01:28] <Zeranoe> BBB: Interesting... I cant reproduce it, but I'll ask him for one
[01:29] <Zeranoe> BBB: Is it GCC or FFmpeg?
[01:29] <wm4> I'm going to laugh if it's just fontconfig being stuck or so
[01:30] <wm4> and by stuck I mean slowly doing its thing of scanning the windows font folder
[01:30] <Zeranoe> wm4: Would that produce a crash or a hang though
[01:30] <wm4> an apparent hang
[01:30] <Zeranoe> Hm
[01:31] <Zeranoe> So fonts and backtrace. Anything else to ask from this guy
[01:37] <saste> Zeranoe, his blood?
[02:02] <BBB> Zeranoe: it'd likely be ffmpeg
[02:03] <BBB> Zeranoe: but in some cases (typically this meant someone gave configure weird arguments), it can be gcc also (but then it's really still our bug, telling gcc to use instructions it shouldn't use)
[02:07] <Zeranoe> BBB: Well hes using my builds, and I never do anything wrong ever... sooooo
[02:16] <BBB> Zeranoe: right, but ffmpeg is also bug-free[tm], soooo :)
[02:35] <{V}> must be user error then :)
[02:43] <iive> there might be an fontconfig bug.
[02:45] <Zeranoe> iive: That only effects certain CPUs?
[02:46] <iive> suuuure. well, there was once a user who had some old setup files... unfortunately he removed them and couldn't reproduce the problem anymore.
[02:48] <Zeranoe> Off topic: I hate the new gnome in Debian testing.
[02:50] <iive> i guess you are late for the party. people have been hating new gnome for years...
[02:52] <Zeranoe> I've hated it before this, but before the layout just sucked. Now it doesn't even work.
[02:57] <Compn> Zeranoe : debian and ubuntu are on our shit list
[02:58] <Zeranoe> Compn: Whats spared, Slackware?
[03:02] <Zeranoe> I'm actually curious as to what distro most FFmpeg's devs are using
[03:03] <Compn> good question. i dont know 
[03:03] <Compn> the last one i installed was ubuntu, that was before the ceo decided to be a dick about everything
[03:03] <Compn> so i'm looking for a new one as well
[03:04] <Compn> arch is popular
[03:04] <Zeranoe> Compn: Unity is worse than Gnome
[03:04] <Zeranoe> Just by a little though
[03:10] <Zeranoe> Wow, theres a whole page for it: http://en.wikipedia.org/wiki/Controversy_over_GNOME_3
[03:24] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:98fc81b20d63: avformat/utils: move side data merge after parser
[03:24] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:01923bab9850: avcodec: move end zeroing code from av_packet_split_side_data() to avcodec_decode_subtitle2()
[03:24] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:f0f75dfa344c: avformat/utils: inject audio skip side data before the side data merge code
[03:30] <michaelni> ubitux, the issue outlined in 01923bab9850 might need your attention
[03:31] <BBB> Zeranoe: mac :)
[03:32] <Zeranoe> I somehow doubt most devs use macs
[03:32] <BBB> a few do
[03:33] <Zeranoe> michaelni: What do you use as an OS?
[03:34] <michaelni> linux (its ubuntu atm, was debian a while ago, iam not really attached to any distro, i might try others ...)
[03:36] <michaelni> i do also have various other OSs for testing & development
[03:36] <Zeranoe> interesting... Do you know if most devs are using Ubuntu?
[03:37] <michaelni> hmm, no idea
[03:46] <smarter> BBB: has work begun on multithreading ffvp9? I'd like to help
[04:18] <clever> Compn: do you happen to know anything about the h264 format in detail?
[04:18] <clever> or anybody else?
[04:18] <clever> ive narrowed down my problem to something about the h264 stream not being right
[04:18] <Compn> no, i'm mostly a troll here :)
[04:19] <clever> i modified my mplayer code to dump the raw bitstream to a file, then aimed the demo app at it
[04:19] <clever> and the demo app produces the same problem as mplayer, no output
[04:19] <clever> so it must be the bitstream, not my code
[04:20] <Compn> or mplayer dump is wrong
[04:20] <Compn> howd you dump it ?
[04:20] <clever> i added a write() call directly in the draw_slice function, right before i copy it into an omx buffer
[04:21] <clever> so its dumping the exact same data i give to the gpu
[04:21] <clever> which should be the exact data given to the codec _decode_slice function
[04:21] <Compn> unless swscale stepped in
[04:21] <Compn> or something nasty like that
[04:22] <clever> how would swscale play with the h264 bitstream?
[04:23] <Compn> oh i'm thinking of regular vo, not hwaccel
[04:23] <Compn> my bad
[04:24] <clever> let me throw mkvextract at the problem, rip the h264 stream out of the mkv file properly, and compare things
[04:24] <Compn> or mplayer -dumpvideo
[04:24] <clever> sample.h264: JVT NAL sequence, H.264 video @ L 41
[04:25] <Compn> there might be an h264 bitstream filter too
[04:25] <Compn> not sure if you need that
[04:25] <clever> /opt/vc/src/hello_pi/hello_video/test.h264: JVT NAL sequence, H.264 video, main @ L 41
[04:25] <clever> ok, file claims that my sample file is the same as the demo video
[04:26] <clever> so if i run the demo app on that...
[04:26] <clever> pi at pi ~/ilclient $ time make && time ./video /media/videos/4tb/dcc/sample.h264
[04:26] <clever> Compn: yep, this sample file plays perfectly in the demo app
[04:27] <clever> /tmp/bitstream: data
[04:27] <clever> but the data being dumped by my vo module, isnt a match
[04:27] <clever> decode_slice isnt giving me the right data
[04:30] <clever> Compn: let me redo these tests with some sample data that doesnt scream "yar i'm a pirate"
[04:30] <Compn> so i was right :)
[04:31] <Compn> aww, dont worry, we all know you're a pirate
[04:31] <clever> you do, but the omx guys dont :P
[04:32] <clever> videotrack:                         JVT NAL sequence, H.264 video @ L 41
[04:32] <clever> ok, the demo app has no demux ability, it cant handle mkv files
[04:32] <clever> and its ignoring ctrl+C
[04:32] <clever> and -9
[04:35] <Compn> love it when hardware locks up software
[04:36] <clever> Compn: http://www.auby.no/files/video_tests/h264_1080p_hp_4.1_40mbps_birds.mkv holy!
[04:36] <clever> that has to be CG?? :O
[04:36] <clever> (oh, and the raw video track plays fine on the demo app)
[04:51] <clever> Compn: http://pastebin.com/ne5AeJMv look at lines 41-45 vs 48-52
[04:58] <clever> Compn: i also see the vdpau start_code_prefix in the raw video track from an mkv file
[04:58] <clever> so it might not be vdpau code, but h264 code
[08:14] <wcpan_> hi, does avformat_open_input accept unix domain socket?
[08:55] <plepere> in ffmpeg, do I have to add a line somewhere to add my .asm file to compilation or just adding it in the libavcodec/x86 is enough ?
[09:17] <plepere> I manually modified the makefile in the libavcodec/x86/. Is this ok ?
[09:21] <ubitux> plepere: yes, you have to reference the .o in the Makefile
[10:06] <sspiff> ubitux: my patch is not getting any love (or hate!) on the mailing list :(
[10:06] <ubitux> sspiff: yeah i'm sorry i need to review it
[10:07] <ubitux> what day is today...
[10:07] <ubitux> mmh, can you wait until tomorrow?
[10:08] <sspiff> ubitux: I can wait until 2014, I was just worried nobody cared anymore!
[10:09] <durandal_1707> what patch?
[10:10] <ubitux> durandal_1707: dvb fix
[10:11] <ubitux> the pkt queue system in ffmpeg
[10:11] <ubitux> [FFmpeg-devel] [PATCH] Added queueing for OutputStreams to sidestep DVB subtitle encoding bug.
[10:11] <ubitux> this one ^
[10:21] <clever> ubitux: ok, ive almost got hardware decode working
[10:22] <ubitux> hw decode?
[10:22] <clever> now i need ffmpeg to provide some data from the video track, not sure where to get it from
[10:22] <clever> http://pastebin.com/ne5AeJMv
[10:22] <clever> do you see the 2 hexdumps in this pastebin?
[10:22] <ubitux> oh yeah i remember, the rpi thing, cool thing
[10:22] <clever> the dump on lines 48 thru 52, is the data given to hwaccel decode_slice
[10:23] <clever> the dump from lines 1 thru 40 is a header in the video track that was stripped out
[10:23] <clever> the omx code in the gpu needs that header to function
[10:23] <clever> i hacked decode_slice to pull the header from a file on disk and inject it, and everything works
[10:24] <clever> but the header is different for every file, and thats just nasty
[10:24] <ubitux> did you check extradata?
[10:24] <clever> where would the extradata be?
[10:24] <ubitux> st->codec->extradata{,_size}
[10:24] <clever> *looks*
[10:24] <ubitux> av_hex_dump() it
[10:25] <clever> AVCodecContext == st?
[10:25] <ubitux> AVStream
[10:25] <clever> oh, that function would have been usefull
[10:25] <clever> all i have in the hwaccel module is a AVCodecContext*
[10:25] <ubitux> codec is the codec context
[10:26] <clever> oh, so i already have what i want, *tries*
[10:26] <ubitux> so av_hex_dump(stdout, avctx->extradata, avctx->extradata_size);
[10:26] <ubitux> probably
[10:26] <ubitux> hopefully there is something
[10:26] <ubitux> and hopefully that's what you're looking for
[10:26] <clever> i got the header in the pastebin by running mkvextract on the sample file
[10:27] <clever> and then comparing the hexdump to the data decode_slice gets
[10:27] <clever> libavcodec/rpi_h264.c:25:2: error: implicit declaration of function 'av_hex_dump' [-Werror=implicit-function-declaration]
[10:27] <ubitux> yeah it's in libavformat hehe (doesn't belong here)
[10:28] <clever> yeah, i see it now, grep just found it
[10:28] <clever> ubitux: did you hear of the double free i found?
[10:29] <plepere> it compiles ! but I have a seg fault on a 2D table. to access table[X][Y] of a table[7][16], should I do [table + 16*X+Y] ?
[10:31] <ubitux> clever: i remember, somehow
[10:32] <clever> so once i get this header problem out of the way, i think the only remaining issue is stuttering and av sync
[10:32] <clever> right now, the draw_slice function directly renders frames, skipping draw_image entirely
[10:33] <clever> hmmm, i think the stuttering was my debug code, dumping the bitstream to the SD card
[10:33] <clever> its smoother now that thats off
[10:33] <clever> ubitux: but the hexdump from extradata isnt anywhere near the size
[10:34] <clever> its about 0x27 bytes, not ~0x280
[10:34] <clever> oh, its the first 0x27 bytes of the header i want
[10:34] <ubitux> maybe some stuff is stripped and only the part you need is available :p
[10:34] <clever> hmmmmm, i wonder what will happen if i just try it anyways
[10:36] <clever> hmmm, its not an exact match, but it is similar
[10:36] <clever> i have no clue how h264 encoding works, so i cant tell what the differences mean
[10:37] <clever> i'll let the gpu tell me, simpler
[10:39] <clever> ubitux: nope, back to a solid black image
[10:40] <clever> whatever that is, it isnt enough
[10:40] <ubitux> mmh too bad
[10:41] <clever> how much do you know about h264?
[10:41] <ubitux> almost nothing
[10:41] <clever> ok, so we are in the same boat, lol
[10:42] <clever> hmmm, h264.c field_end calls the hwaccel->end_frame function
[10:42] <clever> and if its vdpau, it also specialy called ff_vdpau_h264_picture_complete
[10:43] <clever> strange, since vdpau uses the hwaccel hooks
[10:43] <clever> decode_nal_units handles start_frame
[10:44] <clever> and decode_slice
[10:47] <clever> ok, decode_nal_units takes a buf and a size in, lets dump that!
[10:56] <clever> ubitux: the magic buffer is in there!
[10:56] <ubitux> great :)
[10:56] <clever> but this appears to be called for every packet of data
[10:56] <clever> need to isolate which one is the magic header, and somehow feed it to the hwaccel
[10:57] <clever> with almost no clue what i'm actualy looking for
[10:57] <clever> and to make things a bit worse, the header goes thru decode_nal_units before it loads my hwaccel module
[10:57] <clever> so i have to store it somewhere in the codec data
[10:58] <clever> No such audio driver 'alsa'
[10:58] <clever> aha, thats why i cant hear anything!
[11:00] <clever> ubitux: which package was that in debian based systems?
[11:00] <ubitux> like i know ._.
[11:00] <clever> i'll just grab my old ubuntu box to death
[11:01] <clever> ./alsa/asoundlib.h
[11:01] <clever> libasound2-dev.list:/usr/include/alsa/asoundlib.h
[11:01] <clever> ah, thats why i couldnt find it, alsa isnt in the name
[11:06] <ubitux> plepere: http://pastie.org/8497757
[11:08] <plepere> ok thanks
[11:11] <plepere> hmm, still gives a seg fault
[11:18] <sspiff> hmmm, I'm trying to skip MPEG demuxing, but it seems like my packets still need to pass by the dvbsub_parser, and don't
[11:19] <sspiff> how can I make the packets I pass  to decode_subtitle2 go through the parser first?
[11:19] <wm4> wow that's some verbose spam
[11:20] <sspiff> that's some messed up markov chain action :)
[11:22] <wm4> how did they even get the idea to spam TRAC
[11:22] <wm4> or do they just scrape the internet for post forms
[11:24] <ubitux> you think they have AI to look for registering/login logics, and post randomly?
[11:24] <ubitux> (i mean generic logic, not a trac specific code)
[11:25] <wm4> why not
[11:25] <sspiff> wm4: they just look for post forms with a textarea
[11:26] <sspiff> ubitux: I would think so, why the hell would you target TRAC specifically?
[11:26] <ubitux> yeah that's what i'm wondering
[11:26] <sspiff> not only is it low yield (spamming a blog comment is likely to get more views than something on trac, people watching track generally know not to click on any links in this kind of thing)
[11:26] <ubitux> maybe because it's easy (they most likely have a template)
[11:27] <sspiff> my parentheses are wrong, but whatever!
[11:27] <sspiff> ubitux: could be, but I think they just "try" register forms
[11:27] <ubitux> also, the point is to pollute the internet; so they might expect search engines to crawl them
[11:27] <plepere> dafuq I just read :)
[11:28] <sspiff> plepere: I think http://en.wikipedia.org/wiki/Markov_chain#Markov_text_generators
[11:28] <sspiff> ubitux: good point
[11:28] <sspiff> crawlers do hit trac, so if trac is easy, they might target trac
[11:28] <clever> sspiff: that reminds me, my wiki has been flooded with spam, sometimes i sit down and delete 100 articles in a row
[11:28] <clever> its getting thru even with email validation enabled
[11:29] <sspiff> clever: all you need is a bot that can set up webmail accounts or your own domains
[11:29] <ubitux> michaelni: can you give me permissions to delete trac entries?
[11:29] <ubitux> or just delete this shit yourself :p
[11:29] <clever> sspiff: i checked, every single one was @hotmail.com
[11:29] <clever> i'm back to 7 pages of spam on my wiki
[11:29] <clever> i should sit down and nuke it again
[11:30] <ubitux> also, we could add a very simple captcha
[11:30] <plepere> actually, for SteamOS, do we have any info on the tech behind its "gaming" over LAN ?
[11:30] <ubitux> another quite method is to add hidden input 
[11:30] <ubitux> +useful
[11:31] <ubitux> input(s)
[11:31] <sspiff> ubitux: yeah but isn't that easy to fix for the spammers?
[11:31] <ubitux> and if one or more hidden input is filled, you fail
[11:31] <ubitux> sspiff: not that simple
[11:31] <ubitux> because you need to evaluate css
[11:31] <sspiff> ah right
[11:31] <sspiff> I see
[11:31] <clever> ubitux: the wiki software has a hidden input with a noonce code, you must read the page, and return the right code in that input to get thru
[11:31] <sspiff> yeah, I thought <input type=hidden>
[11:32] <clever> i had trouble with that when writting a greasemonkey script to delete with 1 click
[11:32] <ubitux> clever: some kind of captcha/question
[11:32] <ubitux> but that's annoying for users
[11:32] <clever> yeah
[11:44] <michaelni> ubitux, tiket deleted 
[11:44] <ubitux> thx
[11:45] <clever> ubitux: i'm off to bed now, letting things recompile with alsa before i take another stab at things
[11:45] <ubitux> :)
[11:50] <ubitux> Daemon404: don't wanna use trap?
[11:50] <ubitux> also IFS=$'... will add a $ in IFS
[11:51] <michaelni> about trac spam:
[11:51] <michaelni> Feb 21 13:47:44 <michaelni>	also in case i worded it unclearly, some volunteer needs to get us api keys for akismet and the others listed at http://trac.edgewall.org/wiki/SpamFilter with exception of where they key is just for training the external service) 
[11:51] <michaelni> Nov 09 18:12:30 <michaelni>	kierank, trac supports several spam filter services, like akismet, typepad, defensio, http:bl. But all these need API keys AFAIK. If someone provides such keys i can enter them in trac, that may (or may not) improve spam filtering
[11:52] <ubitux> Daemon404: i think you want either IFS=$'\n' or what you have without $, 'need to check
[11:52] <ubitux> also, rm -f instead of rm, and probably in the trap EXIT
[12:02] <saste> ubitux: you going to review my ffprobe patches?
[12:02] <saste> otherwise i'll probably push the whole patchset, since nobody is going to review it
[12:04] <ubitux> i have tons of things to review :(
[12:07] <cone-461> ffmpeg.git 03Sean McGovern 07master:a7b87ca9111b: libxavs: rename and fix a variable name
[12:07] <cone-461> ffmpeg.git 03Michael Niedermayer 07master:074b89f1e235: Merge commit 'a7b87ca9111bafb220ab94d53ab4e4ed48111800'
[12:17] <cone-461> ffmpeg.git 03Martin Storsjö 07master:ea9f7173ae91: configure: Avoid requiring c99wrap for working around msys path issues
[12:17] <cone-461> ffmpeg.git 03Michael Niedermayer 07master:8c9df116cd57: Merge remote-tracking branch 'qatar/master'
[12:27] <Daemon404> ubitux, thatbisnt portable 
[12:27] <Daemon404> it was originally that
[12:27] <Daemon404> doesnt worknon bsd
[12:31] <ubitux> Daemon404: yes but current version is not correct
[12:31] <ubitux> it includes a '$' in the IFS
[12:33] <Daemon404> oh the 2nd has $
[12:33] <Daemon404> yes that should be removed
[12:42] <BBB> smarter: yeah, mostly done already
[12:42] <BBB> smarter: but I can put it up and you can finish it if you like, I did most of the plumbing, the progress reporting itself is basically outstanding
[12:43] <BBB> oh and one refactoring
[12:45] <smarter> BBB: did you both frame-threading and tile-threading?
[12:46] <smarter> *do both
[12:48] <ubitux> saste: what's the patch order for ffprobe?
[12:48] <ubitux> nested option and then string validation?
[12:48] <ubitux> am i missing one?
[12:53] <cone-461> ffmpeg.git 03Clément BSsch 07master:4e70eeef3a5e: cmdutils: randomize spaces after 69cf626f9.
[12:56] <saste> ubitux: lavu/avstring: add av_utf8_decode() function
[12:57] <saste> ffprobe: check for errors, and abort immediately
[12:57] <saste> ffprobe: add support for nested options in writer contexts
[12:57] <saste> ffprobe: implement string validation setting
[12:58] <saste> i'm automatically setting utf8 validation flags depending on the writer
[12:58] <saste> i could expose them as well, as writer generic options, but then it will need more automatic setup
[12:58] <saste> and i suppose users won't be happy in case they have metadata in weird charsets, which is unfortunately very likely
[12:59] <saste> ffprobe: implement string validation setting
[12:59] <saste> this is the patch which affects interface the most, so that's the one which needs a second look
[13:02] <BBB> smarter: only frame so far; tile is easier actually
[13:02] <BBB> smarter: I can leave tile for you if you want, it's not hard, just some mild trickiness with the loopfilter
[13:15] <smarter> I could try :)
[13:16] <smarter> I haven't done anything related to threading in ffmpeg/libav yet
[13:22] <Compn> smarter : we could use vc1 threading too, i think :)
[13:23] <ubitux> why not let it die instead?
[13:23] <smarter> less interesting :P
[13:26] <BBB> vc1 should die, yes
[13:26] <saste> ubitux: av_malloc() and childrean
[13:27] <BBB> sure, you can tile-mt, it's not super-hard, ask questions :)
[13:27] <av500> but porn needs vc1
[13:27] <BBB> you need synchronization if you want to do the loopfilter inline
[13:27] <saste> don't think that comprises av_realloc()
[13:27] <BBB> since it crosses tile boundaries
[13:30] <ubitux> saste: dunno, i see realloc in the code
[13:31] <saste> wow, running unsharp from libavutil, now that's a hack
[13:33] <wm4> it just takes some seconds!
[14:09] <plepere> ok, I'm getting slightly annoyed by this. preparing a pastebin of all the data I got.
[14:14] <michaelni> /home/fate/fate/x86_64-debian-asan-144800/install/lib/libavcodec.a: No space left on device
[14:17] Action: michaelni deletes 1.5g of crap 
[14:17] Action: Compn getting ready to install 4TB drive
[14:20] <plepere> http://pastebin.com/WUw29Uws
[14:21] <plepere> so basically, r7 is supposed to be a value, but gives me an error, and I only get a good value by copying the lower byte from r7 to another register.
[14:22] <plepere> "my" is between 1 and 8
[14:22] <plepere> or 7
[14:22] <nevcairiel> is this on 64-bit?
[14:23] <plepere> yes
[14:23] <cone-461> ffmpeg.git 03Michael Niedermayer 07master:fdc0b3f8c19f: avcodec/utils: remove unused variable
[14:23] <nevcairiel> the fucntion parameter is an int, so you might need to zero-extend it, i guess
[14:24] <plepere> doesn't it do it by default when putting an argument in a register ?
[14:24] <nevcairiel> there was a reason that all of the stride parameters where changed to ptrdiff_t so the compiler zero-extends for you
[14:25] <plepere> ok
[14:25] <plepere> so I need to change the type to uint8_t or ptrdiff_t ?
[14:25] <nevcairiel> %if ARCH_X86_64
[14:25] <nevcairiel>     movsxd        r2, r2d
[14:25] <nevcairiel> %endif
[14:25] <nevcairiel> something like this is done in many other places
[14:25] <plepere> ok
[14:25] <plepere> ah, it explains a lot !
[14:26] <plepere> thanks
[14:27] <plepere> yay, runs now !
[14:47] <cone-461> ffmpeg.git 03Xidorn Quan 07master:973b1a6b9070: vda_h264_dec: backup context before overriding
[14:47] <cone-461> ffmpeg.git 03Michael Niedermayer 07master:78bfc417d430: Merge branch 'master' of https://github.com/upsuper/ffmpeg-vdadec
[15:58] <sspiff> ubitux: are you clement?
[15:58] <ubitux> yes
[15:58] <sspiff> alright
[16:05] <sspiff> for my patch: the remuxing (-map and -scodec copy) doesn't work, but this is a different problem (the data is present in the TS but doesn't show up to the decoder, I haven't figured out why yet)
[16:05] <sspiff> the recoding to dvbsub (-scodec dvbsub) case works
[16:06] <sspiff> I originally intended to keep track of only one packet, but the problem is that the subtitles can overlap randomly, that's why I introduced the queue
[16:06] <ubitux> what is "the decoder"? did you try with mplayer/mpv or vlc?
[16:07] <sspiff> we're talking about subtitle-only TS'es, so no
[16:07] <ubitux> subtitles can overlap randomly? is your code handling that?
[16:07] <sspiff> yes
[16:07] <sspiff> and in the sample, subtitles don't dissappear before 2 or 3 more subtitles have appeared (or more)
[16:08] <sspiff> so you need to keep track of all the pending "clear" packets
[16:08] <sspiff> the code is dirty (the dvb sub specific code in there was already pretty hacky tbh), I know
[16:08] <ubitux> so multiple sub starting at different ts, and all of them being clear later?
[16:08] <ubitux> (can you clear just one of them?)
[16:09] <sspiff> ubitux: I think so, I'll have to check, but I think so
[16:09] <sspiff> I'll see if I get the same appear/disappear sequences as the original, but playing a recoded sample with vlc worked fine IIRC
[16:18] <ubitux> sspiff: did you contact marton btw?
[16:19] <ubitux> he had to deal with a similar issue with the dvb teletext decoder
[16:19] <ubitux> i don't know what's the state of this
[16:20] <ubitux> and really, if you could fix the dvb subtitles properly (instead of adding a workaround in ffmpeg.c) that would be great
[16:20] <sspiff> I'll do some tests, fix the tabbing issue, and switch to av_packet_ref/av_packet_unref
[16:21] <sspiff> I haven't talked to marton yet
[16:21] <sspiff> ubitux: the problem is that I don't know of a way to trigger the clear packet out-of-sequence from the codec
[16:21] <sspiff> since they generate AVSubtitles, not AVPackets
[16:22] <sspiff> I understand that you'd prefer a real fix, but I'm not entirely sure that's possible with the current API
[16:22] <sspiff> caching the packets in the encoder might work, I'll check it out
[16:22] <sspiff> haven't really looked to much at encoding
[16:55] <ubitux> why do the cosmetics guys insist on breaking inline if/switch-cases :(
[18:48] <cone-171> ffmpeg.git 03Vittorio Giovara 07master:305d3d9f1f7f: mpeg4videoenc: restore macro parentheses
[18:48] <cone-171> ffmpeg.git 03Michael Niedermayer 07master:bc140fb568df: Merge commit '305d3d9f1f7f0bdc18744f376a0ff5b012e4e6cf'
[19:04] <cone-171> ffmpeg.git 03Vittorio Giovara 07master:874838dc6589: fate: add one select filter test
[19:04] <cone-171> ffmpeg.git 03Michael Niedermayer 07master:a486dec4fd8f: Merge commit '874838dc6589d978611c89a40694a5074f892a76'
[19:08] <cone-171> ffmpeg.git 03Vittorio Giovara 07master:d28fc7b29a72: avconv_filter: add new line after error message
[19:08] <cone-171> ffmpeg.git 03Michael Niedermayer 07master:c8a0a2e990ba: Merge commit 'd28fc7b29a728bd2f88c10121abbd0442c341746'
[19:14] <cone-171> ffmpeg.git 03Vittorio Giovara 07master:dd249245d012: filter docs: reference scale and fps filters
[19:14] <cone-171> ffmpeg.git 03Michael Niedermayer 07master:c0caf7e81493: Merge commit 'dd249245d012c1eceb57c166e256fc95e74f4bb1'
[19:31] <cone-171> ffmpeg.git 03Diego Biurrun 07master:ac0e03bab001: dct/fft: Give consistent names to fixed/float template files
[19:31] <cone-171> ffmpeg.git 03Michael Niedermayer 07master:6a7980e2cd4b: Merge remote-tracking branch 'qatar/master'
[20:40] <llogan> michaelni: https://trac.ffmpeg.org/ticket/222 last comment is spam with attachment
[20:40] <llogan> same with https://trac.ffmpeg.org/ticket/993
[20:49] <michaelni> llogan, why do you tell me ?, you should be able to delete them i think
[20:50] <michaelni> i mean if you click on the attachment then theres a button "delete attachment"
[20:50] <michaelni> or did i forgot some permission?
[20:56] <ubitux> llogan: "TIP XX: add -f xv - at the end of your transcode line to visually follow the status"
[20:56] <ubitux> (or sdl or whatever)
[21:08] <llogan> michaelni: yes. user error. there was no delete option until i clicked on the attachment.
[21:09] <llogan> i tohught it was a comment with an attachment, but it is an attachment with a comment
[21:10] <llogan> but i can't get rid of "domtheo" user...if it exists
[21:10] <llogan> ubitux: thanks!
[21:15] <llogan> ubitux: it really slows down encoding
[21:16] <ubitux> s/xv/sdl/ for more portability
[21:16] <ubitux> but only 1 window allowed
[21:16] <ubitux> (sdl2 might be a better output)
[21:16] <ubitux> (i've heard it supports multiple output windows, and it's more portable than xv)
[21:35] <michaelni> llogan, domtheo deleted
[21:39] <mraulet> michaelni: some commits merge to our master brnch
[21:40] <mraulet> https://github.com/OpenHEVC/FFmpeg/compare/243eb17278...829c7ac690
[21:54] <michaelni> mraulet, adding a field in the middle of AVCodecContext breaks ABI (unless all fields afterwards where accessed only through wrapers)
[21:54] <michaelni> also the patchset seems to break fate-h264-lossless
[21:58] <michaelni> and theres trailing whitespace in there (our git hooks reject such commits so i would not be able to push that
[21:58] <michaelni> )
[22:34] <mraulet> ok
[22:38] <mraulet> https://github.com/OpenHEVC/FFmpeg/commit/12bbfdba1899d11044d2bd8457159fc8b4b52a76
[22:38] <mraulet> https://github.com/OpenHEVC/FFmpeg/commit/b68d306b3b29bda8351b1702e6a55654eb70d42f
[22:39] <mraulet> and https://github.com/OpenHEVC/FFmpeg/commit/14341c6d9a6885657ba365807223e96a67d6c0ed
[22:39] <mraulet> can be applied
[22:47] <michaelni> libavcodec/hevc.c:379:36: error: PTL has no member named general_PTL
[22:53] <cone-670> ffmpeg.git 03gcocherel 07master:0afa254d4efd: hevc : fix pcm(cherry picked from commit 12bbfdba1899d11044d2bd8457159fc8b4b52a76)
[22:53] <cone-670> ffmpeg.git 03gcocherel 07master:81d0252dacc2: hevc : update hls_decode_neighbour(cherry picked from commit 14341c6d9a6885657ba365807223e96a67d6c0ed)
[23:07] <ubitux> why is the "cherry-pick" message inlined?
[23:07] <ubitux> is it a bug in -x?
[23:08] <Eduard_Munteanu> I'm thinking of patching a mplayer slave-like interface into ffplay, to control it. Would such a change be accepted?
[23:09] <ubitux> lol
[23:10] <ubitux> mplayer slave thing is shitty, that's one of the reason it was dropped from mpv
[23:10] <ubitux> you should consider a better approach
[23:11] <cone-670> ffmpeg.git 03Clément BSsch 07master:616da5954268: avcodec/x86/vp9dsp: merge a few SWAP together.
[23:13] <michaelni> ubitux, dont ask me if its a bug in -x or a feature
[23:14] <ubitux> it's supposed to be added in the description
[23:14] <ubitux> at least that was the case last time i used it
[23:14] <ubitux> this inline thing looks broken somewhere
[23:22] <cone-670> ffmpeg.git 03Stefano Sabatini 07master:98786aa2f05d: lavfi/aevalsrc: initialize pointer to expression to NULL
[23:24] <ubitux> BBB: so using rsp to play with the stack will also work on 32-bit?
[23:24] <ubitux> (not that it matters much in my case since i'm using the 16 xmm registers but i'm curious)
[23:31] <cone-670> ffmpeg.git 03Stefano Sabatini 07master:50a28b13936b: doc/examples: do not check NULL values for avcodec_close()
[23:34] <BBB> ubitux: cglobal func, args, gprs, xmmregs, stack_memory, names[]
[23:34] <BBB> ubitux: if you don't ever need rXm, use -stack_memory, which indicates it won't use an extra register
[23:35] <BBB> ubitux: i.e. saves a reigster, may sometimes be relevant
[23:39] <Eduard_Munteanu> ubitux: yes, I don't mean to duplicate it
[23:40] <Eduard_Munteanu> Right now I just need a way to queue files for playing.
[00:00] --- Fri Nov 22 2013