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

[burek]

[00:45] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:7a5d3a41fe38: avformat/mov: Check avio_read() return code in mov_read_extradata() and shrink the extradata if needed / return an error
[00:45] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:b2361cfb9473: avcodec/svq3: cleanup context in case init fails
[03:26] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:2b31a9c613f9: avformat/iff: shrink packets to the initialized data
[03:26] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:6f9be9106382: avformat/iff: fix memleak of packet
[03:33] <cone-938> ffmpeg.git 03Marton Balint 07master:b50968169df4: libzvbi-teletextdec: cosmetics
[03:33] <cone-938> ffmpeg.git 03Marton Balint 07master:249a435989d0: libzvbi-teletextdec: use defined constants for bitmap char width and height
[03:33] <cone-938> ffmpeg.git 03Marton Balint 07master:c77e0c2130c3: libzvbi-teletextdec: add chopped top row size to y offset
[03:33] <cone-938> ffmpeg.git 03Marton Balint 07master:97f880e7a952: libzvbi-teletextdec: set bitmap teletext canvas dimensions
[03:33] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:ec13849ce2dc: Merge remote-tracking branch 'cus/stable'
[05:02] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:f6cd447bf105: avformat/utils: treat flv like mov with timestamp discarding
[05:02] <cone-938> ffmpeg.git 03Alex Sukhanov 07master:cc0e2ba1aa93: Enable parser in FLV demuxer for H264 codec
[09:14] <rcombs> https://github.com/11rcombs/mkm-spec <-- any thoughts on this?
[09:15] <rcombs> It's meant as a simple specification to improve searching for external files referenced by MKV ordered chapters
[09:54] <wm4> rcombs: ffmpeg doesn't even support ordered chapters in any form
[09:59] <rcombs> wm4: doesn't mean I can't ask for comments
[10:01] <rcombs> wm4: also, AFAIK there isn't consensus against adding support; there was a patch in the mailing lists that went through a fair few iterations, and was eventually dropped because of some implementation issues, not because the concept was disliked
[10:05] <nevcairiel> mostly because the concept doesnt fit into avformats design
[10:07] <rcombs> yeah, iirc the implementation was disliked because it put search code in libavformat, which was awkward
[10:48] <cone-91> ffmpeg.git 03wm4 07master:5f6c21117f23: ffprobe: show best_effort_timestamp in the frame section
[10:48] <wm4> hu
[10:49] <wm4> saste: thanks
[11:26] <nevcairiel> wow, the SWS_FAST_BILINEAR scaler is sure broken
[11:29] <nevcairiel> with fast bilinear, i get ugly chroma bleed, not even static, it moves from frame to frame; http://i.imgur.com/YPzAMJl.png .. see the blue "shadow"
[11:30] <JEEB> that's pretty awful :D
[11:30] <wm4> nevcairiel: yeah, I think this has been long known
[12:11] <michaelni> nevcairiel / wm4 which ticket is that sws issue ?
[12:14] <nevcairiel> no idea, but all i did was scale http://files.1f0.de/samples/bunny444.mkv to yuv422p
[12:28] <cone-91> ffmpeg.git 03Michael Niedermayer 07master:d408d3dbc3c5: fate: update after 5f6c21117f23a3c825777cdb0565a21c5a468d35
[13:09] <wm4> why is libavcodec locking so fucking broken
[13:34] <cone-91> ffmpeg.git 03Michael Niedermayer 07master:81230e2612a9: avcodec/msmpeg4dec: print error in case of invalid vlc in msmpeg4_decode_dc for version <=2
[13:34] <cone-91> ffmpeg.git 03Michael Niedermayer 07master:61edda9a4a34: avcodec/msmpeg4dec: initialize dir_ptr in error cases
[14:58] <cone-91> ffmpeg.git 03Michael Niedermayer 07master:dc54bd4e8d8c: swscale/utils: factor (d + 1 < 4) out
[14:58] <cone-91> ffmpeg.git 03Michael Niedermayer 07master:554e913fd7ac: swscale/utils: remove useless ()
[14:58] <cone-91> ffmpeg.git 03Michael Niedermayer 07master:037fc3b054b1: swscale/utils: check chroma width for fast bilinear scaler
[14:58] <michaelni> nevcairiel, wm4, sws fast bilinear bug fixed
[14:59] <nevcairiel> fast only works for upscaling, eh?
[15:02] <michaelni> the mmx2 code works only for upscaling
[15:06] <BBB> that code is insanely crazy
[15:06] <BBB> it's fast also
[15:55] <cone-91> ffmpeg.git 03Michael Niedermayer 07master:0e0f6bd4a579: avformat/id3v2: Check avio_read() return code in id3v2_parse()
[16:52] <nevcairiel> hm was it ever documented anywhere how the swscale chroma position translates to the avcodec enum?
[16:52] <nevcairiel> it seems rather  confusing :p
[17:03] <wm4> nevcairiel: vf_scale
[17:03] <wm4> there's your "documentation"
[17:04] <wm4> hm, actually
[17:05] <wm4> avcodec_enum_to_chroma_pos()
[17:05] <kierank> does anyone else care about chroma positioning
[17:05] <kierank> apart from interlaced people
[17:06] <kierank> ah mpeg-1 people apparently
[17:06] <kierank> ...
[17:07] <beastd> I see interlaced people ;)
[17:09] <beastd> Should have been a pun on sixth sense, not sure if it came out that way...
[17:12] <saste> beastd, ah you're here
[17:12] <beastd> Hi saste
[17:13] <saste> beastd: i see you can mark a checkbox in the tags cloud page to select wiki/tickets
[17:14] <saste> so i think it should be fine to keep it as is, and add the possibility to add tags to wiki pages
[17:15] <beastd> saste: yes. i will enable them.
[17:15] <beastd> i tried to describe the checkbox thing in my reply to you on that ticket. but looking at it yourself is better.
[17:18] <nevcairiel> kierank: looks like the default chroma pos in swscale is not mpeg2, so i'm trying to figure out if i can fix that
[17:22] <saste> beastd, if you see people interlaced, you must have a serious vision problem
[17:48] <saste> \o/
[19:44] <cone-91> ffmpeg.git 03Michael Niedermayer 07master:e838c9852e6f: avcodec/bink: use av_mallocz for data
[19:44] <cone-91> ffmpeg.git 03Michael Niedermayer 07master:45115315820a: avformat/oggparsetheora: zero extradata padding area
[20:12] <ubitux> michaelni: about 0e0f6bd4a5796f4f668092d7925a31b9b30fedd4, don't you need to check for < 4 instead?
[20:14] <cone-91> ffmpeg.git 03Stefano Sabatini 07master:d37d4b6e4022: lavf/mux: improve feedback in case of no streams in muxer
[20:14] <cone-91> ffmpeg.git 03Stefano Sabatini 07master:2364b4031dcb: doc/muxers/tee: use @ref to reference other sections
[20:14] <cone-91> ffmpeg.git 03Stefano Sabatini 07master:81eff6e7a20b: doc/muxers/tee: add example showing second level escaping
[20:14] <cone-91> ffmpeg.git 03Stefano Sabatini 07master:b2a4316287ea: examples/decoding_encoding: check av_samples_get_buffer_size() for a negative value
[20:21] <michaelni> ubitux, fixed
[20:21] <cone-91> ffmpeg.git 03Michael Niedermayer 07master:476aceaa22a0: vformat/id3v2: check avio_read for short reads in addition to errors
[20:21] <ubitux> thx
[20:44] <clever> ubitux: do you know how much and where ffmpeg will copy frames when getting the data into the player?
[20:44] <clever> seeing performance issues even with -vo null, and i'm wondering if they can be fixed any
[20:45] <ubitux> sounds like a player question
[20:45] <clever> so mplayer allocates the avframe, passes it in, and expects to get the same frame back out with as little copying as possible?
[20:47] <ubitux> i have no idea about mplayer internals, wm4 might be able to help you
[20:47] <clever> i also discovered, sdl is completely software driven
[20:47] <clever> the default libs have no hw accel
[20:47] <clever> so that explains why ffplay is just as bad as -vo x11
[20:48] <ubitux> if you want to bench, ./ffmpeg -i ... -f null -
[20:48] <clever> i was benchmarking mplayer with -vo null and got arround 10 fps
[20:49] <wm4> clever: mplayer will attempt to pass frames directly to the VO
[20:49] <clever> wm4: so what would cause 10 fps even with -vo null?
[20:49] <wm4> it also has a hideous direct rendering mechanism, which is usually not active when not using any filters, though
[20:49] <wm4> hm sdl2 should have a gl(es) backend
[20:50] <wm4> that uses shaders for yuv and all
[20:50] <wm4> clever: aren't the 10 fps caused by the readback?
[20:51] <clever> i was getting about 11 fps when i used -vo null, but my code was proving full yuv420 1080 frames
[20:51] <clever> 15 fps if i commented out the code to copy frames into ffmpeg
[20:52] <clever> part of the problem is that the omx api is async, you run a function, and ~0.03 seconds later it runs a callback (in a diff thread)
[20:52] <clever> then you can read the frame out
[20:52] <clever> but i might be able to double buffer it, read one frame out while feeding another in
[20:52] <Daemon404> thats not exactly hard to handle with some sort of thread pooling
[20:52] <Daemon404> just annoying
[20:53] <clever> i did write an example that will use a pthread condition to block until the last frame is done
[20:53] <clever> then start the next frame, and return the last one
[20:53] <clever> adding a 1 frame lag to the entire chain
[20:53] <Daemon404> i fear that probably doesnt fit so well into ffmpeg's model.
[20:54] <clever> yeah, i would expect it to mess up the sync some
[20:54] <clever> since end_frame returns the wrong frame
[20:54] <clever> but i have no idea how many extra frames of latency the omx core is adding
[20:55] <clever> ive got one more way i can try to double-buffer it, then id like to try lower resolutions, it may handle 720p with this method
[20:55] <clever> if that doesnt work, then the only option is to add gl surfaces
[20:55] <clever> oh, and something else
[20:56] <clever> Daemon404: if i define 2 AVHWAccel, one returns AV_PIX_FMT_YUV420P and one returns the custom glsurface trick
[20:56] <clever> will ffmpeg pick the right one, based on which vo i'm using?
[20:56] <wm4> hwaccels can return software surfaces?
[20:56] <Daemon404> i know nothing of the hwaccel stuff.
[20:56] <clever> wm4: i did sucessfully make a hwaccel that returns a custom pixel format type
[20:56] <clever> wm4: which only -vo rpi supported
[20:57] <wm4> clever: it's left to the application, the get_format callback decides which hwaccel is used
[20:57] <clever> i was just trying to preserve the full yuv420 support for things like transcoding or filters at low resolutions
[20:57] <clever> while adding support for gl surfaces, to make it work at 1080
[20:58] <wm4> for software surfaces it should probably use a separate pseudo-decoder
[20:58] <wm4> like with libstagefright, I think
[20:58] <wm4> or the crystalhd stuff or the vda decoder
[20:58] <wm4> (though vda also has a proper hwaccel thing)
[20:58] <clever> vda?
[20:59] <clever> ah, vda_h264.c
[20:59] <wm4> the OSX hw decoding API
[20:59] <clever> i'll review those files and see what works
[20:59] <wm4> btw. the vda code seems to suck, it always had mem leak problems etc.
[21:00] <clever> also, i should check out the dispmanx code
[21:00] <clever> hardware 2d compositor
[21:00] <clever> pixel format conversions, scaling
[21:01] <clever> the firmware exports a single dispmanx surface as fb0 (framebuffer)
[21:01] <clever> but omxplayer uses dispmanx directly, to draw another surface over fb0
[21:02] <clever> ./interface/vctypes/vc_image_types.h:   VC_IMAGE_YUV420SP,    /* Y as a plane, then UV byte interleaved in plane with with same pitch, half height */
[21:03] <clever> wm4: aha!, dispmanx supports yuv420, so i can create a -vo dispmanx to handle it
[21:03] <wm4> this 420SP thing sounds like NV12
[21:03] <clever> there are others
[21:03] <nevcairiel> indeed it does
[21:03] <clever> ./interface/vctypes/vc_image_types.h:   VC_IMAGE_YUV420,
[21:04] <clever> that one isnt explained, but is probly planar
[21:06] <clever> and after that, it might be fun to check out the weston graphics engine
[21:06] <clever> http://wayland.freedesktop.org/raspberrypi.html
[21:06] <clever> it has dispmanx support, and uses the hw to draw all windows
[21:06] <clever> so every graphical app has its own framebuffer, sized to match its window
[21:06] <wm4> I wonder why everyone cares so much about this really shitty piece of hardware
[21:07] <clever> because unlike the ps3, i have the ability to add support
[21:07] <clever> for anything i want
[21:07] <wm4> there are better ARM boards?
[21:07] <ubitux> wm4: because it went viral and it's now widely spread
[21:07] <clever> wm4: which didnt go viral, so i dont know about them :P
[21:09] <clever> from a glance at the api, i think dispmanx is the same as XV, with more then 1 channel
[21:10] <nevcairiel> wm4: i agree, i never understood the obsession with the rpi, its totally overrated and overhyped
[21:11] <clever> but are there any similarly capable systems that can handle video decode in hw?
[21:15] <wm4> I'm sure there are, though I don't know any (since I'm not into experimenting with bare boards...)
[21:16] <wm4> rpi on the other hand seems to have a bunch of really dumb problems I heard from others
[21:16] <wm4> like horrible and closed problems, incorrectly working (and unfixable) video output, etc.
[21:16] <beastd> wm4: i fear most of the cheap boards have them :(
[21:17] <beastd> Choose your poison! 
[21:18] <nevcairiel> i just got a arduino for some hacking, but not with anything video :p
[21:19] <clever> wm4: what kind of problems?
[21:22] <wm4> not sure, maybe something about always outputting limited range rgb
[21:23] <beastd> IMHO when you are into multimedia development it is best too invest in a more expensive system that can do things CPU based. OTOH small boards are fun too, but you must be able to enjoy pain to some extent ;)
[21:26] <wm4> I knew it, these things are for masochists
[21:27] <JEEB> uhh
[21:27] <JEEB> > multimedia
[21:27] <JEEB> > internals
[21:27] <JEEB> > not masochists
[21:27] <JEEB> not seeing
[21:27] <JEEB> :D
[21:27] <wm4> ok I'm dealing with vsfilter crap and I'm hacking mplayer code too, ok, I must be a masochist
[21:28] <JEEB> yes, so am I
[21:28] <JEEB> also since when are you poking VSFilter o_O
[21:28] <wm4> I'm not
[21:28] <JEEB> that's an extra layer of pain
[21:28] <JEEB> oh
[21:28] <wm4> but I still have to deal with its crap
[21:28] <JEEB> then you're not on this level yet
[21:28] <JEEB> because the code is something special
[21:28] <JEEB> esp. xy-vsfilter code
[21:28] <wm4> just look at libass ticket #111, it makes me sad
[21:29] <wm4> does xy add more special sauce?
[21:29] <JEEB> they rewrote parts in ways that made the MPC-HC maintainer afraid of reading it
[21:29] <wm4> wooh
[21:30] <wm4> someone should convince xy to remove all the crap from his tree
[21:30] <wm4> things carried over from vsfilter which nobody (?) cares about
[21:32] <JEEB> the xy-vsfilter tree was quite a joke to begin with
[21:32] <JEEB> instead of beginning from a cleaned up tree, it just had guliverkli there
[21:32] <JEEB> all of it
[21:32] <JEEB> mpc and all the other stuff
[21:32] <JEEB> completely unused
[21:34] <JEEB> although there now seems to be a pull request to fix that
[21:34] <JEEB> they did also fix their tree mostly regarding line endings
[21:34] <JEEB> they used to have CRLF and LF mixed
[21:35] <wm4> reminds me of mplayer code, which mixes tabs, spaces, and multiple indentation styles in some files
[21:35] <JEEB> I had to use a lulzy editor that does not try to normalize line endings so I would get sane diffs when I patched xy-vsfilter >:|
[21:36] <nevcairiel> legacy code, so much fun
[21:36] <JEEB> anyways, there's plenty of insanity in xy, or weird things at least
[21:36] <JEEB> I mean, even more than the gabest/mpc-hc code
[21:37] <nevcairiel> and people keep asking me to simply copy feature X or Y from ffdshow, and everytime i can only shake my head and cry a little inside, not touching that code base
[21:37] <JEEB> I still remember middle-to-late 2011, when Lord and me were the only ones really working on ffdshow-tryouts, and clsid would in the best cases merge our work within hours
[21:38] <JEEB> and yeah, ffdshow-tryouts' source code tree was "fun"
[21:38] <nevcairiel> wonder what would have happened if i didnt show up
[21:39] <wm4> nevcairiel: endless despair
[21:39] <nevcairiel> more people would've eventually given up on dshow i reckon, and moved to vlc
[21:39] <JEEB> yeah
[21:39] <JEEB> there were some plans on doing large'ish changes to ffdshow-tryouts at one point
[21:39] <JEEB>  but that died out when LAV Video became good enough
[21:39] <JEEB> november 2011 or so when me and Lord finally washed our hands from -tryouts
[21:40] <wm4> I bet they would have kept using ffdshow
[21:40] Action: beastd has given up on dshow 8 years ago
[21:42] <nevcairiel> many still use ffdshow, either because they dont know any better, or because they have a deranged requirement for postproc
[21:43] <JEEB> yup
[21:43] <wm4> such as?
[21:45] <JEEB> at simplest, cropping and resizing, but then there are people who use warpsharp and stuff in -tryouts
[21:45] <JEEB> or avisynth
[21:45] <Daemon404> or custom channel mixing
[21:45] <JEEB> yes, for audio that
[22:13] <saste> michaelni, should I push ffserver Metadata patch?
[22:14] <cone-75> ffmpeg.git 03Michael Niedermayer 07master:d600b18f224e: avformat/utils: limit rfps to values larger than fps
[22:14] <cone-75> ffmpeg.git 03Joakim Plate 07master:6eda91ad54fd: mpegts: stop analyzing when pmt for all programs have been found
[22:14] <cone-75> ffmpeg.git 03Michael Niedermayer 07master:460f8fca9c26: avformat/id3v2: factor free code to the end of read_chapter()
[22:14] <cone-75> ffmpeg.git 03Michael Niedermayer 07master:ffbcb1c6f051: avformat/id3v2: Check avio_read() return value in read_chapter()
[22:25] <michaelni> saste, the new patch looks like it still has the same issue (entry==NULL and segfault)
[23:14] <kierank> Compn: what's the ffmpeg incoming username and hostname
[23:21] <Compn> kierank : i still cant stop from saying kye-rank every time i read your nick :\
[23:43] <funman> smarter: well we can bump after the fact no?
[23:43] <smarter> sure, I don't know how this stuff is done usually :)
[23:44] <wm4> Compn: I'd like access to incoming as well, if possible
[23:45] <funman> smarter: it's done badly
[23:46] <funman> smarter: people who write stuff pulls on one side and people who use stuff written by others pull on the opposite
[23:46] <funman> so there's never a perfect solution
[23:51] <Compn> anyone else need incoming access ?
[23:52] <Compn> other devs should know login info too
[23:52] <Compn> but i guess it wasnt widely advertised...
[00:00] --- Mon Dec 16 2013