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

[burek]

[00:04] <michaelni> nevcairiel, as long as AVFrame is in libavcodec theres no need to use these from libavcodec
[00:05] <michaelni> ffprobe / ffplay /ffmpeg need to use them no matter where AVFrame is
[00:08] <nevcairiel> i think trying to support mixing versions of the tools and libs is a lost cause, but thats just me
[01:40] <ubitux> cbsrobot_: WIP here: https://github.com/ubitux/FFmpeg/compare/master...ebur128-peaks
[01:40] <ubitux> seems to work, only supported as logging output right now
[01:41] <ubitux> i might add it to the visual, but i still don't know where, i might need to extend the video
[01:41] <ubitux> so... later :)
[01:42] <ubitux> (ffmpeg -nostats -i in.mp3 -af ebur128=peak=true -f null -)
[01:42] <ubitux> (last columns)
[02:06] <cone-406> ffmpeg.git 03Giorgio Vazzana 07master:0d66268e1519: lavd/v4l2: copy frames into normally allocated packets whenever there is just one buffer left available
[02:06] <cone-406> ffmpeg.git 03Michael Niedermayer 07master:3827734591d8: v4l2: fix regression that caused ffmpeg to occasionally get stuck
[02:10] <cone-406> ffmpeg.git 03Carl Eugen Hoyos 07release/0.10:85e082d08180: Require at least three frames to autodetect loas. (cherry picked from commit a60530e3ee1d9532c026a52b03661f88e163d647)
[02:10] <cone-406> ffmpeg.git 03Carl Eugen Hoyos 07release/0.11:4b03f2c522e4: Require at least three frames to autodetect loas. (cherry picked from commit a60530e3ee1d9532c026a52b03661f88e163d647)
[02:10] <cone-406> ffmpeg.git 03Carl Eugen Hoyos 07release/0.9:dcdeeea820e4: Require at least three frames to autodetect loas. (cherry picked from commit a60530e3ee1d9532c026a52b03661f88e163d647)
[02:10] <cone-406> ffmpeg.git 03Carl Eugen Hoyos 07release/1.0:857a0379457e: Require at least three frames to autodetect loas. (cherry picked from commit a60530e3ee1d9532c026a52b03661f88e163d647)
[02:10] <cone-406> ffmpeg.git 03Carl Eugen Hoyos 07release/1.1:78dbb1a7e182: Require at least three frames to autodetect loas. (cherry picked from commit a60530e3ee1d9532c026a52b03661f88e163d647)
[02:41] <ubitux> ffs wtf is wrong with mac os
[02:45] <ubitux> so this worked "check_lib2 iconv.h iconv -liconv" (http://ffmpeg.org/pipermail/ffmpeg-user/2013-March/013818.html)
[02:45] <ubitux> but it didn't at ffmpeg built time
[02:45] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-user/2013-March/013830.html
[02:45] Action: ubitux doesn't get it
[02:56] <michaelni> ubitux, maybe you should mail the macosx fate client maintainer, that is maybe you can resolve this together quicker
[02:57] <michaelni> or did you already ?
[02:57] <ubitux> i did
[02:57] <ubitux> i mailed him a while ago, he said he was going to have a look
[03:02] <michaelni> ubitux, also if all else fails iconv could be disabled by default, besides
[03:02] <michaelni> how common is a full iconv setup on embeded targets ?
[03:04] <ubitux> i've made it enabled by default because it's an "essential" avcodec feature if you're dealing with subtitles (and maybe some more later), and it's not a "module" dep
[03:04] <ubitux> that might be discussed, but whatever we decide on it, the mac os build should be fixed :p
[03:05] <ubitux> no idea how common it is
[09:44] <wm4> libavformat does not export icy information does it? stuff like "icy-genre:METAL, ROCK, ALTERNATIVE"
[11:15] <wm4> can't believe these things have been known for years, yet not fixed
[11:38] <cone-215> ffmpeg.git 03Martin Storsjö 07master:c91c63b5380b: flvdec: Don't read the VP6 header byte when setting codec type based on metadata
[11:38] <cone-215> ffmpeg.git 03Michael Niedermayer 07master:973dc110ba0a: Merge commit 'c91c63b5380bf79655c09320774a022f84d76fd5'
[11:48] <cone-215> ffmpeg.git 03Martin Storsjö 07master:c5a738ca4e97: flvdec: Check the return value of a malloc
[11:48] <cone-215> ffmpeg.git 03Anton Khirnov 07master:e671d3ad6cd7: h264: do not copy ref count/ref2frm when updating per-frame context
[11:48] <cone-215> ffmpeg.git 03Michael Niedermayer 07master:ec203cd69b57: Merge commit 'e671d3ad6cd7fe1d02e9b35b889a25d8c059fce9'
[11:57] <cone-215> ffmpeg.git 03Anton Khirnov 07master:668e16a0dd1f: h264: on reference overflow, reset the reference count to 0, not 1.
[11:57] <cone-215> ffmpeg.git 03Michael Niedermayer 07master:2d2e6db7cfe5: Merge commit '668e16a0dd1ff56d4beeff5c658d8a2a08dbfac8'
[12:21] <cone-215> ffmpeg.git 03Anton Khirnov 07master:437211ae73ef: h264: set ref_count to 0 for intra slices.
[12:21] <cone-215> ffmpeg.git 03Michael Niedermayer 07master:547042a8cd0f: Merge remote-tracking branch 'qatar/master'
[12:53] <wm4> does libavformat actually read id3v2 tags that are not at the beginning of the file?
[12:54] <wm4> ah, for mp3 only
[12:54] <wm4> or no, that's not right
[12:54] <wm4> so maybe it doesn't
[12:56] <nevcairiel> its sometimes hard to find them if it doesnt know where to look
[12:56] <wm4> it would have to be part of the normal demuxing process
[12:57] <nevcairiel> but then you would only be able to access them after demuxing x frames when it found them
[12:57] <wm4> I think this kind of stuff is for streaming
[12:57] <wm4> song change -> send new id3v2
[12:58] <nevcairiel> i guess
[12:58] <wm4> I don't know if it's actually used, but I think I saw this reasoning in the spec
[12:58] <wm4> I just wanted to find out how libavformat updates metadata
[12:58] <wm4> it's needed for icy metadata too
[14:05] <jojva> Hey, I fell on something strange in h264_refs.c:split_field_copy() :  "int match = !!(src->f.reference & parity);" Does that mean anything ? not not ?
[14:07] <wm4> do you mean the !! ?
[14:07] <jojva> yes
[14:07] <wm4> it's just the ! operator, applied twice
[14:07] <cbsrobot_> you can convert any value to a 0 or 1 with it
[14:07] <wm4> think of it as "to bool" operator
[14:07] <jojva> ooh, thx :)
[14:32] <jojva> Then I can't see the point in the following : "int match = !!(src->f.reference & parity); if (match) {...}" Why not "if(src->f.reference & parity) {...}" ?
[14:32] <nevcairiel> its used again later, i presume
[14:33] <jojva> no
[14:34] <jojva> oh
[14:34] <jojva> yes
[14:34] <jojva> return match; I'll stop bothering you
[14:49] <cone-215> ffmpeg.git 03Michael Niedermayer 07master:5167bb2e8eaa: er: Fix slice threading check
[16:20] <cone-215> ffmpeg.git 03Michael Niedermayer 07master:4ae74c63120c: ffmpeg: print maxrss "-benchmark" data even on errors
[18:32] <cone-215> ffmpeg.git 03James Almer 07master:1d5b35cc07c7: lavc/flacdec: Add frame CRC calculation
[18:39] <cone-215> ffmpeg.git 03Carl Eugen Hoyos 07master:6091a8d92d26: Avoid huge memory allocations from asf demuxer.
[18:45] <durandal_1707> anyone have FICV codec samples ? 
[19:07] <Compn> durandal_1707 : dont think so, what is it ?
[19:08] <Compn> VIDC.FICV"=ficvdec_x64.dll  ficvdec_x86.dll vidc.ficv
[19:08] <Compn> http://mirillis.com /en/products/action_features.html
[19:08] <Compn> is the site for it
[19:08] <Compn> http://mirillis.com/en/products/action_features.html dumb space
[19:13] <cone-215> ffmpeg.git 03Michael Niedermayer 07master:03bc7a004eb0: mjpegdec: fix endiansoup
[19:15] <durandal_1707> Compn: it is capure codecs as fraps, dxtory
[19:20] <durandal_1707> that mjpeg bug is really: "on what you was when coding it?"
[19:45] <BBB> Daemon404: what did I do?
[19:48] <ubitux> BBB: sorry my fault for hilighting you for nothing :)
[19:49] <BBB> o
[19:49] <BBB> I do actually understand vp6 up to some level
[19:49] <BBB> not for any particular reason, but I've looked into it quite a bit for cleanup reasons, so I may be able to assist in answering questions
[19:50] <BBB> I also understand vp3 a little, but it has evil that I try to pretend does not exist
[19:50] <ubitux> the question was about the decoder changing codec width/height, and thus confusing ffprobe
[19:51] <ubitux> i haven't really look at the patch Derek sent though...
[19:53] <BBB> maybe cropping? see line 85-90
[19:53] <BBB> in vp6.c
[19:56] <BBB> right, vp6 applies cropping and then the wrong values are reset... not sure if his patch is right from a cleanliness point of view (not that I care), but technically speaking I think he's correct
[20:00] <BBB> did anyone ever finish the er and mpegvideo extraction from h264?
[20:01] <nevcairiel> elenril removed the mpegvideocontext from h264 recently
[20:01] <BBB> yes, but h264 still uses mpegvideo functions
[20:02] <BBB> I submitted patches to fix that
[20:02] <BBB> ultimate goal is to be able to compile h264 without dsputil, mpegvideo or er
[20:02] <BBB> kind of like vp8
[20:03] <BBB> I guess that means no... hmk will have to revisit these patches
[20:45] <cone-215> ffmpeg.git 03Michael Niedermayer 07master:6a8f6c773da2: libxvid: remove temporary files at the end
[20:45] <cone-215> ffmpeg.git 03Michael Niedermayer 07master:8fe59240a15d: libxvid: use av_freep() for saftey
[20:45] <cone-215> ffmpeg.git 03Michael Niedermayer 07master:667bf156526f: libxvid: check & clear encoder_handle
[20:45] <cone-215> ffmpeg.git 03Michael Niedermayer 07master:4f0d4acc7017: libxvid: cleanup on error pathes
[20:46] <durandal_1707> hmm, i cant get inlink w/h from config_output(), i recive 0
[20:49] <ubitux> use config_input()?
[20:51] <durandal_1707> but it works for overlay
[20:51] <durandal_1707> and I set output dim depending on input dim
[20:55] <durandal_1707> actually I get correct results but code is funny
[21:09] <peper03> michaelni: Hi, this is probably a quicker method than email.  Do I actually need to add any dependencies for the dvd_nav parser?  There's no decoder or anything else required.
[21:11] <wm4> can I ask what this dvd_nav thing is about?
[21:11] <wm4> doesn't normally libdvdnav do all this?
[21:13] <peper03> wm4: It parses the contents into a structure, yes.  The problem is that that data is also required on the other side.  I.e. I read the 'normal' packets (video/audio/subpicture) via av_read_frame but there are certain times when I also need the information stored in the nav packets as well.  At the moment they are filtered out.
[21:15] <wm4> also, wouldn't some kind of DVD demuxer be a better solution overall? this could handle seeking and subtitle selection better, I think
[21:15] <peper03> In many cases, you can get away without having to pass them through but there are cases where you need them (or at least need to know that one has been read).
[21:16] <Daemon404> BBB, i know it's not the cleanest patch
[21:16] <Daemon404> i couldnt think of anything cleaner
[21:16] <Daemon404> short of rewriting ffprobe
[21:16] <Daemon404> its al entangled with itself
[21:16] <Daemon404> all*
[21:17] <Daemon404> anyone know where saste has been lately?
[21:18] <ubitux> he was traveling around last time i talked to him; he should be back online soon©
[21:18] <peper03> wm4: I wouldn't like to say with confidence as I don't know the ffmpeg architecture well enough but I would guess that a DVD demuxer would quickly become a DVD player with an awful lot of additional logic.
[21:19] <wm4> peper03: I wouldn't mind having a libdvdplayer to handle all the details, though
[21:19] <michaelni> peper03, you possibly dont need any dependancies indeed ...
[21:20] <peper03> wm4: Me too :) Unfortunately no-one's written one, AFAIK :(
[21:21] <Daemon404> ubitux, ok
[21:21] <wm4> peper03: on what are you working? VLC?
[21:21] <peper03> wm4: MythTV
[21:21] <peper03> wm4: Not an official developer, just an unofficial patch provider :)
[21:21] <wm4> ok... I guess there's no hope then
[21:22] <wm4> it appears to be one of the things where every project duplicates all the work
[21:22] <Daemon404> i tought mythtv was somethign related to capping tv shows
[21:23] <wm4> apparently mythtv is everything
[21:23] <peper03> Daemon404: The 'mythical' convergence box.
[21:26] <peper03> wm4: I wouldn't say there's no hope, just that I think it's a substantial undertaking, particularly to abstract DVDs to the level where MythTV, VLC, XBMC et al could just link in a library, point it at a DVD and get it to play.
[21:27] <wm4> maybe some effort could be put into making the libdvdnav API a little less insane?
[21:28] <wm4> but yeah, I realize I'm talking "wouldn't it be nice to have..." instead of "get this thing to work..."
[21:29] <Daemon404> [15:27] < wm4> maybe some effort could be put into making the libdvdnav API a little less insane? <-- VLC forked it for a reason
[21:29] <wm4> oh, I guess I should go and copy mythtv's code
[21:29] <wm4> because I'm still using mplayer's internal mpeg demuxer
[21:29] <wm4> trying to use libavformat's showed... issues
[21:30] <wm4> Daemon404: I thought that was because of unapplied patches and general inactivity
[21:30] <Daemon404> also insane management
[21:31] <peper03> It looks like there's quite a bit of work being done on the fork.  Unfortunately there's no mailing list and only a little discussion on IRC so it's a little hard to work out exactly what the plan is (I'm assuming there is one :) )
[21:31] <peper03> No mailing list for the fork, I mean.
[21:31] <wm4> you could just ask j-b directly
[21:32] <peper03> wm4: Sure.  I only looked more closely this last week to see if anything had happened with the fork as I've been busy getting *my* ideas straight for Myth :)
[21:33] <j-b> Quite a few commits
[21:34] <j-b> but still no fix for the recent crashes
[21:34] <Daemon404> i often forget that j-b has vlc on hilight
[21:34] <peper03> j-b: I saw you mention a crash with Brave.  What was the problem exactly?
[21:34] <peper03> Daemon404: :)
[21:34] <j-b> peper03: a crash? only one? that is sooo nice of you
[21:34] <Daemon404> i am surprised you have not pokes kostya's G2M patch, j-b 
[21:34] <Daemon404> 0 replies so far
[21:35] <j-b> peper03: the number of crashes with those 2 piece of crap libraries is unbeliveable
[21:36] <peper03> j-b: I don't want to speak too soon, but I watched Brave on Myth with only one issue, that wasn't a crash but a bit of bad video buffering.
[21:36] <j-b> not to mention the broken chapters on Thor amd Mission Impossible
[21:36] <j-b> or the wrong order of playback
[21:37] <wm4> so much effort for an obsolete medium
[21:37] <Daemon404> im surprised those movies not to vlc at all
[21:37] <Daemon404> dont they have stuff like arcos or w/e
[21:37] <Daemon404> that generally you need some windows-based stuff to remove
[21:38] <j-b> well, the code of those libraries is horrible
[21:38] <j-b> And the lack of APis...
[21:39] <Daemon404> just consume their internals
[21:39] <Daemon404> like mplayer 
[21:39] Action: Daemon404 runs
[21:39] <wm4> "consume"?
[21:39] <j-b> Hey, let's expose all structs in headers
[21:39] <peper03> Daemon404: In my (limited) experience, playing ARccOS protected DVDs is ok if you don't try to second-guess anything.  I.e. start from the beginning and follow the instructions on the DVD.
[21:39] <wm4> let's have the user mess with those structs!
[21:39] <j-b> and let's not have any functions that are useful
[21:40] <Daemon404> ffmpeg in 2005?
[21:40] <Daemon404> ;)
[21:40] <peper03> j-b: I have to admit, the fieldnames are horrible!
[21:40] <wm4> whenever I look at stream_dvd.c (where mplayer uses libdvdread) I'm laughing
[21:40] <j-b> oh, and btw, those structs needs to be packed, differently according to each OS
[21:40] <j-b> and each version of gcc
[21:40] <wm4> because it's so hilariously nad
[21:40] <wm4> *bad
[21:40] <Daemon404> j-b, wait
[21:40] <j-b> no, I won't wait
[21:40] <Daemon404> does it parse entire structs?
[21:40] <j-b> I need to go
[21:40] <Daemon404> as in alignment matters
[21:40] <Daemon404> :V
[21:40] <j-b> yes, it does
[21:41] <Daemon404> sexy
[21:41] <j-b> but ARccOS are played, but you still see the 98 bogus titles
[21:41] <Daemon404> oic
[21:41] <j-b> and it can crash easily with dvdread directly, if you access the wrong one
[21:41] <j-b> For Brave, it is even worse
[21:41] <j-b> And of course, some APIs are crashing all the time
[21:41] <j-b> like describe_chatpers
[21:42] <j-b> so depending on the struct or API, it can work... or not
[21:42] <j-b> Brave works on VLC if you have the right title, on Linux
[21:42] <j-b> but crashes elsewhere
[21:42] <j-b> etc...
[21:43] <peper03> j-b: One of the problems Myth had was trying to jump to a specific title when starting playback.  When it was changed to just start at firstplay and work through, a lot of problems went away.
[21:43] <peper03> You're basically following the path a stand-alone player would take.
[21:45] <peper03> j-b: I *did* have an issue the other day with Cars 2, though.  It's authored badly and a debug build of libdvdnav causes an assertion because a field is invalid.  Stupid thing is, though, that field was never needed except to check that its value was valid.
[21:47] <peper03> Of course, the 'bad authoring' may just be another aspect of ARccOS.
[21:48] <peper03> I can imagine that VLC has more issues purely due to it being used by more people that Myth, so being 'tested' more.
[22:35] <peper03> Is it safe to use the 'index' field of 'ParseContext' to determine how many bytes have been copied to the buffer so far by ff_combine_frame?
[23:05] <michaelni> peper03, do you even need combine_frame ?
[23:06] <michaelni> its normally used when you can get arbitrary sized chunks
[23:07] <peper03> michaelni: If there's a better solution, I'm all ears.  I just tried to use what I found in other parsers.  The two packets need to be combined as there is no time information in the DSI structure.
[23:08] <peper03> I just tried to find the simplest example of a parser and more or less copied that.
[23:08] <durandal_1707> parser split stream into packets/frame that are feed to decoder
[23:09] <michaelni> if you want to combine 2 a simple array + memcpy should achive the same as combine frame for this case
[23:10] <michaelni> combine frame as said can merge arbirary byte chunks and keep track of pts/dts but
[23:10] <michaelni> IIUC there are no pts/dts on the input side of a dvdnav parser
[23:10] <peper03> So add the array to DVDNavParseContext?
[23:11] <peper03> No, nothing apart from length.
[23:11] <michaelni> its a possibility but you can also continue using combine frame its not wrong
[23:12] <peper03> If using combine frame adds unnecessary overhead, I have no problem to change it.  I just didn't want to spend hours trying to work out how everything works in detail for such a simple class.
[23:21] <durandal_1707> there is no way to set display width / height in lavfi?
[23:35] <durandal_1707> why if i increase display height 2x, output is expected but 4x times smaller?
[00:00] --- Sun Mar  3 2013