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

[burek]

[03:20] <cone-602> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n0.10.10': unknown revision or path not in the working tree.
[03:20] <cone-602> Use '--' to separate paths from revisions
[03:20] <cone-602> refs/tags/n0.10.10:HEAD: avutil/common: error out with clear message if __STDC_CONSTANT_MACROS is not defined with c++
[09:09] <plepere> hello
[09:16] <michaelni> hello
[11:10] <cone-150> ffmpeg.git 03Marton Balint 07master:105d4748cfc0: ffplay: avoid code duplication in AVFILTER enabled and disabled case
[11:10] <cone-150> ffmpeg.git 03Marton Balint 07master:61dd31977066: ffplay: add frame duration estimated from frame rate to VideoPicture
[11:10] <cone-150> ffmpeg.git 03Marton Balint 07master:5ecfcc7dff04: ffplay: add smarter method for determining video picture duration
[11:10] <cone-150> ffmpeg.git 03Michael Niedermayer 07master:1b3d3a9c87f1: Merge remote-tracking branch 'cus/stable'
[11:58] <cone-150> ffmpeg.git 03Michael Niedermayer 07master:a35e30b67222: avformat/libgme: decrease score by 1, fixes probetest failure
[11:58] <cone-150> ffmpeg.git 03Michael Niedermayer 07master:50a3c4c5d263: avformat/rsd: Check channels and sample_rate fields
[11:58] <cone-150> ffmpeg.git 03Michael Niedermayer 07master:7b7697646b9b: avformat/rsd: increase probe score, as misdetections are fixed
[13:04] <cone-150> ffmpeg.git 03Michael Niedermayer 07master:ff1d81b08c06: avformat/swfdec: check version and size during probing
[13:04] <cone-150> ffmpeg.git 03Michael Niedermayer 07master:3e6b7bbce510: avformat/segafilm: check 2nd tag
[13:31] <sspiff> does anyone here have any knowledge of DVB subtitles?
[13:32] <sspiff> It looks to me like 1 packet contains a region update for a block/line of subtitles, and ffmpeg decodes multiple of these packets into one AVSubtitle
[13:32] <sspiff> but I'm not sure how it decides that a frame is done
[13:34] <nevcairiel> there is a "frame done" packet
[13:34] <nevcairiel> called a display segment
[13:37] <sspiff> nevcairiel: ah ok, thanks!
[13:37] <sspiff> nevcairiel: since you seem to understand this, can I ask you a few more questions?
[13:37] <nevcairiel> I dont really understand it too deeply, but feel free to try
[13:39] <sspiff> well, I'm having a hard time understanding what's going on ffmpeg.c:783 to 790, it's basically manipulating the AVPacket pts for DVB subtitles, but I don't know why and how
[13:40] <sspiff> I'm having a hard time figuring out the relation of the MPEG-TS pts'es to ffmpeg's internal pts'es, as well
[13:40] <nevcairiel> the mpeg-ts pts should just end up in the AVPacket.pts without much change
[13:41] <nevcairiel> not sure whats up with the dvb timestamps there, i only really used the libraries, not the ffmpeg application itself
[13:41] <sspiff> nevcairiel: alright, thanks.
[13:45] <sspiff> Looks to me like it's writing out two packets, and it's setting the PTS of the first to the start time of the subtitle, and the second to the end time (probably one to display and one to clear?)
[13:45] <sspiff> (I'm just thinking out loud, hoping someone will jump in and uncover the true problem :))
[13:47] <wm4> that code looks mysterious
[13:49] <sspiff> I'm getting the error (Application provided invalid, non monotonically increasing dts to muxer in stream 0: 551350 >= 309708) on the third AVPacket to go through do_subtitle_out, so I'm going to be guessing the third packet is the second subtitle being displayed, before the 1st has been cleared. (Possibly multiple display segments for one frame being issued)
[13:49] <sspiff> wm4: I've spent the past 2 days obsessing over it, hardly understanding anything
[13:49] <sspiff> but thanks to nevcairiel's comments, things are starting to make sense!
[13:51] <sspiff> Actually, there's a comment that says there's one packet to draw, one packet to clear. Doh!
[13:52] <kierank> it's obviously some hack of some sort
[13:52] <kierank> to fix some broken file
[13:54] <sspiff> what's the resolution of ffmpeg's PTSes?
[13:54] <kierank> comes from the container timebase
[13:55] <sspiff> Then what's "#define AV_TIME_BASE 1000000" for?
[13:55] <sspiff> because it seems like do_subtitle_out uses this (through AV_TIME_BASE_Q)
[13:58] <sspiff> but it seems like my statement is more or less correct
[13:58] <sspiff> it's not triggered by other subtitle outputs, because they don't have the blanking packet
[14:00] <nevcairiel> streams and codecs usually have their own timebase, but some global structures us the generic AV_TIME_BASE
[14:03] <sspiff> can I change dvbsubdec to hold on to subtitles until they're cleared, and outputting a new subtitle frame everytime something changed?
[14:04] <sspiff> that would make them bigger, but would negate the need for this kind of hackery
[14:12] <sspiff> anyone who has an oppinion on whether it would be acceptable to make the subtitles bigger for this case?
[14:13] <ubitux> there is a delay problem if you do that
[14:13] <ubitux> you're looking at removing the DVBSUB hack in ffmpeg.c?
[14:14] <sspiff> ubitux: yes
[14:14] <ubitux> i think marton was trying to achieve something similar with the teletext decoder
[14:15] <sspiff> ubitux: I wouldn't delay the first display, but I would just issue a clear & a new subtitle when the second comes along (possibly overlapping), with the new sub containing all the regions still visible
[14:15] <ubitux> maybe ask him directly, Marton Balint <cus -at- passwd.hu>
[14:15] <sspiff> ubitux: I will, thanks
[14:15] <sspiff> but can you elaborate what you mean by delay?
[14:15] <ubitux> sspiff: note that maybe i'm missing something, but when you call the decode function you feed it with a new packet everytime
[14:16] <ubitux> if half a time you return the decoded packet, and the other half an empty one (to end the previous)
[14:16] <ubitux> aren't you going to accumulate/skip half packets?
[14:16] <ubitux> there are some caps (check CAP_DELAY), look around this
[14:17] <ubitux> dunno if Marton got done with this
[14:17] <ubitux> problem is, doing this means API changes
[14:19] <sspiff> ubitux: a decode is called when the demuxer says "we have a complete packet", I suppose?
[14:20] <wm4> I find it ironic that the current API couldn't even implement a libass decoder
[14:20] <sspiff> and AVPacket needs to be fully constructed when it returns?
[14:20] <ubitux> sspiff: av_read_frame() returns a ready to decode packets
[14:20] <ubitux> with audio, you can (have to) call decode several time on that same packet sometimes
[14:20] <ubitux> (because the decode won't consume all the packet)
[14:21] <ubitux> this logic is not currently used for subtitles
[14:21] <ubitux> and we assume 1 packet = 1 decode
[14:21] <ubitux> sspiff: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/examples/demuxing_decoding.c;hb=HEAD#l319
[14:21] <sspiff> nevcairiel: you seem to know more about DVB subtitles than us, does one packet contain all the segments to do one update?
[14:22] <wm4> having a subtitle interface that works differently could help with wrapping libass, and with teletext stuff
[14:22] <ubitux> this is the generic demux/decode logic, used for audio (for video, it seems 1 packet = 1 video frame all the time anyway)
[14:22] <nevcairiel> not necessarily no, it can have one segment per packet, so you need multiple packets to handle a full cycle, at least AFAIK
[14:23] <sspiff> nevcairiel: so then an decode doesn't necessarily result in a new frame being produced.
[14:23] <nevcairiel> right
[14:24] <sspiff> decoding a packet would result in the manipulation of the changes being staged for the next frame, but the frame wouldn't necessarily be done
[14:53] <sspiff> modifying ffmpeg.c to keep the clear packet in a big, dirty static AVPacket dvbsub_clear, and only sending it out as soon as a subtitle packet with a higher PTS occurs "fixes" the transcoding
[14:53] <sspiff> obviously, the last clear will be missing
[14:53] <sspiff> which is (probably? you tell me...) unacceptable
[14:53] <sspiff> ubitux: I'm guessing the last clear can't be omitted
[14:58] <ubitux> static is even more blocking since it allows processing only one stream
[14:59] <sspiff> There's an almost disturbing amount of DVB subtitle specific stuff in do_subtitle_out...
[14:59] <sspiff> ubitux: right
[14:59] <sspiff> I could put it in the context
[14:59] <ubitux> and yes, encoding subtitles api is heavily broken
[15:04] <ubitux> sspiff: feel free to try hacks and even submit them as rfc on ffmpeg-devel for better suggestion
[15:04] <ubitux> as long as it helps understanding what the issue is :)
[15:41] <sspiff> is an OutputStream unique to a single video/audio/subtitle stream?
[15:42] <ubitux> sspiff: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/ffmpeg.txt;hb=HEAD
[15:42] <ubitux> not sure this is still up-to-date
[15:42] <ubitux> but it might give you some hints
[15:42] <sspiff> thanks ubitux :)
[15:49] <sspiff> ubitux: am I reading that correctly, when I say a container file or transport stream or whatever else needs muxing is created from a bunch of  OutputStreams, where every OutputStream is a single component (audio, video, subtitle, ...)
[15:51] Action: ubitux parse error around `needs muxing'
[15:52] <sspiff> an output file looks to me like it's something like a container etc, where you put in several streams, right?
[15:52] <ubitux> yes sure
[15:53] <ubitux> sspiff: formats is an alias for containers, handled by libavformat; demuxing/muxing
[15:53] <ubitux> sspiff: codecs is handled by libavcodec, decoding/encoding
[15:54] <sspiff> and a stream is something a codec works with, a format is something a muxing/demuxing plugin works with?
[15:54] <ubitux> each stream can be of type audio, video, subtitles (and a few others)
[15:54] <ubitux> some formats can contain several streams and type of streams
[15:55] <ubitux> some formats have limitations on the type of codecs, total number of streams, ...
[15:55] <ubitux> sspiff: http://ffmpeg.org/ffmpeg.html#Detailed-description
[15:56] <sspiff> ubitux: thanks
[16:21] <sspiff> ubitux: how would keeping track of which rectangles are still "active" in the decoder need an API change?
[16:23] <ubitux> i don't understand the question
[16:33] <sspiff> ubitux: I may have skipped a few steps in my mind :)
[16:35] <sspiff> so my proposal was to keep track of which areas are active in dvbsubdec.c, and whenever a packet arrives that calls for something to be displayed, to reconstruct the entire subtitle and produce an AVSubtitle with that
[16:36] <sspiff> and everytime a new AVSubtitle is created, the previous one's end_display_time can be determined and filled in.
[16:37] <sspiff> This would require you to check if any of the active rectangles have expired, and potentially create more than one AVSubtitle for one packet of data that arrives, and the use of CODEC_CAP_DELAY, as you said
[16:39] <sspiff> but I don't see why it would require the API to be changed (I think you said it would need changing for this earlier)
[16:41] <sspiff> ubitux: I've written up an email describing the problem, and asking for suggestions on how to solve it. Is it OK to send without a draft solution? I really can't find a fix that doesn't have many grave pitfalls...
[18:53] <ubitux> sspiff: ofc, feel free to ask any question about ffmpeg development on the ml
[19:49] <llogan> michaelni: more spam. 3122 3123
[19:51] <llogan> michaelni: if you give me the correct permissions i can delete them instead of having to ping you each time
[20:15] <llogan> ubitux: Tip  Create a 15 second video sample for testing: ffmpeg -f lavfi -i testsrc=d=15 output.mkv
[20:15] <llogan> or maybe i should use -t 15
[20:16] <ubitux> both are fine
[20:16] <ubitux> =d=15 shows how to use filters options
[20:17] <llogan> downside is that they will not understand why their fave dumb player won't play it
[20:21] <llogan> unless i add format
[20:21] <llogan> maybe this is not such a good tip
[20:22] <ubitux> mmh?
[20:22] <ubitux> why won't it be played?
[20:23] <llogan> yuv444p
[20:23] <llogan> i guess dumb players won't grok mkv anyway?
[20:23] <nevcairiel> quite possibly :p
[20:23] <ubitux> s/mkv/avi/
[20:23] <nevcairiel> although i'm sure there are people that have mkv something support but no 444 h264 support
[20:23] <ubitux> pb fixed
[20:24] <nevcairiel> too bad the default settings of the mpeg4 encoder give such a horrible picture
[20:25] <llogan> i don't really like to encourage avi usage.
[20:26] <ubitux> s/mkv/gif
[20:26] <llogan> heh. i'll come up with something else.
[20:36] <ubitux> llogan: the mkv command displays a warning anyway
[20:37] <llogan> ubitux: good enough for me
[20:38] <llogan> talking about warnings, "deprecated pixel format used, make sure you did set range correctly" is confusing users
[21:08] <michaelni> llogan, both deleted, (it needed root but ive enabled support to allow admins to delete, carl can delete them too, and ive also tried to give you permission to delete tickets, tell me if it doesnt work)
[21:09] <llogan> michaelni: thanks
[23:56] <cone-874> ffmpeg.git 03Michael Niedermayer 07master:ea6331b2c602: avfilter/af_aresample: Calculate output buffer size more precisely.
[00:00] --- Thu Nov  7 2013