[Ffmpeg-devel-irc] ffmpeg-devel.log.20130529
burek
burek021 at gmail.com
Thu May 30 02:05:02 CEST 2013
[00:30] <cone-342> ffmpeg.git 03Michael Niedermayer 07master:c37d735c1cab: jpeg2000dec: mct_decode: remove unused return
[00:30] <cone-342> ffmpeg.git 03Michael Niedermayer 07master:a510abd5d1f5: j2kdec:merge mct_decode from jpeg2000
[00:30] <cone-342> ffmpeg.git 03Michael Niedermayer 07master:83fd377c94d8: j2k/jpeg2000: merge float DWT and related code
[00:34] <michaelni> BuxiNess, btw if theres any change in jpeg2000 from me that you think is bad dont hesitate to tell me to revert/change it ...
[00:45] <BuxiNess> michaelni, I 'll take the time to reread all the patches in details. After quick review sounds good
[01:08] <durandal11707> michaelni: when next merge strom is comming?
[01:08] <durandal11707> *storm
[01:09] <durandal11707> just don't split wavpack muxer....
[01:09] <durandal11707> one is enough
[02:50] <cone-342> ffmpeg.git 03Michael Niedermayer 07master:93b1281264b8: vc1dec: Shuffle field MVs after decoding, not before
[02:50] <cone-342> ffmpeg.git 03Michael Niedermayer 07master:4f4c91d47487: Merge commit '93b1281264b87961f53c3e9c134cc2727ecd91ed'
[03:17] <cone-342> ffmpeg.git 03Michael Niedermayer 07master:28243b0d35b4: vc1dec: Redesign the intensity compensation
[03:17] <cone-342> ffmpeg.git 03Michael Niedermayer 07master:28923f1923ba: Merge commit '28243b0d35b47bbf9abbd454fc444a6e0a9e7b71'
[03:36] <cone-342> ffmpeg.git 03Michael Niedermayer 07master:3ced06f28388: vc1dec: Implement intensity compensation for vc1_interp_mc()
[03:36] <cone-342> ffmpeg.git 03Michael Niedermayer 07master:5053a9a1ffd9: vc1: Use shuffled use_ic instead of equally shuffled mv_mode
[03:36] <cone-342> ffmpeg.git 03Michael Niedermayer 07master:b412f705b58e: vc1dec: Drop old use_ic code from vc1_b_mc
[03:36] <cone-342> ffmpeg.git 03Michael Niedermayer 07master:c69765a2ccc6: vc1dec: Fix doxy for vc1_mc_4mv_chroma4()
[03:36] <cone-342> ffmpeg.git 03Michael Niedermayer 07master:1be175f929b9: vc1dec: Handle top and bottom blocks in vc1_mc_4mv_chroma4() differently if needed
[03:36] <cone-342> ffmpeg.git 03Michael Niedermayer 07master:17410faa22a9: vc1dec: Match addressing between compensation and MC in vc1_mc_4mv_chroma4
[03:36] <cone-342> ffmpeg.git 03Michael Niedermayer 07master:d8b9dbe7768c: vc1dec: Fix mixed field/frame intensity compensation
[03:36] <cone-342> ffmpeg.git 03Michael Niedermayer 07master:728214992e36: vc1dec: Remove interlaced warning
[03:36] <cone-342> ffmpeg.git 03Michael Niedermayer 07master:a58e10e5d1e9: Merge commit '728214992e3698305550c1762f973d2ac567f016'
[04:01] <cone-342> ffmpeg.git 03Kostya Shishkov 07master:3b03d7e251ff: dxtory v2 support
[04:01] <cone-342> ffmpeg.git 03Kostya Shishkov 07master:6647aa0426e7: indeo4: add missing Haar and slanted transforms
[04:01] <cone-342> ffmpeg.git 03Michael Niedermayer 07master:ca90ca8ce365: Merge commit '6647aa0426e73839b9b1d1c9d86188f469167531'
[04:08] <cone-342> ffmpeg.git 03Kostya Shishkov 07master:2cf5d291104d: indeo4: reuse context block VLC for band instead of defaulting
[04:08] <cone-342> ffmpeg.git 03Martin Storsjö 07master:4a27a52a1f74: fate: Don't use files from SRC_PATH in the actual tests
[04:09] <cone-342> ffmpeg.git 03Michael Niedermayer 07master:e755c8ac462e: Merge commit '4a27a52a1f74016095b7aee1b4a422cf62217ade'
[04:29] <cone-342> ffmpeg.git 03Martin Storsjö 07master:ba13606ca6ad: fate: Add a --target-samples path parameter
[04:29] <cone-342> ffmpeg.git 03Michael Niedermayer 07master:1f5e5d2205df: Merge commit 'ba13606ca6adbc74b4db4a72b0769397d6408791'
[04:37] <cone-342> ffmpeg.git 03Luca Barbato 07master:0ba49d28a1c5: configure: support gcc-4.8 instrumentation
[04:37] <cone-342> ffmpeg.git 03Anton Khirnov 07master:78f75b6fa421: wavpack: extract sample rate from the bitstream
[04:37] <cone-342> ffmpeg.git 03Michael Niedermayer 07master:8543575cc4e2: Merge commit '78f75b6fa421dd39a715588e9487579f1ce5bada'
[04:43] <cone-342> ffmpeg.git 03Anton Khirnov 07master:7d039e70a5ff: wavpack: extract channel information from the bitstream
[04:43] <cone-342> ffmpeg.git 03Michael Niedermayer 07master:4d2825a31719: Merge commit '7d039e70a5ff23a7deaa866684d2e8872acc5169'
[05:18] <cone-342> ffmpeg.git 03Anton Khirnov 07master:eae1b8451a4d: wavpack: check that there aren't too many blocks per packet
[05:18] <cone-342> ffmpeg.git 03Anton Khirnov 07master:89806691b1c3: wavpack: check that all the channels were coded.
[05:18] <cone-342> ffmpeg.git 03Michael Niedermayer 07master:7a2edcf1c8d4: Merge commit '89806691b1c39181c63d95e0fddc30f11e2a7b04'
[09:43] <mateo`> adding a covert art to a random mp3 file via iTunes (covert art show up), remuxing this file with ffmpeg (covert won't show up anymore even if id3 tags tsse and apic are the same), comparing the id3 data between the two files show up that itunes add pading bytes at the end of the data ... but not specify it in the ID3 headers ...
[09:44] <mateo`> writing the same amount of null bytes after the apic frame via ffmpeg and ... the covert art show up ...
[09:44] <mateo`> that sounds ... fishy :(
[09:46] <mateo`> also works with aiff files ...
[09:46] <mateo`> any clues about what is going on there ?
[09:58] <ubitux> mateo`: iTunes wants some padding bytes after the apic?
[10:00] <mateo`> to sum up the situation, apic at the beginning follow by some tags = ok
[10:01] <mateo`> only apic = not ok
[10:01] <cone-452> ffmpeg.git 03Anton Khirnov 07master:0a1a94450a28: lavf: rename wv.c to wvdec.c
[10:01] <cone-452> ffmpeg.git 03Michael Niedermayer 07master:ad649e829d6a: Merge commit '0a1a94450a28eef854162f859e79ecfb9f97915b'
[10:01] <mateo`> only apic with some padding = ok
[10:01] <mateo`> tags + apic at the end + padding = ok
[10:01] <durandal_1707> padding to what?
[10:01] <ubitux> "Support for iTunes ID3 spec violations regarding multiple APIC frames"
[10:02] <ubitux> (random Changelog entry of a random app)
[10:02] <mateo`> i saw that one ... i don't think it's related
[10:02] <durandal_1707> but what padding you need to add?
[10:03] <mateo`> i have to found it out, a just added a random amount from a file tagged by itunes
[10:04] <durandal_1707> and random amount is fixed and works for different APIC sizes?
[10:04] <mateo`> yes ...
[10:07] <durandal_1707> hmm so it looks like it only needs padding if APIC is last
[10:08] <durandal_1707> well, i really don't care what workaround is picked
[10:09] <mateo`> files generated by beatport also have this padding at the end ... (even if apic is at beginning)
[10:10] <ubitux> how many bytes is that?
[10:10] <ubitux> approximately
[10:10] <mateo`> 10k bytes ~
[10:11] <mateo`> i will compare the id3 size and padding size on all the samples i have
[10:11] <mateo`> damn ...
[10:11] <ubitux> oh then it's just to ease editing
[10:11] <mateo`> i guess
[10:11] <cone-452> ffmpeg.git 03Anton Khirnov 07master:794ca87d2bff: wvdec: split block header parsing into a separate file
[10:11] <cone-452> ffmpeg.git 03Michael Niedermayer 07master:53015bb3b340: Merge commit '794ca87d2bff2513118de8b97595b3e23070e67d'
[10:15] <mateo`> damn ... this is pure bullshit :(
[10:16] <ubitux> ffmpeg is still able to read the id3 tags & apic even with that padding, right?
[10:16] <mateo`> yes
[10:19] <ubitux> that problem is only reproducible with aiff?
[10:19] <mateo`> aiff and mp3
[10:19] <ubitux> do we have a format where it works?
[10:20] <mateo`> using id3 tags ... i don't think so
[10:21] <mateo`> itunes also supports m4a for audio but it uses qtags
[10:21] <mateo`> (and this is another problem, i probably gonna fix)
[10:30] <mateo`> adding a minimum of 4 padding bytes after apic does the trick.
[10:31] <mateo`> which correspond to the size of a frame tag name ...
[10:34] <ubitux> also, "Four horses (quadriga) is the maximal number of horses in one row for carriage."
[10:34] <ubitux> no need to thank me
[10:35] <mateo`> :D
[10:35] <mateo`> it's clear now :D
[10:36] <mateo`> so ... writing apic before the other is a solution, mp3 muxer should be patched as well
[10:36] <mateo`> the encoder metadata seems to be always written by ffmpeg
[10:37] <ubitux> not with -bitexact flag iirc
[10:37] <mateo`> ok
[10:41] <ubitux> but i still don't get it
[10:41] <durandal_1707> its bug in ilunes
[10:41] <mateo`> only apic = not ok
[10:41] <mateo`> apic + 4 bytes padding = ok
[10:42] <ubitux> ooh
[10:42] <mateo`> apic + rest of metadata = ok
[10:42] <mateo`> metadata + apic = not ok
[10:42] <mateo`> metadata + apic + 4 padding bytes = ok
[10:42] <durandal_1707> metadata + apic + metadata = ok
[10:42] <ubitux> and there is the same bug in the other apps you mentioned?
[10:43] <durandal_1707> what about: apic+metadata+apic+apic+metadat .... (you got idea....)
[10:43] <mateo`> ubitux: yes
[10:43] <ubitux> weird
[10:43] <durandal_1707> what other apps?
[10:43] <mateo`> durandal_1707: i should craft a sample first ...
[10:43] <durandal_1707> mateo`: dont wast time....
[10:44] <mateo`> traktor / serato / torq (djing softwares)
[10:44] <durandal_1707> *waste
[10:44] <durandal_1707> perhaps they all use same lib for id3 parsing....
[10:44] <mateo`> wild guess, taglib ?
[10:45] <mateo`> c++ most popular tagging library
[10:45] <mateo`> since all those software are written in c++
[10:47] <durandal_1707> how i can put APIC back when muxing?
[10:48] <mateo`> you mean muxing including an apic frame ?
[10:50] <durandal_1707> yes
[10:51] <cone-452> ffmpeg.git 03Anton Khirnov 07master:01656fd47694: matroskaenc: support muxing WavPack
[10:51] <cone-452> ffmpeg.git 03Anton Khirnov 07master:88de0c7901ee: apetag: add support for writing APE tags
[10:51] <cone-452> ffmpeg.git 03Anton Khirnov 07master:2d2d6a488347: lavf: add a raw WavPack muxer.
[10:51] <cone-452> ffmpeg.git 03Michael Niedermayer 07master:d9cde3976c19: Merge commit '2d2d6a4883479403798f4ed46941d5b365823570'
[10:51] <durandal_1707> well -c copy looks to work
[10:51] <mateo`> just map any video streams you like to the output files, the first frame of each streams will be picked
[10:52] <mateo`> if you're file already have apic frames it will be considered as a video stream
[10:53] <durandal_1707> michaelni: you overwrite my code
[10:55] <durandal_1707> don't worry, i will fix that
[10:58] <mateo`> ubitux: i'm not a huge fan of adding an abritrary number of padding bytes (without specifying it in the id3 header)
[11:15] <cone-452> ffmpeg.git 03Janne Grunau 07master:bf20cdbd86b1: mpeg12: skip frames consistently
[11:15] <cone-452> ffmpeg.git 03Martin Storsjö 07master:9f30fb5a773d: configure: Don't pass -mthumb or -march= to MSVC
[11:15] <cone-452> ffmpeg.git 03Michael Niedermayer 07master:200ef1e3c389: Merge commit '9f30fb5a773d59298d8d45c741b3fd971d84c97b'
[11:17] <mateo`> durandal_1707, ubitux: do you think trying to write APIC frames at beginning of ID3 metadata is "good" enough for aiff and mp3 muxers ?
[11:17] <mateo`> i'd like to avoid writing padding bytes if possible
[11:18] <durandal_1707> i don't care, so it is "good" enough for me to write APIC first
[11:18] <ubitux> if you have APIC and no metadata, it doesn't work, right?
[11:23] <mateo`> ubitux: yes
[11:25] <cone-452> ffmpeg.git 03Martin Storsjö 07master:d7b9b66abb25: fate.sh: Allow specifying --as via a specific variable
[11:25] <cone-452> ffmpeg.git 03Martin Storsjö 07master:a51161ed9892: doc: Mention the target_samples and ld variables for fate configs
[11:25] <cone-452> ffmpeg.git 03Michael Niedermayer 07master:4ea5aea86903: Merge remote-tracking branch 'qatar/master'
[11:25] <mateo`> or in id3v2[...]finish, check if last written frame is APIC by setting a flag set when write_metadata / write_apic are called
[11:26] <mateo`> and then decide to write or not 10 padding bytes ...
[11:26] <durandal_1707> that looks complicated
[11:26] <mateo`> not that much ... but i don't like it
[11:27] <mateo`> + possible option -crappy_id3_itunes_fix to overwrite normal default behaviour ...
[11:28] <durandal_1707> even more complicated...
[11:28] <durandal_1707> just add padding with comment
[11:29] <ubitux> mateo`: what about fixing taglib in the meantime?
[11:29] <mateo`> ubitux: assuming tagline if faulty
[11:29] <mateo`> -ne+b
[11:31] <mateo`> durandal_1707: sounds good
[11:34] <durandal_1707> i have latest taglib here, and examples/framelist shows APIC, i'm not interested experimenting more
[11:36] <mateo`> ok
[11:37] <durandal_1707> so its still possible they use taglib, but some older buggy version...
[11:42] <mateo`> should i write a meaningful amount of padding byte (to ease future editing ~ 1k bytes) or something like 10 bytes is ok ?
[11:43] <durandal_1707> what future editing?
[11:44] <mateo`> future editing by iTunes or Dj softwares
[11:44] <mateo`> i personally don't care, I just want the covert art to show up :)
[11:50] <durandal_1707> iirc there is special tag for padding
[11:51] <durandal_1707> is it?
[11:52] <durandal_1707> now if i run just fate-flac it fails...
[11:52] <durandal_1707> michaelni: ^ something get broken recently?
[11:53] <mateo`> durandal_1707: there is no padding tag afaik, just 0s ...
[12:02] <michaelni> durandal_1707, "make fate-flac" no failure here
[12:21] <durandal_1707> mateo`: just pick random number
[12:22] <mateo`> durandal_1707: 10 ^^
[12:22] <durandal_1707> 42
[12:22] <mateo`> size of an id3 frame header ... just in case :D
[12:23] <t4nk629> the command line I use: ffmpeg -f video4linux2 -r 30 -s 640x480 -input_format mjpeg -i /dev/video0 -vcodec copy http://localhost:8090/feed1.ffm after trace ffmpeg code, I see in do_streamcopy(), do_streamcopy() will call write_frame(), and next write_frame() will call av_interleaved_write_frame(), I do not see the code about socket write. Because I see ffserver will keep receive data from socket. Does anyone have idea about
[12:23] <t4nk629> where is the code that help ffmpeg to send data to ffserver?
[12:23] <t4nk629> any ideas?
[12:24] <durandal_1707> if by "socket" code you mean protocols they are in libavformat
[12:31] <cbsrobot> durandal_1707: spent too much time with tiff lately &?
[12:33] <durandal_1707> cbsrobot: too much? not at all...., i spent very little time on tiff
[12:34] <cbsrobot> the 42 reminded me of tiff
[12:35] <t4nk629> I see the flow , ffmpeg donot write data to socket, it call av_interleaved_write_frame()
[12:36] <durandal_1707> cbsrobot: yes, tiff use that as header (useless)
[12:36] <t4nk629> in /libavformat/fmdec.c, function ffm_read_packet(), case READ_DATA: size = AV_RB24(ffm->header + 2); the value of size is very very large, then ffm_is_avail_data() will return EAGAIN,
[12:37] <t4nk629> ffserver will stay in this condition always , then no any data can be output
[12:37] <durandal_1707> t4nk629: didn't we already had this talk yesterday on #ffmpeg, and you said that via ethernet it works
[12:37] <t4nk629> ffserver hangs when feeding it via http
[12:38] <t4nk629> yes, it is more stable via ethernet,
[12:39] <t4nk629> I would like to get point about where ffmpeg send data to ffserver
[12:39] <t4nk629> because I see ffserver call recv to get video data
[12:39] <t4nk629> the source address is 127.0.0.1
[12:39] <durandal_1707> it may be because of latency that it happens
[12:39] <durandal_1707> t4nk629: it never happens on localhost?
[12:40] <t4nk629> what localhost case?
[12:40] <durandal_1707> localhost is 127.0.0.1
[12:40] <t4nk629> when I use the vlc client to get video stream, then it may get problem that I memntioned
[12:41] <durandal_1707> even via 127.0.0.1?
[12:42] <t4nk629> on my embedded system
[12:42] <t4nk629> i can not do that
[12:42] <t4nk629> I do not have video streame player on my embedded system
[12:42] <cone-452> ffmpeg.git 03Paul B Mahol 07master:96db307b3d4e: lavf/flacenc: use ffio_fill()
[12:43] <t4nk629> ffio_fill?
[12:47] <t4nk629> anybody know:why ffserver use "recv" system call to get video data from ffmpeg?
[12:54] <t4nk629> Is there someone familiar with the source code ffmpeg.c ffserver.c?
[12:54] <t4nk629> Could you kindly help to give hints?
[12:54] <t4nk629> Help, please!
[12:56] Action: durandal_1707 not familiar with source code of: ffmpeg.c, ffserver.c, libswscale
[13:04] <t4nk629> Or is anyone have idea how to debug :invalid stream index problem?
[13:04] <t4nk629> the log from ffserver:
[13:04] <t4nk629> Wed May 29 19:02:04 2013 [ffm @ 0x664a20]invalid stream index 26 Wed May 29 19:02:04 2013 [ffm @ 0x664a20]invalid stream index 31
[13:22] <burek> -shortest:a alone would not work if the video was shorter than audio, so i've corrected that
[13:22] <durandal_1707> yes... ffmpeg accepted :a for some reason ....
[13:23] <burek> :beer: :)
[15:40] <cone-452> ffmpeg.git 03Paul B Mahol 07master:7469be099e90: lavc/tta: use init_get_bits8()
[15:40] <cone-452> ffmpeg.git 03Paul B Mahol 07master:b257d9a01fcc: alac: use init_get_bits8()
[15:51] <cone-452> ffmpeg.git 03Paul B Mahol 07master:30d7dcce4c3f: tiff: add helper function for fill_order case
[15:51] <cone-452> ffmpeg.git 03Paul B Mahol 07master:7984ed87c13d: tiff: support inverted fill_order for packbits compression
[16:27] <durandal_1707> shouldn't flush_packets, added in 4f112a8e3 be below /***** ... ?
[16:30] <cone-452> ffmpeg.git 03Paul B Mahol 07master:be5a55535edd: apetag: do not create invalid APE tags
[16:30] <cone-452> ffmpeg.git 03Paul B Mahol 07master:6d3b913479f2: remove APEv1 tag writer
[16:30] <cone-452> ffmpeg.git 03Paul B Mahol 07master:f46732fe4d2c: wvenc: remove flush call, not needed since 4f112a8e3
[18:56] <cone-452> ffmpeg.git 03Paul B Mahol 07master:83f97355927f: lavfi/noise: support slice threading
[18:56] <cone-452> ffmpeg.git 03Paul B Mahol 07master:f8f42f482181: lavfi/noise: fix out of array access
[19:12] <saste> socis 2013... anybody wanna to mentor/admin?
[19:13] <ubitux> saste: tell me more about mentoring
[19:14] <saste> ubitux, just means to mentor a student: propose a task, select candidates, help the student, track his/her progress and whip at him when he's late
[19:14] <saste> usually with socis there is no money for mentors
[19:15] <saste> and there is usually a single slot
[19:16] <ubitux> i'm fine with mentoring a student
[19:16] <ubitux> if that doesn't mean messing too much with random forms and procedures
[19:19] <durandal_1707> and for task pick something like morfology that is space related....
[19:38] <Daemon404> oh wow i didnt realize msvc's fate had been broken for a month or more
[19:38] <Daemon404> :<
[19:39] <gnafu> Hehe.
[19:39] <ubitux> Daemon404: the two lavfi failing tests are due to a change in the tests themselves iirc
[19:39] <ubitux> so it's showing a previously hidden issue possibly
[19:42] <Daemon404> there are trhee lavf failing tests
[19:42] <Daemon404> three*
[19:43] <ubitux> lavf ?
[19:43] <Daemon404> lavfi
[19:43] <Daemon404> typo.
[19:43] <ubitux> that's what i said
[19:43] <ubitux> the two (new) lavfi failing tests
[19:43] <Daemon404> > the two lavfi failing tests
[19:43] <ubitux> ebur128 bug is older
[19:43] <Daemon404> two -> three
[19:43] <ubitux> and is a bug in msvc
[19:43] <Daemon404> i see
[19:44] <ubitux> (compiler fails on a very obvious and stupid loop)
[19:47] <Daemon404> i remember that now
[19:53] <cone-452> ffmpeg.git 03Michael Niedermayer 07master:c2625c26c5e5: mpegvideo: implement ff_put_h264_chroma_mc1 & ff_avg_h264_chroma_mc2
[20:12] <cone-452> ffmpeg.git 03Michael Niedermayer 07master:0abe923d20db: mpegvideo: fix forgotten lowres op_index limits
[20:13] <cone-452> ffmpeg.git 03Michael Niedermayer 07master:ac025d6eca32: j2kdec: remove unused variables
[20:15] <cone-452> ffmpeg.git 03Paul B Mahol 07master:38fefbc474af: wtvenc: use ffio_fill()
[20:16] <ubitux> ah, ffio_fill even better
[20:16] <durandal11707> ?
[20:17] <ubitux> i suggested another clumsy solution :p
[20:42] <mateo`> ubitux: i thought about your solution before the for loop ... i was thinking about future increase of that padding
[20:42] <mateo`> anyway ffio_fill is what i was looking for :) thx durandal11707
[21:06] <durandal11707> mateo`: you are subscribed to devel ml?
[21:50] <durandal11707> michaelni: what are actually doing with j2k* code? i'm confused little
[21:53] <durandal11707> jpeg2000 have one more progressive order implemented(didn't checked if its correct)
[21:53] <durandal11707> but there are 3 more prog orders to implement
[21:53] <durandal11707> libopenjpegenc wrapper encoder can write such files...
[21:58] <michaelni> durandal11707, iam trying to merge the 2 jpeg2000 decoders into one both support features the other doesnt
[21:59] <durandal11707> so it's almost finished, like 90% ?
[22:00] <michaelni> i suspect theres not much left yes, but i had no time today ...
[22:32] <cone-452> ffmpeg.git 03Reimar Döffinger 07master:dccaad3bcdc5: wamenc: handle failure to encode.
[22:32] <cone-452> ffmpeg.git 03Reimar Döffinger 07master:4c2b3f47382e: Add AV_HASH_MAX_SIZE.
[23:01] <funman> http://article.gmane.org/gmane.comp.video.videolan.vlc.devel/91504
[23:16] <funman> why isn't frame threaded encoding delaying encoded frames instead of blocking ?
[23:18] <funman> should we push several (one per core) frames at once and then call decode_video2 until we get all encoded frames?
[00:00] --- Thu May 30 2013
More information about the Ffmpeg-devel-irc
mailing list