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

Sun Feb 15 02:05:02 CET 2015

[00:42] <cone-366> ffmpeg.git 03zhaoxiu.zeng 07master:b11a187575f6: avcodec/golomb: simplify sign conversion
[01:10] <cone-366> ffmpeg.git 03zhaoxiu.zeng 07master:ac7fc444eed5: avcodec/apedec: simplify sign conversion
[06:23] <cone-237> ffmpeg.git 03James Almer 07release/2.4:a78b7c504a7b: x86/swr: add missing alignment check to pack_6ch functions
[06:23] <cone-237> ffmpeg.git 03James Almer 07release/2.4:3c6350379214: avutil/opencl: don't include config.h
[10:19] <ubitux> damn, lanczos is actually really great for downscaling
[10:27] <ubitux> at least compared to bilinear
[13:03] <cone-657> ffmpeg.git 03Michael Niedermayer 07master:ad1549aec3ea: avformat/mov: print a warning if parsing udta failed
[13:03] <cone-657> ffmpeg.git 03Michael Niedermayer 07master:e2fb12b629e8: avformat/matroskaenc: fix handling of VFW style raw rgb
[13:04] <cone-657> ffmpeg.git 03Michael Niedermayer 07master:9ccc4eedd181: avformat/matroskaenc: Do not use native mode for raw RGB
[13:28] <wm4> wait what, matroskaenc outputs vfw style shit? that'S fucking evil
[13:29] <nevcairiel> for some codecs thats the only valid mode for matroska
[13:30] <nevcairiel> ..and as long as it doesnt use bframes also not really a problem
[13:30] <nevcairiel> it just becomes a problem when someone uses h264 in avi with all its evilness and muxes it as vfw in mkv :p
[13:48] <cone-657> ffmpeg.git 03Paul B Mahol 07master:ba22295e76f0: lavc: deprecate VIMA decoder
[14:18] <Mavrik> hmm
[14:18] <Mavrik>  [mpegts @ 0x2a27980] Invalid timestamps stream=1, pts=9399, dts=8589926186, size=1625
[14:18] <Mavrik> This looks like a bug in 2.5.3 - PTS/DTS rollover shouldn't count as invalid timestamp right?
[14:20] <Mavrik> hrm, it looks like it's just a warning.
[14:23] <rcombs> the RasPi2 plays 10-bit H.264!?
[14:26] <wm4> ...not
[14:33] <rcombs> rip
[14:33] <thardin> the new ones does have a lot more horsepower
[14:33] <rcombs> rcombs just didn't know what 8-bit H.264 decoders do when given 10-bit input
[14:39] <BtbN> depending on the resolution, the CPU might be able to handle it
[14:39] <BtbN> but i'm quite sure the hardware decoder doesn't
[15:06] <cone-657> ffmpeg.git 03Zhaoxiu Zeng 07master:3b5ad8fbf77a: avcodec/parser: optimize ff_mpeg4video_split()
[16:29] <wm4> avcodec_flush_buffers() behavior changed recently
[16:29] <wm4> now the only way to make the decoder unref _all_ frames is closing the codec
[16:29] <wm4> inconvenient
[16:42] <durandal_1707> when exactly it changed?
[16:45] <nevcairiel> wm4: that would be a bug
[16:46] <nevcairiel> i dont think i noticed that particular problem myself
[16:48] <wm4> nevcairiel: well, I already fixed my code; it was actually pretty simple
[16:48] <wm4> but surely it could be considered a lavc bug
[16:48] <wm4> it makes no sense to keep any state after flushing
[16:48] <nevcairiel> closing the decoder can have other side effects
[16:48] <wm4> I just know this:
[16:48] <wm4> ==1802==    by 0x4D60822: ff_h264_unref_picture (h264_picture.c:55)
[16:48] <wm4> ==1802==    by 0x4BB43F2: h264_decode_end (h264.c:1920)
[16:48] <wm4> ==1802==    by 0x4BD3B83: avcodec_close (utils.c:2841)
[16:48] <nevcairiel> like, for example it forgets if the encoder was x264 for some workarounds
[16:49] <wm4> (this is called right after a flush call)
[16:49] <nevcairiel> I require a flush to free all surfaces when handling a resolution change in hwaccel
[16:49] <nevcairiel> otherwise bad things start to happen
[16:51] <wm4> good point
[16:51] <wm4> normally, resolution changes should flush the decoder
[16:51] <nevcairiel> maybe it works in that case because of that
[16:54] <wm4> nevcairiel: do you have a small sample so I can test?
[16:55] <nevcairiel> fate has one
[16:55] <nevcairiel> h264/reinit-large_420_8-to-small_420_8.h264
[16:56] <wm4> ok, let's see
[16:57] <wm4> nevcairiel: works fine with my code
[17:01] <nevcairiel> my ffmpeg is a month old or so, but i see no problems there at least
[17:01] <wm4> mine is from 4 days ago
[17:02] <nevcairiel> i put a warning in my code a long time ago that checks if all hw surfaces have been free'ed after a flush on seek, i'll at least notice when it breaks
[17:15] <cone-657> ffmpeg.git 03zhaoxiu.zeng 07master:a196e0c66dd4: avcodec/vc1_pred: few branchless optimizations
[17:21] <wm4> ubitux: have you seen the ffplay subtitle patch yet?
[17:24] <durandal_1707> wm4: why so many '?'
[17:26] <wm4> each one asks "why"
[17:27] <wm4> maybe my reaction was a bit exaggerated, but it's definitely an absurd patch
[17:27] <Daemon404> the word youre looking for is inbred
[17:47] <kierank> wtf
[17:52] <ubitux> wm4: yes, i will object to it obviously
[17:52] <ubitux> i was pretty sure a hate army would rise anyway before i do
[17:55] <Daemon404> "based on a complaint from wm4"
[17:55] <Daemon404> very nice.
[17:57] <ubitux> don't we have a violation flag or something?
[18:28] <Daemon404> ubitux, for trac?
[18:28] <Daemon404> i thought os
[18:28] <Daemon404> so
[18:28] <ubitux> no sorry, i was thinking about the matroska thing
[18:29] <ubitux> trac has a category on its own
[18:29] <Daemon404> o
[18:58] <cone-657> ffmpeg.git 03Christophe Gisquet 07master:b533949813cc: x86: hevc: remove a parameter to WP internals
[19:25] <funman> fosdem video team needs some help to create composited videos
[19:25] <funman> their FFmpeg script is not working as they'd want it to
[19:25] <funman> they want to generate something like http://video-post.fosdem.org/janson_what_is_wrong_with_operating_systems.mp4
[19:27] <funman> Thulinma: hello Jaron, I will let you explain in details what's not working :)
[19:28] <Thulinma> funman: Sure thing. Did you already explain the situation?
[19:28] <funman> 19:25 < funman> fosdem video team needs some help to create composited videos
[19:28] <funman> 19:25 < funman> their FFmpeg script is not working as they'd want it to
[19:29] <funman> 19:25 < funman> they want to generate something like  http://video-post.fosdem.org/janson_what_is_wrong_with_operating_systems.mp4
[19:29] <kierank> hi jaron
[19:29] <Thulinma> kierank: Hey, kieran, how are you?
[19:30] <ubitux> funman: sounds like basic overlay setup
[19:30] <kierank> Thulinma: good thanks, you?
[19:30] <Thulinma> This is the script we're using to generate the overlays: http://pastebin.com/PTKvfkAN
[19:30] <Thulinma> kierank: Pretty good. I was sick last week, but all okay again now :)
[19:30] <funman> ubitux: looks simple enough, i'd be interested to see how it can be done. AFAIU VLC can't do anything like that
[19:31] <ubitux> Thulinma: what doesn't work?
[19:31] <funman> nice filter setup
[19:31] <Thulinma> The video is generated just fine, but there's an issue where the framesync buffer overflows and it drops frames from one or both of the overlayed videos.
[19:31] <ubitux> also, i'd suggest to use -filter_complex_script at this point
[19:32] <Thulinma> The filter setup was created by somebody from the core fosdem team - but I tweaked it a little. Filters isn't my thing, heh :)
[19:32] <ubitux> can you pastebin the complete ffmpeg output?
[19:33] <funman> it's -filter_complex not -filter_complex_script, is there a difference?
[19:33] <Thulinma> Sure. One moment. It's alright if I interrupt it a few minutes in, right? Running an entire talk through this takes like an hour.
[19:33] <ubitux> why -re?
[19:33] <Thulinma> Oh, was an attempt to fix the overflow issue. it didn't make a difference.
[19:33] <ubitux> yeah sure, just press 'q'
[19:33] <funman> ah filter_complex_script reads from a file
[19:36] <Thulinma> http://pastebin.com/eancZGWu <-- Here's the complete output.
[19:36] <ubitux> why -r 50 btw?
[19:37] <Thulinma> Also an attempt to fix the problem.
[19:37] <Thulinma> It also didn't make any difference.
[19:38] <Thulinma> (several people spend a few hours trying to get this to work right - there's some leftover attempts in the script, sorry about that)
[19:38] <ubitux> mmh, it might be caching too much at the same time
[19:38] <wm4> lol
[19:38] <ubitux> reminds me of something
[19:38] <wm4> also this belongs to #ffmpeg (I just want to be an ass)
[19:39] <ubitux> Thulinma: make sure you try latest btw, 2.3 is starting to get old
[19:39] <Thulinma> I could do that - I'm not doing this on my own system. I'm bound to the system that has all the video material stored. It's 1 TB, so it's not easily moved.
[19:41] <ubitux> Thulinma: can you try to simplify the graph until the issue is not reproducible?
[19:41] <ubitux> like, is it reproducible if you drop all the audio layer, etc
[19:41] <ubitux> all the text stuff, ..
[19:41] <Thulinma> Sure let me try that.... just a few minutes....
[19:45] <ubitux> also yeah, please drop all the -framerate, -r and -re
[19:45] <ubitux> they look quite wrong
[19:47] <ubitux> anyway, back to interesting stuff, i just made my colorquant go from 8.431s ’ 3.394s by adding a stupid cache
[19:47] <ubitux> so i'm going to push that stuff in a few hours
[19:48] <Thulinma> Ok, dropping the audio, text and post/pre rolls - problem disappears.
[19:48] <Thulinma> I'll see what makes it come back....
[19:48] <ubitux> just try to create the simplest reproducible case
[19:49] <Thulinma> Working on it :)
[19:49] <ubitux> Thulinma: you possibly want to try to simulate your sources with -f lavfi -i testsrc or something like that btw
[19:49] <ubitux> so you can open a ticket without having to provide samples
[19:50] <Thulinma> Good idea. First let me see what causes it in the first place...
[19:50] <ubitux> :)
[19:50] <ubitux> but this reminds me of a known issue though
[19:51] <ubitux> some frames are probably stuck into the graph or something
[19:51] <ubitux> i mean, it's a deja vu, so a real test case is welcome
[19:52] <wm4> ubitux: so does your patch convert video to pal8 via a lavfi filter?
[19:52] <ubitux> in 2 pass yes
[19:53] <ubitux> first pass for the palette, then in a second pass you send that palette to another filter which is going to use it to output pal8
[19:53] <wm4> how is the data from pass 1 retrieved and handed to pass 2?
[19:54] <ubitux> first pass output 1 16x16 image, which is the palette
[19:55] <ubitux> then you have a filter taking 2 inputs, the palette and the input stream
[19:55] <wm4> eh
[19:56] <wm4> I understand the technical reasons, but that's pretty weird from a user POV
[19:56] <ubitux> ffmpeg -i input.mkv -vf palettegen palette.png
[19:56] <ubitux> ffmpeg -i input.mkv -i palette.png -lavfi paletteuse output.gif
[19:56] <ubitux> looks like this in the simplest case
[19:56] <ubitux> it gets a bit clumsy when you insert scales, trim and fps, but well.
[19:56] <ubitux> it's cool to be able to see the palette, and not have any memory issue
[19:59] <ubitux> Thulinma: btw, just a suggestion, since your background with text and logo etc looks static, you probably want to generate it in a first pass and re-use it for the overlay
[19:59] <ubitux> it will be faster
[19:59] <ubitux> (there is no point in calling 3x drawtext per frame)
[19:59] <Thulinma> Yes that sounds like a good idea. How? :)
[19:59] <Thulinma> I think I found the cause, by the way.
[20:00] <Thulinma> The framerate of the preroll is what does it, from the looks of it.
[20:00] <Thulinma> Still verifying all the combinaties to make sure..... but looks like that was it.
[20:00] <ubitux> i wonder why this -framerate was there in the first place :p
[20:00] <Thulinma> What would be the correct way to make that first image last 5 seconds? I'm sorry for the noob question there.
[20:01] <ubitux> mmh
[20:01] <Thulinma> To do that - make the single-image preroll 5 seconds long.
[20:01] <ubitux> what are you trying to do exactly?
[20:01] <Thulinma> (that was part of the script that I hadn't touched, heh)
[20:01] <Thulinma> It's a single image with the FOSDEM logo, that needs to be shown for 5 seconds before the rest of the video starts.
[20:02] <Thulinma> there's a postroll with all the sponsors, too. Same thing.
[20:02] <ubitux> ooh ok mmh
[20:02] <ubitux> [0:0] trim=end=5 [preroll] maybe?
[20:02] <Thulinma> I'll try that.
[20:03] <Thulinma> and then -loop 1, I assume?
[20:04] <ubitux> yeah i guess
[20:05] <Thulinma> That works :)
[20:05] <Thulinma> Let me put the sound back in to verify that was indeed the problem...
[20:08] <Thulinma> Ah, bah. That makes the problem come back. It's much less often now, though.
[20:09] <ubitux> make sure you trim your infinite silence sources too
[20:09] <ubitux> so they send EOF
[20:09] <ubitux> aevalsrc=0:d=10 for instance
[20:10] <ubitux> or with a trim filter
[20:10] <ubitux> ah seems it's the case already, my bad
[20:11] <cone-657> ffmpeg.git 03Gilles Chanteperdrix 07master:8ca098f4445c: avcocdec/mpegaudio_parser: add MP3 ADU headers parser
[20:11] <cone-657> ffmpeg.git 03Gilles Chanteperdrix 07master:22470510d1f9: avformat/rtpdec_mpeg12: add robust MPEG audio depacketization (RFC 5219)
[20:19] <Thulinma> Ok - it's caused by the compand filter.
[20:19] <Thulinma> if I leave that out, it's perfect - if I add it back in, it breaks again.
[20:21] <Thulinma> Looks like that filter wasn't set up right anyway... I'll yell at the guy that wrote that config :)
[20:22] <Thulinma> Thanks for all the help! I think we got it covered from here on out.
[20:22] <Thulinma> if not, I'll be back ;)
[20:22] <cone-657> ffmpeg.git 03Gilles Chanteperdrix 07master:3eec775b211c: avformat/rtpdec_ac3: add AC3 RTP depacketization (RFC 4184)
[20:30] <funman> Thulinma: nice
[20:32] <Thulinma> funman: Yes! Just some tweaking left and we'll have the talks online! Whoohoo!
[20:37] <cone-657> ffmpeg.git 03Himangi Saraogi 07master:7769be590c7a: vp56: Return meaningful error codes
[20:37] <cone-657> ffmpeg.git 03Michael Niedermayer 07master:4177f501b433: Merge commit '7769be590c7aeb2aad26ca723d105cf5203e33d2'
[20:44] <funman> Thulinma: let me know so I can download what I want before the crowd arrives ^_^
[20:45] <Thulinma> We just have one minor issue to resolve before they can be put online... It looks like something in the VGA capture setup caused the timestamps in that stream to drift, and most talks don't line up correctly. :-(
[20:45] <Thulinma> (slides seem to play back 3/5 faster than real time... which is a pain)
[20:46] <cone-657> ffmpeg.git 03Paul B Mahol 07master:088dfd3ff15e: avcodec/dxtory: use init_get_bits8()
[20:56] <cone-657> ffmpeg.git 03Clément BSsch 07master:adb9b235b6eb: avformat/gif: simplify gif_image_write_header() prototype
[20:56] <cone-657> ffmpeg.git 03Clément BSsch 07master:5f9986f597e8: avformat/gif: use first packet palette as global for PAL8
[20:56] <cone-657> ffmpeg.git 03Clément BSsch 07master:3cab173e2327: avcodec/gif: support crop and transparency with PAL8
[20:56] <cone-657> ffmpeg.git 03Clément BSsch 07master:9b964690e399: avfilter: add palettegen filter
[20:56] <cone-657> ffmpeg.git 03Clément BSsch 07master:bab4fcebb112: avfilter: add paletteuse filter
[20:56] <cone-657> ffmpeg.git 03Clément BSsch 07master:4ab7eb0da232: avfilter: bump minor and Changelog document the new filters
[21:01] <ubitux> alright, now back to equally fun stuff to do
[21:14] <cone-657> ffmpeg.git 03Diego Biurrun 07master:daf8cf358a09: avformat: Don't anonymously typedef structs
[21:14] <cone-657> ffmpeg.git 03Michael Niedermayer 07master:a0fe1a25fa76: Merge commit 'daf8cf358a098a903d59adb6c0d0cc3262a8c93e'
[21:26] <cone-657> ffmpeg.git 03Diego Biurrun 07master:7f9f771eac0d: avcodec: Don't anonymously typedef structs
[21:26] <cone-657> ffmpeg.git 03Michael Niedermayer 07master:a94eba6f0c06: Merge commit '7f9f771eac0d37a632e0ed9bd89961d57fcfb7e0'
[21:35] <cone-657> ffmpeg.git 03Diego Biurrun 07master:bf704132a51f: Don't anonymously typedef structs
[21:35] <cone-657> ffmpeg.git 03Michael Niedermayer 07master:6998400c618f: Merge commit 'bf704132a51f5d838365158331d4e535e1df4c8e'
[21:59] <rcombs> wow, the raspi's libc yells at you and abort()s if you free(NULL)
[21:59] <rcombs> "double free or corruption (out)", it says
[22:00] <JEEB> lol
[22:06] <nevcairiel> what libc do they use?
[22:13] <rcombs> oh, actually, I take that back
[22:14] <rcombs> didn't realize that av_freep clears the input pointer before it frees it
[22:25] <cone-657> ffmpeg.git 03Diego Biurrun 07master:b339019de4e5: dca: Split code for handling the EXSS extension off into a separate file
[22:25] <cone-657> ffmpeg.git 03Michael Niedermayer 07master:d8901c2f018e: Merge commit 'b339019de4e5f4d3c661bbdba98ae248ab77e2f0'
[22:25] <cone-657> ffmpeg.git 03Michael Niedermayer 07master:ad0be7038257: avcodec/dcaenc: rename DCA_SUBBANDS
[22:27] <ubitux> jamrial: btw, i'll disconnect my laptop around march 20th
[22:27] <ubitux> for about a month
[22:27] <jamrial> ok
[22:28] <ubitux> (traveling, and need a light one, even though the clickpad is going to drive me mad pretty quickly)
[22:32] <cone-657> ffmpeg.git 03Diego Biurrun 07master:a96f51f29ac4: dca: Return more informative error codes
[22:32] <cone-657> ffmpeg.git 03Michael Niedermayer 07master:877c038a9db5: Merge commit 'a96f51f29ac4cd95650a8bcda6c3d5d87c6357fa'
[22:39] <cone-657> ffmpeg.git 03Diego Biurrun 07master:8a213179aff0: dca: Remove trace debugging code
[22:39] <cone-657> ffmpeg.git 03Michael Niedermayer 07master:6c44dd6c6ee6: Merge commit '8a213179aff0174d81b3e889134a3b4f7d21f5c3'
[22:46] <cone-657> ffmpeg.git 03Diego Biurrun 07master:2a9c6fae9279: dca: Move all tables into dcadata.h
[22:46] <cone-657> ffmpeg.git 03Michael Niedermayer 07master:d2223ec2bd36: Merge commit '2a9c6fae927964b5dd0b5d3d9292f5621bd21664'
[23:00] <cone-657> ffmpeg.git 03Diego Biurrun 07master:36cf8eb4489f: mov: Fix compilation with DEBUG enabled
[23:00] <cone-657> ffmpeg.git 03Diego Biurrun 07master:ecbcebde344c: vdpau: Adjust necessary #includes for vdpau_internal.h
[23:00] <cone-657> ffmpeg.git 03Michael Niedermayer 07master:dfa7cb646d20: Merge commit '36cf8eb4489f8709b5fb1cdb87e125ef53301c2f'
[23:00] <cone-657> ffmpeg.git 03Michael Niedermayer 07master:e33b084ee986: Merge commit 'ecbcebde344c9eaeb8877ba2c5d32eb3af621e7f'
[00:00] --- Sun Feb 15 2015