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

[burek]

[01:33] <cone-349> ffmpeg.git 03Michael Niedermayer 07master:3819db745da2: avcodec/rpza: Perform pointer advance and checks before using the pointers
[09:53] <cone-987> ffmpeg.git 03Stefano Sabatini 07master:eadb3ad7580a: lavf/tee: initialize ret in parse_bsfs()
[11:22] <zidanne> Range header in http.c triggers a bug on some icy (shout cast) servers.
[11:22] <zidanne> When I comment out Accept and Range headers in http.c, it connects to problematic servers successfully.
[11:35] <wm4> zidanne: what bugs?
[11:35] <zidanne> ok, you can try it:
[11:42] <zidanne> http://pastebin.com/V9vnXRFN
[11:43] <wm4> zidanne: what, both Accept and Range?
[11:44] <zidanne> I didn't try commenting out just 1 yet. (I commented out both headers till now). Probably Range is the responsible one. I am trying it now.
[11:47] <zidanne> ok
[11:47] <zidanne> I tried it an the problem is only at "Range:" header
[11:47] <zidanne> Server does not like "Range: bytes=0-\r\n"
[11:48] <wm4> it shouldn't be needed (if offset is 0), but according to the code comment, it's to detect seekability with some broken servers
[11:49] <wm4> but if this makes some other servers not work at all, this probably shouldn't be done
[11:49] <wm4> zidanne: what exactly is happening? here, it doesn't close the connection, just gets... stuck
[11:49] <wm4> maybe a workaround is possible
[11:49] <zidanne> I tried wireshark 
[11:49] <zidanne> server stops replying
[11:50] <zidanne> and ffmpeg hangs at poll()
[11:50] <zidanne> ffmpeg hangs on waiting for data.. it never comes from the server..
[11:50] Action: Daemon404 likes seeing giant lists of avfilter deprecation warnings
[11:53] <wm4> zidanne: see commit f0bb88e2bc8b20e0181
[11:54] <wm4> of course it doesn't say details
[11:54] <wm4> because, as we all know, commit message bytes are scarce and valuable
[11:55] <wm4> zidanne: looks like you could set the seekable option to 0
[11:56] <wm4> I'd rather have it work with all servers by default, and require setting seekable to 1 for servers where we misdetected seekability
[12:03] <zidanne> what did you change? I couldn't find the change
[12:06] <wm4> try ffplay http://95.211.60.38:6004 -seekable 0
[12:07] <zidanne> so, no change in the code, we have to specifically add seekable 0 to options.
[12:08] <zidanne> Maybe seekable could be 0 as default. You may not want to seek by default but play by default (for remote streams).
[12:09] <zidanne> (but I understand that this can be a breaking change...)
[12:12] <wm4> no, as I explained above, if the offset is 0, the Range header is sent only to determine seekability with some broken (?) servers
[12:12] <wm4> but this in turn breaks connecting to your icy server
[12:13] <wm4> maybe the problem can be worked around by changing the order of sent headers? after all, the icy server (or http.c) doesn't disconnect, just gets stuck somehow
[12:16] <zidanne> if changing the order changes things (It shouldn't according to http protocol definition), it means that the developer of icy server did not implemented http protocol correctly.
[12:18] <wm4> a correct implemented http protocol doesn't just freeze after sending headers either
[12:20] <zidanne> I tried to contact the developer but no response yet& I will add seekable 0 to options parameter of my avformat_open_input
[12:20] <zidanne> thanks, this at least solves the problem in my scenario where I really don't need seekability in my specific situation.
[12:54] <durandal_1707> ffmpeg still picks for filter gray format instead rgb when input is pal8
[12:57] <durandal_1707> and it looks like if filter supports gbrp chain will still pick yuv444p
[13:02] <cone-987> ffmpeg.git 03Paul B Mahol 07master:139a98be8e2c: lavfi/gradfun: support gbrp
[13:08] <cone-987> ffmpeg.git 03Diego Biurrun 07master:0b45269c2d73: x86: h264_idct: Remove incorrect comment
[13:08] <cone-987> ffmpeg.git 03Michael Niedermayer 07master:503aec142526: Merge commit '0b45269c2d732d15afa2de9c475d85fcf5561ac4'
[13:11] <durandal_1707> git br
[13:14] <cone-987> ffmpeg.git 03Rafaël Carré 07master:4622f11f9c83: w32pthread: help compiler figure out undeeded code
[13:14] <cone-987> ffmpeg.git 03Michael Niedermayer 07master:221a99aae767: Merge commit '4622f11f9c83db8a2e08408c71ff901826ca652c'
[13:42] <cone-987> ffmpeg.git 03Clément BSsch 07master:f8ef91ff3d6b: movenc: add faststart option for web streaming
[13:42] <cone-987> ffmpeg.git 03Michael Niedermayer 07master:d68adbd666cb: Merge commit 'f8ef91ff3d6bb83d601d816ef9368f911021c64b'
[14:03] <cone-987> ffmpeg.git 03John Stebbins 07master:fe5d5a8ffcaf: movenc: Make chapter track QuickTime compatible
[14:03] <cone-987> ffmpeg.git 03Michael Niedermayer 07master:606a30c5a115: Merge commit 'fe5d5a8ffcafdc14c0d26eaea6464c89e120cc9e'
[14:21] <cone-987> ffmpeg.git 03Clément BSsch 07master:60198742ff85: movenc: fix detection of 64bit offset requirement
[14:21] <cone-987> ffmpeg.git 03Michael Niedermayer 07master:25e4ec6aa14d: Merge commit '60198742ff851f11a3757c713fc75a9c19b88566'
[14:28] <cone-987> ffmpeg.git 03Stefano Sabatini 07master:7af7b45c3802: lavf/image2: extend start_number range to accept zero
[14:34] <cone-987> ffmpeg.git 03Diego Biurrun 07master:e7b31844f68e: x86: Split DCT and FFT initialization into separate files
[14:34] <cone-987> ffmpeg.git 03Michael Niedermayer 07master:f903b4266381: Merge remote-tracking branch 'qatar/master'
[14:35] <michaelni> ubitux, mateo` , if you have time please check the past few days changes introduced to mov*c by the merges
[14:38] <ubitux> i'm slightly concerned about the co64_required() simplification
[14:38] <ubitux> that might be correct but..
[14:38] <michaelni> ubitux, dont hesitate to undo/revert it if you think theres an issue
[14:38] <ubitux> i need to look a bit more closely
[14:42] <ubitux> my main concern being that i'm not convinced about the tracks being ordered properly in every situation
[14:43] <ubitux> but well it's been a long time i haven't look at this stuff
[15:08] <mateo`> michaelni: i'll take a look at it this week-end (no time until then)
[15:13] <mateo`> ubitux: they picked up your patch ?
[15:14] <ubitux> they cherry-picked the faststart patchset, but did a few changes
[15:15] <mateo`> have they mentionned why ?
[15:15] <ubitux> because it makes the code is simpler, there is a discussion on their ml
[15:15] <ubitux> but i didn't read it closely
[15:15] <mateo`> ok good
[15:18] <durandal_1707> michaelni: why 2850 is not closed?
[15:22] <durandal_1707> what about all this license violation bugs?
[15:37] <durandal_1707> why 1900 is not fixed?
[16:46] <cone-987> ffmpeg.git 03Paul B Mahol 07master:6e643239d995: pngdec: frame multithreading support
[17:08] <cone-987> ffmpeg.git 03Paul B Mahol 07master:b1e276f8df25: lavfi/hue: allow changing brightness
[00:00] --- Fri Aug 23 2013