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

[burek]

[00:47:11 CEST] <jamrial> michaelni: that h264_mp4toannexb test you added fails to actually apply the bitstream filter, but it doesn't abort because ffmpeg.c checks for exit_on_error before aborting which by default is 0
[00:47:43 CEST] <jamrial> after the bsf port, exit_on_error is not being checked and it of course aborts
[00:48:33 CEST] <jamrial> we could add a check for exit_on_error in the bsf port to keep the current behavior but i don't think ignoring a bitstream failure is a good idea
[00:49:14 CEST] <Chloe> gonna push sdl2 stuff tomorrow evening if there's no further comments/objections
[00:53:10 CEST] <jamrial> michaelni: looks like it fails to apply the bitstream filter in the last frame, probably because the source file was badly cut
[00:54:39 CEST] <michaelni> yes, to me it also looked like it was just failing on a single frame
[00:57:22 CEST] <michaelni> killing the whole transcoding due to a single (input) error in bitstream filtering seems mismatching what we do in decders
[00:57:53 CEST] <michaelni> which try to continue if they can
[00:58:09 CEST] <michaelni> at least by default ...
[00:58:19 CEST] <jamrial> ok, will add an exit_on_error check then
[00:58:30 CEST] <michaelni> ok, thx
[00:59:46 CEST] <nevcairiel> reading and decoding is a nother thing then writing/creating data though, writing faulty data has far worse consequences then trying to resume decoding after a broken frame
[01:00:48 CEST] <jamrial> nevcairiel: it seems to write the same thing failing or not, at least this teast in the bsf port. same md5 value for the output. it just doesn't abort right then and there
[01:01:01 CEST] <nevcairiel> i guess
[01:03:10 CEST] <jamrial> michaelni: this is the result of adding the error_on_exit check in the bsf port: http://pastebin.com/XnZHBDGi
[01:04:11 CEST] <jamrial> guess the badly filtered frame is not dumped after the failure (even if it didn't abort), whereas git head does
[01:04:49 CEST] <jamrial> should we assume the new result as being "more correct"(tm)?
[01:06:30 CEST] <jamrial> following what nevcairiel said, i think not writting the faulty data is more desirable...
[01:07:18 CEST] <nevcairiel> writing an unconverted mp4 atom into the annexb stream will just lead to failure either way
[01:08:14 CEST] <michaelni> jamrial, i dont know which is better (time and user bug reports will tell what effect if any it has) but it should be documented in the commit message that this changes (for anyone who ends o it by bisect)
[01:08:55 CEST] <jamrial> sure
[01:32:11 CEST] <jamrial> ubitux: pushed the fix for the above stuff to my repo, so the ref for all three tests failing (remove_extra and h264_mp4toannex) need to be updated with the new results when you rebase
[02:11:57 CEST] <cone-913> ffmpeg 03Sasi Inguva 07master:6a2cbf901461: ffprobe.c: Indicate decode-but-discard packets when doing -show_packets.
[04:32:55 CEST] <cone-913> ffmpeg 03Steven Liu 07master:1212e3468e7b: avformat/hlsenc: refine EXT-X-BYTERANGE support for segments
[09:02:52 CEST] <cone-213> ffmpeg 03Anssi Hannula 07release/3.1:748a4747da5a: avformat/hls: Fix handling of EXT-X-BYTERANGE streams over 2GB
[10:01:40 CEST] <cone-213> ffmpeg 03Clément BSsch 07master:c29b532a9422: lavfi: add nlmeans filter
[10:16:06 CEST] <smitb> Hey there I don't know whats happening but I'm unable to subscribe in to the mailing list ffmpeg-devel...
[10:16:46 CEST] <smitb> everytime I add my email and click subscribe, a message comes that I'll be receiving a mail by which I should confirm...but I dont recieve such email
[10:50:46 CEST] <atana> Hi, I am an opw aspirant. I have an idea for opw project. It's building a search system for audios (content based audio retrieval). Does it sound relevant to FFmpeg ?
[13:03:01 CEST] <ubitux> if someone is looking for a shell that doesn't support $(cmd), csh is one
[13:05:28 CEST] <JEEB> ugh
[13:05:32 CEST] <JEEB> container cropping pops up
[13:05:41 CEST] <JEEB> gotta love you MXF
[13:07:05 CEST] <JEEB> {stored,sampled,display}_{width,height}
[13:07:42 CEST] <JEEB> so now I have a sample with stored_height being 0x130*2 and display_height being 0x120*2
[13:08:06 CEST] <JEEB> what's the right way to pass this info on?
[13:09:10 CEST] <JEEB> I'm still looking at the info that would tell me if it's top or bottom (I know, but I want to know if the container tells me)
[13:27:06 CEST] <JEEB> ... SMPTE 386M seems to define something similar to what I have on hand and it specifies Display Y-Offset to be used for specifying where to crop
[13:28:00 CEST] <JEEB> yet this sample is a boss and sets that value to zero
[14:10:14 CEST] <Compn> atana : what kind of search system? with a sql database or something ?
[14:10:25 CEST] <Compn> content matching?
[14:10:33 CEST] <Compn> i'm not sure if this falls within ffmpeg itself
[14:10:40 CEST] <Compn> i'm sure it could use ffmpeg
[14:12:08 CEST] <atana> its basically audio search. retrieving similar audio
[14:12:21 CEST] <atana> based on content of audio
[14:15:46 CEST] <RiCON> chromaprint?
[14:30:25 CEST] <Compn> atana : oh, so input a song, and it spits out similar sounding songs? that sounds really interesting
[14:30:47 CEST] <atana> Compn: Yes
[14:31:30 CEST] <atana> This could further has a scope in recommendation too
[14:32:02 CEST] <Compn> atana : probably the filter or device that you have to make for ffmpeg to output the fingerprint or whatever metric you are judging songs by would be a good OPW project. as long as it can be reused by other people easily for other things
[14:32:37 CEST] <Compn> the whole system / project, i think would be bigger than OPW "job" ehe
[14:33:05 CEST] <atana> Yes, audio fingerprinting is one of the measure. I have some ideas in mind including finger printing.
[14:33:46 CEST] <atana> We could discuss about the timeline for the project
[14:34:06 CEST] <atana> if the idea sounds interesting to ffmpeg community
[14:34:41 CEST] <Compn> you might want to try posting your opw idea to ffmpeg-devel mailing list. maybe focus on the ffmpeg filter you would want to write. that way there is a clear goal for opw.
[14:35:14 CEST] <Compn> i'm not sure the process for ffmpeg opw , or who is online here on irc at the moment :)
[14:35:20 CEST] <Compn> but more devs read the mailing list
[14:35:28 CEST] <atana> Yeah, I will do that.
[14:36:34 CEST] <Compn> atana : do you have experience coding in C ? or signal processing ? 
[14:36:58 CEST] <Compn> (write your experience into your mail as well... there are other applicants for OPW)
[14:37:56 CEST] <atana> Yes, I have sound knowledge of C, C++ and python. I have some experience in (information retrieval, machine learning, deep learning)building search engines from scratch
[14:38:17 CEST] <atana> sure I will add that too.
[15:13:57 CEST] <JEEB> oh, fun, MXF patches on the ML. I wonder if the netflix meridian sample has all this metadata in this format
[15:14:13 CEST] <JEEB> if so I might be able to test that stuff on monday
[15:17:17 CEST] <JEEB> also do we now prefer "avio_read(pb, thing, 16)" versus "thing = avio_rb32(pb)"?
[15:17:58 CEST] <durandal_17> JEEB: 16 != 4
[15:18:20 CEST] <JEEB> well yes, the number was mismatching
[15:18:42 CEST] <JEEB> and the avio_read takes in a pointer while the latter thing returns a value
[15:19:09 CEST] <JEEB> also, d'oh. it's reading a UUID :P
[15:19:39 CEST] <JEEB> so probably for reading just a 32bit value we can still use avio_rb32 et al
[15:19:48 CEST] <JEEB> I need more sleep and/or coffee
[15:27:46 CEST] <JEEB> so if you have a struct defined within a .c file (a single demuxer) which means its definition is not exported (unless the definition is copied to a .h file somewhere), can the struct be freely changed?
[15:28:07 CEST] <JEEB> mostly talking of things like this where there actually were multiple width/height fields https://github.com/jeeb/ffmpeg/commit/e6885b3784cee920fd24288eb4d582398d7ba67f
[15:28:29 CEST] <JEEB> also I'm not 100% sure how to deal with the fact that width/height are uint32_t in MXF and it seems like they're int in FFmpeg?
[15:28:42 CEST] <JEEB> do I just put a check before setting the value in?
[15:29:28 CEST] <ubitux> jamrial: i squashed and pushed in my branch
[15:29:40 CEST] <ubitux> (and rebased)
[15:29:59 CEST] <ubitux> i need to extend the commit desc about ffmpeg-bsf-remove-* fate changes though
[15:30:05 CEST] <ubitux> can you suggest something?
[15:30:18 CEST] <ubitux> also re-read the message for any improvement
[15:30:22 CEST] <ubitux> please :)
[15:39:57 CEST] <jamrial> ubitux: the refs for remove_extra change because the packet flags pre patch were wrong and keyframes weren't marked
[15:40:23 CEST] <jamrial> so in a bsf that specifically looks for keyframes in order to do stuff, things don't work as intended :p
[15:52:36 CEST] <jamrial> ubitux: looks good. maybe instead of "dumped" use "written", but it works either way
[17:17:17 CEST] <JEEB> hmm, what's the simplest way to make ffprobe export some metadata for a file?
[17:17:36 CEST] <JEEB> because we don't have a proper flow for container cropping I think I might as well just export it somehow for now
[17:17:57 CEST] <JEEB> and then utilize it either from the API or with ffprobe parsing
[17:20:52 CEST] <Chloe> JEEB: wasnt that what the new avprobe muxer was for?
[17:21:27 CEST] <JEEB> no
[17:21:45 CEST] <JEEB> that was for replacing input data with something that came from an ffprobe dump
[17:45:23 CEST] <rcombs> JEEB: if the struct's internal to a .c then it's not public ABI, so yeah no problem changing it
[17:45:58 CEST] <rcombs> JEEB: and yeah it sounds like you'll want an INT_MAX check and a PATCHWELCOME or the like for oversized width/height
[17:46:57 CEST] <JEEB> yea
[17:47:18 CEST] <JEEB> I actually wonder how many formats we actually set without checking
[17:47:31 CEST] <JEEB> where the format is uint32_t and we just stick it into int
[17:47:47 CEST] <rcombs> I actually wonder why they're signed in the struct
[17:48:20 CEST] <rcombs> it's not like we need -1 to indicate unset (0 does just fine)
[18:16:51 CEST] <cone-773> ffmpeg 03Josh de Kock 07master:3877e3d8a8bd: lavd: Add SDL2 output device
[18:16:52 CEST] <cone-773> ffmpeg 03Josh de Kock 07master:f94b8d2557c6: MAINTAINERS: update my entries
[18:16:53 CEST] <cone-773> ffmpeg 03Lukasz Marek 07master:645353829f27: lavd/opengl: use SDL2
[18:16:54 CEST] <cone-773> ffmpeg 03Marton Balint 07master:9c5fab5ed421: ffplay: add SDL2 support
[18:16:55 CEST] <cone-773> ffmpeg 03Josh de Kock 07master:47ea6f5c9d1b: lavd: drop SDL1 device and SDL1 support
[18:29:05 CEST] <jamrial> "lavd: drop SDL1 device and SDL1 support" heh
[18:29:38 CEST] <jamrial> time to uninstall sdl1 at last
[18:29:54 CEST] <Chloe> :)
[18:30:07 CEST] <Chloe> jamrial: any idea where I'd write this 'news entry'?
[18:30:42 CEST] <Chloe> ah. ffmpeg-web?
[18:30:49 CEST] <jamrial> yeah
[18:31:07 CEST] <jamrial> clone that repo, add the news entry then send a patch to the ml
[18:31:16 CEST] <Chloe> to the main ffmpeg-devel ml?
[18:31:32 CEST] <ubitux> jamrial: OK
[18:31:34 CEST] <jamrial> yes
[18:31:44 CEST] <Chloe> ok thanks
[18:31:48 CEST] <ubitux> jamrial: a few more words about the adtstoasc hack maybe?
[18:31:59 CEST] <ubitux> i wasn't able to follow exactly the comment in the source
[18:34:16 CEST] <cone-773> ffmpeg 03Carl Eugen Hoyos 07master:04fa20d53c57: lavf/aacdec: Do not autodetect a single frame inside the file.
[18:35:58 CEST] <jamrial> ubitux: the comment in the source is what would need to be done in order to remove the hack
[18:36:07 CEST] <jamrial> basically, what we were doing before this patch was copying extradata as modified after the first filtered frame back to the muxer's codecpar extradata. this is technically the bsf misbehaving as extradata should only be modified by bsfs during init
[18:36:38 CEST] <jamrial> the hack in question keeps things working as they were until now
[18:37:05 CEST] <cone-773> ffmpeg 03Carl Eugen Hoyos 07master:1d92256d60df: lavd/sdl2: Move unsupported formats SDL_PIXELFORMAT_xxx888 updwards.
[18:37:11 CEST] <jamrial> i guess instead of HACK it should be a FIXME or TODO, since it doesn't explain what the hack does but what would need ot be done to remove it
[18:38:02 CEST] <ubitux> i updated my branch; do you want to update the source and description and push?
[18:38:29 CEST] <jamrial> sure
[18:38:35 CEST] <ubitux> thanks :)
[18:40:32 CEST] <ubitux> sdl is dead, long live sdl!
[18:41:19 CEST] <wm4> nice, SDL1 finally gone
[18:41:31 CEST] <wm4> it'd still nice if SDL2 weren't linked by default, though
[18:41:52 CEST] <ubitux> it won't if you use old-stable! ;)
[18:41:53 CEST] <wm4> like excluding it from libavdevice by default, and linking only ffplay with it, or so
[18:43:50 CEST] <ubitux> fullscreen looks broken :3
[18:44:21 CEST] <ubitux> does 'f' behaves correctly with everyone with ffplay/sdl2?
[18:44:38 CEST] <ubitux> it works "sometimes"
[18:46:22 CEST] <ubitux> Chloe: does it work for you?
[18:46:40 CEST] <ubitux> it blinks fullscreen then go back to windowed here
[18:47:20 CEST] <ubitux> it works fine with dbl click though
[18:57:03 CEST] <Chloe> ubitux: yes it works fine for me
[18:58:03 CEST] <Chloe> ubitux: what's your OS (distro if applicable)?
[18:58:27 CEST] <cone-773> ffmpeg 03Carl Eugen Hoyos 07master:159aa1275e5d: lavd/sdl2: Fix 32bit rgb formats on little-endian hardware.
[18:58:53 CEST] <ubitux> archlinux
[19:00:31 CEST] <ubitux> sdl 2.0.4
[19:01:21 CEST] <Chloe> I have no idea why double click would work but not 'f', they literally do exactly the same thing
[19:01:33 CEST] <ubitux> race in event queue?
[19:02:45 CEST] <Chloe> I wonder if 'f' is getting triggered twice
[19:04:27 CEST] <ubitux> yes
[19:04:34 CEST] <ubitux> it is
[19:05:39 CEST] <ubitux> funny things, if i move the window once before hitting 'f'
[19:05:41 CEST] <ubitux> it does work
[19:05:44 CEST] <JEEB> :D
[19:07:41 CEST] <Chloe> ubitux: does pause work consistently?
[19:08:03 CEST] <ubitux> it seems so
[19:11:20 CEST] <Chloe> I'm not sure what to recommend for a fix here then. I was going to say throttle all input events, but I don't think that'd help here. The fact that it's only f makes it even weirder.
[19:13:09 CEST] <ubitux> there are a bunch of av_gettime_relative() adjusting behaviour
[19:13:16 CEST] <ubitux> there is probably a race around this
[19:19:32 CEST] <rcombs> hmm
[19:19:57 CEST] <rcombs> so, auto-bsf doesn't work if the first packet's first NAL has a size between 0x100 and 0x1FF bytes
[19:20:30 CEST] <rcombs> because with a 4-byte size you end up with 0x000001XX, and the first 4 bytes look like an Annex B start code
[19:20:43 CEST] <rcombs> that's not great
[19:21:04 CEST] <nevcairiel> you could try to validate if interpreting it as a mp4 start code matches up the packet size perfectly
[19:22:38 CEST] <rcombs> yeah, thinking I'll do something like that
[19:22:45 CEST] <rcombs> probably expose a function out of h2645_parse
[19:24:45 CEST] <rcombs> wondering how h264_parse does this, though
[19:24:51 CEST] <rcombs> or does it always just know ahead of time
[19:25:04 CEST] <rcombs> (PARSER_FLAG_COMPLETE_FRAMES?)
[19:25:05 CEST] <nevcairiel> h264 knows the type from extradata
[19:25:14 CEST] <nevcairiel> afaik
[19:31:52 CEST] <rcombs> looks like for h264 you can check if extradata[0] == 1
[19:32:24 CEST] <rcombs> not sure for HEVC
[19:33:59 CEST] <nevcairiel> the same rule applies for hevc, however in the bsf that check might not be very wise since you want to convert
[19:34:12 CEST] <nevcairiel> and may be used to fix half-weird streams
[19:34:31 CEST] <JEEB> rcombs: that would otherwise work but until the spec was finalized some matroska implementations would write it with a zero
[19:34:34 CEST] <JEEB> :D
[19:34:45 CEST] <rcombs> :|
[19:35:05 CEST] <JEEB> because of https://lists.matroska.org/pipermail/matroska-devel/2013-September/004567.html
[19:35:07 CEST] <rcombs> who starts a stream with a >255-byte NAL anyway
[19:35:37 CEST] <rcombs> >// The number zero (0) shall be written to
[19:35:37 CEST] <rcombs> >// the configurationVersion variable until
[19:35:37 CEST] <rcombs> >// official finalization of 14496-15, 3rd ed.
[19:35:40 CEST] <rcombs> :|
[19:35:56 CEST] <JEEB> I am sorry
[19:36:01 CEST] <JEEB> I wrote that :<
[19:36:21 CEST] <JEEB> because we weren't sure if it would change or not
[19:36:32 CEST] <rcombs> I guess& if it's Annex B extradata (who does this anyway) then it will start with 0x000001 or 0x00000001?
[19:36:55 CEST] <rcombs> so I could check for extradata that is present, but doesn't match that
[19:38:07 CEST] <rcombs> tell me you can't have general_profile_space, general_tier_flag, general_profile_idc, _and_ the first 8 bits of general_profile_compatibility_flags all be 0, but the next 8 bits be 0x01
[19:40:01 CEST] <JEEB> rcombs: also looking at the positions of the reserved bits might be one way?
[19:40:12 CEST] <JEEB> since they are specified to be 1s
[19:40:27 CEST] <Chloe> ubitux: are you sure you're just not hitting the key twice?
[19:40:28 CEST] <JEEB> (not that it didn't stop some people making shit with zeroes there but thankfully I don't give a fuck about them)
[19:40:29 CEST] <cone-773> ffmpeg 03Clément BSsch 07master:5ef19590802f: ffmpeg: switch to the new BSF API
[19:40:39 CEST] <ubitux> Chloe: yes
[19:41:11 CEST] <ubitux> jamrial: nice
[19:42:19 CEST] <jamrial> ubitux: kept the hack notice and added a fixme
[19:44:26 CEST] <rcombs> also why does H264 have 2 different startcodes (24- and 32-bit)
[19:44:32 CEST] <rcombs> do they have different meanings somehow
[19:46:50 CEST] <rcombs> JEEB: I might be inclined to assume that no file will have both HEVC extradata not starting with 0x01 _and_ a first packet starting with a 0x1XX-byte NAL
[19:47:05 CEST] <rcombs> or, at least, assume that until someone gives me a sample indicating otherwise
[19:49:39 CEST] <JEEB> rcombs: sounds OK'ish on first thought
[19:51:30 CEST] <rcombs> like, (pkt->size >= 5 && AV_RB32(pkt->data) != 0x1 && AV_RB24(pkt->data) != 0x1) || (st->extradata && st->extradata[0] == 0x1)
[19:56:44 CEST] <rcombs> AV_RB32(pkt->data) != 0x0000001 &&
[19:56:44 CEST] <rcombs> AV_RB24(pkt->data) != 0x000001
[19:57:08 CEST] <rcombs> ^ just realized I'm missing a 0 on the first line; good thing nobody cares
[20:00:34 CEST] <ubitux> :D
[20:31:09 CEST] <cone-773> ffmpeg 03Michael Niedermayer 07master:1e3458481407: avfilter/tests/integral: Remove unused variables
[20:49:57 CEST] <cone-602> ffmpeg 03James Almer 07master:dc48248ea8e6: avcodec/nvenc: use AVERROR_BUFFER_TOO_SMALL instead of ENOBUFS
[20:51:32 CEST] <wm4> wonderful, sdl2 in ffmpeg broke mpv windows builds
[20:52:14 CEST] <Chloe> note: not-our-bug
[20:52:20 CEST] <Chloe> caused by sdl2 not by ffmpeg
[20:52:23 CEST] <wm4> yes, of course it's SDL's issue
[20:52:38 CEST] <wm4> but the problems in the past were also only caused by sdl
[20:52:46 CEST] <wm4> so nothing new
[20:55:20 CEST] <rcombs> --disable-ffplay
[20:55:33 CEST] <RiCON> and probably only static builds at that, -luuid is only in Libs.private
[20:56:02 CEST] <Compn> i figured sdl2 would break on windows
[20:56:07 CEST] <Compn> just a hunch... :P
[20:56:23 CEST] <Compn> wonder if the rpi guys are also having trouble with it now
[20:56:44 CEST] <RiCON> works fine in ffmpeg itself, fwiw
[20:57:53 CEST] <jamrial> Compn: seems to work fine for me
[20:57:58 CEST] <jamrial> ffplay, that is
[20:58:05 CEST] <jamrial> no idea about the outdevs
[20:59:16 CEST] <RiCON> i only tried with ffplay too
[21:02:33 CEST] <cone-310> ffmpeg 03Carl Eugen Hoyos 07master:267da70ea8c3: lavf/utils: Avoid an overflow for huge negative durations.
[21:12:16 CEST] <cone-310> ffmpeg 03Carl Eugen Hoyos 07release/3.0:73b644cdee8a: lavf/utils: Avoid an overflow for huge negative durations.
[21:12:17 CEST] <cone-310> ffmpeg 03Carl Eugen Hoyos 07release/3.1:8b21b44e7e31: lavf/utils: Avoid an overflow for huge negative durations.
[00:00:00 CEST] --- Sun Sep 25 2016