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

[burek]

[00:02] <someone-noone> Hey! If I want to reorder packets by pts (decoder is not ffmpeg), how can I know when to "flush" those packets? When new key-frame arrives or when dts==pts? Or may be some other algorithm?
[00:04] <nevcairiel> for mpeg2 and vc1 its pretty easy, you basically delay the last I/P frame until the next one arrives, for H.264 thats quite a bit more complex
[00:06] <someone-noone> nevcairiel, the first codec I'm working on is exactly h264
[00:06] <nevcairiel> well good luck with that
[00:06] <nevcairiel> i wouldn't know how to do it :D
[00:06] <someone-noone> :D
[00:06] <nevcairiel> you could just store the packets and then simply sort by time
[00:07] <nevcairiel> since pts is out of order, you can just re-sort them to give you a linear time
[00:07] <nevcairiel> but its meh :)
[00:07] <nevcairiel> anyway, sleeping time
[00:09] <someone-noone> nevcairiel, pts is in milliseconds time. So& it's not so obvious. However, now I do following: while (pts!=dts || list.size() < 10) wait() 
[00:09] <someone-noone> But it's not very accurate :)
[00:10] <someone-noone> okay, what is a "good time" for this channel? I mean, it's night here too, but I don't know when is it better time to ask
[00:11] <someone-noone> not || but && 
[00:14] <michaelni> someone-noone, if you want to know how h264 pixture reordering works, the authorative source is the itu h264 spec
[00:14] <michaelni> its not a nice easy to read doc though
[00:15] <someone-noone> anyway thanks :_
[00:43] <cone-580> ffmpeg.git 03Ronald S. Bultje 07master:faf8eca08dcb: h264: remove clear_blocks call in threading init.
[00:43] <cone-580> ffmpeg.git 03Michael Niedermayer 07master:701e9b82547c: h264: Use mb itself as memcpy anchor and assert the other anchors position
[01:00] <cone-580> ffmpeg.git 03Vignesh Venkatasubramanian 07master:30c5c45b123c: Adding support for parsing BlockAdditional
[01:01] <cone-580> ffmpeg.git 03Michael Niedermayer 07master:a08ebf04b1b0: matroskadec: simplify additional_id writing code
[03:35] <cone-580> ffmpeg.git 03Michael Niedermayer 07master:9f16cb9e50a5: doc/APIchanges: fix odd .01 versions
[06:58] <wm4> so, how am I supposed to use libavformat in presence of sparse video packets (lots of sound packets, but video packets come only after a number of seconds, like mjpeg "slide shows" in mp4 with audio) - I think this is an API weakness, or am I overlooking something?
[06:58] <wm4> trying to find the next video packets ends in being flooded with audio packets
[06:58] <wm4> ffplay has the same problem
[06:59] <wm4> and in presence of the cover art hack, you'd end up demuxing the whole audio file just to find out that there are no more video packets
[10:47] <wm4> ffmpeg still fails to inject cover art images when trying to seek before start of the file
[10:47] <wm4> or, at least my code just Works on libav
[10:48] <wm4> haven't managed to reproduce it with 'ffmpeg'
[10:49] <durandal_1707> how you recognise cover art on libav?
[10:49] <wm4> I don't think I'm doing anything special here
[10:52] <durandal_1707> so what not special are you doing?
[10:53] <durandal_1707> do you know why it happens?
[10:53] <wm4> not really
[10:53] <durandal_1707> also what container?
[10:53] <wm4> mp3
[10:54] <wm4> also converting mp3s with cover art to mkv produces strange files
[10:54] <wm4> maybe ffmpeg should repeat the picture in the video stream
[10:55] <durandal_1707> what "strange files" means?
[10:55] <durandal_1707> doesn't ffmpeg disposition for covers and libav doesn't?
[10:56] <durandal_1707> lets try again:
[10:56] <durandal_1707> ffmpeg have disposition for covers and libav does not?
[10:57] <wm4> they both have it set
[10:57] <wm4> the AV_DISPOSITION_ATTACHED_PIC flag on the stream
[10:58] <wm4> how can I seek to negative timestamps with ffplay?
[10:58] <durandal_1707> ok, can we get back with strange mkv files?
[10:58] <durandal_1707> wm4: with left/right cursor/arrow keys?
[10:59] <wm4> the "strange" thing about the produced mkv file is that it 1. starts at 10 seconds timestamp (?), and 2. nothing can seek in it (ffplay just jumps to the start)
[11:00] <durandal_1707> and resulted video stream (covert arts) is not marked as cover art?
[11:00] <nevcairiel> many things try to seek to a video frame
[11:00] <nevcairiel> idealy, such an attached pic should not result in a video stream in the mkv
[11:00] <nevcairiel> but also an attached pic
[11:00] <wm4> durandal_1707: no, the produced mkv picture is a "real" video stream
[11:00] <durandal_1707> that is bug, please report it
[11:01] <durandal_1707> nevcairiel: you are talking to the void
[11:01] <wm4> wut
[11:06] <wm4> durandal_1707: can I make ffprobe to seek?
[11:12] <durandal_1707> wm4: seek in what sense?
[11:12] <wm4> durandal_1707: call av[format]_seek_
[11:13] <wm4> before dumping packets with -show_packets
[11:15] <durandal_1707> wm4: don't think so, feature request should be reported in usual place
[11:16] <durandal_1707> wm4: why you did not tell in bug report 
[11:17] <durandal_1707> #2270 that disposition flag is not set?
[11:17] <wm4> isn't that obvious from the output
[11:18] <wm4> isn't that why you ask everyone to post the full output
[11:18] <durandal_1707> not for cehoyos, instead you mentioned metadata and attachments which confused him even more
[11:19] <nevcairiel> attachments are just metadata
[11:19] <nevcairiel> its all in id3 tags for example in mp3
[11:19] <nevcairiel> the disposition flag probably is set, ffmpeg output just doesnt show it, btw
[11:19] <wm4> oops
[11:20] <durandal_1707> why would muxer create dispostion stream in h264?
[11:20] <wm4> it really doesn't
[11:20] <nevcairiel> the muxer just creates a video stream
[11:20] <nevcairiel> it ignores the disposition, apparently
[11:22] <durandal_1707> this doesn't happen with avconv?
[11:22] <cone-893> ffmpeg.git 03Diego Biurrun 07master:c6507946d428: dsputil: Move STRIDE_ALIGN macro to the only place it is used
[11:22] <cone-893> ffmpeg.git 03Derek Buitenhuis 07master:130cefc9dced: doc/platform: Fix 10l typo
[11:22] <cone-893> ffmpeg.git 03Michael Niedermayer 07master:8bbb487e443a: Merge remote-tracking branch 'qatar/master'
[11:22] <wm4> durandal_1707: didn't check
[11:23] <wm4> durandal_1707: yes avconv does the same
[11:24] Action: durandal_1707 is not motiviated to fix their mess rigth now
[11:27] <durandal_1707> wm4: about seek, does ffplay show same issue?
[11:31] <wm4> durandal_1707: no, ffplay doesn't mind if there's no video packet after a seek, I think
[11:33] <durandal_1707> whatever export attachment as stream does not work when seeking
[11:40] <durandal_1707> michaelni: michaelni what is supposed output when qp filter is applied before pp one?
[11:43] <michaelni> pp filter applies postprocessing depending on qp values, qp filter can change qp, higher qp stronger postprocessing
[11:48] <durandal_1707> michaelni: it doesn't work because qcale<->qp_table are not copied?
[11:49] <michaelni> yes, dunno if thats the only reason
[11:52] <saste> durandal_1707, can you send an updated noise?
[11:53] <saste> if you see no review from me within today, then feel free to push it
[12:00] <wm4> durandal_1707: I made a craptacular test program: http://pastebin.com/QCFPXdUU
[12:01] <wm4> durandal_1707: when I use this on a mp3 with cover art, I never see a packet from stream 1
[12:01] <wm4> durandal_1707: but when changing the negative seek target pts to something positive, it shows up
[12:04] <durandal_1707> saste: i want to remove mp=softskip and mp=dsize (and mp=qp, non functional but will port it)
[12:05] <durandal_1707> and maybe  also ilpack
[12:07] <durandal_1707> michaelni: libavcodec/h264.c:1257:30: warning: comparison of distinct pointer types ('CABACContext *'
[12:07] <durandal_1707>       (aka 'struct CABACContext *') and 'int16_t (*)[512]')
[12:07] <durandal_1707>         av_assert0(&h->cabac == &h->mb_padding + 1);
[12:07] <durandal_1707>         ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
[12:07] <durandal_1707> ./libavutil/avassert.h:38:11: note: expanded from macro 'av_assert0'
[12:07] <durandal_1707>     if (!(cond)) {                                                      \
[12:07] <durandal_1707>           ^
[12:09] <nevcairiel> its meant to compare those pointers
[12:18] <cone-893> ffmpeg.git 03Diego Biurrun 07release/1.1:077beee4653f: x86: ac3: Fix HAVE_MMXEXT condition to only refer to external assembly
[12:18] <cone-893> ffmpeg.git 03Tim Walker 07release/1.1:5393a5600ddb: mlpdec: set the channel layout.
[12:18] <cone-893> ffmpeg.git 03Tim Walker 07release/1.1:59f22ef91a1e: mlpdec: TrueHD: use Libav channel order.
[12:18] <cone-893> ffmpeg.git 03Tim Walker 07release/1.1:5af78cc98d80: mlp: store the channel layout for each substream.
[12:18] <cone-893> ffmpeg.git 03Michael Niedermayer 07release/1.1:e1a86b1433f1: mlpdec: dont leave a invalid huff_lsb in the context.
[12:18] <cone-893> ffmpeg.git 03Michael Niedermayer 07release/1.1:e67491a2a49a: Merge commit '99ccd2ba10eac2b282c272ad9e75f082123c765a'
[12:18] <cone-893> ffmpeg.git 03Michael Niedermayer 07release/1.1:1d20d975aa89: Merge commit '3ffcccb4fbaae4d5ad775506f1f2761f2029affa'
[12:18] <cone-893> ffmpeg.git 03Michael Niedermayer 07release/1.1:9e3e11a348e0: Merge commit '1fd2deedcc6400e08b31566a547a5fac3b38cefb'
[12:19] <cone-893> ffmpeg.git 03Michael Niedermayer 07release/1.1:6baaaa0174bf: Merge commit '5af78cc98d807f3b43510410dad46e1840c5c99f' into release/1.1
[12:19] <cone-893> ffmpeg.git 03Michael Niedermayer 07release/1.1:358e4081edb8: mlp: fix channel order.
[12:24] <saste> durandal_1707, i'm not against removing mp filters if useless, but i prefer if it is michael to give the ok, since that's mostly his code
[12:24] <saste> ubitux, still willing to optimize kerndeint?
[12:25] <nevcairiel> try to figure out why it fails in msvc-dll builds while you're in there :D
[12:28] <durandal_1707> michaelni: your opinion on mp=dsize and mp=softskip removal?
[12:29] <durandal_1707> saste: michaelni did not write those two filters
[12:29] <michaelni> i leave it to saste todecide
[12:29] <durandal_1707> maybe thay where useful with mplayer/mencoder but thay are not with ffmpeg
[12:30] <durandal_1707> i tried my best to prove they do anything and i failed
[12:30] <durandal_1707> unlike mp=qp, which is useless but port could be useful
[12:33] <durandal_1707> also my goal is to write more generic filters - they are way more useful
[12:35] <cone-893> ffmpeg.git 03Michael Karcher 07release/1.1:901682ff78da: atrac3: use correct loop variable in add_tonal_components()
[12:35] <cone-893> ffmpeg.git 03Anton Khirnov 07release/1.1:e0e425042193: dnxhdenc: fix invalid reads in dnxhd_mb_var_thread().
[12:35] <cone-893> ffmpeg.git 03Anton Khirnov 07release/1.1:e835ce83e2ac: vf_delogo: fix an uninitialized read.
[12:35] <cone-893> ffmpeg.git 03Anton Khirnov 07release/1.1:5bee21d724dc: vf_delogo: fix copying the input frame.
[12:36] <cone-893> ffmpeg.git 03Michael Niedermayer 07release/1.1:5a3c8f95d5bf: Merge commit '5bee21d724dc47d115faae3f5065a6db74e1594a' into release/1.1
[12:41] <wm4> hm, so under some condition, libav actually fails to inject a video packet too... actually the seek can sometimes fail
[12:43] <durandal_1707> saste: sent new noise
[12:46] <saste> durandal_1707, thanks for the noise :)
[12:46] <durandal_1707> what is different between unsharp and mp=unsharp?
[12:46] <saste> durandal_1707, interface
[12:46] <saste> also there is a possible out-of-buffer read in unsharp
[12:47] <saste> give me some time and i'll send you a link to the thread
[12:47] <durandal_1707> saste: so no reason to keep mp=unsharp?
[12:47] <saste> i'd prefer to keep it until unsharp is fixed
[12:47] <durandal_1707> what needs fixing?
[12:47] <saste> for theoretical security reasons people may prefer to use mp=unsharp
[12:48] <durandal_1707> nonsense, it is nowhere documented
[12:48] <saste> durandal_1707, i forgot the details, but it is all in the thread
[12:50] <durandal_1707> no, i just found thread that you found that output differs
[12:51] <durandal_1707> which is WTF, filter should not be commited if it have obvious bug
[12:51] <durandal_1707> like earwax
[13:00] <durandal_1707> unsharp have strange macro UPSHIFT
[13:00] <durandal_1707> *SHIFTUP
[13:01] <cone-893> ffmpeg.git 03Anton Khirnov 07release/1.1:00bf66785f7d: fraps: fix off-by one bug for version 1.
[13:01] <cone-893> ffmpeg.git 03Anton Khirnov 07release/1.1:7e35c50b81d9: yop: check that extradata is large enough.
[13:01] <cone-893> ffmpeg.git 03Anton Khirnov 07release/1.1:108ca6fad1e0: yop: check for input overreads.
[13:01] <cone-893> ffmpeg.git 03Michael Niedermayer 07release/1.1:81bcf9454e19: Merge commit '108ca6fad1e0e9af8d6337f908bfd23807b7fbd6' into release/1.1
[13:03] <durandal_1707> ok i removing softskip and dsize
[13:11] <durandal_1707> what is happening with mplayerhq.hu? I cant read its manual
[13:17] <michaelni> elaborate what where doesnt work ?
[13:17] <michaelni> manual i mean ?
[13:17] <durandal_1707> native unsharp indeed gives different output, maybe because its syntax is broken
[13:18] <durandal_1707> michaelni: not acessible, stalled
[13:22] <michaelni> i dont know what you mean by "not acessible, stalled" it doesnt timeout it doesnt give http errors
[13:23] <michaelni> also ive no time for guessing games
[13:23] <michaelni> which URL does what ?
[13:25] <durandal_1707> itsn't ffmpeg so why would it be so imporant?
[13:25] <durandal_1707> no it works
[13:26] <durandal_1707> *now
[13:26] <michaelni> if theres a problem with the server it may be important
[13:26] <michaelni> also mplayerhq.hu uses a mirror network
[13:27] <michaelni> www1.mplayerhq.hu www2, ...
[13:30] <iive> meaning you may have been routed to some of the mirrors that is having problems.
[13:30] <durandal_1707> lol, unsharp can do some unintentional effect
[13:31] <cone-893> ffmpeg.git 03Anton Khirnov 07release/1.1:1f8bf163e4b4: aasc: fix output for msrle compression.
[13:31] <cone-893> ffmpeg.git 03Kostya Shishkov 07release/1.1:d0249f1c2e55: qtrle: fix the topmost line for 1bit
[13:31] <cone-893> ffmpeg.git 03Anton Khirnov 07release/1.1:b7765d00f911: msrledec: check bounds before constructing a possibly invalid pointer,
[13:31] <cone-893> ffmpeg.git 03Michael Niedermayer 07release/1.1:7f8846405e8a: Merge commit 'b7765d00f911fe0f8fcda21b93a540f27d2ba2f5' into release/1.1
[13:32] <durandal_1707> saste: actually unsharp gives same output as mp=unsharp
[13:32] <saste> durandal_1707, yes
[13:33] <saste> durandal_1707, but it accepts param values for which it will read oob values
[13:33] <durandal_1707> so what should be done? change syntax?
[13:33] <saste> the port was ill-done
[13:33] <cone-893> ffmpeg.git 03Michael Niedermayer 07release/0.11:470ee0c660ed: h264_refs: Print default in case we are missing a reference.
[13:34] <cone-893> ffmpeg.git 03Michael Niedermayer 07release/0.11:ebe645f02b3f: h264: Reset last_pocs in case of reference or frame number inconsistencies
[13:34] <cone-893> ffmpeg.git 03Michael Niedermayer 07release/1.0:9c659b3a678f: h264_refs: Print default in case we are missing a reference.
[13:34] <cone-893> ffmpeg.git 03Michael Niedermayer 07release/1.0:169d84934423: h264: Reset last_pocs in case of reference or frame number inconsistencies
[13:34] <cone-893> ffmpeg.git 03Michael Niedermayer 07release/1.1:2ac6b573a408: h264: Reset last_pocs in case of reference or frame number inconsistencies
[13:34] <saste> since the unsharp syntax is different from mp=unsharp
[13:34] <saste> and it accepts different ranges
[13:35] <durandal_1707> it can also crash
[13:35] <durandal_1707> i want to fix obvious nonsense/useless nonfeatures/misfeatures/bugs/and atc
[13:35] <durandal_1707> so what solution you prefer?
[13:36] <durandal_1707> keep syntax and add missing checks?
[13:45] <durandal_1707> config_props can be called several times in row without uninit?
[13:55] <cone-893> ffmpeg.git 03Kostya Shishkov 07release/1.1:5479e08cc44a: xxan: properly handle odd heights.
[13:55] <cone-893> ffmpeg.git 03Derek Buitenhuis 07release/1.1:4eede1fca24a: doc/platform: Fix 10l typo
[13:55] <cone-893> ffmpeg.git 03Martin Storsjö 07release/1.1:5310da7e83ec: arm: Fall back to runtime cpu feature detection via /proc/cpuinfo
[13:55] <cone-893> ffmpeg.git 03Michael Niedermayer 07release/1.1:7d3e21762317: Merge remote-tracking branch 'qatar/release/9' into release/1.1
[14:17] <cone-893> ffmpeg.git 03Michael Niedermayer 07release/1.1:71fee2ab1e77: sws: dont write out of array on bigendian
[14:19] <cone-893> ffmpeg.git 03Xi Wang 07release/0.8:e163d884ef6c: rtmp: fix multiple broken overflow checks
[14:19] <cone-893> ffmpeg.git 03Xi Wang 07release/0.8:b59ee5dcf119: rtmp: fix buffer overflows in ff_amf_tag_contents()
[14:19] <cone-893> ffmpeg.git 03Janne Grunau 07release/0.8:801eff785aa1: rv34: error out on size changes with frame threading
[14:19] <cone-893> ffmpeg.git 03Michael Niedermayer 07release/0.8:03ddc260668b: indeo5dec: Make sure we have had a valid gop header.
[14:19] <cone-893> ffmpeg.git 03Anton Khirnov 07release/0.8:604d72aa0d05: dfa: improve boundary checks in decode_dds1()
[14:19] <cone-893> ffmpeg.git 03Anton Khirnov 07release/0.8:440e98574bde: indeo4/5: check empty tile size in decode_mb_info().
[14:19] <cone-893> ffmpeg.git 03Anton Khirnov 07release/0.8:301761792a69: mpeg12: do not decode extradata more than once.
[14:19] <cone-893> ffmpeg.git 03Reinhard Tartler 07release/0.8:db5b454c3d20: Update changelog for 0.7.7 release
[14:19] <cone-893> ffmpeg.git 03Michael Niedermayer 07release/0.8:e4831bb9a678: huffyuvdec: Check init_vlc() return codes.
[14:19] <cone-893> ffmpeg.git 03Michael Niedermayer 07release/0.8:4f91c4564493: huffyuvdec: Skip len==0 cases
[14:19] <cone-893> ffmpeg.git 03Michael Niedermayer 07release/0.8:acada70ffbd7: Merge remote-tracking branch 'qatar/release/0.7' into release/0.8
[14:23] <durandal_1707> last time to say no to dsize & softskip removal
[14:26] <durandal_1707> cehoyos, bug is not wish
[14:46] <durandal_1707> saste: http://ffmpeg.org/pipermail/ffmpeg-devel/2012-February/120640.html <- why this was never applie?
[14:49] <cone-893> ffmpeg.git 03Paul B Mahol 07master:968f8acec882: lavfi: remove dsize libmpcodecs wrapper
[14:49] <cone-893> ffmpeg.git 03Paul B Mahol 07master:41ae43cade37: lavfi: remove softskip libmpcodecs wrapper
[14:56] <saste> durandal_1707, i was not anymore sure it was a good idea
[14:56] <durandal_1707> why?
[14:56] <durandal_1707> please explain
[14:57] <saste> maybe we should keep separate options
[14:57] <saste> and use shorthands to keep syntax compatibility
[14:58] <saste> having an ad-hoc specification language for the params is a bit inconsistent
[14:59] <durandal_1707> saste: so the only reason why you prefer to keep mp=unsharp is because native one crash?
[14:59] <saste> especially now that we have shorthands and options
[14:59] <saste> does it crash?
[14:59] <durandal_1707> yes
[15:00] <saste> durandal_1707, as i explained, i was not confortable with the other patch which was limiting the ranges
[15:00] <saste> because i couldn't tell why those ranges were choosen
[15:00] <saste> and i'm sorry that i've being busy but i'd still would like to update my unsharp patchset
[15:02] <durandal_1707> sorry but too much time passed
[15:03] <durandal_1707> mp=unsharp clip them somehow
[15:04] <ubitux> saste: not soon
[15:04] <ubitux> got some other priorities somehow now
[15:12] <durandal_1707> saste: mp=unsharp set blocks size to odd values between [3, 63]
[15:12] <saste> durandal_1707, missing micro bumps
[15:13] <saste> durandal_1707, give me some time to work on unsharp, now i gonna leave
[15:14] <cone-893> ffmpeg.git 03Carl Eugen Hoyos 07master:7d0e3b197c81: Write the fiel atom to mov files independently of the used video coded.
[15:14] <cone-893> ffmpeg.git 03Carl Eugen Hoyos 07release/0.10:7a21b089c275: sws: dont write out of array on bigendian
[15:14] <cone-893> ffmpeg.git 03Carl Eugen Hoyos 07release/0.11:2f98537ea074: sws: dont write out of array on bigendian
[15:14] <cone-893> ffmpeg.git 03Carl Eugen Hoyos 07release/1.0:140ca8f6c035: sws: dont write out of array on bigendian
[15:19] <durandal_1707> this is unacceptable
[15:30] <cone-893> ffmpeg.git 03Kostya Shishkov 07release/0.10:a94f789c334c: indeo3: initialise pixel planes on allocation
[15:30] <cone-893> ffmpeg.git 03Luca Barbato 07release/0.10:1076ea8115ad: mp3: exit on parsing error in mp_decode_frame
[15:30] <cone-893> ffmpeg.git 03Anton Khirnov 07release/0.10:a4c9260e6914: pthread: set the frame properties from the thread context, not user.
[15:30] <cone-893> ffmpeg.git 03Xi Wang 07release/0.10:165f783235a0: rtpenc: fix overflow checking in avc_mp4_find_startcode()
[15:30] <cone-893> ffmpeg.git 03Xi Wang 07release/0.10:69b3fedc09d9: rtmp: fix multiple broken overflow checks
[15:30] <cone-893> ffmpeg.git 03Xi Wang 07release/0.10:ef953f760ef1: rtmp: fix buffer overflows in ff_amf_tag_contents()
[15:30] <cone-893> ffmpeg.git 03Michael Niedermayer 07release/0.10:ba4b57e8024a: huffyuvdec: Check init_vlc() return codes.
[15:30] <cone-893> ffmpeg.git 03Michael Niedermayer 07release/0.10:b07c79125270: huffyuvdec: Skip len==0 cases
[15:30] <cone-893> ffmpeg.git 03Michael Niedermayer 07release/0.10:5b7f7f3809a8: Merge remote-tracking branch 'qatar/release/0.8' into release/0.10
[15:53] <cone-893> ffmpeg.git 03Carl Eugen Hoyos 07release/0.10:83446017128b: Write the fiel atom to mov files independently of the used video coded.
[15:53] <cone-893> ffmpeg.git 03Carl Eugen Hoyos 07release/0.11:ec18baadfa17: Write the fiel atom to mov files independently of the used video coded.
[15:53] <cone-893> ffmpeg.git 03Carl Eugen Hoyos 07release/1.0:397e769f74dd: Write the fiel atom to mov files independently of the used video coded.
[15:53] <cone-893> ffmpeg.git 03Carl Eugen Hoyos 07release/1.1:057051b84879: Write the fiel atom to mov files independently of the used video coded.
[16:19] <michaelni> Paranoialmaniac, is there a fiel atom in mp4 like in mov ?
[16:25] <TimNich> I don'y have the mp4 spec to hand but Quicktime Pro writes them to .mp4 files
[16:25] <JEEB> not like QuickTime really cares about the specs
[16:26] <michaelni> well iam asking because carls commit makes ffmpeg write them into mp4 too now
[16:26] <nevcairiel> i probably have the iso spec somewhere, but i hate reading it :D
[16:26] <JEEB> the ISO base media format spec is freely available
[16:26] <JEEB> the ones that are not are the short MP4 file format spec
[16:26] <JEEB> and the -15 AVC-in-"mp4" spec
[16:27] <JEEB> (AVC file format)
[16:27] <TimNich> Yes, but I tend to have qtff to hand at all times, but not the part 10 specs
[16:27] <nevcairiel> -12 should be the isom
[16:28] <JEEB> oh right, 12
[16:29] <nevcairiel> where in the hierarchy is fiel?
[16:29] <JEEB> http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=61988 <- click the ITTF link
[16:29] <JEEB> for a free copy of -12
[16:39] <cone-893> ffmpeg.git 03Nicolas George 07master:bb3303b94c1c: lavfi/vf_ass: ignore subtitles decoding errors.
[16:39] <cone-893> ffmpeg.git 03Nicolas George 07master:c557a5b08efe: lavfi/vf_ass: reindent after last commit.
[16:44] <michaelni> TimNich, QT pro writes fiel also into h264 in mp4 files ?
[16:47] <TimNich> not for H264, but for some other codecs..\
[16:50] <JEEB> also stuff becomes even more fun because "mp4" is not a single entity
[16:50] <JEEB> given the written brand
[16:51] <TimNich> ISO/IEC 14496-12:2012(E) doesn't specifically mention the 'fiel' atom, but that doesn't necessarily mean its disallowed..
[16:51] <JEEB> various brands have various feature sets
[16:51] <JEEB> f.ex. QT does have some brands of its own
[16:51] <JEEB> which then follow qtff
[16:51] <JEEB> just like DTS and Dolby have their own, too
[16:51] <JEEB> "oh ze joy"
[16:52] Action: michaelni fails to find a single mp4 with fiel except what ffmpeg generates now
[16:54] <TimNich> If I put proves in mp4 with QTPro I get a fiel atom
[16:55] <JEEB> check the brands written
[16:55] <TimNich> s/proves/prores/
[16:57] <TimNich> QTPro brand QT compatible QT&..
[16:57] <nevcairiel> why would something like h264 get a fiel atom anyway?
[16:58] <TimNich> quite, why should it need it? but then why should Prores need it. they all have the infer in the stream parameters anyway...
[16:58] <nevcairiel> i have no idea about prores, just know that h264 has it :D
[16:59] <michaelni> so write fiel if mov || prores ?
[16:59] <TimNich> nevcairiel: btw the file is in trak->mdia->stbl->stsd
[16:59] <nevcairiel> there are a lot more formats that will probably get it
[17:00] <TimNich> I think the matrix is more complicated than that
[17:01] <michaelni> what about write if !h264 && !mpeg4
[17:02] <michaelni> mpeg4-asp video that is
[17:04] <michaelni> id like to avoid it for at least things like ipod and other hw player specific files
[17:05] <michaelni> i doubt it will do any good to them ...
[17:06] <TimNich> The problem I see is that for .mov it is only mandated for raw video *but* included in other formats that shouldn't need it (like Prores) while similar formats, like DNX don't use it. The big question is does its presence do any harm? It should be silently ignored by applications that do not want or expect it, but can we garuantee that?
[17:07] <nevcairiel> sadly plenty applications arent smart enough to simply ignore unknown data, but tend to explode
[17:09] <michaelni> also theres the case that what fiel says differs from what the codec stream says where it can store it like h264
[17:10] <TimNich> I think thats important and afaik untested, which is why I wanted to do extensive testing on DX before being completely happy.
[17:12] <TimNich> If the section of mov.c with all those 'if else' was turned into a set of 'case' sections it would be easier to fine tune, and only add in codecs as needed.
[17:22] <durandal_1707> nobody working on bitexact dirac?
[17:24] <kierank> dirac is largely dead
[17:24] <durandal_1707> as codec?
[17:25] <kierank> yes
[17:25] <kierank> jpeg2k is all the rage
[17:26] <TimNich> this week at least....
[17:28] <durandal_1707> someone from libav is working on fully working native decoder, i think i had cotact with repo but i forgot where it was
[17:28] <michaelni> TimNich, dnxhd has fiel or no fiel ?
[17:30] Action: Compn tried to tell people about reinventing dirac a) before it was finished and b) before there were even samples / codec was used
[17:30] <Compn> no one listens to me :P
[17:30] <TimNich> dnxhd has no fiel in my "genuine" samples
[17:30] <michaelni> ok, thx
[17:31] <TimNich> got to go now back tomorrow
[17:33] <durandal_1707> vf_transpose have interesting way to detect number of data[planes]
[17:50] <cone-893> ffmpeg.git 03Michael Niedermayer 07master:405cc0d90520: movenc: hotfix, dont store fiel for h264 / mpeg4-asp / dnxhd
[17:50] <cone-893> ffmpeg.git 03James Almer 07master:8c95d177dfa9: fate: Add encrypted tta stream test
[19:11] <durandal_1707> i cant use ffplay with -filter_complex?
[19:25] <llogan> durandal_1707: "Set noise seed for pixel component or all of them" <- this phrase doesn't make sense to me. what is "them"?
[19:27] <durandal_1707> all pixel components
[19:32] <llogan> "Set noise seed for specific pixel component of all pixel components" or something would be more clear to lusers like me
[19:32] <llogan> s/of/or
[19:32] <iive> how about "set noise seed for one or all pixel components" ?
[19:34] <llogan> "set noise seed for all-one, all-one, all-one: all-one or none" (can you guess the reference?)
[19:38] <iive> nope
[19:46] <durandal_1707> i think i will add float and double pixel format
[19:52] <llogan> iive: some weird-ass hippy soap in the US. Dr. Bronners.
[19:54] <iive> oh, i guess they haven't ported it to EU market yet.
[19:56] <ubitux> durandal_1707: i've been away for a while and saw a lot of activity from you, are you waiting for some particular review?
[20:11] <durandal_1707> ubitux: yes, unsharp, kerndeint and tinterlace removal from mp
[20:17] <durandal_1707> ubitux: there is also trivial overlay patch that adds yuv444p but it somehow is broken with ffplay, because it inject strange conversion in middle of chain, breaking chroma values
[20:18] <durandal_1707> dunno if that is lavfi bug
[20:22] <ubitux> michaelni: do you expect someone to check all the hash or you're waiting for more general reviews?
[20:22] <ubitux> durandal_1707: about unsharp and tinterlace, dunno
[20:22] <ubitux> about kerndeint i had a relative performance concern, which i wasn't really able to understand
[20:23] <ubitux> i have no idea when i'll have time to look again at it
[20:23] <ubitux> i'm not sure to be the best person for the yuv444p thing; i think i've actually already expected a similar problem with ffplay
[20:28] <michaelni> ubitux, dunno, i had no specific expectattions
[20:28] <ubitux> sorry i'm not motivated to check every single hash :))
[20:29] <michaelni> :)
[20:29] <michaelni> they should be ok
[20:29] <michaelni> version numbers are trickier to lookup so higher chance that theres a wrong one in it
[20:30] <michaelni> i mean version numbers are not unique before we added .100
[20:30] <michaelni> also there are typos in the file
[20:36] <cone-893> ffmpeg.git 03Michael Niedermayer 07master:ad6802f975a9: apichanges: fix date
[20:36] <cone-893> ffmpeg.git 03Michael Niedermayer 07master:33d6330652c0: apichanges: Use , instead of / to seperate multiple hashes
[20:55] <durandal_1707> ubitux: also you may review noise
[21:42] <cone-893> ffmpeg.git 03Michael Niedermayer 07master:2f3bc5122822: apichanges: fix 2 wrong hashes
[21:43] <cone-893> ffmpeg.git 03Vignesh Venkatasubramanian 07master:ce6a8e5947ca: Adding AlphaMode element to Matroska Parser
[21:49] <ubitux> durandal_1707: ok, i'm having a look
[22:16] <ubitux> michaelni: i won't make any more review for APIChanges, so you can consider it a LGTM from me
[22:51] <durandal_1707> ubitux: filters that use filter_complex need PRESERVE?
[22:53] <ubitux> filters that use filter_complex?
[22:53] <ubitux> what does that mean?
[22:54] <ubitux> i'm not familiar with the preserve thing btw
[22:54] <durandal_1707> filter that operates on > 1 buffers
[22:54] <durandal_1707> one need to queue such buffs
[22:55] <durandal_1707> i encountered problem with my filter if i use 2 images as inputs i will get nothing as output
[22:56] <durandal_1707> may not be related to it at all
[22:56] <ubitux> that's what i was going to say
[22:58] <ubitux>     * Filters that intend to keep a reference after the filtering process
[22:58] <ubitux>       is finished (after filter_frame returns) must have the PRESERVE
[22:58] <ubitux>       permission on it and remove the WRITE permission if they create a new
[22:58] <ubitux>       reference to give it away.
[22:58] <ubitux> next point might be related too
[23:02] <ubitux> divVerent: ping
[23:11] <cone-893> ffmpeg.git 03Clément BSsch 07master:cf8dec7d6421: lavfi/showspectrum: pretty-align constants.
[23:11] <cone-893> ffmpeg.git 03Clément BSsch 07master:022437518086: lavfi/showspectrum: simplify intensity_color_table declaration.
[23:47] <cone-893> ffmpeg.git 03Clément BSsch 07master:35a995f4518a: doc/resampler: fix two typo.
[23:47] <cone-893> ffmpeg.git 03Clément BSsch 07master:d5ce725cb32b: Fix a few "its" vs "it's" typo.
[23:59] <cone-893> ffmpeg.git 03Michael Niedermayer 07master:c3fb20bab4f0: ffmpeg: Check for parameter changes at the output of the audio filter graph
[00:00] --- Fri Feb 15 2013