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

[burek]

[04:10] <cone-484> ffmpeg.git 03Michael Niedermayer 07master:8cde94ec0db0: avformat/flvenc: fix codec_id_text check
[04:50] <cone-484> ffmpeg.git 03Benoit Fouet 07master:c29d999f71f6: avformat/mxfenc: add jpeg2000 support.
[08:22] <cone-484> ffmpeg.git 03James Almer 07master:c9f2ec8a3464: jpeg2000: split off inverse MCT decoding as Jpeg2000DSP
[09:43] <cone-484> ffmpeg.git 03Carl Eugen Hoyos 07master:80ca627abb53: Check for oom in the dirac parser.
[09:43] <cone-484> ffmpeg.git 03Carl Eugen Hoyos 07master:6efe4137ce39: Stop demuxing wtv on eof.
[10:05] <cone-484> ffmpeg.git 03Carl Eugen Hoyos 07master:81cee700f781: Support decoding 32bit pcm audio in mov.
[10:14] <thardin> some interesting fuzzing tools mentioned here: http://lcamtuf.blogspot.se/2014/10/bash-bug-how-we-finally-cracked.html
[10:15] <thardin> -> https://code.google.com/p/american-fuzzy-lop/
[10:42] <pross> q: why does adding side_data() to packets affect the crc (avformat/crcenc?)
[10:53] <thardin> running american-fuzzy-lop on ffprobe with MXF input, let's see what it comes up with
[10:54] <thardin> a massive 33k of input
[11:21] <thardin> this thing needs to be paralellized badly
[11:22] <thardin> it even does fork() and all that jazz, so it shouldn't be too hard
[11:22] <Daemon404> but the site claims "it has a modest performance overhead"
[11:22] <Daemon404> ;)
[11:23] <thardin> well, to be fair it's doing ~60 runs/second
[11:23] <Daemon404> for ffprobe?
[11:23] <Daemon404> that's very low.
[11:23] <hawken> Still no reply from mr. Britz :P
[11:24] <thardin> well, try "time (for x in `seq 1 100`; do ffprobe somefile;done)
[11:24] <thardin> it takes maybe 1 second, even  with an SSD
[11:24] <Daemon404> thardin, nah
[11:24] <ubitux> even with -v quite?
[11:25] <Daemon404> gnu parallel is your pal
[11:25] <thardin> parallel <3
[11:25] <Daemon404> cat filelist | parallel ffprobe
[11:25] <ubitux> quiet*
[11:29] <thardin> how do I shut up ff* again?
[11:29] <ubitux> -v quiet
[11:29] <thardin> danke
[11:29] <thardin> ok, 1000 runs with xargs -P 0 -L 1 -> 2.852s
[11:30] <thardin> so afl could probably run 10x faster on my machine
[12:22] <Daemon404> that page should just be 'gl;hf'
[12:22] Action: Daemon404 runs
[12:23] <kierank> lol
[12:23] <mateo`> hello there ! i'm wondering ... in HLS, is it possible to face a container change between playlists ?
[12:27] <pross> hmmm. av_packet_split_side_data? what does this do
[12:28] <nevcairiel> evil things
[12:29] <pross> my side data is leaking into pkt->buf !
[12:31] <ubitux> yes...
[12:32] <pross> AVFMT_FLAG_KEEP_SIDE_DATA to rescue
[12:44] <pross> 3 lines of code later, and the dst decoder is x5 faster :)
[13:05] <nevcairiel> i've been using the reference decoder and having performance issues, so much fast is it in comparison to that one now?
[13:06] <nevcairiel> s/much/how/
[13:15] <Daemon404> dst?
[13:15] <pross> single threaded: 2.10 times faster then the "tweaked" reference decoder
[13:16] <pross> ISO 14496-3 DST
[13:16] <Daemon404> ohlol
[13:23] <cone-484> ffmpeg.git 03Derek Buitenhuis 07master:1dbc3e8ac814: avfilter/aresample: Check for memory alloc failure for out sample rates
[13:23] <cone-484> ffmpeg.git 03Derek Buitenhuis 07master:23c9ebffb5e2: avfilter: Properly check for failed format query
[14:19] <ubitux> https://twitter.com/notch/status/517583207714537472
[14:24] <av500> +1
[15:57] <Compn> ugh!
[15:57] <Compn> ffmpeg takes 300M mem to convert one 8mp jpg to jpg
[15:58] <Compn> also its fun when computer runs OOM
[16:00] <av500> I had a machine like that once
[16:05] <thardin> >Last unique crash : none seen yet
[16:05] <thardin> doing good for close to five hours
[16:06] <thardin> it sticking queued fuzzed copies of the input files on disk feels suboptimal though
[16:07] <Compn> stick it in ramdisk ?
[16:07] <Compn> or zzuf has reproducability in cli
[16:13] <thardin> I suspect the file system cache takes care of it
[16:51] <Compn> man
[16:51] Action: Compn upgrades ffmpeg
[16:52] <Compn> people fixing bugs around here too quickly :)
[17:27] <ubitux> [caf @ 0xf10720] skipping CAF chunk: 75756964 (uuid), size 131
[17:27] <ubitux> any idea about what we could do with that tag?
[17:27] <ubitux> exporting as metadata?
[17:57] <cone-198> ffmpeg.git 03Yusuke Nakamura 07master:6ea357ea83e3: Fix compilation of jpeg2000dsp when disabling the encoder.
[18:57] <cone-198> ffmpeg.git 03Michael Niedermayer 07master:0d92b0d5f445: avutil/avstring: Factor av_match_list() out
[19:53] <cone-198> ffmpeg.git 03Vignesh Venkatasubramanian 07master:a9b10e1510dd: lavf/webm_dash: some fields should go into Representation
[20:32] <cone-198> ffmpeg.git 03wm4 07master:cdd6f059a65f: avcodec, avutil: allow more control about how samples are skipped
[21:50] <akira4> ubitux, I wrote the get_ts function for stl similar to that of srtdec.c but the srt file generated only reads the first line correctly  
[21:51] <akira4> would you mind taking a look and see what's wrong?
[21:51] <cone-198> ffmpeg.git 03Manfred Georg 07master:a950edb472e8: avcodec/utils: av_lockmgr_register defines behavior on failure.
[21:51] <ubitux> feel free to paste a diff
[22:04] <akira4> okay
[22:09] <akira4> here is the link : http://pastebin.com/FZPt3wbU
[22:10] <ubitux> what diff that is?
[22:10] <ubitux> please use diff -u, or a git format-patch
[22:10] <wm4> looks like some traditional diff format
[22:10] <wm4> probably diff produces it for historical reasons when calling it without -u
[22:11] <nevcairiel> i could never read those old diff formats
[22:11] <ubitux> yeah but i don't know what it's diffing here
[22:11] <ubitux> i was looking for a diff of the addition of the demuxer
[22:11] <ubitux> not between srt and stl or something like that
[22:11] <wm4> akira4: in a git repo, just doing "git diff" does approximately the right thing
[22:12] <ubitux> won't handle the added file
[22:12] <ubitux> git add libavformat/stldec.c
[22:12] <ubitux> git commit -a -m "WIP"
[22:12] <ubitux> git format-patch -1
[22:12] <wm4> yeah that's better
[22:12] <wm4> technically "git diff" doesn't include staged changes
[22:12] <akira4> sorry. I'll do that
[22:17] <akira4> I think this is what you had in mind? http://pastebin.com/ehBtv5XT . I also added the stldec.c file and commited the changes
[22:17] <ubitux> git you commit?
[22:17] <wm4> looks a bit incomplete
[22:17] <ubitux> if you did the git format-patch -1 after that it should generate a full diff
[22:18] <ubitux> wm4: after git add it doesn't appear in the git diff unless you use --cached so...
[22:18] <wm4> git can be pretty confusing at first
[22:18] <wm4> I thought that the gitk tool is pretty good at giving you an overview what got changed/committed/etc
[22:18] <akira4> Sorry. I think I got confused(again).
[22:19] <akira4> I'll fix it
[22:37] <akira4> is this better? http://pastebin.com/GM4cVk03
[22:37] <ubitux> yes thanks
[22:38] <ubitux> akira4: the srt has not the text on the same line than the timestamp
[22:39] <ubitux> so you just need to move the buffer after the timestamps
[22:39] <ubitux> and read the data payload from here, until the end of the line
[22:39] <akira4> Oh. I see.
[22:45] <J_Darnley> `git add` what you want then `git diff --cached` is another option
[23:45] <akira4> ubitux, sorry for bothering again but could you explain how the get_pts function in srtdec works?
[23:46] <ubitux> it's trying to read 2 lines, until it matches the timestamp one
[23:46] <ubitux> when it matches it, it set the duration etc
[23:46] <ubitux> then move the focus at the end of the line
[23:47] <ubitux> so ptr points on the data payload after that
[23:48] <ubitux> it could probably be simplified, by doing ff_subttiles_next_line to skip the number, then do it again to get the line of the timestamps, then do it again to focus on the text payload
[23:48] <akira4> the ff_subtitle_next_line is for moving the pointer right?
[23:48] <ubitux> yes
[23:48] <akira4> hmm.
[23:49] <akira4> I dont understand what you meant by moving the buffer after the timestamp 
[00:00] --- Fri Oct  3 2014