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

[burek]

[00:02] <cone-48> ffmpeg.git 03Dale Curtis 07master:4feca2214a0b: h264: Clear ERContext.cur_pic when unref'ing current picture.
[03:55] <cone-742> ffmpeg.git 03Michael Niedermayer 07master:8a1714ad85dd: ffmpeg: do not fail when options are routed to libavformat and libavcodec and only one can be used
[03:56] <Daemon404> uhhhh shouldnt that at least issue a warning?
[05:11] <cone-742> ffmpeg.git 03James Almer 07master:2c759d7018fa: matroskadec: Export the MuxingApp element value as metadata
[05:36] <michaelni> Daemon404, in the use case that lead to it, -frame_size was causing it and it was specified for the demuxer/decoder side. The problem occured because theres a frame_size for encoders too
[05:37] <michaelni> but noone specified it for encoders so i think it shouldn need a warning
[05:37] Action: michaelni goes to bed, will read log tomorrow
[13:27] <saste> anyone has hints about #3265?
[13:27] <saste> michaelni, what about the fm check in the code?
[13:27] <saste> audio-only seems to work fine
[13:33] <michaelni> saste, seems to be checking for libavformat/ffm* PACKET_ID
[13:34] <michaelni> i dunno that part of the code though so ...
[13:39] <saste> i wonder why it only seems to affect libvpx...
[14:05] <cone-17> ffmpeg.git 03Peter Ross 07master:0588acaffaf6: avformat/bink: seek to first frame
[14:06] <cone-17> ffmpeg.git 03Anssi Hannula 07master:857841c1b63b: avformat/http: always allow no-op seek
[14:06] <cone-17> ffmpeg.git 03Anssi Hannula 07master:9371d70bad2e: avformat/hls: decouple playlists from variants
[14:06] <cone-17> ffmpeg.git 03Anssi Hannula 07master:6275d93d1f19: MAINTAINERS: add myself for spdif* and hls.c
[14:39] <cone-17> ffmpeg.git 03Peter Ross 07master:57cfcbf34776: avformat/bink: display audio track ids
[15:34] <j-b> "HLS provides MPEG TS timestamps via ID3 tags in the beginning of each segment of elementary audio streams." this is a joke, right?
[15:34] <av500> lol
[15:34] <JEEB> lol
[15:37] <cone-17> ffmpeg.git 03Michael Niedermayer 07master:0389f9abe9b1: avcodec/avcodec: document that some video decoders do not support linesizes changing between frames.
[15:41] <Compn> id3 ! of course!
[15:41] <Compn> the best metadata format ever!
[16:07] <Anssi> j-b: I wished it was :/
[16:07] <j-b> Anssi: come on...
[16:31] <kierank_> j-b: wtf
[16:33] <Anssi> (here's the spec paragraph: http://tools.ietf.org/html/draft-pantos-http-live-streaming-12#page-23 )
[16:35] <kierank> Anssi: any idea why?
[16:36] <Anssi> kierank: not really
[16:36] <kierank> why the hell do they need to do that
[16:36] <wm4> ubitux: anything new on the gif encoding front?
[16:38] <Anssi> kierank: well, they had a raw audio stream (no timestamps) and wanted to sync it with an actual MPEG-TS, so they needed timestamps in the raw stream
[16:38] <kierank> then why can't they add timestamps the normal way
[16:42] <Anssi> kierank: you mean not use a raw format?  not sure... maybe they wanted to avoid MPEG-TS overhead but didn't want to use a non-MPEG format so they went with raw + id3 timestamps
[16:42] <kierank> usually you'd just add a PES header
[16:42] <kierank> which isn't that large
[16:43] <kierank> unless they want to hack round the padding requirements at the end
[16:44] <nevcairiel> the timestamps dont apply to the mpeg-ts, but a separate raw audio stream, cant put timestamps in there
[16:45] <Anssi> kierank: right, no idea why they didn't go with that
[16:46] <kierank> nevcairiel: eugh and they can't just multplex that with the ts?
[16:46] <nevcairiel> who knows why they decided what they did
[16:46] <Anssi> kierank: they want to save bandwidth so that client can decide what streams to stream
[16:47] <kierank> i mean they can have a separate TS?
[16:48] <Anssi> kierank: hm, didn't get what you meant
[16:48] <kierank> instead of providing a separate raw audio track with timestamps, just provided another TS file
[16:49] <nevcairiel> that reminds me that i need to implement hls streaming into the media server, i bet that'll be much fun :(
[16:51] <Anssi> kierank: with just the audio or video+audio?  if you mean the former, I guess to avoid TS overhead (I'm not sure how much that is, though),  if the latter, since there may already be X different video options and then Y audio options (and Z subtitle options)
[16:51] <kierank> former
[16:51] <Anssi> the spec allows TS for that though
[16:51] <Anssi> but also raw+id3
[17:06] <cone-17> ffmpeg.git 03Stefano Sabatini 07master:d52dd2430bcd: doc/ffserver: mention how to access streams through RTSP
[17:06] <cone-17> ffmpeg.git 03Stefano Sabatini 07master:d392619a465e: doc/faq: remove "-profile option fails when encoding H.264 video with AAC audio" entry
[17:22] <ubitux> wm4: since last i work on it? no
[17:23] <ubitux> not that i know of at least
[17:23] <wm4> didn't j-b ask about gif encoding?
[17:23] <wm4> anyway, it seems users kind of expect being able to encode color gifs
[17:23] <wm4> but that apparently requires pal8 input
[17:23] <ubitux> huh? oO
[17:24] <wm4> there's also RGB8, but that's pretty useless
[17:24] <ubitux> well at least that's 10x smaller than pan
[17:24] <ubitux> pal*
[17:26] <wm4> also, I have a case where seeking in a mpeg stream doesn't jump to a key frame
[17:26] <wm4> is this expected behavior or should I report a bug?
[17:26] <nevcairiel> mpeg streams dont seek to keyframes in general, the decoder is expected to pick up the pieces
[17:28] <wm4> so it's broken by design on the demuxer level?
[17:38] <nevcairiel> on containers who dont have a keyframe flag on packets, sure, the demuxer simply doesnt know whats in the packets
[17:39] <wm4> doesn't libavformat use all these codec parsers (and sometimes even full decoders) exactly for that reason?
[17:39] <nevcairiel> not for seeking
[17:40] Action: Daemon404 hugs his pre-indexed ffms2
[17:40] <nevcairiel> i suppose it could be rigged up to drop packets until it finds a keyframe, but for complex codecs that would cause much logic duplication
[17:40] <nevcairiel> take h264 with intra-refresh, whats a keyframe?
[17:41] <wm4> there's some functionality in libavcodec to drop "broken" frames
[17:41] <nevcairiel> i once considered all these cases to get more accurate and faster seeks, but a generic solution is really hard
[17:42] <wm4> that gets frames with missing reference frames, but AFAIK also frames that simply are corrupted
[17:42] <nevcairiel> so i spent my time making sure decoders dont output broken frames after any random access into the stream
[17:42] <nevcairiel> its not perfect of course, but much better
[18:19] <cone-17> ffmpeg.git 03Michael Niedermayer 07master:9c5260e73a7a: avutil/mathematics: fix 2 typos in the doxy
[20:13] <ubitux> ok, i can now somehow dicern the original video after the optimized loop filter
[20:13] <ubitux> so it's "starting to work but still broken as shit"
[20:14] <ubitux> assuming there is no major design issue, this is going to bring about 25 fps (175 -> 200) with only the vertical one
[20:17] <ubitux> (thanks the threading ofc)
[21:34] <cone-17> ffmpeg.git 03Michael Niedermayer 07master:950fb8acb42f: avcodec/mpegvideo: fix ac/dc_val and coded_block table sizes
[21:38] <ubitux> oh...
[21:38] <ubitux> now how am i supposed to make add an unsigned byte with a signed byte, with unsigned saturation?
[21:41] <ubitux> basically, clip_u8(u8 ± i8)
[21:44] <nevcairiel> that seems like a weird task
[21:45] <ubitux> tell that to the vp9 authors :(
[21:45] <nevcairiel> maybe there are restrictions that the signed byte will never be negative?
[21:46] <ubitux> no :P
[21:46] <nevcairiel> result of the calculation can be negative and needs to clip to 0?
[21:46] <ubitux> 0-255
[21:46] <ubitux> really, it's just clip_u8(u8 ± i8)
[21:47] <ubitux> (i need to support both add and sub)
[21:47] <nevcairiel> the question is, can u8 be so small that adding a negative i8 would make it negative?
[21:47] <ubitux> yes it can be full unsigned byte range
[21:47] <nevcairiel> well, 16-bit intermediates then, not sure how else to solve it
[21:47] <nevcairiel> but maybe there are some magic tricks
[21:47] <ubitux> eeeh :(
[22:05] <michaelni> ubitux, split the signed bytes in 2 registers one that holds the positive ones and one that holds the negative ones and then just do 2 unsigned saturating add/sub
[22:07] <michaelni> not sure how best to do the split but you have add/sub and min/max available to build it out of
[22:10] <JEEB> hmm, anyone interested at looking at https://trac.ffmpeg.org/ticket/2739 when they have time?
[22:10] <wm4> oh that again
[22:10] <nevcairiel> its ogm, of course not
[22:11] <JEEB> wm4, decided to poke the channel for the first time in X months :D
[22:20] <JEEB> nevcairiel, and yes -- I wish those files didn't exist. Yet they do :<
[22:25] <michaelni> JEEB, where is the file ?
[22:26] <JEEB> I uploaded it onto the sample FTP
[22:26] <JEEB> although I do IIRC have it on a random server if that's gone away by now
[22:26] <michaelni> i think i found it
[22:29] <ubitux> michaelni: mmh ok
[22:30] <Daemon404> ogm you say?
[22:30] <Daemon404> http://chromashift.org/img/%5bAXP%5d-Intro.ogm as usual.
[22:36] <ubitux> 3d, matrix, angels, techno font, fire, gothics
[22:36] <ubitux> what's missing? :))
[22:36] <llogan> naturally it was prepended to some anime
[22:37] <llogan> i imagine he lives in Frankfurt
[22:38] <JEEB> oh yes, the classic intros >_>
[22:58] <Daemon404> llogan: why indeed.
[22:58] <Daemon404> indeed it was.
[00:00] --- Sat Jan  4 2014