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

[burek]

[00:19] <bernie_> anyone have experience with fate?  To figure out if a test is OK does it just do a check-sum of the output text?
[00:21] <bernie_> because when I pull from git, and run one of the tests by hand, it shows an assertion failure, but somehow the test is accepted.
[00:29] <BBB-work> make fate-list
[00:29] <BBB-work> grep for your test of interest
[00:29] <BBB-work> make fate-h264 groups all 264 tests
[00:29] <BBB-work> etc.
[00:50] <bernie_> cool -- thanks BB-work
[00:52] <bernie_> could it be possible that a test that is marked as accepted has an assertion failure in it's output?  I have not looked that closely at it, but does fate compare a hash of what is "accepted" vs. what is run, and if the "accepted" test has an assertion failure, then that fate test is still OK?  (hope my question makes sense)
[01:01] <bernie_> never mind -- looks like I messed something up real good with just a few lines of code.  yay!
[01:04] <BBB-work> bernie_, sorry, was off for a sec
[01:05] <BBB-work> no, if a tests asserts, it will not be marked as passed
[01:05] <BBB-work> the test needs to complete 100% succesfully and return a known-good hash before it's marked as completed and succesful
[01:05] <BBB-work> but it looks like you figured that out already :)
[01:17] <bernie_> BBB-work -- thanks.  Yeah, investigating...
[01:39] <bernie_> oh shit found my bug
[01:39] <bernie_> I don't usually write code like this:
[01:39] <bernie_>     entries[cues->num_entries  ].pts = ts;
[01:39] <bernie_>     entries[cues->num_entries  ].tracknum = stream + 1;
[01:39] <bernie_>     entries[cues->num_entries++].cluster_pos = cluster_pos - cues->segment_offset;
[01:40] <bernie_> because then I just went and added...
[01:40] <bernie_>     entries[cues->num_entries++].relative_pos = relative_pos - cluster_pos;
[01:40] <bernie_> which is obviously stupid of me...
[01:40] <bernie_> but I didn't look for the ++ right there, because I would never do something like that ;)
[01:41] <bernie_> Not to start any wars or anything, but I personally like keeping statements with side-effects like that on a line by itself.
[01:46] <bernie_> okay no more assertion failures, but the test is still failing.  Should I be surprised that it's failing if I ended up adding a new EBML tag to the output of the video file?  I guess not.  But do I tell if it's failing because it's a different output file?
[01:47] <bernie_> meant to say:  How do I tell if it's failing because it's a different video output file?
[01:50] <wm4> bernie_: I looked at it myself
[01:51] <bernie_> wm4: cool
[01:51] <wm4> bernie_: I wonder how this seeking is supposed to work, because it points directly to the block, instead of the block group
[01:51] <wm4> but the block group is the containing element, and contains important information
[01:51] <bernie_> Hrmmm
[01:51] <wm4> so I guess it's somehow guaranteed that the Block is the first element of the BlockGroup?
[01:54] <bernie_> I see your point.
[01:54] <bernie_> Would also be nice to know the size of the block group...
[01:56] <wm4> either way, if I understand this right, the Matroska devs fucked up yet again
[01:56] <bernie_> So you'd need like a reference to the blockGroup, and the the offset into that blockGroup to seek to the block?
[01:57] <wm4> a BlockGroup contains only one Block
[01:57] <wm4> and some other elements to e.g. set the duration of the block
[01:57] <bernie_> oh, gotcha
[01:57] <wm4> so there'd be no downside to point to the BlockGroup instead (but mkvmerge doesn't do that)
[01:59] <bernie_> I see, so your point being, if the Block is the first element, you can just continue to read the other tags, and pick those up, but it's unclean, because you are depending on the order of the EBML tags, which is kind of an implementation question.  Not specified per spec.
[01:59] <wm4> you also need to know when the BlockGroup ends
[01:59] <wm4> which is hard
[02:00] <bernie_> yep, which would be the reason to actually point to the blockgroup tag, which would have that info
[02:00] <wm4> yes but mkvmerge doesn't do that
[02:00] <bernie_> Poop
[02:00] <wm4> indeed
[02:01] <bernie_> do you ever talk to those guys?
[02:01] <wm4> no
[02:04] <bernie_> I wonder who in the world actually uses this currently?  My guess is no one.  So they should just fix their spec, and then fix mkvmerge and be done with.  "what could possibly go wrong" ;)
[02:04] <wm4> but there are broken files out there
[02:04] <wm4> oh well, they still could introduce a separate, correct element
[02:05] <bernie_> yeah
[02:05] <bernie_> I'll see if they'll get back to me on that
[02:06] <bernie_> Hmm they have an IRC #matroska
[02:07] <wm4> joined there
[02:09] <bernie_> you beat me to it :)
[02:10] <bernie_> wm4: not too active in there... :/
[02:10] <cone-561> ffmpeg.git 03Ramiro Polla 07master:454c89dde3af: img2enc: add option to use strftime() for filename
[02:10] <wm4> well, if we get any reply, it'll probably take half a day or something
[02:11] <bernie_> groan
[02:12] <bernie_> okay, so maybe for now, I'll point it to blockGroup for myself, but obviously won't put up a patch to ffmpeg for it, but I do need to keep going on my implementation
[02:12] <bernie_> In the future, I'd hope they add a new EBML tag for this purpose
[02:12] <wm4> if I were you I'd test with a mkvmerge produced file first
[02:25] <bernie_> You know, I bet the only real other important information besides the block itself is the block duration, and the other elements do not get used typically -- of course, that's kind of a lame explanation, but given a cuepoint is an I-frame... maybe you only really need the block + the duration
[02:27] <bernie_> and the block duration could be indicated by CueDuration
[02:28] <wm4> that's even worse
[02:28] <bernie_> hahaaa
[02:28] <wm4> that'd you somehow need to get the duration value from the index
[02:29] <bernie_> via CueDuration
[02:29] <wm4> it's bad because it makes the code more complicated
[02:30] <bernie_> I agree
[03:26] <bernie_> wm4: cool, so all I have to do to force a new matroska cluster at the start of a key frame is to modify some logic in mkv_write_packet(), specifically right at the first logic block that has the comment about when it currently starts a new cluster.
[03:26] <bernie_> seems quite easy
[10:22] <bernie_>  
[10:53] <cone-261> ffmpeg.git 03Martin Storsjö 07master:d010e95f8608: avserver: Remove unused loadable module support
[10:53] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:8740762c43dc: Merge commit 'd010e95f86089abe9a3d4d4a66ac8102312d28a4'
[11:03] <cone-261> ffmpeg.git 03Diego Biurrun 07master:439902e0d68a: Employ consistent LIBAV_COMPAT_ multiple inclusion guards in compat/
[11:03] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:c88503e3f6bd: Merge commit '439902e0d68a0f0d800c21b5e6b598d5fa0c51da'
[11:36] <cone-261> ffmpeg.git 03Diego Biurrun 07master:910042072a88: compat: Add missing license boilerplates
[11:36] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:25ffaf527702: Merge remote-tracking branch 'qatar/master'
[12:18] <cone-261> ffmpeg.git 03wm4 07master:06b269dacbe1: examples: demuxing: do partial audio packet decoding
[12:18] <cone-261> ffmpeg.git 03wm4 07master:9f31c1608c74: examples: demuxing: simplify audio output
[12:18] <cone-261> ffmpeg.git 03wm4 07master:72f5a6d0672a: examples: demuxing: print ffplay command even if sample format is planar
[12:51] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:a4b55bbb6f8b: swscale/input: fix 16bit gbrp input
[15:00] <cone-261> ffmpeg.git 03Michael Niedermayer 07release/1.2:d83ab33715cb: swscale/input: fix 16bit gbrp input
[15:00] <cone-261> ffmpeg.git 03Michael Niedermayer 07release/2.0:8f9bc6f2ce49: swscale/input: fix 16bit gbrp input
[15:07] <JEEB> hmm
[15:07] <JEEB> I might have found the first semi-valid use for MVC
[15:08] <JEEB> hacking high bit depth video onto blu-ray
[15:08] <JEEB> I thought there was a guy here who was working on MVC decoding? :D
[15:08] <JEEB> might have to read the logs back a few months
[15:14] <saste> just got SOCIS mail
[15:15] <saste> we were not accepted
[15:16] <nevcairiel> JEEB: the only valid use is multi-view coding, using it as a hack is by definition completely invalid
[15:17] <nevcairiel> also, since the second view is always a predicted frame against the first view, such a hack would also be very inefficient :p
[15:17] <JEEB> I guess that's why they only went for 12bit and not for 16bit :
[15:17] <JEEB> :D
[15:17] <JEEB> also in such a way I completely agree, I wonder how much herp and derp panasonic got from Sony
[15:17] <JEEB> for this hack
[15:18] <nevcairiel> but i also heard of this hack before
[15:18] <JEEB> yes
[15:18] <JEEB> I brought it up on another channel earlier
[15:19] <JEEB> we got the first blu-ray using that just a couple of days ago
[15:19] <nevcairiel> if earlier is weeks ago, then  sure
[15:19] <JEEB> well, I remember linking it back in april when panasonic first announced it, too :D
[15:19] <JEEB> http://dl.dropboxusercontent.com/u/17138887/ADC/Porco%20Rosso/Info.png "master grade video coding"
[15:20] <nevcairiel> that they are still allowed to carry the Blu-ray Disc logo is mind boggling
[15:21] <JEEB> well, the higher 8 bits are on the main view so it's backwards compatible in a way :D
[15:21] <JEEB> until some player tries to play that as '3-D' :D
[15:21] <saste> i get this email from an indian guy who calls me "mam", guess my name sounds like a female name in his (her?) language
[15:21] <j-b> JEEB: WTF
[15:21] <j-b> JEEB: you are joking, right?
[15:21] <nevcairiel> even if backwards compatible, you usually cant bastardize a standard format like this
[15:21] <JEEB> j-b, I'm not, although it will be some hours before my copy is here
[15:21] <JEEB> so I can have a full look
[15:22] <JEEB> but the article's out and that's a real thing
[15:22] <JEEB> lol
[15:22] <JEEB> nevcairiel, true
[15:22] <JEEB> which is why
[15:22] <JEEB> > I wonder how much herp and derp panasonic got from Sony
[15:23] <nevcairiel> next up, half-4K discs with two 1080p frames coded as MVC and then stretchted vertically :p
[15:23] <JEEB> :DDD
[15:24] <j-b> nevcairiel: oh god...
[15:24] <j-b> or just 4k interlaced with two 1080p frames?
[15:24] <nevcairiel> not enough frame rate allowed for that to be viable
[15:31] Action: Daemon404 just luls
[15:39] <Compn> and we thought video stuff would get more normal
[15:39] <Compn> we thought maybe interlaced was going away
[15:39] <j-b> Compn: do you honestly think it will get more normal?
[15:40] <Compn> i meant back in 2004 
[15:40] <Compn> whenever h264 came out
[15:41] <Compn> kinda thought we were done with format wars
[15:41] <wm4> "more sins are committed in the name of optimization than something something"
[15:41] <wm4> whatever was the correct quote
[15:41] <Daemon404> grep dsputil
[15:41] <Daemon404> im sure its there
[15:42] <wm4> I guess cargo culting and micro optimizations are really big in multimedia, just like in game dev
[15:42] <Daemon404> id wager its worse in game dev... from what ive seen anyway
[15:42] <Daemon404> optimizing like it's 1994
[16:18] <gnafu> So what do you think it'd look like if you watched one of these 12-bit MVC videos decoded as 3D video?  What would your right and left eyes see?
[16:30] <nevcairiel> one eye sees an 8-bit image, the other garbage
[16:35] <gnafu> nevcairiel: I'd love to try it :-).
[16:35] <gnafu> Could be some real psychedelic stuff.
[16:36] <nevcairiel> probably similar to this avisynth stacked high-bit hack
[17:28] <Compn> i dont get why people are creating encodes that wont play with hwaccel decoders
[17:28] <Compn> i guess reencoding for mpeg2 or mpeg4 without qpel never goes out of style
[17:29] <nevcairiel> because they want to preserve more information than the default profile supports? :D
[17:41] <wm4> saste: will the HAVE_INCOMPATIBLE_LIBAV_ABI issue be fixed at some point?
[17:54] <cone-261> ffmpeg.git 03Piotr Bandurski 07master:5f39992ed925: bmp: fix decoding of flipped rle4
[18:42] <saste> wm4, what's the issue with have-incompatible-libav-abi?
[18:43] <saste> if they will ever be completely compatible? only $deity knows
[18:43] <wm4> include/libavfilter/avfilter.h:1314:5: warning: "HAVE_INCOMPATIBLE_LIBAV_ABI" is not defined [-Wundef]
[18:44] <saste> uh?
[18:44] <saste> wm4, how did you get it?
[18:44] <wm4> by including avfilter.h
[18:45] <saste> weird
[18:45] <Compn> >warning
[18:45] <Compn> >not error
[18:46] <saste> wm4, what if you put AV_HAVE...
[18:46] <saste> that should fix it, since it will use the public symbols
[18:47] <saste> *symbol
[18:49] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:db33010483a0: jpeg2000dec: silence unused variable warning
[18:51] <wm4> saste: I think that works
[18:54] <saste> wm4, please send a patch, I'm uncomfortable to commit patches which I didn't test
[19:06] <wm4> saste: sent
[19:07] <wm4> feel free to adjust the commit message
[19:15] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:6d323ff57af2: swscale: remove unneeded include assert.h
[19:15] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:8589d7a61c56: avfilter/vf_yadif:remove unneeded include assert.h
[19:15] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:ca857c86bdd3: tests/tiny_psnr: remove unneeded include assert.h
[19:15] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:56123fc721b1: avutil/softfloat: remove unneeded include assert.h
[20:02] Action: llogan is looking forward to the resulting Kamedo2 tests
[20:03] Action: nevcairiel is looking forward to the actual patches that give use these fixes
[20:43] <bernie_> wm4: thanks for your help regarding the CueRelativePosition
[20:49] <wm4> bernie_: so now that it turned out this was a mkvmerge bug, and CueRelativePosition is a bit more sane than we thought, which approach will you implement?
[21:05] <bernie_> wm4: It's a good question.  I really like the simplicity of starting a new cluster, and the code change is trivial in ffmpeg.  I'd like to add this as an optional feature to ffmpeg, but would need guidance on if that is a reasonable thing to add, given the use-case is quite constrained to the specific project I'm working on.  I like the idea of adding it, because it's an easy change
[21:09] <bernie_> wm4: I do have a patch that I think implements CueRelativePosition correctly, but it blows up fate test -- I'm guessing fate looks at the output video file and checks if it's been unchanged from what is currently accepted?
[21:10] <wm4> uh, I don't know
[21:10] <nevcairiel> yeah it does a crc check on the file, so if you add new elements it would need to be updated, after validating with mkv validation tools that the file is valid, of course
[21:10] <wm4> I guess it might be possible that there's a seek check
[21:10] <wm4> so if the seek behavior changes, the test could blow up?
[21:10] <wm4> much simpler
[21:10] <nevcairiel> there might be seek tests too, i dont know about that
[21:11] <bernie_> Well currently I have both things turned on:  forcing a new cluster on a keyframe and generating CueRelativePosition.
[21:11] <bernie_> So for the first path, I guess I should turn forcing a new cluser on a keyframe off.
[21:12] <bernie_> ^path^patch
[21:12] <wm4> bernie_: how much overhead do clustered keyframes cause?
[21:12] <wm4> when remuxing
[21:14] <bernie_> well -- for me it's not worth to worry about, because I basically constrain my keyframes to happen only at the percise points in the video file that I need fast-seeking to.  In my case, that would be maybe 100 key frames for a video that's ~20 minutes long.  
[21:16] <bernie_> I'm using -force_key_frames and -g with a very high number.
[21:16] <bernie_> afk for a bit.  My wife wants to share a sandwich with me for lunch
[21:37] <cone-261> ffmpeg.git 03Lukasz Marek 07master:a289f418e4fa: doc/filters: add sepia example for colorchannelmixer
[21:56] <bernie_> wm4: seek behavior should not have changed -- code that doesn't make use of CueRelativePosition can safely ignore it, and i didn't make any modification to demux.  Just adding an EBML element.  Which mkv validation tools should I be using to verify, and how would I go about adding / changing the fate test expected output data?  
[21:57] <wm4> these are good questions, and I don't know how to answer any of them
[21:58] <bernie_> d'oh!
[21:58] <wm4> but it'll probably be hard to verify it's correct, because the only thing that is writing these elements (mkvmerge) did it incorrectly so far
[21:58] <bernie_> yes
[21:59] <bernie_> well, perhaps I can give you the patch, have you code review it, and then you could double check the EBML dump and verify a sample?  :)  (doesn't that sound like fun?)
[21:59] <bernie_> after all, you are the one that caught the bug in mkvmerge
[22:00] <wm4> I could try whether my code can read it correctly
[22:00] <bernie_> yep
[22:00] <bernie_> do you want me to email you the proposed patch real quick?
[22:00] <wm4> sure
[22:02] <wm4> you can also compile mkvmerge from git
[22:02] <wm4> mosu said he fixed it
[22:31] <bernie_> so many interruptions today
[22:33] <bernie_> wm4: finally got around to emailing you the patch.  I'll look at downloading mkvmerge and building that... though I'm totally new to that tool
[22:38] <bernie_> aww man, mkvtoolnix is complaining about gcc, and my machine happens to be mac OS X, so it's really XCode underneath... configure: error: support for required C++11 features incomplete
[22:38] <bernie_> grrr
[22:39] <wm4> hm, try to get it to use clang
[22:42] <bernie_> they suggest compiling the latest version of gcc
[22:42] <bernie_> ouch
[22:43] <bernie_> And with "they" I mean Mosu
[22:44] <bernie_> http://forum.doom9.org/archive/index.php/t-155732-p-5.html ... "There's no workaround, I will not remove the code using these features again. See http://marcmutz.wordpress.com/2011/09/20/c98-support-costs-extra/ why. I like being an early adopter of good stuff :)" and "What you can do is compile gcc 4.6.1"
[22:44] <wm4> yeah, isn't it a joy?
[22:45] <nevcairiel> i think its great that a dev doesnt enslace himself to the stupid legacy systems in this world
[22:45] <bernie_> and all I wanted to do was implement a video player.  hahaha
[22:45] <nevcairiel> enslave*
[22:47] <durandal_1707> those are some c++ extensions?
[22:47] <nevcairiel> no extensions, just a newer version of the standard
[22:48] Action: wm4 is so glad that ffmpeg uses C
[22:48] <wm4> also why does mkvmerge want boost::filesystem
[22:49] <nevcairiel> its not like C doesnt have the opportunitys to use newer functionality, in C99 or even C11
[22:49] <nevcairiel> but its easier to decide for a project that you basically control alone
[22:50] <wm4> now boost regex
[22:50] <wm4> which depends on libicu
[22:51] <nevcairiel> while i do like c++, i'm not a fan of boost =p
[22:52] <wm4> aaand it compiles soo slow
[23:07] <wm4> bernie_: I'm not sure yet (and mkvmerge is still compiling), but I think there might be a problem with your patch (or with my code)
[23:07] <wm4> bernie_: we said the relative offset starts from the end of the cluster length field, right?
[23:07] <wm4> while your patch looks like it takes the start of the cluster
[23:08] <wm4> as in, the file position of the cluster ebml id
[23:26] <wm4> bernie_: ok my code works with the newest mkvmerge
[23:29] <bernie_> wm4: oh I screwed it up? sorry.
[23:30] <bernie_> wm4: so you'll submit your patch?
[23:31] <bernie_> wm4: I think you are right, I have a bug in my implementation
[23:31] <wm4> I didn't write a patch against ffmpeg if you mean that
[23:31] <bernie_> wm4: oh, okay -- then I shall go and fix my patch proposal for ffmpeg
[23:34] <cone-261> ffmpeg.git 03wm4 07master:122536e01a0a: avfilter: fix preprocessor condition
[23:34] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:07704c61dd70: avformat/matroskaenc: Only change chapter ids if needed.
[23:41] <durandal_1707> this mxf is nightmare
[23:43] <bernie_> wm4: okay, just making sure I understand the structure correctly, ebml_master.pos points to the offset where the first child element goes.  Given I'm interested in that point for relative cluster offset, I should be using mkv->cluster.pos, so specifically: (packet_start_pos - mkv->cluster.pos)
[23:46] <wm4> cluster pos seems to point to the start of the cluster element itself
[23:47] <wm4> but you need the position where the cluster element's header ends
[23:47] <wm4> mkv->cluster = start_ebml_master(pb, MATROSKA_ID_CLUSTER, 0);
[23:47] <wm4> after his, probably
[23:47] <wm4> *this
[23:47] <wm4> again I ask me why they did it this way... seems confusing
[23:49] <bernie_> yeah, and start_ebml_master -- I think returns ebml_master struct that seems to populate the pos field with the position after writing the EBML tag and the size data.
[23:50] <bernie_> so mkv->cluster.pos should point where we want it.
[23:50] <bernie_> Just confirming... ;)
[23:50] <wm4> I think it doesn't
[23:51] <wm4> mkv->cluster_pos points to the start of the cluster element itself
[23:51] <wm4> including the MATROSKA_ID_CLUSTER id and the cluster size field
[23:51] <wm4> but you want the position after this
[23:51] <bernie_> I agree
[23:51] <bernie_> that is why I wrote, mkv->cluster.pos
[23:52] <bernie_> and not mkv->cluster_pos 
[23:52] <bernie_> :)
[23:53] <wm4> oh
[23:53] <wm4> ok then it should be correct
[23:54] <wm4> will you send an updated patch?
[23:54] <bernie_> nice, okay -- I will do that
[23:54] <bernie_> first have to undo my force-new-cluster-for-every-keyframe hack
[00:00] --- Sat Jul 20 2013