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

[burek]

[00:00] <Daemon404> thats not true. you might get an earlier displayable frame.
[00:00] <wm4> also... what if audio and video are from the same file, but different positions?
[00:00] <Daemon404> its nto guaranteed to be in the gap
[00:00] <wm4> e.g. presentation time 5s could have video from position 5s, but audio from position 40s
[00:01] <Daemon404> my unpopular idea was just to export timeline metadata and have the user (me) deal with it manually
[00:02] <ubitux> i don't know.
[00:02] <wm4> sounds like a huge pain, especially because libavformat can't do some of the stuff required
[00:02] <ubitux> i just don't get it but my brain probably melt a few minutes ago
[00:02] <Daemon404> ubitux, why do you think there have been like 50 people who tried to do timelines in the past
[00:02] <wm4> like audio and video from different positions
[00:02] <Daemon404> they all failed
[00:02] <ubitux> well, it works here :(
[00:03] <Daemon404> the correct solution is simple
[00:03] <ubitux> it will just creates slow downs with large gaps
[00:03] <Daemon404> build a time machine
[00:03] <wm4> I have 2 backup ideas: 1. implement it in the demuxer, 2. implement it in the demuxer, but not the mp4 one, but a pseudo-demuxer which implements the presentation logic of edit lists
[00:03] <Daemon404> murder the person who thought it was a good idea
[00:03] <Daemon404> profit.
[00:03] <wm4> Daemon404: excellent idea
[00:03] <wm4> Daemon404: but just as unfeasible as the others
[00:03] <ubitux> exporting the meta won't help btw
[00:04] <ubitux> i mean, how are you going to deal with it then?
[00:04] <wm4> how does other software deal with this?
[00:04] <wm4> e.g. vlc?
[00:04] <wm4> l-smash apparently exports all metadata
[00:04] <ubitux> i got weird artefacts with vlc
[00:04] <wm4> what about xbmc or blender?
[00:04] <ubitux> so i'm assuming they cut at packet level
[00:04] <Daemon404> i build a timeline in my own layer above, and unrelated to libav*
[00:04] <ubitux> but i might be wrong
[00:04] <Daemon404> and i apply it based on decoded frame timestamps
[00:04] <Daemon404> and stuff
[00:04] <ubitux> so... the same as i do?
[00:04] <Daemon404> and seeking whilst taking how it maps int oaccount
[00:05] <ubitux> tell me more about the seeking
[00:05] <ubitux> do you seek stream based?
[00:05] <Daemon404> you can map a timestamp fro mthe timeline to a stream's time
[00:05] <Daemon404> and seek to it
[00:05] <Daemon404> it's just mapping timestamps to timestamps
[00:05] <ubitux> yeah well i guess that could be done in mov demuxer
[00:06] <ubitux> like, trying to seek to more appropriate places
[00:06] <ubitux> basically, roughly segmenting on packets
[00:06] <Daemon404> wm4, a birdy told me vlc has (secret) lsmash support
[00:06] <Daemon404> hidden somewhere
[00:06] <Daemon404> fyi
[00:06] <Daemon404> anyway, food time
[00:06] Action: Daemon404 brb
[00:07] <wm4> maybe this shit should be implemented on the demuxer level after all?
[00:10] <ubitux> no it won't work well
[00:10] <ubitux> you'll have artefacts
[00:13] <wm4> what arterfacts?
[00:13] <nevcairiel> Well your approach can't be entirely correct, since that would seriously make it useless during playback
[00:14] <nevcairiel> for mkv it works decently on the demuxer level, since people know that they need to put IDRs at the points a segment "starts"
[00:15] <wm4> the mpv implementation doesn't require that, but implementing editlists in the same way in mpv would be a serious complication
[00:15] <ubitux> wm4: you can't randomly drop packets
[00:15] <wm4> ubitux: you still decode these packets
[00:16] <wm4> ubitux: but mark them as "do not present"
[00:16] <ubitux> you still need to decode them right?
[00:16] <wm4> yes
[00:17] <wm4> but discarding a decoded frame based on a flag is simple
[00:17] <ubitux> that doesn't solve the issues we talked about anyway
[00:17] <wm4> which ones? switching codecs?
[00:17] <ubitux> no, the bad interleaving
[00:17] <ubitux> and seeking and whatever
[00:18] <wm4> the demuxer could handle this internally
[00:18] <ubitux> yeah sure
[00:18] <ubitux> but i can also do it with my proposition
[00:18] <wm4> what I suggest and your patch have a certain overlap
[00:18] <ubitux> also, i'm wondering about adjusting timestamps at packet level
[00:19] <ubitux> which sounds like a very bad idea to me
[00:19] <ubitux> but well
[00:19] <ubitux> anyway i just added support for ffmpeg (but untested)
[00:19] <ubitux> going to test in a moment and probably sleep
[00:20] <wm4> mpv actually adjusts timestamps on the packet level for mkv
[00:21] <ubitux> how is timeline support in mkv in mpv?
[00:21] <wm4> only comparing timestamps is questionable; adjusting actually works, because it's only an offset and doesn't affect reordering
[00:22] <ubitux> it looks more complex to me to use that approach anyway
[00:22] <ubitux> but dunno
[00:23] <ubitux> we can still pick another approach later; we would just have to deprecate 1 field and 1 function
[00:23] <wm4> and trash anyone's code that actually tried to use it
[00:24] <ubitux> wm4: the usage is very simple
[00:24] <ubitux> so far..
[00:24] <ubitux> https://github.com/ubitux/FFmpeg/compare/edts
[00:24] <ubitux> see the changes in ffplay and ffmpeg
[00:25] <wm4> anyway, I'm off to sleep
[00:25] <ubitux> yeah, same
[00:25] <wm4> I'll take a closer look tomorrow
[00:26] <wm4> and maybe Daemon404 could tell us some more that we're doing everything wrong
[00:26] <wm4> because he's one of the few lucky people who managed to implement it
[00:27] <wm4> and I guess there's also the "build a giant libavfilter graph" idea
[00:30] <iive> you forgot to mention lua
[00:48] <cone-640> ffmpeg.git 03Carl Eugen Hoyos 07master:7a4be4315fd6: Support muxing 4k AVC Intra in mov.
[00:48] <cone-640> ffmpeg.git 03Jonathan Baecker 07master:5a57f389f45e: avdevice/decklink_common: fix heap corruption run time error
[02:04] <rcombs> \o/ it works!
[02:04] <rcombs> `ffmpeg -charenc_detection 1 -libguess_language japanese -i in.srt -y out.srt` with an EUC Japanese input file gave me a UTF-8 output :D
[02:05] <rcombs> now to add ENCA and more customization and make it more fault-tolerant
[02:05] <rcombs> oh, and make it work with decoders other than SRT
[03:13] <cone-640> ffmpeg.git 03Michael Niedermayer 07master:242f1152bf90: ffmpeg: drop usage of coded_frame
[03:16] <rcombs> nevcairiel: know how FDK compares to Apple's encoder?
[08:05] <kierank> rcombs: apple is better
[08:07] <rcombs> heh
[11:39] <arwa> can anyone give me documentation on "eq/eq2" filters?
[11:48] <ubitux> man mplayer
[11:48] <ubitux> also you should contact James Darnley
[11:48] <ubitux> before starting this
[11:48] <ubitux> or look at uspp first
[11:48] <ubitux> arwa ^
[11:49] <arwa> I talked to James Darnley
[11:50] <arwa> He gave me this link - https://gitorious.org/ffmpeg/jdarnley-ffmpeg/commits/filter_eq
[11:50] <arwa> These are all the commits done by him
[11:51] <ubitux> good
[11:51] <arwa> So, should I proceed with eq/eq2 or uspp?
[11:52] <ubitux> you should probably start with uspp
[11:52] <arwa> Okay.
[11:52] <ubitux> because we didn't decide what to do with eq
[11:52] <ubitux> and he seems to have started working on this
[11:52] <ubitux> also we need to answer the question of whether it belongs in hue or not
[11:53] <ubitux> you can of course give your opinion on such decision
[11:53] <ubitux> but it needs dicussion
[11:53] <arwa> Cool. What do I need to implement in uspp?
[12:03] <ubitux> arwa: it just needs to work properly natively
[12:04] <ubitux> you can look at a2c547ffecb11ccfe515e1e50b631aa3b15a3ae8 for an example of a pp filter being ported
[12:05] <arwa> Okay. 
[12:06] <arwa> what is the desired output?
[12:06] <arwa> is there any documentation on this filter?
[12:12] <cone-642> ffmpeg.git 03Christophe Gisquet 07master:9fa056ba75c0: pngdsp x86: use unaligned access
[12:17] <ubitux> arwa: i told you, "man mplayer"
[12:17] <ubitux> you can try the filter with -vf mp=uspp
[12:33] <arwa> But man mplayer just tells how to use the filter.
[12:41] <ubitux> ah you mean the code itself? no
[12:41] <wm4> the desired output is what mplayer outputs (lol)
[12:41] <wm4> welcome to the ghetto
[12:42] <ubitux> well it's just a pp filter that use snow codec to smooth "blocks"
[12:42] <ubitux> iiuc
[12:42] <ubitux> no idea about the details.
[13:28] <ubitux> wm4: i'm preparing a version demuxer wise following what you said
[13:28] <wm4> ubitux: interesting
[13:29] <ubitux> so basically, flag the packet, so it has to be decoded but the result frame(s) should not appear on presentation
[13:29] <ubitux> and for audio maybe i'll put a side data for truncation
[13:29] <ubitux> i'm a bit unsure about how to play with the dts
[13:29] <wm4> ffmpeg already has that
[13:29] <ubitux> yeah i know
[13:29] <ubitux> i mean, i will set the side data
[13:30] <wm4> I'm still wondering what's the most feasible method
[13:30] <wm4> are edit lists with different codecs on the same track common?
[13:32] <ubitux> the first sample i had mixed h264 and h265
[13:32] <wm4> aw
[13:32] <ubitux> :p
[13:33] <wm4> then there'd also be a need to switch codecs on the fly...
[13:37] <Paranoialmaniac> it has nothing to do with edit list
[13:40] <wm4> Paranoialmaniac: I thought edit lists can reference different tracks with different codecs for the same virtual track
[13:42] <Paranoialmaniac> wm4: edit list maps media timeline to presentation timeline in the enclosing track only
[13:43] <Paranoialmaniac> different codecs can be stored in the same track but it is not a feature of edit list
[13:56] <wm4> Paranoialmaniac: I see...
[13:58] <wm4> how does software even deal with this?
[13:58] <Paranoialmaniac> this?
[13:58] <Paranoialmaniac> to support switching different codecs on the fly, need to support multiple sample description
[13:59] <nevcairiel> most stuff probably just doesnt support it
[13:59] <nevcairiel> hence in the real world, it also doesnt really exist
[13:59] <Paranoialmaniac> we need get rid of mov_skip_multiple_stsd to support multiple sample descriptions
[14:01] <Paranoialmaniac> and need reopen avcodeccntext internally on the fly for different codesc
[14:03] <wm4> the hard part is to synchronize this with packet reading...
[14:03] <wm4> and of course it would break all API users
[14:05] <Paranoialmaniac> synchronize this with packet reading <--- decoder delay thing?
[14:07] <Paranoialmaniac> avcodeccontext should not be closed before all decoded frames are flushed
[14:09] <wm4> I mean, the API user calls an API function to read a new packet
[14:10] <wm4> then, at which point should libavformat switch the codecs?
[14:10] <wm4> when reading a packet with the new codec?
[14:10] <wm4> it could get messy
[14:10] <wm4> most applications will actually have an internal packet queue too
[14:11] <Compn> mencoder doesnt seem to mind inputs with different codecs :P
[14:12] <Compn> likewise mplayer , of course
[14:12] <wm4> Compn: we're talking about something completely different
[14:12] <Compn> ah
[14:12] <Compn> then i will slink away
[14:16] <ubitux> Daemon404: any idea what's the meaning of an empty entry in the middle of the edit list?
[14:16] <Paranoialmaniac> empty entry?
[14:17] <ubitux> {.time=-1, .duration=<whatever>}
[14:17] <ubitux> if it's in position 0 it means the duration is the start time in the presentation itself
[14:17] <ubitux> but if it's elsewhere it doesn't seem to be defined
[14:18] <Paranoialmaniac> empty edit is a duration of no corresponding media
[14:18] <wm4> so the player has to show nothing during this?
[14:19] <ubitux> Paranoialmaniac: well, you can define "empty" by doing: {t=0,duration=5}{t=7,duration=5}
[14:19] <Paranoialmaniac> it depends on implementation. show the same frame before the empty edit or just show a black frame etc...
[14:19] <ubitux> so this is equivalent to: {t=0,duration=5}{t=5,duration=2}{t=7,duration=5} ?
[14:19] <ubitux> i mean
[14:19] <ubitux> so this is equivalent to: {t=0,duration=5}{t=-1,duration=2}{t=7,duration=5} ?
[14:20] <ubitux> intuitively i would say that in {t=0,duration=5}{t=7,duration=5} you adjust timestamps so the 2 chunks are continuous
[14:21] <ubitux> while in {t=0,duration=5}{t=-1,duration=2}{t=7,duration=5} they aren't adjusted
[14:21] <ubitux> but i might completely misinterpret it
[14:22] <Paranoialmaniac> all edit list entries are concatenated
[14:22] <ubitux> right, but what does the empty entry means in the second case?
[14:22] <ubitux> to me it sounds like "do not display these"
[14:23] <ubitux> (the 2 seconds for the empty in the middle)
[14:24] <ubitux> oh fuck it seems to be related to fragments
[14:25] <ubitux> damn the specs is confusing.
[14:25] <Paranoialmaniac> as i said it depends on implementations. an implementation shows the same frame before the empty edit for 2 seconds, and another implementation shows a black frame for 2 seconds
[14:26] <Paranoialmaniac> its undefined
[14:27] <ubitux> ok so that's exactly what i said initially
[14:27] <ubitux> it's indeed a gap where the timestamps are not adjusted
[14:28] <ubitux> like, entry before and after the empty one will not get stuck together
[14:28] <ubitux> anyway ok
[14:28] <ubitux> thx
[14:30] <Paranoialmaniac> when media_time==-1, segment_duration only represents that there is 2 seconds not belonging to any portion of media
[14:33] <Paranoialmaniac> if you wish, i'll ask david about this. he is mp4 chairman
[14:34] <ubitux> ok.. dunno
[14:34] <ubitux> i'm going to try another implementation, i'll see how it looks like
[14:39] <ubitux> i'm wondering about fun cases such as [t=3 d=0][t=-1 d=0][t=5 d=5]
[14:40] <ubitux> in [t=3 d=0][t=5 d=5] case i suppose you are supposed to consider it's [t=3 d=2][t=5 d=5]
[14:41] <ubitux> anyway..
[14:41] <Paranoialmaniac> segment_duration==0 is horrible...
[14:42] <Paranoialmaniac> it is explicitly mentioned in the spec about movie fragments with empty initial movie
[14:42] <ubitux> yeah
[14:42] <ubitux> but there are a lot of undefined cases
[14:42] <Paranoialmaniac> but no about non-fragmented movie
[14:43] <Paranoialmaniac> i guess it is just the same as the case where there is no edit list
[14:45] <Paranoialmaniac> i'll ask david about this. i still have many questions about 14496-12
[14:45] <ubitux> :)
[14:48] <Paranoialmaniac> ISO will add loop to edit list for MPEG-H image file format
[14:49] <wm4> wat
[14:49] <ubitux> something i wonder in iso is why is why there are so much entry count in boxes
[14:49] <wm4> that's just fucked up
[14:49] <ubitux> when the size of the box actually defines that
[14:49] <ubitux> it's a "waste of 4B" but also a way of "hiding data"
[14:52] <ubitux> i guess it simplifies patching the header
[14:52] <ubitux> without shifting everything
[14:52] <Paranoialmaniac> loop is indicated in flags (24bits) field
[14:54] <ubitux> i can't handle loop with the demuxer mechanism :(
[14:54] <ubitux> or maybe i can... but that's starting to be really ugly
[15:03] <wm4> well it would be ugly in the presentation layer too
[15:03] <wm4> Paranoialmaniac: why do they need loop? could a muxer not just repeat entries manually?
[15:08] <Paranoialmaniac> wm4: presentation of iso base media is finite.
[15:08] <Paranoialmaniac> presentation duration is restricted by movie duration
[15:08] <cone-642> ffmpeg.git 03Michael Niedermayer 07master:e316caf712b2: avcodec/opusdec: Use avpriv_float_dsp_alloc()
[15:08] <cone-642> ffmpeg.git 03Michael Niedermayer 07master:c5dc8cc03a29: avcodec/mpegaudiodec_float: Use avpriv_float_dsp_alloc()
[15:08] <cone-642> ffmpeg.git 03Michael Niedermayer 07master:534f901fcaa4: avcodec/atrac3plusdec: Use avpriv_float_dsp_alloc()
[15:08] <wm4> Paranoialmaniac: so it's just a global flag for infinite looping?
[15:09] <Paranoialmaniac> wm4: yes
[15:09] <Paranoialmaniac> as long as movie duration is unknown/indefinite
[15:09] <wm4> that actually sounds sane then
[15:10] <wm4> and rather easy to implement
[15:11] <Paranoialmaniac> looping is an extension for image file format derived from iso base media. so, this is reasonable
[15:14] <Paranoialmaniac> the draft has not defined how to indicate indefinite movie duration yet though
[15:30] <ubitux> wm4: so... doing it at demuxer level is kind of annoying because of the dts (i believe)
[15:31] <wm4> hm?
[15:31] <ubitux> i mean, for the packet that are supposed to be dropped, i can't really adjust the dts
[15:31] <ubitux> but then after you get back packet to be presented, these must be time adjusted (both pts... and actually dts)
[15:32] <ubitux> and so you get dts smaller than the previous ones that were not supposed to be presented
[15:32] <ubitux> and it's a mess
[15:32] <ubitux> but maybe i miss a trick somewhere
[15:32] <ubitux> i'd say i'd just don't touch the dts and only the pts
[15:32] <ubitux> but it breaks badly
[15:33] <wm4> hm
[15:35] <ubitux> http://b.pkh.me/0001-avformat-RFC-WIP-add-basic-timeline-support.patch
[15:35] <ubitux> it would look like this
[15:35] <ubitux> but it doesn't work.
[15:36] <ubitux> so it looks appealing, but unless i find a way to adjust the pts/dts properly, it can't work
[15:38] <ubitux> in theory i'd say that not changing the dts is the correct thing to do
[15:38] <ubitux> but unfortunately ffmpeg doesn't like the inconsistency between pts and dts
[15:40] <wm4> no, dts and pts must be consistent
[15:41] <wm4> hm possible we could create another mechanism that changes the timestamps after decoder
[15:41] <wm4> *possibly
[15:42] <wm4> but yeah, it's a mess
[15:50] <ubitux> alright so, we do agree that the original proposition was saner?
[15:50] <ubitux> reynaldo: oh mmh sorry about the opw thing
[15:50] <ubitux> i'll do that in a few hours when i'm home..
[15:51] <ubitux> damn... paperwork.
[15:51] <wm4> what was the original proposition?
[15:52] <ubitux> the patch on ml
[15:52] <wm4> that isn't complete
[15:52] <ubitux> what's missing?
[15:52] <ubitux> i mean as a PoC it works
[15:52] <Paranoialmaniac> PoC?
[15:53] <ubitux> proof of concept
[15:53] <Paranoialmaniac> i see
[15:53] <ubitux> i'm going back to the implementation in ffmpeg and will resubmit
[15:54] <wm4> ubitux: I still don't get how seeking or segment switching works
[15:54] <wm4> or whatever the mp4 name for segment is
[15:55] <Paranoialmaniac> segment?
[15:56] <ubitux> i don't know why it matters
[15:56] <wm4> well, going from one edit list entry to the next
[15:56] <Paranoialmaniac> i really dislike the name of segment_duration of edit
[15:57] <ubitux> wm4: you don't; it's just as if you were decoding packets and got no frame out of it for a while
[15:57] <Paranoialmaniac> iso add another meaning to 'segment' for dash
[16:01] <Paranoialmaniac> basically, the spec does not call each entry in edit list 'segement'
[16:03] <Paranoialmaniac> if the spec says 'segment', it means incomlete file not conforming to iso base media
[16:09] <reynaldo> ubitux: no worries, all cool ;)
[16:09] <reynaldo> ubitux: just make sure you dont forget handling it today 
[16:09] <ubitux> i guess i need to fight with my printer and scanner again?
[16:10] <ubitux> or i can use gimp to "draw" a random cross?
[16:11] <reynaldo> ubitux: now sure, I do that with other docs tbh, whatever you preffer really, if they dont like it they will probably tell you to resubmit afterwards
[16:11] <reynaldo> everyone happy all the same
[16:12] <ubitux> ok
[16:26] <ubitux> damn the decoded frames in ffmpeg have no pts
[16:26] <ubitux> grrr
[16:27] <av500> reordered_opaque
[16:28] <wm4> ubitux: ??
[16:28] <ubitux> wm4: well, for some reason the packets sent to the decode functions have no pts
[16:29] <ubitux> so as the result the decoded frames are without any pts
[16:29] <wm4> what, why
[16:29] <ubitux> i don't know :(
[18:47] <cone-642> ffmpeg.git 03Jonathan Baecker 07master:868cec587454: avdevice/decklink_common: fix COM initialization failure check
[19:34] <wm4> 400 is possible!
[19:34] <koda> 9000
[19:46] <cone-642> ffmpeg.git 03Michael Niedermayer 07master:eac5c7b8377f: avformat/aviobuf: Fix infinite loop in ff_get_line()
[20:07] <cone-642> ffmpeg.git 03Michael Niedermayer 07master:a6f730730b82: avformat/rmdec: Check codec_data_size
[20:37] <kurosu_> anshul's code on cc decoding reminds me of ccextractor
[20:38] <cone-642> ffmpeg.git 03Michael Niedermayer 07master:8524558858b7: swscale/x86/rgb2rgb_template: fix crash with tiny size and nv12 output
[22:20] <cone-642> ffmpeg.git 03Lukasz Marek 07master:650aa36f3581: lavf/oggenc: use meaningful error codes
[22:50] <cone-642> ffmpeg.git 03Michael Niedermayer 07master:1027a4468185: Changelog: Add libpostproc visualization
[22:50] <cone-642> ffmpeg.git 03Michael Niedermayer 07master:43520771f1d0: doc/APIchanges: fill in hashes and dates
[22:50] <cone-642> ffmpeg.git 03Michael Niedermayer 07master:dac9e5090207: RELEASE_NOTES: update for 2.5
[23:02] <anshul_mahe> has any one tested ffmpeg with new fdk-aac it seems to break
[23:02] <anshul_mahe> error AAC_PCM_OUTPUT_CHANNELS undeclared
[23:13] <cone-642> ffmpeg.git 03Reimar Döffinger 07master:49d9cbe55d67: h264_i386: Fix operand size
[00:00] --- Thu Dec  4 2014