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

[burek]

[00:34] <amalia> michaelni I just discussed with marina and she said I can still work on the qualification task until Wednesday 31st (next week)
[00:38] <michaelni> amalia, ok, do you know what to do, has paul or thilo explained all or you prefer to work on some other task than ALS ?
[00:41] <amalia> Neither paul nor thilo has said anything yet. However, I would like to work on this since it's related to the project I am applying for
[00:41] Action: amalia is studying the ALS decoder written by thilo in 2009
[00:42] <amalia> If I could just have some documentation on what the functions do.......
[00:46] <kierank> ALS is not an easy task
[00:46] <amalia> Which is easy kierank ?
[00:47] Action: Jul13t that's probably to test how good the girls are ;)
[00:47] <wm4> rcombs: ERROR 403: Forbidden.
[00:47] <michaelni> yes, also if theres any communication problem with your mentor(s) ... no way for me to guess if there is or not ... it might make sense to edit your application to something else than ALS
[00:47] <wm4> rcombs: on your sample file
[00:47] <rcombs> wm4: uh
[00:47] <michaelni> the yes referfered to "<kierank> ALS is not an easy task"
[00:48] <wm4> rcombs: or wait, it's probably because this terrible dropbox shit checks useragent or cookies
[00:48] <wm4> so getting the direct URL from the browser and then using wget doesn't work
[00:48] <rcombs> works for me in a private browsing window in Chrome
[00:48] <amalia>  So what do I do now michaelni ?
[00:48] <rcombs> I think https://www.dropbox.com/s/32ve4hp567ukikt/Maken-Ki%21%20-%20S01E02.mkv?dl=1 should work with wget
[00:48] Action: Jul13t thinks giving such a task for girls is abit of an overkill
[00:49] <rcombs> just tried; works here
[00:49] <kierank> Jul13t: erm?
[00:49] <rcombs> Jul13t: what?
[00:50] <michaelni> amalia, it depends on you, if you are happy with paul and thilo as mentors and think you can with their help finish the qualification task then just continue otherwise maybe look at our wiki and pick or propose some other project
[00:52] <michaelni> or maybe ask thillo if he could suggest something else as qualification something that is part of the work in december-march for AlS
[00:53] <michaelni> that is if just the choice of the qualification task feels like a problem
[00:59] <michaelni> "<amalia> If I could just have some documentation on what the functions do" <-- about this its best to ask the author of the code, if thats libavcodec/alsdec.c that would be thilo
[01:08] <rcombs> wm4: file downloading fine now?
[01:08] <wm4> rcombs: yes, downloaded it
[01:08] <rcombs> OK, cool
[01:09] <wm4> so to me it looks like it has a seekhead at the start, which merely links to the seekhead at the end
[01:09] <wm4> (inefficient, a player must seek to the end of the file to continue reading the file...)
[01:10] <rcombs> yeah
[01:10] <rcombs> (thus why the sample clip didn't work)
[01:11] <wm4> and I'm not sure what lavf does
[01:11] <wm4> it simply doesn't seek?
[01:11] <wm4> mpv barfs because it doesn't decode audio while skipping video (so the audio packets add up)
[01:12] <rcombs> yeah, it looks like it just doesn't seek
[01:12] <wm4> this probably means libavformat simply returns all packets starting from the start of the file after seeking
[01:12] <wm4> and this is wrong
[01:12] <wm4> it should just skip packets until the target TS is reached
[01:12] <wm4> I suspect this is because of an earlier hack, which made seeking work in files that have timestamps not marked properly
[01:13] <wm4> in any case, libavformat reading the seekhead properly would avoid hitting this bug
[01:13] <rcombs> yup, and that one-line patch does seem to fix it for this case
[01:14] <rcombs> oddly enough, it also makes the sample clip seek as expected
[01:14] <rcombs> and I think that's because the index gets marked as broken (matroska->cues_parsing_deferred = -1;), which triggers different seeking behavior
[01:14] <michaelni> also about easy OPW-FFmpeg projects, "Setting up FATE automated testing system on various platforms" is probably one of the easiest on the wiki ATM and reynaldo wanted to add more non coding tasks today IIRC
[01:15] <wm4> rcombs: if the index is not usable, it should just rebuild it incrementally
[01:16] <rcombs> yeah; so that should probably be the default behavior if no index is found at all, instead of only being triggered if something explicitly fails
[01:16] <wm4> definitely... it doesn't do that?
[01:16] <rcombs> apparently not
[01:18] <ramiro> michaelni: I can mentor FATE as well
[01:19] <wm4> yeah, the simplest solution would be reading the seekheads recursively
[01:19] <amalia> Thanks michaelni
[01:19] <michaelni> ramiro, thats great, please add yourself as mentor for it on the wiki
[01:20] <rcombs> it appears that behavior is triggered by matroska_read_seek returning -1, which only happens if either st->nb_index_entries is 0 (and it's apparently 1 on this file for some reason?) or matroska->cues_parsing_deferred < 0 (which only happens if parsing a Seekhead or Cues fails)
[01:20] <wm4> rcombs: I see only one index (cues) in this file, and they are proper
[01:20] <rcombs> so that behavior could probably improve for actually broken files, but for these (which just have inefficiently-placed Cues), we should just resolve seek heads recursively
[01:21] <wm4> st->nb_index_entries is the generic index though
[01:21] <ramiro> michaelni: done
[01:21] <wm4> sometimes other entries are added to it
[01:21] <wm4> so they don't reflect file contents
[01:21] <wm4> (god, libavformat seeking is terrible)
[01:21] <michaelni> ramiro, thanks
[01:21] <rcombs> wm4: in this case, it's a 0 entry
[01:22] <wm4> an entry pointing to the start?
[01:22] <rcombs> yeah
[01:22] <rcombs> wm4: clip the first 30MB of the file and try seeking in that; you'll see what I mean
[01:22] <amalia> michaelni I think I'll  consider working on that
[01:23] <wm4> rcombs: I don't...
[01:24] <michaelni> amalia, ok, great, btw we not only need fate clients for OS not listed on fate.ffmpeg.org but we also some that are listed new. For example our openbsd is quite a bit outdated. Setting a new one up is probably easier than updating the one we have
[01:24] <rcombs> wm4: without my patch, seeking with -c copy or -copyts in the 30MB clip still doesn't work, because matroska_read_seek finds the single generic 0 index entry, seeks to that, and returns 0
[01:25] <rcombs> wm4: with my patch, it works properly, because it attempts to execute the seekhead and fails (because it points past the end of the clip), and returns -1, which falls back on index-less seeking behavior
[01:27] <amalia> michaelni Please can you add me to the wiki as applicant for this project ?
[01:27] <wm4> ah
[01:28] <michaelni> amalia, its editable by anyone who registers (just needs an email address), you can edit it yourself
[01:28] <michaelni> if theres any problem like with spam filters, ping me
[01:29] <wm4> rcombs: in any case, the behavior for no index should be fixed
[01:29] <rcombs> wm4: right
[01:29] <wm4> rcombs: obviously, this nb_index_entries check is wrong, then
[01:29] <rcombs> right
[01:29] <rcombs> (but we should still execute seek heads recursively)
[01:30] <amalia> Okay michaelni
[01:30] <wm4> rcombs: yes
[01:33] <rcombs> wm4: maybe check matroska->index->nb_elem instead?
[01:34] <wm4> rcombs: looks viable
[01:34] <wm4> but it has to interact well with the lazily read cues
[01:35] <wm4> (I assume matroska->index are the raw cues)
[01:35] <wm4> rcombs: also check whether protection against recursion is needed
[01:35] <wm4> consider a seekhead pointing to itself
[01:36] <wm4> but maybe it actually isn't needed and there are already measures against that
[01:36] <rcombs> yeah, that was the only thing I was really concerned about with this
[01:37] <rcombs> we have a maximum EBML element depth, so that's something
[01:37] <rcombs> so it wouldn't just grow the stack until it overflowed, at least
[01:38] <wm4> is the depth increased even when reading the seekhead? (as opposed to the automatic element reader)
[01:39] <wm4> also, does the code take care of not reading elements twice?
[01:39] <rcombs> yes, it's increased
[01:39] <wm4> the "normal" way to read a matroska file is reading all header elements until the first cluster is reached - and then checking the seekhead for more elements that have not been read yet
[01:40] <amalia> michaelni could you mentor this project ?
[01:40] <rcombs> yup
[01:42] <rcombs> I don't _think_ I see any other protection against re-reading the same element
[01:43] <rcombs> but EBML_MAX_DEPTH isn only 16, so I guess I'm not too concerned about potentially slowing down the parser by looping for a long time
[01:43] <michaelni> amalia, ramiro should have more time, iam always busy, also he did setup and run fate clients and IIRC a fate server, and i think the script that iam using for my fate clients is based on his
[01:44] <michaelni> also iam backup mentor for it if he disappears ;)
[01:44] <rcombs> unless it added itself to the list and returned to the loop, rather than recursing
[01:45] <wm4> rcombs: I suspect reading elements twice just overwrites them
[01:45] <rcombs> wm4: this seems likely, but perhaps we should double-check with someone who knows matroskadec.c better :3
[01:45] <wm4> so reading chapters twice might set matroska->chapters twice, but in the end only the "last" chapters are copied to the av input context
[01:46] <wm4> that is, to AVFormatContext
[01:49] <ramiro> amalia: michaelni is always busy, I'm unemployed, I have much more free time =)
[01:50] <amalia> Okay Great then
[01:50] <amalia> Can you send me your email address
[02:00] <ramiro> michaelni: is there anyone supporting FATE with hardware? would the OPW candidate need to dedicate a box to FATE duty?
[02:05] <michaelni> for the time of the qualification and the main project  i think the candidate needs to have a box locally to work on, doing something like virtualbox remotely is probably rather painfull, that should not need a dedicated box though
[02:09] <michaelni> and once some client is setup and working i imagined we could transfer it to some volunteers box to run long term unless the candidate has a dedicated box or someone donates one and she is ok with maintaining the hw&sw beyond the project
[02:10] <ramiro> michaelni: ok, good.
[02:21] <ramiro> sudo apt-get install -y make build-essential libssl-dev zlib1g-dev libbz2-dev \
[02:22] <ramiro> wrong window =)
[03:13] <cone-16> ffmpeg.git 03Michael Niedermayer 07master:832b4c0a86bc: avcodec/libutvideodec: print extradata size if unsupported
[03:43] <cone-16> ffmpeg.git 03Rodger Combs 07master:315f9e929dc0: ffmpeg_opt: Add -start_at_zero option.
[03:53] <cone-16> ffmpeg.git 03Andrey Utkin 07master:24dfd6e79b41: avformat/rtspcodes: introduce ff_rtsp_averror()
[03:53] <cone-16> ffmpeg.git 03Andrey Utkin 07master:282c9354f135: avformat/rtsp: Use ff_rtsp_averror()
[05:17] <wm4> webvtt in hls? seriously?
[05:19] <Compn> the most buzzwordy named project goes the furthest :p
[06:02] <rcombs> wm4: it's a thing! It's specified! It's implemented in iOS and Safari!
[06:05] <rcombs> (though said implementation appears to be somewhat buggy when seeking&)
[06:06] <wm4> weird
[06:07] <rcombs> the "write empty segments if necessary" bit should be pretty simple; just use a while() instead of an if() on the close/reopen-segments code
[06:07] <rcombs> duplicating lines that span multiple segments is a bit more complicated, but certainly not rocket science
[09:49] <rcombs> anyone know why the hls and segment encoders exist separately?
[09:50] <rcombs> AFAIK there's nothing the HLS encoder can do that the segment encoder can't, and there's a lot of duplicated code there
[09:50] <ubitux> segment was written first, then ffmpeg side added hls support in it, and then libav decided to make a hls muxer separated
[09:50] <rcombs> of course :|
[09:50] <ubitux> (they originated the segment)
[09:51] <nevcairiel> for some reason people submit patches for the hls muxer in ffmpeg as well though
[09:51] <nevcairiel> i use segment myself and it works fine
[09:51] <nevcairiel> since for a long time it had many more features which i actually needed
[09:51] <ubitux> i'm not sure of the motivation of the split and why it wasn't done in segment
[09:51] <rcombs> it seems like the HLS encoder could be implemented (to maintain compatibility) as a thin wrapper around the segment encoder?
[09:51] <rcombs> (to avoid all the duplication)
[09:51] <ubitux> rcombs: i would say so as well
[09:52] <nevcairiel> by now there are a few rather hls specific things in the hls muxer i think, but could still implement them in segment i guess
[09:52] <ubitux> hlsenc is less than 450 lines, it shouldn't be that hard to squash it into segment
[09:52] <ubitux> some way or another
[09:54] <wm4> HLS is the thing with timestamps wrapped in id3v2 for mp3?
[09:54] <ubitux> hls is a .m3u manifest linking to split files
[09:55] <nevcairiel> i think HLS does actually support this mode wm4, but i use it for audio/video in one TS file and no such madness
[09:55] <rcombs> I've never even heard of that ID3 thing you're talking about
[09:55] <nevcairiel> its rather crazy
[09:55] <nevcairiel> because mp3 carries no timestamps, they had to shove timestamps somewhere for audio-only streams to sync them
[09:55] <nevcairiel> so they put them in ID3 tags
[09:56] <rcombs> wat
[09:56] <rcombs> well then, I'll handle work in #4048 as if the HLS encoder didn't exist, and then maybe things could be backported sometime or whatever
[10:00] <ubitux> it seems luca also added hls support in the segment muxer in libav, somehow
[10:00] <rcombs> so we've come full-circle on uselessness!
[10:02] <ubitux> actually, we might not be the one adding hls support, so this is very curious
[10:02] <ubitux> unless i'm mistaken
[10:02] <ubitux> i thought stefano worked on the segmenter and hls support but i might have been wrong here
[10:03] <ubitux> maybe he added other formats in the segmenter
[10:03] <ubitux> so libav might have originated both the hls segmenter and the hls support in segment
[10:03] <ubitux> which is kind of surprising
[10:05] <ubitux> so yeah, disregard ffmpeg adding hls support in segment, that was wrong
[10:06] <ubitux> the split of segment/hlsenc for hls support is not because of the fork, it's because libav made 2 :p
[10:32] <rcombs> ^ I think I explained that pretty well; if anyone would like to peruse and comment, that'd be great
[10:39] <pross> 10 years of ubuntu. woo.
[11:33] <kevmitch> are there opinions on this https://github.com/mpv-player/mpv/issues/1205 ?
[11:34] <kevmitch> is it just the rendering that's happening relative, or is it actually stored that way?
[11:35] <wm4> nothing ffmpeg has business about
[11:35] <wm4> PGS subtitles store a resolution (typically matches video res), but that's it
[12:46] <cone-158> ffmpeg.git 03Thilo Borgmann 07master:6e6b79e7b809: lavf/mov.c: Prevent memory leak in case of invalid metadata reads.
[13:31] <cone-158> ffmpeg.git 03Stefano Sabatini 07master:7ba2e134fb78: lavfi/afade: fix cur_sample computation
[13:32] <cone-158> ffmpeg.git 03Stefano Sabatini 07master:843d7bb3a60d: lavfi/concat: accept a single segment
[14:01] <cone-665> ffmpeg.git 03Rodger Combs 07master:1372c557866a: doc/ffmpeg.texi: document the new -start_at_zero option
[14:57] <ubitux> Assertion pkt->dts == ((int64_t)0x8000000000000000UL) || pkt->dts >= 0 failed at libavformat/mux.c:577
[14:57] <ubitux> :(
[15:21] <j-b> 'morning
[15:29] <Compn> kierank : want to make a gpl violation for http://mac.eltima.com/media-player.html  ?
[16:49] <cone-665> ffmpeg.git 03Michael Niedermayer 07master:059c842818a1: avcodec/mjpegdec: Support 24111100 pix fmt id
[16:52] <ubitux> now i probably need to bisect...
[16:52] <Daemon404> you mean ffbisect
[16:53] <ubitux> is it still necessary nowadays?
[16:54] <Daemon404> yes
[16:54] <Daemon404> afaik
[16:54] <ubitux> ok
[17:11] <ubitux> mmh that's actually not a regression, my 2.4 just hasn't the same assert level
[17:47] <ubitux> "And be civil. [...] please fuck off."
[17:47] <ubitux> haha wm4 
[17:51] <ubitux> ok it might actually be a regression, but from a long time ago
[18:02] <saste> arwa, ping
[18:02] <feklee> Which branch contains the bleeding edge? I'm looking for WebM/VP9 such as "-tile-columns".
[18:03] <thardin> master?
[18:03] <feklee> In master I can't find these.
[18:03] <thardin> if it's a very recent feature in libvpx then  it's probably not in yet
[18:06] <feklee> @thardin I'm following a tutorial: http://wiki.webmproject.org/adaptive-streaming/instructions-to-playback-adaptive-webm-using-dash
[18:06] <feklee> Quote: "Note about FFmpeg: You will need to download the latest (tip-of-the-tree) version of FFmpeg in order for some DASH features to work. You can either download nightly static build from https://www.ffmpeg.org/download.html or build FFmpeg yourself from the git repository."
[18:07] <feklee> A patch has been submitted in Nov. 2013: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2013-November/150547.html
[18:09] <thardin> not providing a git hash is somewhat unhelpful of that guide
[18:09] <thardin> try to grep for the commit in the logs
[18:12] <feklee> @thardin Found it. Commit: 517afd72c6772f69671d913f03f4be89dd1dd665
[18:12] <feklee> Weird that it seems missing now.
[18:14] <thardin> maybe it got replaced with something better?
[18:14] <thardin> gitk libavcodec/libvpxenc.c
[18:16] <thardin> uhm, "tile-columns" and "tile-rows" are in current master
[18:24] Action: Daemon404 wonders if there is some irc client that adds @
[18:50] <feklee> @thardin Weird, I must have grep'ed in the wrong directory before. Anyhow - after recompilation - when executing ffmpeg I still get: "Unrecognized option 'tile-columns'."
[18:50] <feklee> Well, I guess that's an end user question now, doesn't belong here.
[19:33] <kierank> Compn: i only did it because I had to sit through a marketing presentation about the stupid player
[19:34] <cone-665> ffmpeg.git 03Mika Raento 07master:17702f1fc584: mov.c: reasonable bitrate for fragmented mp4
[20:10] <Compn> kierank : ahhaha, really? 
[20:10] <Compn> wow
[20:11] <feklee> @thardin In the end it was simply a matter of specifying `--enable-libvpx` as option for `configure`. Facepalm!
[20:14] <kierank>  I believe we have followed the licensing rules for FFmpeg and more than happy to comply if you can tell us what we have violated. We have not distributed any source code and have used the compiled libraries as-is from the Zeranoe site
[20:14] <kierank> Compn: that's what I got in response
[20:19] <llogan> most spammers seem to get a trac "karma" in the 30-50 range. first time i've seen one 10x bigger...
[20:24] <llogan> hundreds of script kiddy attempts today
[21:43] <cone-665> ffmpeg.git 03Michael Niedermayer 07master:d5a3a20d1e19: avcodec/mjpegdec: simplify chroma_height calculation
[21:53] <culey> hello, i'm applying for opw, is it late for me? If not what can I start contributing on? Thanks!
[21:56] <cone-665> ffmpeg.git 03Janne Grunau 07master:04d8af5f1796: fate-mpeg4: use TARGET_SAMPLES for resize tests
[21:56] <cone-665> ffmpeg.git 03Michael Niedermayer 07master:2f74b8d0edbe: Merge commit '04d8af5f17961b9b7076b8c974e360feb08787c2'
[22:06] <cone-665> ffmpeg.git 03Vittorio Giovara 07master:e73d26bbd65f: smoothstreamingenc: explict cast to avoid overflow
[22:06] <cone-665> ffmpeg.git 03Michael Niedermayer 07master:4542615063fb: Merge commit 'e73d26bbd65f1ac5fc73ef3fd24cab1bed8ba2e2'
[22:24] <J_Darnley> Oh... culey left
[22:27] <cone-665> ffmpeg.git 03Vittorio Giovara 07master:f22aa6b841dc: flvdec: avoid unitialized use of a struct member
[22:27] <cone-665> ffmpeg.git 03Michael Niedermayer 07master:1922357e5a05: Merge commit 'f22aa6b841dc54fa1dd804303885b1e230a5f629'
[22:46] <cone-665> ffmpeg.git 03Vittorio Giovara 07master:629b2ed0ac77: flvdec: make sure to check create_stream and report the same error
[22:46] <cone-665> ffmpeg.git 03Michael Niedermayer 07master:3099008f0780: Merge commit '629b2ed0ac77d7c4bf1aeac5e70cafee5fa0fcae'
[22:48] <ubitux> remote: -Deny-          Trailing whitespace found in tests/ref/fate/sub-stl.
[22:48] <ubitux> remote: -Deny-          Commit aborted, fix the issue and try again.
[22:48] <ubitux> rhaaa
[22:48] <ubitux> j-b: ^
[22:48] <ubitux> :((
[22:49] <ubitux> well, i guess i can avoid them but still..
[22:50] <Compn> thats something we made a commit hook for ubitux
[22:50] <Compn> not really j-b's problem
[22:50] <ubitux> it's on videolan
[22:50] <Compn> ffmpeg did that since like 2011
[22:51] <ubitux> yes sorry, i mistook it with the bug from earlier
[22:51] <ubitux> but anyway, the problem is, the file is supposed to have trailing whitespace
[22:51] <Compn> ah 
[22:51] <Compn> i see desu ne.
[22:51] <Compn> probably michael can override it
[22:52] <J_Darnley> What?  How is it supposed to have it?
[22:52] <ubitux> sample has some trailing spaces
[22:52] <michaelni> Compn, no, j-b can
[22:53] <J_Darnley> Oh, the fate reference?
[22:53] <ubitux> J_Darnley: yes
[22:53] <michaelni> ubitux, maybe it can be tricked by using a merge, but thats a bit ugly
[22:54] <ubitux> so when transcoded to ass, the trailing whitespaces are kept
[22:54] <ubitux> michaelni: yeah it sucks :p
[22:54] <ubitux> michaelni: we can change the sample maybe
[22:55] <ubitux> michaelni: http://b.pkh.me/STL_capability_tester.stl
[22:55] <ubitux> can you replace it with this one?
[23:00] <cone-665> ffmpeg.git 03Lukasz Marek 07master:da833a6d090f: lavd/fbdev_dec: use default device when not provided
[23:01] <cone-665> ffmpeg.git 03Lukasz Marek 07master:6aa1cfed0b22: lavd/fbdev_common: report error during probing fbdev device
[23:02] <michaelni> ubitux, done
[23:02] <ubitux> cool, thanks
[23:02] <ubitux> i guess i can't push now though...
[23:02] <ubitux> got to wait another 24 hours...
[23:33] <rcombs> is it just me, or does AC3 never get extradata, resulting in mov_write_ac3_tag never being run?
[23:33] <rcombs> (well, never finishing successfully)
[23:36] <wm4> you have to mux mp4 with ffmpeg? poor soul
[23:36] <rcombs> yup :3
[23:36] <rcombs> DASH, actually
[23:37] <wm4> it can't even demux dash properly
[23:37] <Compn> >always complaints >never fixes
[23:38] <wm4> why don't you fix it then
[23:38] <wm4> if it's so simple
[23:38] <rcombs> works for me if I byte-concatenate the initial mp4 to all the segments :3
[23:38] <wm4> hm is it that simple
[23:38] <rcombs> apparently
[23:39] <rcombs> you can also start at any segment, as long as you have initial.mp4 immediately before it and it's first
[23:39] <rcombs> (for the files I've worked with, anyway)
[23:40] <wm4> my own problem with mp4 dash is that youtube-muxed dash is pretty simple, but libavformat still insists on reading the whole file on opening
[23:40] <wm4> though that one could probably be fixed by reading the dash-specific index element (or whatever it is)
[23:41] <cone-665> ffmpeg.git 03Vittorio Giovara 07master:7207dd8f829b: rmdec: check av_new_packet return value
[23:41] <cone-665> ffmpeg.git 03Michael Niedermayer 07master:840bc8e284c8: Merge commit '7207dd8f829baee58b4df6c97c19ffde77039e8d'
[23:59] <cone-665> ffmpeg.git 03Vittorio Giovara 07master:be42c0b8d57f: rmdec: stricter error check to avoid theoretical unitialized use
[23:59] <cone-665> ffmpeg.git 03Michael Niedermayer 07master:979062fe2feb: Merge commit 'be42c0b8d57fe2ea769892d102ffd5561dc18709'
[00:00] --- Wed Oct 22 2014