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

[burek]

[00:46] <superware> I have an RTP/h264 video stream, when I ffplay -f h264 rtp://0.0.0.0:1234 it plays only half picture, the lower area seems corrupted. Do I need to specify more information about the stream? http://pastebin.com/MTxZw0PL
[00:50] <superware> michaelni: hi
[00:51] <kierank> dropping packets or something
[00:54] <superware> kierank: it works with VLC, so I thought it's something I need to define in the command line
[00:58] <superware> kierank: can I set RTP Packetization Mode from the command line?
[00:58] <kierank> dunno
[00:59] <superware> must I play an SDP file?
[01:04] <cone-660> ffmpeg.git 03Fabian Neundorf 07master:353f302250fd: lavf/matroskaenc: using valid chapter ids
[01:19] <superware> I have an RTP/h264 video stream, when I ffplay -f h264 rtp://0.0.0.0:1234 it plays only half picture, the lower area seems corrupted. Do I need to specify more information about the stream? http://pastebin.com/MTxZw0PL
[01:27] <cone-660> ffmpeg.git 03Michael Niedermayer 07master:37ded5303719: vf_scale: use sws_init_context()
[01:54] <cone-660> ffmpeg.git 03Lukasz Marek 07master:247e658784ea: ftp: fix interrupt callback misuse
[01:54] <cone-660> ffmpeg.git 03Lukasz Marek 07master:db72b7742a94: ftp: remove unused headers
[01:54] <cone-660> ffmpeg.git 03Lukasz Marek 07master:2217243e1234: ftp: comments
[01:54] <cone-660> ffmpeg.git 03Lukasz Marek 07master:816c579cf3cb: ftp: warning about pure-ftp server used as and output
[01:54] <cone-660> ffmpeg.git 03Michael Niedermayer 07master:1816f5509e4f: Merge https://github.com/lukaszmluki/ffmpeg
[02:08] <cone-660> ffmpeg.git 03Lukasz Marek 07release/2.0:fcab45f39bda: ftp: fix interrupt callback misuse
[08:00] <bernie_> the option -g, can take INT_MIN to INT_MAX.  Not 0 to INT_MAX.  What does a negative group of picture size signify? 
[09:13] <wm4> saste: forgot about it
[09:13] <wm4> saste: so there was the linesize issue, right?
[09:13] <wm4> saste: I don't understand why the linesize would include padding, that makes no sense to me
[09:13] <wm4> planar audio doesn't use the linesize for access, or does it
[10:02] <saste> wm4: I tested your patch, and noted the audio glitch
[10:02] <saste> and yes, in general audio linesize is padded, for alignment reasons
[10:03] <wm4> yes, I think I actually experienced the same problem with some files, I just didn't get what was wrong
[10:03] <wm4> so why is the linesize padded?
[10:03] <saste> for alignment reasons
[10:03] <saste> linesize is the padded size of the plane
[10:04] <wm4> I understand that for the allocation, but the linesize itself could be just the exact size, because unlike video frames, you don't need them for access
[10:04] <saste> yes
[10:04] <wm4> s/them/it/
[10:04] <saste> i don't remember the exact reasoning we did
[10:04] <saste> also iirc that was merged from libav, so that's probably a better place where to ask
[10:05] <wm4> I see
[10:07] <wowdd1> hello 
[10:08] <wowdd1> is there some good book about  multimedia  ? 
[10:26] <cone-766> ffmpeg.git 03Diego Biurrun 07master:3ac7fa81b238: Consistently use "cpu_flags" as variable/parameter name for CPU flags
[10:26] <cone-766> ffmpeg.git 03Michael Niedermayer 07master:9d01bf7d66df: Merge remote-tracking branch 'qatar/master'
[11:21] <cone-766> ffmpeg.git 03James Almer 07master:562fb9c54099: lavf/riff: Add ITRK tag
[11:30] <wm4> michaelni: just curious; how do you merge? do you manually merge until the first conflicting commit, or is there a magic git-merge option that does it for you?
[11:53] <michaelni> i mostly use git merge and a text editor but occasionally i use/try different methods
[11:55] <wm4> michaelni: I saw this, it sort of looks like it might be useful (though I haven't tried it myself, so I don't know if it works well): http://softwareswirl.blogspot.de/2013/05/git-imerge-practical-introduction.html
[11:55] <wm4> it's a git extension for incremental merging
[12:08] <cone-766> ffmpeg.git 03James Almer 07master:630fc7dcfc31: vorbiscomment: Add DESCRIPTION to ff_vorbiscomment_metadata_conv
[13:51] <cone-766> ffmpeg.git 03Nicolas George 07master:ebaf20e94b99: lavfi/scale: allocate interlaced scalers only if needed.
[14:32] <wm4> here's an interesting idea for libavfilter: make it possible for the graph to export variables
[14:32] <wm4> which the application can set in a controlled manner
[14:32] <wm4> even at runtime
[14:32] <wm4> maybe that'd be better than the command stuff
[16:54] <Daemon404> nevcairiel, fyi MSE still has issues with c00conv
[16:54] <Daemon404> er c99conv
[16:55] <JEEBsv> lol
[16:55] <Daemon404> i just ran into it again
[16:57] <nevcairiel> yeah i noticed it at home as well
[16:57] <nevcairiel> apparently my laptop here just balances out between IO and CPU power
[16:57] <nevcairiel> so you can get 100% 
[16:57] <Daemon404> lol
[16:57] <Daemon404> aka magic
[16:58] <nevcairiel> although at home its not one core anymore, its like 50% cpu now since i move my code onto a SSD
[16:58] <nevcairiel> moved*
[18:07] <cone-675> ffmpeg.git 03Ed Torbett 07master:7203dbde3910: avformat/rt*p: Joining a SSM multicast group using an SDP (Issue #2171)
[18:51] <cone-675> ffmpeg.git 03Carl Eugen Hoyos 07master:42272e86fea5: lut3d: Fix reading 3dl files with leading comments.
[18:51] <cone-675> ffmpeg.git 03Carl Eugen Hoyos 07master:36b21e17a23c: lavf/concat: Never fail for sample aspect ratio 0:1.
[18:51] <cone-675> ffmpeg.git 03Carl Eugen Hoyos 07master:b39a6bbe7f43: Fix pix_fmt detection in the native jpeg2000 decoder.
[18:51] <cone-675> ffmpeg.git 03Michael Niedermayer 07master:ed8c34a7666a: Merge remote-tracking branch 'cehoyos/master'
[20:54] <mateo`> durandal_1707: do you know if some work (or brainstorming) has been started on how to handle stream with AV_DISPOSITION_ATTACHED_PIC ?
[20:56] <wm4> what's there to handle?
[21:04] <mateo`> wm4: try to find a better way to handle attached pics in lavf
[21:06] <wm4> better in what way?
[21:08] <mateo`> not treated as a normal stream
[21:09] <mateo`> that's just an idea ...
[21:10] <mateo`> the way the cover art are handled in the different muxer is quite ugly
[21:10] <mateo`> imho
[21:16] <mateo`> supporting such feature in the mov muxer for example results in intrusive code
[21:21] <mateo`> storing the covert arts in some kind of metadata would be nice but we need to keep the ability to transcode the cover art itself
[21:34] <durandal_1707> mateo`: nothing, and i
[21:34] <durandal_1707> 'm not movitaved to do/fix it
[21:35] <mateo`> i'm motivated to do it
[21:37] <durandal_1707> imho, metadata should remain metadata
[21:37] <durandal_1707> but some "smart" libav dev thought that it better to make it stream. so avplay can display it
[21:38] <durandal_1707> and michaelni want abi compability with evil fork, so be it....
[21:38] <bernie_> I wonder if CueRelativePosition is implemented correctly in the matroska format.  I'm getting byte offsets that easily fall outside the size of the cluster itself.
[21:38] <mateo`> so we are basically doomed :D
[21:38] <wm4> mateo`: well, you can access the AVPacket directly, instead of treating the AVStream as video stream
[21:40] <bernie_> actually, possible just a decoding bug... (sorry) :)
[21:42] <mateo`> wm4: but you'll still have to discard in some way this kind of stream in the muxer
[21:44] <bernie_> yeah, okay -- now I see that CueRelativePosition is not being set in the encoding for matroska, though it is part of the spec (I guess it's pretty new).  I'm looking for fast seek performance... would be good to set that EBML element for Cues.
[21:44] <mateo`> wm4: assuming the muxer will automatically map all video streams
[21:47] <bernie_> this would mean chaning mkv_add_cuepoint() in matroskaenc.c to include the relative byte offset in the cluster to get to the block.
[22:03] <wm4> bernie_: or just use mkvmerge
[22:04] <wm4> bernie_: how is seeking slow? are you sure it isn't just because of keyframes?
[22:05] <bernie_> I'm writing my own video player for iOS for a laundry list of reasons...  Seeking isn't really going to be slow I don't think, but using CueRelativePosition just makes sense, that way you do not need to parse through all preceding blocks before getting to the block you really want to go to.
[22:05] <bernie_> I think I can make a patch that would just include this information
[22:06] <bernie_> as per the matroska spec to-date.
[22:06] <bernie_> It should be quite trivial to add... so I think... it just makes sense to add it.
[22:07] <bernie_> The specific ID for CueRelativePosition is 0xf0
[22:07] <bernie_> as docuemnted here: http://matroska.org/technical/specs/index.html
[22:08] <bernie_> In my situation, I'm in contorl over both the encoding and decoding process for the content I wish to present to the end-user, so this is a reasonable option.
[22:08] <bernie_> I guess my question is... should I make this patch, if it would be of general interest to ffmpeg to include it. 
[22:10] <wm4> it probably would, though I don't really see how it's useful (cluster sizes are limited by convention anyway?)
[22:10] <bernie_> it's useful like so:
[22:11] <bernie_> http://permalink.gmane.org/gmane.comp.multimedia.matroska.devel/4454
[22:12] <bernie_> Specifically: At the moment seeking to a particular block requires
[22:12] <bernie_> seeking to the cluster the block contains for two reasons: First, the
[22:12] <bernie_> ClusterTimecode element has to be found. Second, the block's actual
[22:12] <bernie_> position inside the cluster is unknown. A splitter usually finds the
[22:12] <bernie_> ClusterTimecode as the first child in the cluster, but then it still
[22:12] <bernie_> has to scan all children up to the required block.
[22:12] <bernie_> With this proposal reading the ClusterTimecode would not change.
[22:12] <bernie_> However, a splitter could then seek directly to the required block
[22:12] <bernie_> skipping all the elements in between. This would speed up seeking
[22:13] <wm4> ok so you can skip all blocks in the start of the cluster
[22:13] <bernie_> correct
[22:13] <bernie_> that would be faster
[22:13] <wm4> but if the seek destination (including preroll) falls at the start of a cluster, you have to parse everything yet again?
[22:13] <wm4> even if e.g. subtitles are sparse at best
[22:13] <bernie_> cuepoints are typeically I-frames
[22:14] <bernie_> in my situation they definately are
[22:17] <bernie_> In fact, it only makes a cuepoint entry for keyframe.  So there ought be no reason to have to re-prase.  You should be able to go to the cluster, and then go to the correct offset to start reading the block that contains the I-frame you need to start.  At least, this is how I understand it.
[22:18] <wm4> I think there was something else that was actually useful
[22:18] <wm4> oh right
[22:18] <wm4> cue duration, I think
[22:19] <wm4> so you can estimate whether you really have to seek before to get a subtitle
[22:21] <bernie_> okay, so I'm working on a patch to implement this... not sure what the process is to submit it for consideration of inclusion.  But first I will have lunch :)
[22:22] <wm4> send it to the -dev mailing list
[22:25] <durandal_1707> bernie_: read http://ffmpeg.org/developer.html
[22:25] <bernie_> cool -- thanks!  
[22:26] <wm4> durandal_1707: when will cehoyos read these guidelines?
[22:27] <wm4> durandal_1707: if you want to do something awesomely passive-aggressive, reject his next patch and point to the dev policy, and quote "When you submit your patch, please use git format-patch or git send-email. We cannot read other diffs :-)"
[22:32] <cone-561> ffmpeg.git 03Michael Niedermayer 07master:99de97cabf35: jpeg2000dec: parse CDEF
[22:32] <cone-561> ffmpeg.git 03Michael Niedermayer 07master:fc6de70c44be: jpeg2000dec: Support non subsampled 8bit planar pixel formats
[23:04] <bernie_> wow make fate takes a while... :)
[23:21] <bernie_> great -- now I have to also patch mkvinfo to support CueRelativePosition.
[23:23] <bernie_> It's output is funny though, because it can ID the EBML tag by name: (Unknown element: CueRelativePosition; ID: 0xf0 size: 9) at 4993253 size 9
[23:24] <bernie_> One the one hand, it knows that 0xf0 is CueRelativePosition, but on the other it's unknown... grrr!
[23:42] <bernie_> is there an easy way I can run just a single test?  In my case, I need to re-run lavf-mkv, and a global make fate takes too long...
[00:00] --- Fri Jul 19 2013