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

[burek]

[00:06] <cone-300> ffmpeg.git 03Michael Niedermayer 07master:2f6bb86f8588: swscale/utils: support bayer input + scaling, and bayer input + any supported output
[02:32] <rcombs> ubitux: why does ASS get AVFMT_NOTIMESTAMPS but SRT doesn't?
[03:07] <cone-936> ffmpeg.git 03Michael Niedermayer 07master:3e1ac1034535: avcodec/utils: Add ATRAC3+ to av_get_audio_frame_duration()
[08:28] <cone-949> ffmpeg.git 03Reimar Döffinger 07release/2.4:3e0802e42b07: configure: Hack to treat x32 as x86_64.
[08:30] <ubitux> rcombs: i don't know... i'm not actually aware of the effects of that AVFMT_NOTIMESTAMPS
[08:31] <ubitux> but ASS muxing definitely needs them
[08:31] <ubitux> thought, the way the dts are used might come into play here
[11:37] <ubitux> damn the edit lists are twisted
[11:38] <ubitux> like, first entry can be relative to whole presentation while others entry are relative to the stream itself
[12:00] <cone-671> ffmpeg.git 03Vittorio Giovara 07master:68a35473ed42: 4xm: more thorought check for negative index and negative shift
[12:00] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:64e12aec9654: Merge commit '68a35473ed423a14731c418939fba7913647979a'
[12:01] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:29234f568181: vp7: fix checking vp7_feature_value_size()
[12:01] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:8e6084eebe86: Merge commit '29234f56818135faf2f1868ab324c073abd28fbd'
[12:11] <cone-671> ffmpeg.git 03Vittorio Giovara 07master:b09cf8afc519: libopusenc: check return value
[12:12] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:3c6e148e843e: Merge commit 'b09cf8afc5199d359ac985ad7cea72a6a9f20e4e'
[12:52] <cone-671> ffmpeg.git 03Vittorio Giovara 07master:8dd0a2c5cf40: libopusenc: prevent an out-of-bounds read by returning early
[12:52] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:aa7c429c4e8e: nellymoserenc: fix array element ordering
[12:52] <cone-671> ffmpeg.git 03Vittorio Giovara 07master:bdcb5794f0c2: nellymoserenc: fix array index
[12:52] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:7b824e8b25cb: Merge commit '8dd0a2c5cf40a8a49faae985adc11750b6429132'
[12:52] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:0f29e92091d4: Merge commit 'aa7c429c4e8e561009176d51b7dcb626c85eb276'
[12:52] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:946a5cb64d58: Merge commit 'bdcb5794f0c2d74371152303bffe4172671af264'
[13:04] <cone-671> ffmpeg.git 03Vittorio Giovara 07master:b1b1a7370e14: display: fix order of operands
[13:04] <cone-671> ffmpeg.git 03Vittorio Giovara 07master:e3f50f247155: dnxhdenc: check negative index
[13:04] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:76fa78911f58: Merge commit 'b1b1a7370e141c912e3d0bbaa668dcee05c3ad67'
[13:04] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:7f8ef7876efe: Merge commit 'e3f50f247155216229e34f165bae8c329d5a001e'
[13:04] <rcombs> ubitux: one effect is allowing negative timestamps
[13:05] <rcombs> ubitux: if it (and AVFMT_TS_NEGATIVE iirc) are not present, the first frame gets shifted to start at 00:00:00 if its timestamp is negative
[13:06] <rcombs> ubitux: which can be really confusing behavior for e.g. using ffmpeg to shift times in plain SRT files
[13:31] <cone-671> ffmpeg.git 03Vittorio Giovara 07master:2c98dc75f280: vc1dec: always initialize tx and ty
[13:31] <cone-671> ffmpeg.git 03Vittorio Giovara 07master:28d82b7675be: vc1dec: refactor check with missing parenthesis
[13:31] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:94cf1ef008c2: Merge commit '2c98dc75f2802a2fe91922d4a11b698b66420e5b'
[13:31] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:ef4e54e0df44: Merge commit '28d82b7675bea76a1349070a3cdd737d964d4775'
[13:35] <rcombs> ubitux: weirdly, the behavior is different between seeking on input and output
[13:36] <rcombs> ubitux: try `ffmpeg -ss 25:00 -i longfile.srt outfile.srt`, where 25:00 is between 2 subtitles
[13:36] <rcombs> I'd say it doesn't give the expected behavior
[13:40] <ubitux> rcombs: aren't you looking for -itsoffset?
[13:40] <rcombs> if I'm trying to shift without clipping, yes
[13:40] <rcombs> (right?)
[13:40] <ubitux> yeah, i guess
[13:41] <rcombs> it's at least somewhat weird that -ss as an output arg gives the expected behavior, but as an input arg it doesn't
[13:41] <ubitux> it's probable this stuff is a bit buggy, i admit i haven't look closely
[13:41] <cone-671> ffmpeg.git 03Vittorio Giovara 07master:4dda5e9b0829: sunrastenc: mention missing break
[13:41] <cone-671> ffmpeg.git 03Vittorio Giovara 07master:e9a6ae775dab: dpxenc: mention missing break
[13:41] <cone-671> ffmpeg.git 03Vittorio Giovara 07master:5aa710f46119: vorbisenc: add missing parenthesis
[13:41] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:ccfae038152b: Merge commit '4dda5e9b0829b119c17d950906c61d3ebffc494f'
[13:41] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:b882079b1265: Merge commit 'e9a6ae775dabef3942632e8d4ef95fff94a1b310'
[13:41] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:198e55bfa791: Merge commit '5aa710f46119bb9c1c38542f80f5338eb8b5ffb2'
[13:41] <ubitux> also make sure you don't involve the decoding chain in your test
[13:42] <ubitux> like, try if it's different with -c copy
[13:43] <ubitux> i remember fixing some stuff so ffmpeg -ss 123 -i in.mkv -c copy out.mkv work fine
[13:43] <ubitux> but if transcoding is involved, timestamps might be messed up
[13:43] <ubitux> (because of the timestamps still in the decoded form blabla you know the story)
[13:43] <rcombs> no difference
[13:43] <ubitux> ok
[13:44] <ubitux> i don't know...
[13:44] <rcombs> ffmpeg.c itself shifts the timestamps so the first frame starts at 00:00
[13:44] <rcombs> (to avoid a negative timestamp)
[13:44] <ubitux> ok..
[13:44] <rcombs> I'm not sure why it works differently for an output seek
[13:45] <rcombs> might have to do with the lack of a `strim` filter to insert
[13:45] <ubitux> please open a ticket if you can summarize the weird behaviour(s) and inconsistencies
[13:45] <rcombs> sure
[13:58] <cone-671> ffmpeg.git 03Vittorio Giovara 07master:6abe7edabb7d: ffv1: fix out-of-bounds read
[13:58] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:e266e186cf12: Merge commit '6abe7edabb7d57e82d7ea6312d30cf05d2192c5b'
[14:07] <cone-671> ffmpeg.git 03Vittorio Giovara 07master:2ffb0598dbdb: mlpdec: check for negative index
[14:07] <cone-671> ffmpeg.git 03Vittorio Giovara 07master:1a9c1333b5d7: escape124: explicitly set get_bits1 variable
[14:07] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:9b424accbe10: Merge commit '2ffb0598dbdb81c40650952aa9299fa02fa5e834'
[14:07] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:2c4d5d3497e9: Merge commit '1a9c1333b5d70b427c82cb98f383aa2fa9b2b319'
[14:29] <cone-671> ffmpeg.git 03Vittorio Giovara 07master:d5d2d6c3b8cf: dcadec: initialize variables before use
[14:29] <cone-671> ffmpeg.git 03Vittorio Giovara 07master:8e104619a627: shorten: check for return value
[14:29] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:785f71fcd508: Merge commit 'd5d2d6c3b8cff61eb26c18bbd977881cf6d5524a'
[14:29] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:ecb748866e00: Merge commit '8e104619a627fcf5f4c2bd3c09d0c2d323aae745'
[14:45] <cone-671> ffmpeg.git 03Vittorio Giovara 07master:c6d7c201dfa8: indeo3: check ff_set_dimensions return value
[14:46] <cone-671> ffmpeg.git 03Vittorio Giovara 07master:2b5c1efa1465: g2meet: check ff_set_dimensions return value
[14:46] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:dfa0800c414a: Merge commit 'c6d7c201dfa80502cb6cefbee7dc9160cedb5187'
[14:46] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:b697a3314e84: Merge commit '2b5c1efa1465d8646f8be525cace7a21404e40ad'
[15:03] <cone-671> ffmpeg.git 03Vittorio Giovara 07master:c7384664ba0c: avs: check ff_set_dimensions return value
[15:03] <cone-671> ffmpeg.git 03Vittorio Giovara 07master:994ab1804b8b: ansi: check ff_set_dimensions return value
[15:03] <cone-671> ffmpeg.git 03Vittorio Giovara 07master:59846452af76: svq1enc: check ff_get_buffer return value
[15:03] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:04f6a5230db8: Merge commit 'c7384664ba0cbb12d882effafbc6d321ae706cff'
[15:03] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:057b74d19c0f: Merge commit '994ab1804b8bf532f44876927b07b51f1f63247f'
[15:03] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:45660c7d1b76: Merge commit '59846452af762f6af5ced4399e8dcd709ca50fcd'
[15:26] <cone-671> ffmpeg.git 03Vittorio Giovara 07master:a2448cfe167a: jpeg2000: do not compute the same value twice
[15:26] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:7a79c055e378: Merge commit 'a2448cfe167a4cd4eb631318550d4eef38fca24a'
[15:32] <ubitux> why is there so much time shift craziness in the mov demuxer because of the edit list?
[15:32] <ubitux> i mean, it's supposed to be a start time, why not use st->start_time
[15:32] <ubitux> and let the application deal with that?
[15:38] <cone-671> ffmpeg.git 03Peter Ross 07master:2093c1dc51ee: cinedec: report white balance gain coefficients using metadata
[15:38] <Daemon404> ubitux, youll likely not find out
[15:39] <Daemon404> most of that stuff in mov*c is from The Time Before Commit Messages
[15:40] <ubitux> everything starts at baf2ffd3297b707dbb5794ec568c61091acf5c0c according to git log -p --reverse --full-diff -Gtime_offset libavformat/mov.c
[15:41] <Daemon404> ive found usually when i look at mov.c it goes back to some commit form baptiste with a useless message, and like 5 changes in one commit
[15:41] <Daemon404> from svn times
[15:48] <wm4> even today, commit messages are neglected
[15:49] <wm4> and my patch that fixes the big Libav memory leak still wasn't reviewed yet
[15:51] <ubitux> ok i think i get it...
[15:52] <ubitux> so basically, we support the presentation start_time and the and eventually an initial skip in the stream itself
[15:52] <wm4> initial skip?
[15:53] <ubitux> and instead of having them treated separately (like using st->start_time for presentation and the ts adjustement for the initial skip), the same logic is used, afaiu
[15:53] <ubitux> wm4: yeah, basically, you have a concept of start_time (so relative to presentation)
[15:53] <ubitux> and then the other entries specifies how each segment can cut/skip parts of the stream itself
[15:54] <ubitux> basically we support both that concept of start_time and the skip of the first segment
[15:54] <ubitux> and it's kind of "merged" into the same logic
[15:54] <wm4> not sure if I get it
[15:55] <ubitux> ok. so... edit list in mp4 are kind of weird, they have 2 usages
[15:55] <ubitux> so you have edit list for each streams
[15:56] <ubitux> and if for example you have a presentation of 40 seconds
[15:56] <ubitux> audio st is 40 seconds, and video st is 30 seconds
[15:56] <ubitux> you want video st with a start_time of 10
[15:56] <ubitux> what you do is that you create an edit list in the video st
[15:56] <wm4> so the first 10 seconds have no video or what?
[15:56] <ubitux> and the first entry is {.time=-1, duration=10}
[15:57] <ubitux> this particular "empty" edit list entry basically translates to this start_time
[15:57] <ubitux> wm4: yeah well, don't ask me, maybe static frame or dunno
[15:57] <ubitux> you can take the audio example if you prefer
[15:57] <ubitux> like audio starting later
[15:58] <wm4> mpv and ffplay would in this case keep reading packets from the demuxer to find the next video frame
[15:58] <ubitux> anyway, you can have such empty entry (which you can identify by time=-1)
[15:58] <ubitux> and then you can have other entries
[15:58] <ubitux> which are relative to the stream itself
[15:58] <wm4> (this actually happens with mov files that contain "slide shows", which very low number of video frames)
[15:58] <wm4> *with
[15:58] <ubitux> like, you can say to skip some frames in the stream itself
[15:58] <wm4> ok
[15:59] <ubitux> like you can have {.time=-1, duration=10} followed by {.time=5, duration=whatever}
[15:59] <ubitux> so basically the video stream starts after 10 seconds in the presentation
[15:59] <ubitux> but you actually have to skip 5 seconds of video
[15:59] <ubitux> so currently, we seem to support that
[16:00] <ubitux> but that's the most complex pattern we support
[16:00] <ubitux> and both this start_time and skipping is handled with the same logic
[16:00] <ubitux> (setting some kind of time_offset and messing with pts/dts/whatever)
[16:00] <ubitux> all at demuxer level
[16:00] <ubitux> that's how i understand it
[16:00] <ubitux> but i might be wrong :)
[16:01] <ubitux> what we don't support is having more than 1 skip/duration entry
[16:02] <wm4> or cutting up frames
[16:02] <ubitux> yeah right
[16:02] <ubitux> anyway, i think the start_time should be handled outside of stream skipping
[16:03] <wm4> so, in theory, you could implement everything in the demuxer, and use side-data to make the decoder cut up the frames
[16:03] <ubitux> basically by just setting st->start_time, assuming that's possible
[16:03] <ubitux> i don't know... maybe
[16:03] <ubitux> so packet side data saying "please ignore this?"
[16:04] <wm4> a high level API of some sort (NOT lavfi), which handles this kind of stuff, would be cleaner
[16:04] <wm4> yes
[16:04] <wm4> like AV_FRAME_DATA_SKIP_SAMPLES
[16:04] <wm4> that is used for gapless stuff, and to trim frame padding
[16:05] <ubitux> sounds more clumsy that exporting a timeline information along with the stream
[16:05] <ubitux> and let the application handle it the way it fits
[16:05] <ubitux> but i dunno
[16:05] <ubitux> s/that/than/
[16:06] <ubitux> (in ffmpeg/ffplay we would translate with timeline to a filtergraph which we would auto insert)
[16:06] <ubitux> also, i wonder how the timestamps should be adjusted with all these skips
[16:14] <wm4> ideally, a demuxer would just export the edit list, and another piece of code would turn it into a linear stream of some sort
[16:15] <wm4> which could be via lavfi, some high level API, a demuxer that passes through the packets and uses tricks like AV_FRAME_DATA_SKIP_SAMPLES...
[16:26] <ubitux> yeah maybe
[16:27] <ubitux> anyway, i'm curious about samples that make use of st->start_time
[16:27] <ubitux> for both audio and video
[16:28] <wm4> you could even use the libavdevice "lavfi" demuxer to turn a lavfi graph into something that can actually be used by applications
[16:28] <wm4> although you'd lose things like hw decoding
[16:28] <wm4> (my conclusion is that lavfi is not a playback engine)
[16:29] <ubitux> i like the idea of exporting a timeline through C API, and let user deal with that for now
[16:29] <ubitux> and in ffmpeg we will use our lavfi system
[16:30] <ubitux> but honestly, designing such monster api just to fix playback issues is kind of a pain
[16:36] <ubitux> specs: "If this field is set to 1, it is an empty edit. The last edit in a track shall never be an empty edit."
[16:36] <ubitux> first sample i'm checking:
[16:36] <ubitux> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7ff45c000920] st 0: duration=2437071 time=200 rate=1.000000
[16:36] <ubitux> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7ff45c000920] st 0: duration=2392423 time=-1 rate=1.000000
[16:37] <ubitux> great.
[16:37] <ubitux> thank you.
[16:37] <ubitux> ("this field"  time field, obviously)
[16:38] <ubitux> oh wait my bad... 
[16:38] <ubitux> not actually the stream. derp.
[16:40] <wm4> lol
[16:41] <wm4> I wouldn't be surprised if that actually happened
[16:41] <wm4> apparently it's normal for specs
[17:52] <cone-671> ffmpeg.git 03James Almer 07master:3cec54b7d72b: x86/flacdsp: add SSE2 and AVX decorrelate functions
[18:01] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:dae7e4e63da3: tests/tiny_psnr: remove redundant initialization
[19:06] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:4001fc426798: avcodec/4xm: remove duplicate assert
[21:13] <cone-671> ffmpeg.git 03Michael Niedermayer 07master:5c805d69a49a: avcodec/nellymoserenc: fix sign error
[21:49] <ubitux> can i push the xbr test?
[21:55] <michaelni> ubitux, y
[21:56] <ubitux> thanks
[22:07] <lukaszmluki> michaelni: are you ok with fate test update?
[22:15] <cone-671> ffmpeg.git 03Carl Eugen Hoyos 07master:34288651633a: lavc/flashsv2enc: Fix encoding resolution error message.
[22:29] <michaelni> lukaszmluki, will look at it in a few minutes, am working on some other patches atm
[22:31] <pross> does stefano still wander about here?
[22:31] <wm4> you mean saste?
[22:31] <pross> yes!
[22:34] <pross> saste: where did you get inspiration for gammaval()
[22:39] <saste> pross, i don't remember
[22:40] <saste> i remember it was proposed on the mailing-list during review, so you should be able to track it
[22:40] <cone-671> ffmpeg.git 03Aleksey Vasenev 07master:df8248f66e36: avfilter/vf_interlace: more accurate pts calculation
[22:40] <cone-671> ffmpeg.git 03Aleksey Vasenev 07master:8349001638fb: avfilter/vf_tinterlace: fix frame rate
[22:45] <pross> thanks
[22:46] <cone-671> ffmpeg.git 03Clément BSsch 07master:57688aecbd72: fate: add xBR filter tests
[22:47] <cehoyos> pross, saste: Maybe this thread: http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/121563
[22:47] <michaelni> lukaszmluki, you need accessor functions for recommended_encoder_configuration, see MAKE_ACCESSORS
[22:48] <michaelni> access to it from outside libavformat should use only these accessors
[22:53] <michaelni> lukaszmluki, maybe the opt serialize should start with something like serialize_format_version=123, not sure, also can be done later
[22:53] <michaelni> about the fate update, that should be ok
[22:57] <lukaszmluki> i forgot about this accessor
[22:57] <lukaszmluki> but i have to go, see ya later
[23:04] <pross> i propose to add a new lut gamma function iaw rec 709. what should this be called? gammaval709()?
[00:00] --- Fri Nov 14 2014