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

[burek]

[00:00] <ubitux> 488 actually now
[01:57] <cone-417> ffmpeg.git 03Michael Niedermayer 0712eb2fd53948: dxa: dont try to use the previous frame if there is none.
[01:57] <cone-417> ffmpeg.git 03Michael Niedermayer 07a3cb7f992f88: xwma: check bytes_per_sample, fix division by 0.
[03:45] <cone-417> ffmpeg.git 03Michael Niedermayer 07caa2fa2c69e7: rv10: always check image size not just in some cases.
[03:45] <cone-417> ffmpeg.git 03Michael Niedermayer 0762006b539ddd: ituh263dec: more complete w/h check.
[05:16] <Compn> j-b : did i ask why your wiki and forum is all 403 ? 
[05:16] <Compn> etc http://wiki.videolan.org/Deinterlacing
[05:16] <Compn> or should i pretend its not there
[06:53] <hyun_> hi anyone know previously which file is for rtpdec_jpeg?
[09:41] <JEEB> wbs, poke jure for testing -- he is having problems
[09:42] <JEEB> also I found http://wiki.multimedia.cx/index.php?title=Advanced_Audio_Coding#Decoder_Features to be rather interesting itunes-wise
[09:43] <jure> the switch to add is "-signaling implicit" for "Implicit backwards compatible signaling"
[09:43] <JEEB> oh, that worked?
[09:43] <jure> yep
[09:43] <jure> thanks to that matrix
[09:44] <jure> iTunes doesn't support PS
[09:45] <jure> which is odd, because that's the whole point of HE-AACv2
[09:45] <JEEB> not sure if that chart is correct, but if that switch works then it makes libaacplus effectively useless
[09:45] <JEEB> le yay
[11:29] <cone-641> ffmpeg.git 03Xi Wang 07e8769b37fe8a: segment: fix NULL pointer dereference in seg_write_header()
[11:29] <cone-641> ffmpeg.git 03Mans Rullgard 077ba0c1b390a6: avutil: change GET_UTF8 to not use av_log2()
[11:29] <cone-641> ffmpeg.git 03Mans Rullgard 077f1fcaf0e648: ppc: do not pass redundant compiler flags
[11:29] <cone-641> ffmpeg.git 03Diego Biurrun 07a3138ebfa85e: fate: Add dependencies for aac, alac, amrnb, amrwb, atrac tests
[11:29] <cone-641> ffmpeg.git 03Luca Barbato 073b4296f41473: avformat: clarify stream id for muxing
[11:29] <cone-641> ffmpeg.git 03Michael Niedermayer 074d941eac1655: Merge commit '3b4296f41473a5b39e84d7a49d480624c9c60040'
[11:41] <cone-641> ffmpeg.git 03Luca Barbato 078034130e06b0: rtp: set the payload type as stream id
[11:41] <cone-641> ffmpeg.git 03Xi Wang 07b74dbdd5e99a: bgmc: Fix av_malloc checks in ff_bgmc_init()
[11:41] <cone-641> ffmpeg.git 03Michael Niedermayer 07a9b1536a018b: Merge remote-tracking branch 'qatar/master'
[11:52] <cone-641> ffmpeg.git 03Clément BSsch 070e482a8e49f3: ffserver: fix streams and priv_data memleaks when closing a connection.
[12:34] <cone-641> ffmpeg.git 03Michael Niedermayer 0717da2d9eee6b: swr: reorder/redesign operations to avoid integer overflow.
[12:34] <cone-641> ffmpeg.git 03Michael Niedermayer 07d53f44713081: swr: move if() block into the only branch where it can be true.
[13:05] <ubitux> isn't ffserver test supposed to end automatically?
[13:09] <ubitux> seems the wgets never end..
[14:41] <cone-641> ffmpeg.git 03Carl Eugen Hoyos 07850e5c041d7e: Read QuickTime version 1 audio fields in broken mov files.
[14:52] <ubitux> seems even a simple jpeg is in a "wait" state :(
[15:31] <kcm1700> I think codec_tag copying operation is not working properly with segment format. If output format is mp4 for example, segment format's codec_tag must be mp4. but ffmpeg HEAD, segment muxer's codec_tag is always null, so it allows inappropriate codec_tag for the output codec context.
[15:31] <kcm1700> ah, the code is in ffmpeg.c
[15:33] <kcm1700> Do you have any suggestion how to fix this issue?
[15:33] <Compn> sample file and command line that fail 
[15:33] <Compn> ?
[15:36] <kcm1700> I'll try to make sample file, it may take some time.
[15:37] <kcm1700> but I saw a video file (other computer, I don't have right now) that produces the issue.
[15:38] <kcm1700> anyway command line was like ffmpeg -i video.mp4 -c copy -map 0 -f segment result%03d.mp4
[15:41] <kcm1700> and I know that issue is disappeared when I add a line 'st->codec->codec_tag = 0;' after 'avcodec_copy_context(st->codec, s->streams[i]->codec);' in libavformat/segment.c
[15:43] <Compn> maybe michael knows whats up
[15:44] <Compn> something about codec_tag changed recently 
[15:44] <Compn> libav likes shuffling those deck chairs
[15:44] <kcm1700> now making a sample with Gangnam style ~_~
[15:54] <michaelni> Compn, if someone provides me with a testcase that shows the issue then iam happy to look at it ...
[16:05] <ubitux> libav is going to release version 9, should we start versionning in binary? ffmpeg 1, ffmpeg 10, ffmpeg 11, ffmpeg 100, ...?
[16:06] <ubitux> sorry, that was easy.
[16:07] <kcm1700> http://119.70.5.68:8080/sample.mp4
[16:07] <kcm1700> here's the sample.
[16:08] <nevcairiel> just keep incrementing that 1 every release instead of going 1.1, and you'll catch up eventuallly =p
[16:08] <ubitux> 1 + 1 = 10
[16:11] <nevcairiel> to avoid confusiong, should possibly add a subscript 2 or a "b" :p
[16:11] <nevcairiel> -g
[16:22] <ubitux> sounds complicated
[16:22] <ubitux> michaelni: btw, weren't the connection supposed to be closed automatically with the ffserver tests?
[16:23] <ubitux> it seems running a wget on any of the test stream never ends
[16:23] <ubitux> it sounds like a regression to me, but maybe i'm missing something?
[16:27] <michaelni> ubitux, dunno
[16:47] <cone-641> ffmpeg.git 03Michael Niedermayer 07bc08ca841e66: flashsv: reallocate block array independant of frame type.
[16:47] <cone-641> ffmpeg.git 03Michael Niedermayer 07c0d68be555f5: pgssubdec: check RLE size before copying. Fix out of array accesses
[16:51] <kcm1700> I've copied codec context's codec_tag validating logic from ffmpeg.c to segment.c. looks like issues solved. https://github.com/kcm1700/VideoSplitter/commit/e2e92d6ddd6a77cd4a35cb7428a3b86bedfd2c37
[16:51] <kcm1700> is this the right way to go? or should I fix somewhere else like ffmpeg_opt.c ?
[17:00] <michaelni> kcm1700, from a quick look your fix looks ok
[17:03] <michaelni> probably best if you post the patch to ffmpeg-devel
[17:03] <kcm1700> well, NULL is symantically wrong, should be 0 I think. I'll commit --amend. thanks michaelni 
[17:04] <kcm1700> Ok. I'll send a patch then.
[17:06] <cone-641> ffmpeg.git 03Paul B Mahol 07eca2eb2dfa99: pcm: give more descriptive name to codec
[17:31] <DaKaZ> hello ffmpeg group - I think I uncovered a but a libavcodec with MPEG2 encoding, and I wanted to discuss it quickly to make sure I am looking at it correctly.
[17:31] <DaKaZ> Here is the problem, when encoding into MPEG2 from a source with soft telecine, we are not getting compliant output. 
[17:31] <DaKaZ> Specifically, during a soft-telecine sequence we need to encode the frames with the repeat-field-flag (RFF) set to be progressively encoded AND to signal progressive->frame as progressive.
[17:31] <DaKaZ> Today, in mpeg12enc.c at line 411 we set the progressive frame flag to the value of progressive sequence.  While it is true that we have an interlaced sequence, in this case we need a progressive frame.
[17:32] <DaKaZ> I have been looking at the code and trying to figure out how to force the encoding of the frame to progressive, because that is the hard part here, because changing the flag to progressive based on the RFF flag is easy but doesn't work if the frame is not actually progressive.
[17:32] <DaKaZ> Thoughts?
[17:33] <DaKaZ> sorry - my line number is for version 0.8.10 (the version we are using)
[17:35] <ubitux> you are at least 4 major version in the past
[17:35] <ubitux> or not even using ffmpeg
[17:36] <ubitux> can you try to upgrade to ffmpeg git/head and see if it helps?
[17:37] <ubitux> iirc some ppl were discussing this interlacing thing recently
[17:37] <ubitux> there might be some fixes upstream already
[17:37] <DaKaZ> I will check version 1.0
[17:37] <ubitux> please check git/master instead DaKaZ 
[17:37] <DaKaZ> okay, will do
[17:43] <DaKaZ> ubitux: its exactly the same in tip git:         s->progressive_frame = s->progressive_sequence;
[17:43] <ubitux> at least the file & line you provided might match now :)
[17:43] <ubitux> and you know it's not already fixed
[17:43] <DaKaZ> again, we can easily change that to something like         s->progressive_frame = s->s->repeat_first_field       but that would be bad
[17:43] <DaKaZ> without actually encoding the frame as a progressive frame
[17:44] <DaKaZ> so, let me state the problem a little differently
[17:44] <DaKaZ> we have an interlaced sequence& today, in ffmpeg, if I encode with interlaced on, every frame is encoded as interlaced.  for mpeg2 encoding, this is not desirable
[17:44] <DaKaZ> and breaks the spec
[17:45] <DaKaZ> we need to either A) respect the interlaced_frame flag in the source av_frame struct (which we don't, we tried that) or B) force the encoding to progressive the RFF flag is set for that frame
[17:46] <DaKaZ> then, as I said, setting the correct progressive_frame flag would be easy to fix
[17:46] <DaKaZ> I can't figure out where in the code the interlaced versus progressive frame encode decision is made
[17:46] <TimNich> DaKaZ:  Are you saying you want to turn on/off the ildct on a frame by frame basis?
[17:48] <DaKaZ> yup
[17:48] <DaKaZ> I think so
[17:48] <DaKaZ> to be compliant with the h.262 spec (and not cause broken playback on Motorola DCT2000 STBs)
[17:51] <michaelni> DaKaZ/TimNich, ildct is choosen per MB when its enabled
[17:52] <michaelni> iam not sure what you are trying to do thus ...
[17:53] <TimNich> michaelni: I am not sure either, coding with/without ildct shouldn't affect the stream apart from the quality surely?
[17:53] <michaelni> yes
[17:53] <michaelni> now i could guess its maybe the yuv2rgb that differs on frames marked as interlaced vs progressive
[17:53] <michaelni> but that would violate spec if iam not mistaken
[17:54] <michaelni> its the sequence infor IIRC that should be used for that but id have to check the spec
[17:55] <TimNich> I cannot imagine a playback device wanting to switch between interlace/progressive mid stream, what happens if you mix from one type to the other? 
[17:55] <DaKaZ> michaelni: in the h.262 spec, it states that any frame with RFF must be progressively encoded, but contained within an interlaced sequence (which by definition can contain interlaced or progressive frames)
[17:56] <DaKaZ> TimNich: almost all US broadcast MPEG2 sources do this (switch encoded frames).  Some notable sources: VH1, Starz
[17:59] <TimNich> So if ildct is chosen per MB it should all work
[18:02] <TimNich> ahh. I think its the other bit thats the problem "AND to signal progressive->frame as progressive" I don't think the interlace signalling gets changed on a frame by frame basis.
[18:02] <DaKaZ> yes, if we encode each MB for that frame as progressive AND set the appropriate progressive_frame and rff flags, it would work
[18:03] <DaKaZ> TimNich: thats an easy patch if someone could point me to where the MB encode decision is made
[18:04] <DaKaZ> for those that are interested, in ITU H.262, section 6.3.10: "repeat_first_field -- This flag is applicable only in a frame picture, in a field picture it shall be set to zero and does not affect the decoding process."
[18:05] <DaKaZ> but if you set RFF on an interlaced frame, older MPEG2 STBs have a horible glitch (like a decoder reset)
[18:05] <michaelni> well, nothing sets it in that case ...
[18:07] <michaelni> DaKaZ, iam still not sure what the problem is, you just force progressive seq to 0 and set RFF as you want while making sure its progressive encoding
[18:09] <DaKaZ> michaelni: we have interlaced sequences (frames that are interlaced) with the progressive sequence
[18:09] <DaKaZ> we cannot deinterlace the interlaced sequences
[18:09] <DaKaZ> (legally)
[18:10] <DaKaZ> and, libavcodec is not spec compliant currently and I'd think we'd want it to be
[18:10] <michaelni> like i said already libavcodec does not set RFF currently so it does not break spec
[18:11] <michaelni> maybe you have local modifications that break the spec
[18:11] <michaelni> but i am just guessing
[18:12] <michaelni> also if you have interlaced + progressive sequences you can encode them as all interlaced or seperate as 2 concatenated sequences at NO point does RFF come in
[18:12] <michaelni> so i still dont know what you are trying to do
[18:13] <michaelni> RFF is for stretching progressive frames onto 3 fields like whan you have material of different fps
[18:13] <michaelni> compared to what your output equipeemt needs
[18:15] <DaKaZ> michaelni: instead of debating our needs for a spec compliant output - could you just point me to where in the code the MB mode decision is made (interlaced versus progressive) - I havent been able to find / follow the code
[18:18] <michaelni> DaKaZ, try to put a av_log(0,0, "repeat_first_field = %d\n", s->repeat_first_field); in the code and you will see it is not set in the encoder
[18:18] <michaelni> if it IS set for you there is a problem that need to be fixed 
[18:19] <michaelni> its not going to go away by changing some ildct bits somewhere (its in mpegvideo_enc.c to awnser your question)
[18:20] <DaKaZ> michaelni: correct - we set the RFF flag on the incoming av_frame, this is by design
[18:21] <DaKaZ> but I also set av_frame->interlaced frame to false and would like to have that frame encoded as progressive
[18:22] <michaelni> so you want the frame encoded as 3 fields / 1.5 times longer than a normal frame ?
[18:22] <DaKaZ> no, I want it encoded as a single progressive frame
[18:22] <DaKaZ> and the I'll set the RFF flag on the egress
[18:27] <michaelni> well there are just 2 choices: 1 progressive frame -> RFF=0 or 3 fields / progressive frame of 1.5 durations RFF=1. What you talk about is like dividing by 0 
[18:28] <michaelni> either you want a normal duration=1 progresive frame then RFF is never 1 or you want a longer duration progressive frame then RFF would become 1 
[20:03] <DaKaZ> michaelni: just a follow up, I haven't tested this, but I think this is what I am trying to accomplish, would welcome any feedback: http://privatepaste.com/d75016ad95
[20:05] <ubitux> please use a unified diff (-u)
[20:06] <DaKaZ> updated with diff -u http://privatepaste.com/0aeef130b9
[20:18] <kierank> DaKaZ: check it's frame accurate with threads
[20:19] <kierank> i did the same thing you are doing but with closed captions and you end up being frame inaccurate and/or crashing with threads
[20:19] <kierank> though CCs are a lot more complex
[20:24] <DaKaZ> kierank: thanks for the feedback, will check
[20:24] <kierank> DaKaZ: how do you do closed caption extraction by the way?
[20:25] <kierank> it is possible to do it before decoding but then you have to reorder manually which is easy for mpeg-2 i guess
[20:44] <DaKaZ> kierank: we have a custom library that inserts the CC as either SCTE-20 or a/53 (608) into the compressed bitstream post codec
[20:44] <kierank>  DaKaZ i mean how do you extract the CC's
[20:44] <kierank> it should be a similar process, no?
[20:45] <DaKaZ> that library also converts the CC from any format to the format we need
[20:45] <michaelni> DaKaZ, the last hunk of that patch is not correct
[20:45] <michaelni> for example the code under != PICT_FRAME is never run for a encoder so this can make no diffrerence for encoding
[20:45] <kierank> ah ok
[20:47] <ubitux> michaelni: seems the last flashv commit made valgrind angry
[20:47] <DaKaZ> michaelni: whoops - I see 
[20:48] <DaKaZ> let me re-think that, thats what I was saying about having a hard time with the code
[20:48] <DaKaZ> unfortunately I'm about to jump on a plane, so you may not hear from me for a day& but I will follow up with the group and let you know what I find
[20:48] <michaelni> ok
[21:03] <cone-641> ffmpeg.git 03Michael Niedermayer 07ea3eaa37b119: flashsv: only realloc blocks for version 2
[21:03] <cone-641> ffmpeg.git 03Michael Niedermayer 07c2409a7c5b1c: vmdav: more complete check for block_align, prevent out of array access.
[21:03] <cone-641> ffmpeg.git 03Michael Niedermayer 07e31b1938acbe: zmbv: avoid use of uninitialized data
[21:04] <michaelni> ubitux, should be fixed
[21:04] <ubitux> thx :)
[21:27] <cone-641> ffmpeg.git 03Clément BSsch 078ea8833979d2: swr/resample: move templating parameters to template itself.
[21:27] <cone-641> ffmpeg.git 03Clément BSsch 075e68bf9b927e: swr/rematrix: move templating parameters to template itself.
[21:34] <ubitux> michaelni: anything wrong with patch 1 in the pp patchset?
[21:34] <ubitux> "[PATCH 1/6] pp: fix a few typo in the internal header."
[21:44] <michaelni> ubitux, patch should be ok
[21:49] <cone-641> ffmpeg.git 03Clément BSsch 07b3bf9b1d976c: lavfi/geq: fix GPL license header.
[21:49] <ubitux> michaelni: ok thx
[21:59] <cone-641> ffmpeg.git 03Clément BSsch 07c4f317e7fe70: pp: fix a few typo in the internal header.
[21:59] <cone-641> ffmpeg.git 03Clément BSsch 074c0aece1926a: pp: use av_clip_uint8 instead of a custom implementation.
[21:59] <cone-641> ffmpeg.git 03Clément BSsch 075cd567cfb49f: pp: fix typo in avg() comment.
[22:04] <ubitux> saste: i love your answer "lavu/opt: fix av_opt_get_key_value() API." :))
[22:57] <ubitux> michaelni: do you think it makes sense to introduce x86/ and ppc/ layout in pp?
[22:58] <ubitux> i'm don't understand yet how that works though
[22:58] <ubitux> -'m
[23:00] <michaelni> you mean subdirectories for asm ? sounds like a lot of work and not clear what advantage that would have
[23:00] <ubitux> yes i was talking about that
[23:22] <ubitux> saste: i was wondering,
[23:23] <ubitux> it would be nice to be able to construct a pix fmt desc list based on some constraints
[23:23] <ubitux> for the filters
[23:23] <saste> ubitux: yes a pixel format list may help some filters
[23:23] <ubitux> like get me the list of yuv-like/planar/3-comp
[23:23] <saste> so you don't have to specify long list (which tend to get outdated when new ones are added)
[23:24] <saste> yuv-like?
[23:24] <saste> we don't have such info in pixdesc
[23:24] <ubitux> yeah, not rgb
[23:24] <saste> the way colorspace are managed is confusing
[23:24] <ubitux> you have the name
[23:24] <ubitux> strstr "yuv" :)
[23:24] <saste> first, there was a veto into adding colorspace info to pixdesc
[23:25] <saste> then people started adding all sort of crap to pixdesc
[23:25] <ubitux> alternatively, we can just add some subset "profiles" list helpers
[23:25] <ubitux> which filters could use
[23:26] <saste> the best thing would be to keep format layout and chroma component separated
[23:26] <saste> "chroma component info" separated
[23:26] <saste> so you know what contains each component
[23:27] <saste> and don't need to extract the map procedurally
[23:27] <saste> but then i don't know, for sure this would need to be discussed
[23:28] <saste> but then there is the merge issue, and i gave up
[23:29] <ubitux> :)
[23:29] Action: ubitux likes to work on "free for all" area such as pp or swr
[23:29] <ubitux> no need to worry about the merges
[23:29] <ubitux> :D
[23:29] <ubitux> i hope libav will drop avserver soon
[23:30] <ubitux> so we can work on it freely
[23:30] <saste> what about avserv?
[23:30] <saste> was the gsoc task successfull, anyhow?
[23:30] <saste> any followup?
[23:31] <ubitux> "Last updated 2 months ago"
[23:31] <saste> or is it doomed to rot, like most rewrites?
[23:31] <ubitux> https://github.com/nenjordi/libav/blob/avserv/avserv.c
[23:32] <ubitux> ouups
[23:32] <ubitux> seems i broke something
[23:34] <saste> seems more like a sketch rather than something which could possibly work
[23:34] <saste> also no license notice...
[23:35] <ubitux> meh, i don't understand what's wrong with the templating
[23:50] <ubitux> michaelni: i'm sorry, do you have any idea what could have gone wrong?
[23:51] <ubitux> oh.
[23:51] <ubitux> i get it&
[23:53] <cone-641> ffmpeg.git 03Clément BSsch 078f42b09604a6: swr/resample: fix SSSE3 included unconditionally.
[00:00] --- Fri Nov 16 2012