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

[burek]

[01:19] <cone-593> ffmpeg.git 03Michael Niedermayer 07master:268b1eae2276: avcodec/mpegaudioenc_template: default to 384k bitrate as default
[01:27] <cone-593> ffmpeg.git 03Luca Barbato 07master:a7448064c526: mp2: Do not force a samplerate
[01:27] <cone-593> ffmpeg.git 03Michael Niedermayer 07master:1de8a4f73665: Merge remote-tracking branch 'qatar/master'
[06:37] <cone-803> ffmpeg.git 03Michael Niedermayer 07master:d9fef740bd6a: avcodec/dnxhdenc: use av_malloc_array()
[10:00] <relaxed> 2.2.1 probably needs mentioned on the front page
[11:20] <wm4> "IMHO, the fact that we merge Libav code does mean that we cooperate with them, even if Libav doesn't want to."
[11:20] <wm4> that thread is going places
[11:21] <ubitux> well that's pretty accurate
[11:21] <ubitux> it means there are some recognition to that project
[11:21] <wm4> you can't cooperate with someone against his will
[14:13] <Compn> iive : just submit a patch to libav-devel and call the bluff
[14:13] <Compn> dont bother arguing in mail threadsd
[14:14] <Compn> ubitux : bluff time! 
[14:14] <Compn> :)
[14:25] <cone-476> ffmpeg.git 03Vittorio Giovara 07master:89ef08c992c4: DNxHD: K&R formatting cosmetics
[14:25] <cone-476> ffmpeg.git 03Michael Niedermayer 07master:bad101ab8a54: Merge commit '89ef08c992c484a46711b1a68a988303679c288e'
[14:32] <ubitux> michaelni gmx.at: Envelope expired
[14:32] <ubitux> :(
[14:32] <wm4> wut
[14:32] <michaelni> what ?
[14:32] <ubitux> i've sent a mail to reimar as well
[14:32] <ubitux> it has expired
[14:32] <ubitux> i mean it's been trying to send it for a few days now
[14:33] <ubitux> maybe that's a problem with my smtpd though... :)
[14:38] <cone-476> ffmpeg.git 03Timothy Gu 07master:676856204b84: DNxHD: make get_pixel_8x4_sym accept ptrdiff_t as stride
[14:38] <cone-476> ffmpeg.git 03Michael Niedermayer 07master:ee2a43798c2a: Merge commit '676856204b84dfaffe329dce8502e834a0dbdb19'
[14:45] <ubitux> Compn: huh?
[14:53] <cone-476> ffmpeg.git 03Timothy Gu 07master:71c32ed5335a: DNxHD: convert inline asm to yasm
[14:53] <cone-476> ffmpeg.git 03Michael Niedermayer 07master:4899ccd29572: Merge remote-tracking branch 'qatar/master'
[17:24] <koda> hi, im designing an api for exporting rotation information from containers like mov and other codecs
[17:24] <koda> is there any preference in what should be exported?
[17:24] <koda> like full matrix, or just rotation angle or more fields even
[17:25] <ubitux> just like it's done currently, "rotate" tag is enough
[17:25] <ubitux> (at stream level)
[17:26] <koda> ok so no change would be your preference
[17:26] <ubitux> this information is currently extracted from a stream box header (tkhd, track header)
[17:26] <ubitux> so it's information at stream level to start with
[17:26] <Compn> ubitux : you dont want it in metadata or stream data ,how will vlc read it ?
[17:26] <ubitux> if at some point they decide to add frame level rotation that will be stored differently
[17:26] <Compn> er s/streamdata /side data 
[17:27] <koda> the api i had in mind would remain in stream level, and there are codecs that export rotation at codec level
[17:27] <ubitux> Compn: by looking at the stream metadata?
[17:27] <koda> also metadata is usually for textual information, not this essential information
[17:27] <Compn> koda : so you want to export it how ?
[17:28] <koda> avstream side data, with possible avframe side data translation
[17:28] <ubitux> the "text metadata" is not optimal but it has a lot of benefits
[17:29] <ubitux> typically, it is automatically exported to ffprobe, so you can do stuff like that:
[17:29] <ubitux> - ffprobe -v 0 -of flat -show_entries stream_tags=rotate ~/samples/iphone-rotate/r180.mov                                                     
[17:29] <ubitux> streams.stream.0.tags.rotate="180"
[17:29] <koda> ok lets work on the not optimal and provide the same number of benefits with this api
[17:30] <ubitux> you could do both
[17:30] <ubitux> not sure how
[17:30] <koda> for instance you can do the same with the showinfo filter
[17:30] <ubitux> it requires decode, so it sucks
[17:31] <koda> well you usually want to do something with rotation info, so might as well decode the frame
[17:31] <ubitux> no
[17:32] <koda> just knowing that a video is rotated doesnt say much
[17:32] <ubitux> because it will be done at probe stage
[17:32] <koda> and the ffprobe case is somewhat limited/lmiting
[17:32] <ubitux> before setting up your decode workflow
[17:32] <ubitux> no it's not
[17:33] <koda> why?
[17:34] <ubitux> typically you extract that information at probe stage because you want to insert automatically transpose or vflip/hflip filter, or rotate filter for special rotation in another command, where you would drop the metadata itself
[17:35] <ubitux> if you can do that all transparently with a single command then that's fine as well
[17:35] <koda> the problem is that this is not textual information (metadata) but additional information essential for correct displaying
[17:35] <koda> and moreover you can only represent rotation with the current api, i wanted to add hflip vflip and maybe translation like you mentioned
[17:35] <koda> and adding a metadata entry for each of them is ugly
[17:36] <ubitux> let me re-explain
[17:36] <ubitux> currently the common workflow is the following:
[17:36] <ubitux> you probe the input file to get the rotation (and generally a lot of other stuff)
[17:36] <ubitux> then you setup a filtergraph to hard-rotate the output video based on that value
[17:37] <ubitux> depending on the value you construct a different filtergraph
[17:37] <ubitux> using transpose, vflip/hflip, or rotate filter
[17:38] <ubitux> (and you also add -map_metadata -1 to drop the metadata itself so the it's not rotated twice in the output)
[17:38] <koda> well thats a (quite complex) usecase, but its nothing that could not be done automatically with the new api
[17:38] <ubitux> this is what most people do to handle players with no soft rotate, which happens a lot
[17:38] <koda> instead of having to probe first, youd let the api detect the operation to perfom
[17:39] <koda> and the filter would just use this value to perform it automatically
[17:39] <koda> its somewhat less work for them overall too
[17:39] <ubitux> well if you can do that logic in ffmpeg & ffplay sure&
[17:39] <ubitux> but you know you can also do that with string metadata as well
[17:40] <ubitux> strcmp("90" ...) and the 4 other cases
[17:40] <ubitux> one nice thing missing would be to support special rotation matrix
[17:40] <koda> ok, but rotation is not really metadata, but something needed for correct displaying
[17:40] <koda> or we could just add every information like pixel format as metada then :p
[17:41] <ubitux> it belongs perfectly in metadata
[17:41] <ubitux> rotation in exif are also called metadata for instance
[17:41] <koda> exif is textual information, mov thd atom is not
[17:42] <ubitux> i'm not sure exif rotation is stored as "text" and it doesn't change anything
[17:42] <ubitux> it's really not much a problem to deal with strings here
[17:42] <koda> afaik exif reports it as rotation, mov as rotate, i see a little problem there too
[17:42] <Compn> i think koda means he wants to rotate the video before , so all of the player applications dont have to implement the check, and implement the rotate filtering ?
[17:43] <ubitux> Compn: you can't do that at demux level, you have to use a filter
[17:43] <Compn> 'auto-rotate'
[17:43] <koda> you can, if the api is not just metadata
[17:43] <ubitux> it doesn't change the data
[17:43] <ubitux> demuxer has blob of data not decoded
[17:44] <ubitux> you're not going to rotate in the demuxer, that's what i'm saying
[17:44] <ubitux> anyway, you could have stream metadata in a binary representation if you prefer that way
[17:44] <Compn> ubitux : maybe he wants a way for the filter api to read the demuxer rotate flag ?
[17:44] <ubitux> but i'm not sure it will simplify much things
[17:44] <Compn> right
[17:44] <ubitux> Compn: i understand what he wants you know
[17:44] <Compn> ok then :P
[17:44] Action: Compn goes back under his rock
[17:45] <ubitux> as long as it's not at frame level that should be fine
[17:45] <koda> ubitux: well binary represenation is again annoying to parse, i was thinking something more simple to report
[17:45] <ubitux> well i mean something API-usable
[17:45] <koda> eg fields or maybe an enum with data
[17:46] <ubitux> you also have the disposition stuff
[17:46] <ubitux> you can add a rotation disposition bit, meaning that some fields are set and should be honored
[17:46] <ubitux> and then use that
[17:47] <ubitux> AV_DISPOSITION_ROTATED
[17:47] <ubitux> then set whatever field you'd like to have
[17:47] <koda> so youd prefer enum for simple transformation
[17:48] <ubitux> note that "rotate" tags is already in heavy use
[17:48] <koda> + other fields
[17:48] <ubitux> ?
[17:49] <ubitux> you add a disposition (there is already an api around that, ffprobe partially supports it)
[17:49] <ubitux> then in the AVStream you add a rotation_matrix field with whatever struct you fancy
[17:50] <koda> ah, im not familiar with it
[17:50] <ubitux> it's simple
[17:51] <ubitux> in lavf/mov.c you video_stream->disposition = AV_DISPOSITION_ROTATED; video_stream->rotation_matrix = ...
[17:51] <cone-476> ffmpeg.git 03Lukasz Marek 07master:6db42a2b6b22: lavd: add device capabilities API
[17:51] <cone-476> ffmpeg.git 03Lukasz Marek 07master:c02e3dca2d49: lavd: add control message enums
[17:51] <ubitux> then add some print stuff in ffprobe.c
[17:51] <ubitux> that's all, and that should do it
[17:52] <ubitux> ah, and update the muxer to honor it as well
[17:52] <ubitux> we can already auto-insert the filters in ffplay btw&
[17:52] <ubitux> maybe we should do that heh
[17:54] <koda> oh i see, its avformat internal api though
[17:54] <ubitux> yes, format level, like currently, just not stored as string
[17:54] <koda> as soon as codecs implement rotation too its going to be in the way
[17:54] <ubitux> do you have one in mind?
[17:54] <koda> h264 and hevc have a sei message
[17:55] <ubitux> what happens if both are set?
[17:55] <ubitux> (codec and stream)
[17:55] <Compn> same thing that happens when codec and container have different sar/par 
[17:56] <ubitux> what happens then?
[17:56] <Compn> ffmpeg picks one (i forgot which)
[17:56] <Compn> or maybe mplayer does
[17:56] <Compn> oh
[17:56] <Compn> fun fact
[17:56] <Compn> different players pick different ones
[17:56] <Compn> so it will look correct in mplayer but not wmp
[17:56] <Compn> :)
[17:56] <ubitux> koda: i'd say that in the case of codec level, the codec should do the rotation itself
[17:57] <ubitux> (because it can, as opposite to the format)
[17:57] <Compn> aspect ratio can change mid stream in some formats too. fun! 
[17:57] <Compn> so future proof your thing to handle that imo
[17:57] <Compn> thing/api i mean
[17:57] <koda> ubitux: how can it rotate itself?
[17:58] <ubitux> well the codec has visibility on the raw decoded data
[17:58] <ubitux> and the rotation information (if stored at codec level)
[17:58] <ubitux> so it can do the rotation itself
[17:58] <koda> ah i see, but wed be cross layers too much
[17:58] <koda> imho
[17:59] <ubitux> i don't think so
[17:59] <Compn> you mean like codec flag is_flip or so ?
[17:59] <ubitux> exactly
[17:59] <Compn> decode the raw data opposite order to flip it 
[17:59] <Compn> ah
[17:59] <koda> Compn: no i mean, lavc should provide decoded data, then its another layer who should do operations on it, like a player or a filter
[18:00] <ubitux> koda: some codecs support a "flip" flag
[18:00] <ubitux> they decode it "flipped"
[18:00] <ubitux> the same could happen for the rotation information if they have it
[18:02] <koda> ah like vp3
[18:02] <ubitux> or mjpeg and others
[18:03] <koda> they seem rather codec specific hacks to me
[18:03] <cone-476> ffmpeg.git 03Thilo Borgmann 07master:d2417061ef50: Add AVFoundation input device.
[18:04] <michaelni> also v-flip is free, rotate would likely not be free for most codecs
[18:05] <michaelni> that is unless one is crazy and transposes the idct scantable and scans mbs in columns and a few other things ...
[18:06] <koda> yeah, no, lets not do that :P
[18:07] <michaelni> transpose + flip == 90° rotate btw if that helps anywhere
[18:08] <ubitux> well you could raise the information to codec as well
[18:08] <ubitux> codec context*
[18:08] <ubitux> not sure if there is a "disposition" equivalent in lavc
[18:09] <koda> there is not, and id pefer to avoid breaking api too much
[18:09] <ubitux> well for the format the disposition is fine
[18:09] <ubitux> you need to find something else for codec
[18:10] <ubitux> 90 is transpose=1, 180 is hflip,vflip and 270 is transpose=2
[18:10] <ubitux> now for the other values we have rotate filter ofc
[18:11] <koda> yeah
[18:12] <ubitux> anyway that's for ffplay/ffmpeg
[18:14] <ubitux> koda: something really simple would be to just add a AVRotationMatrix in AVStream and AVCodecContext
[18:14] <ubitux> set AVStream->disposition
[18:14] <ubitux> add a AVCodecContext->disposition or just AVCodecContext->ihasrotation
[18:15] <ubitux> and that should do it
[18:15] <koda> that would work but itd break api, while side data would not, and again difficult to expand to cover other kinds of transformation
[18:15] <ubitux> break api? how?
[18:16] <ubitux> it would just be a minor bump
[18:16] <ubitux> just like anything you would do with side data i'm pretty sure
[18:16] <ubitux> (do we have stream and codec side data?)
[18:18] <koda> oh avcodeccontext not avcodec, sorry i got confused
[18:19] <koda> however id still be difficult to export if it is not carried outside in avutil
[18:19] <ubitux> you will define AVRotationMatrix in lavu ofc
[18:20] <koda> so youd go for having the full matrix there too, right?
[18:23] <ubitux> sure
[18:23] <ubitux> it can be heap allocated too
[18:24] <ubitux> NULL ’ no matrix btw, that could work, no need for bit flags
[18:24] <ubitux> (but still a good idea to set the disposition for AVStream)
[18:27] <koda> im looking at it but its used mostly for textual information
[18:27] <ubitux> it's just bool flags iirc
[18:28] <ubitux> you'd just do st->disposition |= AV_DISPOSITION_ROTATED and set your matrix
[18:29] <koda> well you have to check two places to get it though
[18:30] <ubitux> ?
[18:30] <ubitux> of course
[18:30] <ubitux> it's important to keep a distinction between both
[18:31] <koda> hm not sure, you could just check if the rotation side data is present and then do that
[18:31] <ubitux> maybe you could set one or another depending on one's value
[18:31] <ubitux> but that depends on the politic of which override which
[18:31] <ubitux> why the hell do you want to put side data in every AVPacket?
[18:31] <ubitux> that has nothing to do with it
[18:31] <koda> avstream
[18:32] <koda> and id put it only once
[18:32] <ubitux> i only know avpacket side data
[18:32] <ubitux> what's this stream side data you're talking about?
[18:33] <ubitux> ah there is a stream->side_data
[18:34] <ubitux> oh that was some recently added nastiness for that exact purpose
[18:34] <ubitux> :)
[18:34] <koda> i wouldnt call it nastiness, but yeah
[18:34] <ubitux> i really don't see the point of this
[18:35] <ubitux> i mean, what's the benefit of this over special field for each entry?
[18:35] <ubitux> here api users need will have to mess with a side data api
[18:35] <ubitux> instead of just accessing fields
[18:36] <ubitux> afaict side data in avpacket makes sense because avpacket can (could?) be on the stack so it needs to be small
[18:36] <ubitux> AVStream is heap allocated so it doesn't matter
[18:36] <ubitux> ...but maybe i'm wrong.
[18:36] <nevcairiel> they dont like cluttering the struct with format specific fields, is the only reason
[18:36] <ubitux> it's not format specific
[18:37] <ubitux> rotation could be in various format
[18:37] <koda> because you cant just add fields everywhere everytime something new is available
[18:37] <nevcairiel> its video specific, thats reason enough :D
[18:37] <ubitux> nevcairiel: ahah
[18:37] <ubitux> koda: how so?
[18:37] <ubitux> you just add them at the end
[18:37] <ubitux> it's not stack allocated as i said
[18:37] <koda> its messy
[18:37] <ubitux> you use an api to create those streams
[18:37] <ubitux> how so?
[18:38] <koda> not every stream has rotation information, so its useless to add fields that do not apply to the majority of cases
[18:38] <ubitux> this is probably true for 80% of the fields in AVStream
[18:38] <ubitux> and it's fine to have unused fields
[18:39] <koda> i beg to disagree, and if its true for other fields, its not the case to add even more
[18:39] <ubitux> it's simpler to use for user
[18:39] <ubitux> simpler to understand
[18:39] <ubitux> and less access overhead
[18:39] <koda> umh not really simpler and you get overhead when passing that structure around
[18:40] <ubitux> ??
[18:40] <ubitux> you pass a pointer&
[18:40] <koda> ah right nevermind
[18:41] <koda> but its not like calling a function in a slowpath will reduce performance
[18:41] <koda> and its tidier and simpler for users, imho
[18:41] <ubitux> it's not like there is any single benefit of doing like this
[18:41] <ubitux> no it's not
[18:41] <ubitux> stream->field is simpler than av_get_side_data(stream) ... and interpret the binary shit side data is
[18:41] <koda> ive interrogated many downstreams and they seem pretty ok with accessors rather than filling up contextes
[18:42] <koda> and its not binary again
[18:42] <nevcairiel> i was never asked
[18:42] <ubitux> that's not an accessor
[18:42] <ubitux> look at how you use side data
[18:42] <ubitux> that's a pain
[18:42] <ubitux> while i can understand the logic for replaygain tags (and even that... it should be in metadata) i could understand
[18:42] <ubitux> but rotation is somehow generic
[18:42] <ubitux> it doesn't belong in this side data insanity
[18:42] <ubitux> just add a matrix and be done with that
[18:43] <koda> nevcairiel: i asked for feedback before and the patch on the other side is waiting for feedback for months
[18:43] <ubitux> don't try to overthing a shitty api, it's not worth the effort
[18:43] <ubitux> anyway, gtg
[18:43] <koda> i dont agree sorry
[18:43] <koda> its not metadata
[18:43] <koda> nor its disposition
[18:43] <ubitux> i was talking about replaygain
[18:43] <ubitux> that's something else
[18:43] <ubitux> (when talking about metadata)
[18:43] <koda> well side data can be both because its generic
[18:44] <ubitux> it's a generic and really painfull way of accessing non generic fields
[18:44] <koda> exactly which right now only 1 format exposes
[18:44] <ubitux> i'd say you should just add a generic rotate field and be done with that
[18:45] <ubitux> well it's not hard to imagine rotation field in various other formats
[18:45] <koda> ok thanks for the feedback, i disagree because of the reasons exposed ago
[18:45] <koda> above*
[18:45] <ubitux> you have no good reason to disagree
[18:45] <koda> i have
[18:45] <koda> read above
[18:45] <ubitux> well you didn't give any good argument
[18:45] <ubitux> i read
[18:45] <ubitux> and it's wrong
[18:45] <ubitux> gtg
[18:45] Action: ubitux &
[18:45] <koda> ubitux: you not liking something doesnt make something wrong
[18:46] <koda> and i gave enough arguments, from expandibility to tidiness
[18:46] <nevcairiel> you liking it doesnt make it right
[18:46] <koda> nevcairiel: no, my writing it makes it right :p
[18:46] <nevcairiel> every of your arguments is pretty weak, and can be taken as-is and turned around against it instead :p
[18:47] <koda> nevcairiel: well what would you suggest?
[18:47] <nevcairiel> first and foremost, make it easy to use, noone likes complicated api for the sake of cleanlyness
[18:48] <nevcairiel> when designing API, that should always be your primary goal
[18:48] <koda> nevcairiel: ok checking for disposition and then rotationmatix doesnt seem that simple either
[18:48] <nevcairiel> if you have to go and ask downstreams if they would mind this slightly more complicated approach, you're already doing it wrong :)
[18:49] <koda> nevcairiel: im asking downstreams because users proposed 4 different ways (now 5) of doing it 
[18:49] <nevcairiel> especially because those established downstreams are already familiar with the oddities of the API, and may accept more crazyness than a new developer might before going crazy :D
[18:50] <koda> nevcairiel: im just trying to find the one that dissatisfies the least
[18:53] <koda> anyway i think i gathered enough feedback
[18:53] <koda> cya
[19:25] <cone-476> ffmpeg.git 03Anton Khirnov 07master:b9dea23766f5: resample: fix avresample_get_delay() return value
[19:25] <cone-476> ffmpeg.git 03Michael Niedermayer 07master:c04961fa0ff6: Merge commit 'b9dea23766f52b8e059e72d34980bb7b456efe8f'
[19:29] <ubitux> > gathered enough feedback
[19:29] <ubitux> completely ignored them actually
[19:35] <cone-476> ffmpeg.git 03Anton Khirnov 07master:f20892eb67a7: resample: split the nearest neighbour path into a separate function pointer
[19:35] <cone-476> ffmpeg.git 03Michael Niedermayer 07master:671f9086571a: Merge commit 'f20892eb67a7b4b5a3c080388a35a3380516a805'
[19:43] <cone-476> ffmpeg.git 03Anton Khirnov 07master:3c84f6b5d20c: resample: reindent
[19:43] <cone-476> ffmpeg.git 03Michael Niedermayer 07master:fb7d64df7e3b: Merge commit '3c84f6b5d20cd345fac706f8cfb70c55e541ffb5'
[20:24] <jnvsor> Can't ./configure on sid any more - says something about missing hogweed?
[20:24] <cone-476> ffmpeg.git 03Anton Khirnov 07master:eed752d61da3: resample: drop useless abs()
[20:24] <cone-476> ffmpeg.git 03Michael Niedermayer 07master:6d6bd16fce08: Merge commit 'eed752d61da332fb13e9893a175a90fed7b1d7d3'
[20:39] <cone-476> ffmpeg.git 03Anton Khirnov 07master:be394968c810: resample: add initial padding explicitly
[20:39] <cone-476> ffmpeg.git 03Michael Niedermayer 07master:65088b925a0d: Merge commit 'be394968c81019887ef996a78a526bdd85d1e216'
[20:41] <michaelni> what configure command line causes this ?
[21:07] <cone-476> ffmpeg.git 03Anton Khirnov 07master:254c95cdd1b6: resample: split linear into its own function
[21:07] <cone-476> ffmpeg.git 03Michael Niedermayer 07master:662a8d882758: Merge commit '254c95cdd1b669a722204a4a65974fc2523c8f83'
[23:06] <cone-476> ffmpeg.git 03Derek Buitenhuis 07release/2.2:96e13c989750: libx265: Use x265_param_parse to set the SAR
[23:48] <cone-476> ffmpeg.git 03Michael Niedermayer 07master:88ceede1fd78: avcodec/jpegls: print coding parameters stored in LSE
[00:00] --- Sat Apr 12 2014