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

[burek]

[01:29] <BBB-work_> j-b, poke!
[03:05] <Compn> Daemon404 : i blame you for this http://files.nyaa.eu/HOW_DID_I_PLAYED_BACK.txt
[03:08] <Daemon404> its a terrible guide
[03:08] <Daemon404> not my doign
[03:08] <Daemon404> enjoy.
[03:09] <Compn> maybe nevcairiel then
[03:33] <cone-934> ffmpeg.git 03Michael Niedermayer 07master:ef9063900430: avfilter/vf_mp:  preserve pixel format when possible
[04:02] <Compn> hmm were yuvj pix fmts even supported in mplayer filters ?
[04:03] <Compn> do ffmpeg filters work with rgb ?
[04:09] <durandal11707> nope they only work with mono white
[04:10] <drv> but all of my favorite videos are in mono black!
[05:14] <highgod> Hi, I want to ask a question, I want to rewrite the av_opencl_register_kernel_code because it has lock operation before thread init if we want to use dynamic lock, so I reference the function avfilter_register, but I found that it does not have any lock either, is it OK, if two threads call the function at the same time, the global variable first_filter may cause some error I think
[08:18] <wm4> assume it's possible to demux only one track of a file, is there a way to make this work with libavformat?
[08:18] <wm4> since the user can just request any combination of tracks at once
[09:52] <michaelni> wm4, if i understand correctly, that would mean the demuxer would have to fail if the user enables more than one track or there would be need for multiple demuxers
[09:52] <wm4> michaelni: yes
[10:07] <cone-507> ffmpeg.git 03Luca Barbato 07master:6d8629aac136: aac: K&R formatting cosmetics
[10:07] <cone-507> ffmpeg.git 03Michael Niedermayer 07master:1bcfb1eea836: Merge commit '6d8629aac13692447b54eac795bf74007ebf8987'
[10:08] <wm4> pretty fun how even ffmpeg uses some deprecated ffmpeg functionality
[10:14] <cone-507> ffmpeg.git 03Luca Barbato 07master:07c52e2c7c60: aac: return meaningful errors
[10:14] <cone-507> ffmpeg.git 03Michael Niedermayer 07master:831e749bc926: Merge remote-tracking branch 'qatar/master'
[10:19] <cone-507> ffmpeg.git 03Carl Eugen Hoyos 07master:7f1b3c2ca694: Fix muxing QDM2 mono into caf.
[10:19] <cone-507> ffmpeg.git 03Carl Eugen Hoyos 07master:f91833210e74: Set block_align when reading QDM2 in mov.
[10:19] <cone-507> ffmpeg.git 03Carl Eugen Hoyos 07master:41f3c60fbb74: Avoid a null pointer dereference in avcodec_decode_video2().
[10:19] <cone-507> ffmpeg.git 03Michael Niedermayer 07master:16310e36d940: Merge remote-tracking branch 'cehoyos/master'
[12:48] <cone-507> ffmpeg.git 03Michael Niedermayer 07master:223645671576: avfilter/avfilter: Make avfilter_register() thread safe
[13:10] <cone-507> ffmpeg.git 03Timothy Gu 07master:934df3b03757: doc/encoders: alphabetically list the encoders
[13:10] <cone-507> ffmpeg.git 03Timothy Gu 07master:7eb5288f17aa: doc/decoders: document libopus decoder
[13:55] <superware> I'm struggling with this for days now :| I have an h264-ts-udp stream that doesn't ffplay/ffprobe with "udp://0.0.0.0:1234" but if I dump the stream to a .ts file it plays great. Any ideas??
[13:55] <wm4> superware: debug the protocol implementation?
[13:56] <wm4> if there isn't anyone who cares about it, and it has a problem, you're the only one who can fix it
[13:58] <wm4> saste: anything about that icy stuff?
[14:01] <superware> wm4: but ffplay can play a file with the stream dump, what does it mean?
[14:02] <superware> it's like getting the stream off udp doesn't work and getting it from a file does
[14:06] <superware> wm4: if I'm getting the stream from UDP by myself, how can I feed it (Transport Stream) to libav* for playback?
[14:06] <superware> not playback, for frame extraction..
[14:10] <wm4> superware: you can use custom streams with libavformat
[14:10] <wm4> superware: demux_lavf.c in mplayer would be an example for that (although I'm not sure if looking there is a good idea)
[14:13] <superware> what would you do? I've used dvbsnoop to inspect the TS and it seems just fine. ffplay can play it from a .ts file, but not from udp. VLC can play it from both.
[14:13] <av500> didnt you have some udp error messages?
[14:14] <av500> about buffer sizes?
[14:15] <superware> using udp://0.0.0.0:1234?buffer_size= or udp://0.0.0.0:1234?fifo_size= didn't help
[14:15] <av500> still error messages?
[14:15] <superware> yes
[14:15] <av500> then you know where to start debugging
[14:16] <superware> it seems the data is corrupted
[14:16] <superware> when coming from UDP
[14:17] <superware> can I stream it to you? :)
[14:18] <superware> please?
[14:21] <av500> to me?
[14:21] <superware> :) please, so you can see the problem
[14:23] <av500> sorry, not my day job :)
[14:23] <superware> some of the udp datagrams are 18988 bytes long, maybe buffer_size/fifo_size have upper limits?
[14:24] <superware> just for a few minutes, helping not working :)
[14:26] <superware> av500: ok, that's 101 TS packets in one datagram, maybe ffmpeg can't handle it..
[14:29] <av500> maybe
[14:30] <wm4> I doubt ffmpeg cares about datagrams
[14:30] <wm4> on the demuxer level
[14:31] <superware> but in the udp level libavformat/udp.c, the demuxer level is just fine, it plays nicely from a .ts file
[14:35] <superware> does MPEG TS standard forces 7 TS packets per IP packet?
[14:36] <av500> no
[14:36] <kierank> no
[14:36] <kierank> but it makes sense to use 7
[14:37] <kierank> and a lot of devices go crazy if you don't
[14:37] <superware> you mean playback devices?
[14:38] <kierank> yes
[14:38] <kierank> or analysers
[14:39] <kierank> ffmpeg probably has an upper limit of packet size
[14:39] <superware> or ffplay :) it seems it can't handle 101x188 (18988) at once
[14:40] <superware> is it configurable? I can't spot it on https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/udp.c
[14:41] <av500> #define UDP_MAX_PKT_SIZE 65536
[14:43] <superware> oh, so I've tried to override this with udp://0.0.0.0:1234?buffer_size=131072&fifo_size=200&pkt_size=64000, but nothing helped
[14:48] <superware> av500: the error I see related to udp is "Part of datagram lost due to insufficient buffer size" which is at line 752
[14:49] <kierank> change the max packet size
[14:49] <superware> isn't udp://0.0.0.0:1234?buffer_size=131072&fifo_size=200&pkt_size=64000 enough?
[14:50] <superware> the largest UDP packets are ~18988 (101x188) bytes
[14:53] <superware> kierank: can you please help me? :|
[14:53] <kierank> then i don't know
[14:53] <kierank> use normal sized packets
[14:53] <kierank> :)
[14:55] <superware> kierank: it's not under my control. VLC handles it nicely..
[14:56] <superware> the buffer size can be defined, so there's no apparent reason for it not to work other that a bug
[14:56] <superware> that=than
[14:57] <superware> if you show me where the spec limits packet size, I might be able to do something about it
[15:06] <kierank> the spec doesn't limit packet size
[15:06] <kierank> it's a convention
[15:07] <superware> kierank: so ffmpeg should handle 18988 bytes packets, maybe there's a bug in udp.c?
[15:07] <kierank> probably
[15:07] <superware> can you please please help me locate it?
[15:07] <kierank> fifo_size appears to be a private option
[15:08] <kierank> but i don't know much more about the circular buffer thread in udp.c
[15:08] <kierank> ask michaelni 
[15:08] <superware> ok
[15:08] <superware> michaelni: hi
[15:11] <superware> kierank: what do you mean by "private"? line 555/6 set it
[15:11] <kierank> private means it's a demux specific option
[15:13] <superware> it's being adjusted in line 588 (*= 188) and used in line 699 in fifo constructor
[15:18] <superware> kierank: who else might know? :|
[15:31] <superware> kierank: do you happen to know michaelni activity hours?
[15:31] <kierank> no
[16:03] <BBB> j-b: pokey
[16:25] <cone-467> ffmpeg.git 03Carl Eugen Hoyos 07master:2bccd82c29de: Do not list libshine like a main option in configure's output.
[17:30] <saste> uhm nobody gonna review my doxy patches?
[17:35] <Compn> saste : which ones ?
[17:35] Action: Compn afk bbl
[17:38] <saste> Compn, i notice that you usually go afk just after doing a question
[17:39] <saste> bitstream API and AVPicture API
[17:58] <Compn> saste : its fun , but rain has spoiled my afk plans
[18:59] <Daemon404> wm4, nicolas is a perfect example of the inbreeding / bubble-life of ffmpeg
[19:00] <wm4> Daemon404: but even reimar disagrees with him
[19:00] <Daemon404> so far its 3-to-1... we shall seee how it goes
[19:00] <Daemon404> my money is on stubborness
[19:01] <Compn> ghost in the shell arise is terrible. character redesign, fanservice, no yoko kanno
[19:01] <wm4> honestly I'm starting to stop caring... I use it for a few obscure cases only, anyway
[19:01] <wm4> and it's not that important
[19:01] <Daemon404> it == ffmpeg?
[19:01] <wm4> no the issue at hand
[19:01] <Daemon404> heh
[19:02] <Daemon404> mixed encodings in subtitles filers is *ver* common
[19:02] <Daemon404> very*
[19:02] Action: Daemon404 shrugs
[19:02] <wm4> as for ffmpeg... I guess I can't not use it
[19:02] <Daemon404> the eternal struggle
[19:02] <Daemon404> "what is this stupid shit?"
[19:02] <Daemon404> "i have no choice.. meh"
[19:02] <wm4> yeah, but this affects only the libavcodec subtitle converter
[19:02] <Daemon404> well nobody uses that
[19:03] <Daemon404> for a reason
[19:03] <wm4> the only "important" cases I use it for are smi and webvtt
[19:03] <wm4> (btw. the smi reader doesn't really work on real world files)
[19:03] <Daemon404> smi are pretty common too
[19:03] <Daemon404> (in china)
[19:04] <wm4> and korea
[19:04] <Daemon404> wm4, i dream of one day when libaegisub is usable as a library
[19:04] <Daemon404> but that day prbably wont come.
[19:04] <wm4> a generally usable subtitle library sure would be nice
[19:06] <Daemon404> oh well
[19:06] <Daemon404> time for crepes
[19:06] Action: Daemon404 vanish
[19:07] <Compn> wm4 : ati cards support vdpau ?
[19:07] <Compn> wm4 / Daemon404 : btw just start attaching your smi files as samples , thats how this project works. samples or ignore bug report
[19:10] <wm4> Compn: I reported it to ubitux (who wrote this), but he lost interest
[19:10] <wm4> such is the way of open source
[19:31] <iive> Compn: radeon+mesa3d add vdpau decoding. should be avaliable in 3.10 kernels and mesa 9.2
[19:32] <wm4> libva has a xvba backend too
[19:32] <wm4> though I heard that it's unmaintained and bad
[19:43] <wm4> wow testing .rm in low memory situations
[19:43] <JEEBsv> :D
[19:43] <wm4> seriously the sttff this guy finds
[19:43] <wm4> *stuff
[21:03] <superware> michaelni: hi
[21:29] <michaelni> superware, hi
[21:31] <superware> how are you? saw my email to you? :)
[21:38] <superware> michaelni?
[21:40] <michaelni> superware, my inbox is full of mails i was afk a bit :)
[21:41] <superware> can I please describe you the issue?
[21:42] <ubitux> superware: why don't you just open a bug report?
[21:42] <superware> well it might be hard to reproduce
[21:45] <superware> I have a device unicasting a h264-ts-udp stream which ffmpeg/ffplay/ffprobe have troubles playing. When I dump the udp dump to a .ts file it plays nicely. The main issue seems to be "Part of datagram lost due to insufficient buffer size", after some investigation it turns out that stream contains 18988 bytes long datagrams (101*188 TS packets) which udp.c/fifo.c has troubles with. Using 
[21:45] <superware> udp://0.0.0.0:1234?fifo_size=200 didn't help.
[21:47] <michaelni> superware, which buffer/fifo exactly is causing the problem ?
[21:48] <superware> I guess https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/udp.c#L752
[21:49] <superware> I'm not really 100% sure this is the problem, but a) the TS stream is playing when dumped to a file, b) that stream contains quite big datagrams.
[21:52] <michaelni> is there a easy way to reproduce this ? 
[21:52] <superware> I can send the stream to any IP you'll give me
[21:52] <superware> (will it work over the internet?)
[21:53] <superware> very small, about 200kbps
[21:53] <michaelni> id prefer a local way to reproduce it if possible
[21:54] <michaelni> more predictable/reproduceable and i dont have to mess with the router to forward it
[21:54] <superware> then I guess somehow produce a stream with 101*188 bytes datagrams
[21:55] <superware> I rather think me send the stream to you (for as long as we need) might be a faster method to find the bug/issue
[21:55] <superware> send=sending
[21:56] <superware> I'll really appreciate it
[21:56] <michaelni> what are you using to send the stream ?
[21:57] <superware> what do you mean? it's an encoder card
[21:57] <michaelni> hmm ok
[21:59] <michaelni> being able to locally reproduce this would also come in handy for regression testing later btw
[21:59] <superware> we can think about this after we solve the problem :)
[21:59] <michaelni> that is we could check future changes against it to make sure we wont break it again once its fixed
[22:00] <superware> of course
[22:00] <superware> I can prepare a small utility that will send a TS file using large datagrams
[22:01] <michaelni> that would be very usefull 
[22:01] <michaelni> if its reproduceable with it 
[22:01] <superware> but it might take me time, can we still try me sending the stream to you in the meantime?
[22:01] <superware> that's another question
[22:02] <superware> can I please /msg you?
[22:03] <michaelni> can i see the full uncut output with all warnings and debug stuff that you get when this bug happens ?
[22:03] <superware> yes, a sec
[22:08] <superware> http://pastebin.com/iAAP3isS
[22:18] <superware> michaelni: do you need more info?
[22:27] <michaelni> superware, dunno, maybe a backtrace from where the error gets printed but i think i can guess where that will be
[22:32] <superware> backtrace? how?
[22:33] <llogan> http://ffmpeg.org/bugreports.html
[22:34] <Daemon404> wm4, i think i may refrain from being involved anymore in ths
[22:34] <Daemon404> it just rots my brain
[22:34] <wm4> heh
[22:34] <wm4> he'll probably create a monster
[22:34] <superware> llogan: but there's no crash
[22:35] <Daemon404> wm4, and i will continue to not use ffmpeg's subttle facilities
[22:35] <Daemon404> because of shit like this.
[22:35] <durandal11707> shit being ... ?
[22:36] <wm4> well, the subtitle demuxers are probably slightly better than MPlayer's hilarious old code, so I'll use it
[22:36] <Daemon404> read any of nicolas' replies to wm4's patch, durandal11707 
[22:36] <Daemon404> that shit.
[22:37] <Daemon404> he lives in an imaginary world
[22:37] <durandal11707> that little patch ...
[22:37] <wm4> yeah, way too much effort for such a small patch
[22:37] <wm4> so I guess I'll stop caring
[22:37] <Daemon404> i gotta say, he does a great job of the neckbeard-style "all output is correct or it wont work"
[22:37] <Daemon404> completely unrealistic.
[22:39] <durandal11707> use AV_EF_AGGRESSIVE ?
[22:39] <nevcairiel> isnt there a explode flag for giving up on errors
[22:40] <Daemon404> nevcairiel, doenst matter. he argues it's not "correct" to ever return anything thats not perfect utf8
[22:40] <durandal11707> you always could add new AV_EF_....
[22:41] <Daemon404> durandal11707, unfortunately i think this is an ideaological issue nicolas has
[22:41] <Daemon404> i dont think anything else will pelase him
[22:41] Action: Daemon404 shrugs
[22:42] <wm4> yeah, he's rejecting even a flag to disable the check
[22:43] <superware> michaelni: I've just checked with a friend, he managed to receive the stream over the net
[22:43] <Daemon404> wm4, dreppers gonna drepper
[22:43] <Daemon404> that is all.
[22:44] <wm4> now I feel sorry for dreppering on another place today
[22:44] Action: durandal11707 will stop this
[22:45] <Daemon404> wm4, let me just not merge some gl3 code because i have to rewrite all the man pages first
[22:45] Action: Daemon404 runs
[22:45] <Daemon404> (unrelated, but \FOSS/
[22:45] <wm4> oh yeah that's kind of what happened
[22:45] <Daemon404> i know.
[22:46] <wm4> so I forked an already weak project forked from another weak project, I guess that's FOSS too
[22:47] Action: nevcairiel created something new
[22:47] <Daemon404> thats different
[22:47] <Daemon404> ffdshow was not saveable
[22:47] <Daemon404> by any means.
[22:48] <nevcairiel> exactly
[22:48] <nevcairiel> the code still gives me headaches when i look at it
[22:48] <Daemon404> /* ffdshow custom code */
[22:48] <nevcairiel> thats just because they are too stupid to use a vcs to manage their patches
[22:49] <wm4> that code must ridden with years of hacks that deal with dshow interaction with other software
[22:49] <wm4> I can imagine that this part is the least fun
[22:49] <nevcairiel> that reminds me that i need to clean up my patches again and submit the clean ones
[22:50] <wm4> nevcairiel: do you intend to merge that haali thing with ffmpeg mainline?
[22:50] <nevcairiel> no
[22:50] <wm4> too windows specific?
[22:51] <nevcairiel> not really
[22:52] <Daemon404> there's no reason really
[22:52] <nevcairiel> i just don't think it belongs in upstream, its an ugly hack to work around the shortcomings of the native mkv demuxer
[22:53] <Daemon404> ffms2 has the exact same thing
[22:53] <wm4> couldn't it replace the native demuxer?
[22:53] <Daemon404> i wouldnt be surprised if nevcairiel ripped it from there
[22:53] <nevcairiel> nah
[22:53] <nevcairiel> i just used haalis demuxer and made a thin avformat wrapper at first
[22:53] <nevcairiel> then it grew
[22:54] <nevcairiel> now its full of weird special logic for ordered chapters/segment linking
[22:54] <Daemon404> ffms2 is 'cleaner' but uglir too
[22:54] <Daemon404> cause it uses haali completely separately
[22:54] <Daemon404> and then decodes with lbavcodec
[22:54] <Daemon404> excpt lavf doesnt export its matroska mappings
[22:54] <Daemon404> thus, lavc is unusable with it without copying it
[22:55] <nevcairiel> yeah i didnt want to implement a separate demuxer backend into my own code, so i put it into lavf
[22:56] <Plorkyeran> probably a better solution since lavf and lavc are pretty clearly not designed to be used separately
[22:56] <wm4> oh what heretic words
[22:56] <nevcairiel> well, i always use them separately, and it usually works fine
[22:56] <superware> michaelni: do you want me to redirect the stream?
[22:58] <durandal11707> wm4: concealment for subtitles is none but there should be one..
[22:58] <michaelni> superware, no, i succeeded reproducing a similar possibly identical issue already
[22:58] <durandal11707> wm4: there should be option to not do concaealment and instead abort immediatelly
[22:59] <superware> michaelni: wow, great!
[22:59] <wm4> durandal11707: well, Nicolas seems to have his own plans... from what I've read, he'll probably implement sub codepage autodetection and some error concealment stuff
[23:00] <durandal11707> in near or distant future?
[23:00] <wm4> who knows
[23:02] <durandal11707> spam him, or do it yourself, it doesn't appear to be lot of work
[23:09] <durandal11707> why is not possible to flag packets as keyframes from parser?
[23:09] <nevcairiel> that is possible
[23:10] <nevcairiel> you need to set "key_frame" in the parser context, and the code in utils.c will then copy it into the packet
[23:10] <nevcairiel> rather ugly because parsers dont take AVPackets
[23:10] <nevcairiel> but hey
[23:11] <nevcairiel> see parse_packet in lavf/utils.c
[23:12] <durandal11707> is that actually used by any parser?
[23:13] <nevcairiel> h264_parser uses it
[23:14] <nevcairiel> seems to be the only one, though
[23:19] <superware> michaelni: have you found the bug? :)
[23:20] <michaelni> superware, iam working on several things, not just that bug ...
[23:25] <superware> sure, thanks
[23:25] <superware> just curious you know
[23:32] <cone-868> ffmpeg.git 03Paul B Mahol 07master:36748d4b6ca9: tak_parser: properly mark packets as key frames
[23:34] <michaelni> btw, about subtitles, if someone designs a better system and is willing to maintain it and asks me to merge/pull i wont hesitate to merge it after checking that it is better
[23:40] <durandal11707> "If it only kills one out of every 100 crews, as an example, their made be no need to bother with additional expensive shielding."
[23:43] <wm4> durandal11707: why is key frame info important?
[23:45] <durandal11707> taking single packet, which does not have required info, you can not succesfuly decode it in one go (instead you need to play rulette)
[00:00] --- Sat Jun 29 2013