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

[burek]

[00:18] <cone-297> ffmpeg.git 03Michael Niedermayer 07master:d3068d25ca6d: avcodec: Add avpriv_mpa_decode_header2()
[00:18] <cone-297> ffmpeg.git 03Michael Niedermayer 07master:5669ae84016f: avcodec/mpegaudio_parser: treat codec_id like the other parameters
[00:18] <cone-297> ffmpeg.git 03Michael Niedermayer 07master:c33351f3e75d: avcodec/mpegaudio_parser: Delay setting codec_id if it appears wrong
[00:18] <michaelni> JEEB, that mp1+mp3 in mp4 thing should be fixed
[00:18] <JEEB> oh, thanks <3
[00:18] <michaelni> np
[00:19] <JEEB> one less I thing I have to work around elsewhere :)
[00:45] <superware> what's the difference between PTS and DTS?
[00:45] <Skyler_> PTS is Presentation Time Stamp, DTS is Decode Time Stamp
[00:46] <Skyler_> PTS = when it should go on your screen, DTS = when the decoder should eat it (assuming instantaneous decoding)
[00:46] <Skyler_> in the absence of B-frames or other frame reordering, PTS generally equals DTS.
[00:49] <superware> ok, so for display syncing I need PTS. but frame->pts is constant, maybe I should use frame->pkt_pts?
[00:51] <superware> Skyler_?
[00:53] <Skyler_> I only know of the generic terminology, I'm not precisely sure of the lavf details
[00:54] <superware> ok, thanks
[00:59] <cone-297> ffmpeg.git 03Nicolas George 07master:1b05ac220ef1: lavf: add write_uncoded_frame() API.
[00:59] <cone-297> ffmpeg.git 03Nicolas George 07master:62106fcc23cf: lavd/alsa: preliminary support of uncoded frame.
[00:59] <cone-297> ffmpeg.git 03Nicolas George 07master:d201a0f0f843: lavd/xv: preliminary support of uncoded frame.
[00:59] <cone-297> ffmpeg.git 03Nicolas George 07master:dcda5ef1eab5: lavf: add uncodedframecrc test muxer.
[00:59] <cone-297> ffmpeg.git 03Nicolas George 07master:8400368f319b: tools: add uncoded_frame test program.
[00:59] <cone-297> ffmpeg.git 03Nicolas George 07master:edc7e67669ad: lavf/lavd: version bump and APIchanges for uncoded frames.
[00:59] <cone-297> ffmpeg.git 03Michael Niedermayer 07master:058a3d65427e: Merge remote-tracking branch 'cigaes/master'
[01:03] <superware> I need to sync video frames for display, how can I go from PTS to time?
[01:04] <Skyler_> PTS * timebase = time in seconds
[01:06] <superware> video_stream->time_base is { den: 0, num = 429849479 } so 429849479 / 0?
[01:08] <Skyler_> that sounds like "completely and totally invalid"
[01:13] <superware> does a timebase of 0.02 make sense?
[01:15] <Skyler_> superware: that makes sense, that would be 50fps
[01:15] <Skyler_> (typically)
[01:16] <superware> ah... can't be
[01:16] <superware> that's the codec timestamp
[01:21] <superware> what a mess, isn't there a safe way to get a specific frame PTS?
[01:22] <Skyler_> I think it's generally better to rely on the container timestamps
[01:24] <superware> you mean frame->pkt_pts * av_q2d(_video_dec_ctx->time_base) ?
[01:31] <superware> the video stream time_base is 429849479/0 and the codec context time_base is 1/50, none makes sense
[01:39] <BtbN> 1/50 makes perfect sense
[01:42] <superware> the video is 25 fps
[01:44] <BtbN> is it interlaced?
[01:44] <Skyler_> the timebase being 2x the fps is pretty common for h264 videos
[01:44] <Skyler_> but you could have a timebase of 1/1000 for a 25fps video; that would be valid too
[01:45] <superware> I don't know if it's interlaced (http://ch0.jurnaltv.md/channel0.flv)
[01:45] <Daemon404> "but frame->pts is constant" <-- this sounds very, very wrong
[01:46] <superware> frame->pkt_pts seems ok
[01:46] <BtbN> fps = avctx->time_base.den / (avctx->time_base.num * avctx->ticks_per_frame); is what i use to get the fps.
[01:47] <Daemon404> which is also invalid in many cases
[01:47] <BtbN> not that exact code, though. That wouldn't work
[01:48] Action: Daemon404 checks that file
[01:48] <superware> isn't there a safe way to get a frame's PTS in seconds/milliseconds?
[01:49] <BtbN> pts * timebase
[01:49] <Daemon404> frame->pts
[01:50] <Daemon404> superware, that is a stream right?
[01:50] <superware> BtbN: for frame->pkt_pts * av_q2d(_video_dec_ctx->time_base) I'm getting 0.8 (seconds?) between frames
[01:50] <superware> @Daemon404: yep
[01:50] <Daemon404> superware, do not use pkt_pts
[01:50] <Daemon404> it doesnt do what you want
[01:51] <Daemon404> im seeing the stream time base correctly set
[01:52] <Daemon404> for both streams
[01:52] <superware> see http://stackoverflow.com/a/18842961/1549486
[01:52] <Daemon404> well
[01:52] <Daemon404> are you going to believe a developer of ffmpeg and heavy downstream user
[01:52] <Daemon404> or a random stack overflow answer?
[01:52] <superware> "AVFrame.pts is not ever set to anything useful when decoding, ignore it (it might replace pkt_pts in the future, to make the whole mess less confusing, but for now it's like this, for historical reasons mostly)."
[01:52] <superware> heh
[01:53] <Daemon404> first question: are you calling avformat_find_stream_info() first?
[01:53] <superware> yep
[01:54] <Daemon404> im able to get the proper pts and stream timebase here from that url
[01:54] <Daemon404> so next question: git head
[01:54] <Daemon404> ?
[01:54] <superware> I see the video (no syncing yet)
[01:54] <Daemon404> also i just realized that elenril wrote that stackoverflow answer
[01:55] Action: Daemon404 will have to stab him
[01:55] <superware> 2.1.3
[01:55] <Daemon404> try head first
[01:55] <superware> what's head?
[01:56] <Daemon404> git HEAD
[01:56] <Daemon404> git master
[01:56] <Daemon404> latest git
[01:56] <superware> a sec
[01:56] <Daemon404> also you should be calling av_frame_get_best_effort_timestam
[01:56] <Daemon404> p
[01:56] <Daemon404> (i hate it too... such is the API
[01:57] <Daemon404> this way you dont need to worry about accessing the right thing
[01:59] <Daemon404> av_frame_get_best_effort_timestam(frame) * timebase is givng me correct results
[01:59] <Daemon404> note that since it's a stream it has a non-zero starting PTS
[01:59] <superware> is av_frame_get_best_effort_timestamp external?
[02:00] <Daemon404> external?
[02:00] <Daemon404> it's in libavutil/frame.h
[02:02] <superware> frame.c -> "they should not be accessed directly outside libavcodec"
[02:03] <Daemon404> its telling you to use av_frame_get_best_effort_timestamp() nstead of directly accessing the pts member
[02:03] <Daemon404> as i suggested you do above
[02:10] <superware> ok, av_frame_get_best_effort_timestamp(frame) * av_q2d(_video_stream->time_base) seems to work! thanks
[02:11] <Daemon404> np
[02:12] <superware> what's the most basic way to sync the frames? I have a thread that's pulling frames from a queue...
[02:12] <Daemon404> the best you can do is probably based on time
[02:12] <Daemon404> im not very versed in realtime streamign sync stuff.
[02:13] <superware> why is it needed to sync a real-time stream? frames can't come early anyway..
[02:18] <Daemon404> well i dont know much about the playback side of things
[02:18] <Daemon404> sync etc
[02:41] <superware> thanks
[03:24] <superware> I'm using libav to play a live network stream, does it make sense to render frames as they arrive, without any sync?
[03:34] <superware> anyone?
[06:43] <cone-487> ffmpeg.git 03Michael Niedermayer 07master:a0911b059763: avformat/mov: fix keyframe flags for sample from chromium Issue 340865
[07:28] <smoak> if i have a patch submitted (via git send-email) and it needs to be updated with a new commit, do i just use git send-email --in-reply-to=<message id of the message i am replying to> to send the new commit? or is there a better/preferred way?
[07:36] <smoak> or should i start a new thread with the entire patch series?
[07:37] <ubitux> as you pleased
[07:37] <ubitux> we see both
[07:37] <ubitux> if you resend the complete patchset, eventually add a [v2] or something
[07:37] <ubitux> there is no real convention though
[07:37] <smoak> ok thank you
[08:28] <Keestu> hi,  av_read_frame (), i understand it reads the packet, but what i do not understand is does the syncronization between server and this api is taken care by framework or do we have to take care ?. Sorry if the question is very basic. i am at beginning level of exploring ffmpeg. 
[08:29] <Keestu> means does av_read_frame() provides all the streaming data from rtsp server?   while(1) {  sleep for sometime;  now do av_read_frame() }...
[10:14] <cone-326> ffmpeg.git 03Clément BSsch 07master:b6c0f07d5a11: avfilter/lut3d: inline whole loop in interpolation function.
[10:56] <ubitux> Timothy_Gu: https://github.com/FFmpeg/fateserver
[11:04] <ubitux> ah, wait, you wanted the original
[11:04] <ubitux> it was hosted on git.mansr.com previously
[14:12] <cone-480> ffmpeg.git 03Derek Buitenhuis 07master:bb6b1731eba2: Add libx265 encoder
[14:21] <durandal_1707> michaelni: who is working on dts-xll?
[14:22] <j-b> durandal_1707: Niels Möller, the nettle guy
[14:22] <wm4> durandal_1707: see libav-devel
[14:23] <j-b> on a bounty from us
[14:23] <durandal_1707> and what he have done?
[14:23] <j-b> not much yet
[14:23] <nevcairiel> he just started this week  it seems
[14:23] <durandal_1707> well i have some code i did done
[14:24] <durandal_1707> but i then stopped
[14:24] <j-b> he is a nice guy and quite competent
[14:24] <j-b> and working with merbanan :)
[14:25] <merbanan> durandal_1707: I have pointed him to your repo
[14:25] <michaelni> and picked libav because "I think it was my colleague who suggested I work with the libav tree"
[14:25] <durandal_1707> i just did basic bitstream header parsing
[14:26] <durandal_1707> not in the repo
[14:26] <JEEB> ok, great :) this cleared a lot around XLL
[14:26] <JEEB> ok, I guess since I never even got to writing a parser I'll stop my attempts then
[14:26] <JEEB> one less thing on the TODO list I guess
[14:26] <durandal_1707> parser? parser should work without any problems
[14:27] <j-b> michaelni: sorry, but it makes sense to work around Kostya, since he is the only one who actually wrote a DTS-HD-MA decoder
[14:27] <durandal_1707> but libav dts code does not have lot of stuff ffmpeg one has
[14:28] <j-b> sure
[14:28] <j-b> libav sucks more than ffmpeg on dts decoding
[14:28] <j-b> yet the main thing here is xll
[14:28] <JEEB> I think someone was already in the process of backporting the dts stuff from FFmpeg
[14:28] <nevcairiel> but xll shares  dts-hd asset parsing, which is used for all hd extensions, which ffmpeg already has
[14:29] <durandal_1707> i just pushed my trivial 200line insertions to xll branch
[14:30] <j-b> I don't think the hard part is the asset parsing, but the missing bits
[14:30] <nevcairiel> but if someone is already trying to backport, what do i care, i only want the finished feature in the end
[14:30] <merbanan> durandal_1707: great I have informed Niels
[14:30] <j-b> DTS-HD-MA is the biggest missing codec, as far as I am concerned
[14:31] <kierank> yeah the hard part is the things not in the spec
[14:31] <nevcairiel> did vlc at least get HD bitstreaming yet? I havent been following it at all :)
[14:31] <Daemon404> j-b, we'll still be missing one bluray codec after though
[14:31] <kierank> lossless core transform
[14:31] <kierank> s/lossless/bitexact
[14:31] <nevcairiel> Daemon404: eac3?
[14:31] <j-b> Daemon404: MVC?
[14:32] <Daemon404> no
[14:32] <j-b> nevcairiel: hdmi passthru?
[14:32] <Daemon404> some chinese crap
[14:32] <nevcairiel> j-b: yea
[14:32] <Daemon404> which is actually in the spec
[14:32] <Daemon404> iirc
[14:32] <j-b> nevcairiel: I have a branch for this
[14:32] <j-b> Daemon404: wut?
[14:32] <Daemon404> no, really.
[14:32] <JEEB> I don't remember such from the spec
[14:32] <nevcairiel> Daemon404: well it still lacks proper eac3 support too. It can only decode the ac3 "core" but not the eac3 dependent frames with the extra channels, so you get only 5.1 and not 7.1, similar to DTS-HD just not lossless :)
[14:32] <Daemon404> kierank might know
[14:33] <kierank> DRA audio
[14:33] <kierank> chinese dts
[14:33] <JEEB> oh
[14:33] <nevcairiel> although this shouldn't be too hard. I thought about trying it once, but time...
[14:33] <j-b> http://en.wikipedia.org/wiki/Dynamic_Resolution_Adaptation ?
[14:34] <kierank> yeah and the spec is in chinese iirc
[14:34] <durandal_1707> i'm sick of shitty codecs
[14:34] <nevcairiel> that seems kinda stupid, accept something into an international spec like the blu-ray spec which doesnt even have a english spec? :p
[14:36] <j-b> did they include 4k in the new bluray spec?
[14:37] <nevcairiel> last i heard they are still working on a new version with 4k
[14:38] <ubitux> is Kyle on irc?
[14:39] <nevcairiel> kyle who?
[14:39] <JEEB> kierank, hmm, interestingly I can't see DRA mentioned in version 2.01 of the spec. Granted, this is pretty old by now :P
[14:39] <kierank> it's relatively recent yes
[14:39] <j-b> JEEB: added in 2.3
[14:39] <JEEB> ah
[14:40] <nevcairiel> isnt there like version 5 by now
[14:40] <nevcairiel> might be confusing profiles with spec versions
[14:41] <j-b> I thought we were at 2.4 or 2.5
[14:42] <ubitux> nevcairiel: schwarz
[14:42] <JEEB> Part 3: Audio Visual Basic Specifications Ver.2.5 June 2011
[14:42] <JEEB> in ROM format version 3
[14:47] <j-b> Daemon404: interesting, I did not know about this codec.
[14:49] <Daemon404> i apologize for informing you
[14:49] <cone-480> ffmpeg.git 03Diego Biurrun 07master:25a1ba814ad8: log: Have function parameter names match between .c and .h file
[14:49] <j-b> Daemon404: :)
[14:49] <cone-480> ffmpeg.git 03Michael Niedermayer 07master:74744790a366: Merge commit '25a1ba814ad80056247fd357ec4c6911324a3f66'
[14:50] <j-b> Daemon404: more bounty ideas to waste VideoLAN money \o/
[14:50] <Daemon404> lu
[14:50] <Daemon404> lul
[14:52] <kierank> parc asterix > bounties :)
[14:54] <j-b> untrue
[14:56] <cone-480> ffmpeg.git 03Diego Biurrun 07master:4a7d3837b4dd: buffersrc: Have function parameter names match between .c and .h file
[14:56] <cone-480> ffmpeg.git 03Michael Niedermayer 07master:1bc3f1b73dff: Merge commit '4a7d3837b4dd17fff270b55166597c093204e542'
[15:00] <kierank> j-b: if I were you i'd write some code that added some bass to DTS and say it was a lossles decoder
[15:00] <kierank> and see how many people actually nitce
[15:00] <kierank> notice*
[15:01] <JEEB> lol
[15:01] <j-b> none
[15:01] <Daemon404> i need lossless audio for my $2 d->a convert and 2.5 jack
[15:02] <Daemon404> it is absolutely necessary
[15:13] <kurosu_> Perhaps you meant "sampled at more than 2*20KHz" ?
[15:15] <Compn> i'd like to see the vlc http seeking bounty fixed :\
[15:18] <cone-480> ffmpeg.git 03John Stebbins 07master:462d5e8e6c05: aacdec: set AVFrame sample_rate
[15:18] <cone-480> ffmpeg.git 03Michael Niedermayer 07master:8c5fece11fcb: Merge commit '462d5e8e6c050eae7cbb1f2d5c34628088bd0eb6'
[15:23] <Compn> maybe i just need to pass vlc the option to use ffmpeg's network code
[15:25] <Compn> blah, libav.org 's redesign does not work for older opera browser
[15:26] <Compn> oh nevermind, some odd opera setting was on
[15:26] <Compn> ah, page zoomed in too far did it, i see.
[15:28] <Compn> yep, zoom too far in , same with firefox
[15:28] <Daemon404> it's almost as if you should use software from this decade
[15:28] <Compn> hey my firefox is updatd
[15:28] <Compn> try zooming into the page 
[15:28] <Daemon404> i dont zoom in
[15:29] <Compn> do it!
[15:31] <Compn> also happens if your browser window is skinny
[15:31] <Compn> i guess if you have lots of windows open and read browser in a limited window size
[16:15] <cone-480> ffmpeg.git 03Janne Grunau 07master:0ebb523f0723: asfdec: check ff_get_guid() return values during seeking
[16:15] <cone-480> ffmpeg.git 03Michael Niedermayer 07master:d32926db7f42: avformat/riff: return error code from ff_get_guid()
[16:15] <cone-480> ffmpeg.git 03Michael Niedermayer 07master:5634c9518f07: Merge commit '0ebb523f072322972ea446616676fff32e9603c6'
[16:26] <kurosu_> michaelni: no need to look at the lfe_dir patch for now, I see you are right for the scale, and will continue investigating from there
[16:26] <michaelni> ok
[16:29] <kurosu_> J_Darnley: by the way, my comments on asm are border-line nitpicky, only the inner loop might have an impact
[16:29] <kurosu_> for x86_64 and shift parameter, you're right: it's only win64 abi that only uses up to 4 gps for parameters
[16:31] <kurosu_> it's just that callee-saved parameters may cause noticeable extra work when too numerous but that again is probably not worth it
[16:35] <J_Darnley> Regarding your comment about inc/dec.  I have read conflicting things about the how useful they are.  Various arguments about speed.  All of which is probably horribly outdated when you are writing sse4 code.
[16:36] <cone-480> ffmpeg.git 03Andrew Kelley 07master:0c0825659652: asfdec: short-circuit seeking to the start of stream
[16:36] <cone-480> ffmpeg.git 03Michael Niedermayer 07master:f73901f815d0: Merge commit '0c082565965258dca143767cc6cb25e38b6e9ea3'
[16:43] <kurosu_> J_Darnley: yes - the only thing to consider nowadays is maybe "how long is the generated instruction" for code/cache size reasons
[17:02] <cone-480> ffmpeg.git 03Janne Grunau 07master:f5d92d9cab07: asfdec: fix seeking with fragmented packets
[17:02] <cone-480> ffmpeg.git 03Michael Niedermayer 07master:3e8b17f05b91: Merge remote-tracking branch 'qatar/master'
[17:05] <Compn> why the other ciphers task in gsoc ? i mean if they are used for some video format or network protocol, it might be nice to list that in there
[17:06] <Compn> i'm not against it of course, just curious
[17:55] <kurosu_> michaelni: well, prescaling the coeff table is slower...
[17:55] <kurosu_> this is strange
[17:56] <michaelni> for both C and asm ?
[17:57] <kurosu_> asm only, C is negligible
[17:57] <kurosu_> the order of operations in the C code has a bigger impact...
[17:59] <kurosu_> (note: fate-dts passes, so it's not a consequence of doing things improperly)
[18:00] <kurosu_> measuring the whole loop in lfe_interpolation_fir:
[18:01] <Daemon404> 31
[18:01] <Daemon404> woops.
[18:01] <kurosu_> before: 1367 now: 1378
[18:01] <kurosu_> testing win32
[18:02] <kurosu_> faster...
[18:02] <kurosu_> 1462 -> 1428
[18:03] <kurosu_> well, the change makes sense, let's just say these are the consequences of random things that will change at the next commit
[18:03] <kurosu_> the bigger issue is that it needs a (small) rewrite of the neon part
[18:05] <michaelni> agree on random
[18:12] <kurosu_> for the other change, about pre-shuffling the coeffs so as to reduce the shuffling inside of the function
[18:13] <kurosu_> I think this needs a x86/arm/...-specific function to achieve the proper shuffling
[18:13] <kurosu_> and an output buffer for the shuffled coeffs
[18:13] <kurosu_> where would you put this buffer? decoder context or dsp context ?
[18:30] <michaelni> all existing buffers we have are in the decoder contexts if iam not missing one
[18:30] <michaelni> or rather if i havnt forgotten one
[18:31] <kurosu_> nothing for mdct/fft ?
[18:32] <Daemon404> afaik all the fft and mdct buffers are in codec contexts
[18:32] <Daemon404> at least when i looked a year or so ago
[18:32] Action: Daemon404 may be wrong
[18:32] <kurosu_> I thought there were permutations that were arch-specific, but I don't remember either
[18:32] <kurosu_> anyway...
[18:33] <kurosu_> win32: no difference, win64: slower...
[18:33] <kurosu_> not surprising that it changes nothing: that's 2 shuffles in a function that takes 340 cycles
[18:34] <kurosu_> I don't think this one is worth it
[18:36] <kurosu_> (ie not in loop, and probably completely masked by ooo execution)
[19:52] <llogan> ubitux: his nick is Zeranoe 
[19:52] <llogan> IIRC
[20:16] <ubitux> llogan: ah..
[20:16] <ubitux> ok
[00:00] --- Thu Feb 13 2014