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

[burek]

[00:39] <neXyon> hi
[00:40] <rcombs> wm4: so, your problem with Nicolas's concept is that it only allows the code page to be changed during "header reading", whereas mine allows it any time?
[00:43] <j-b> iive: that's deny the actual facts
[00:43] <neXyon> I'm trying to use ffmpeg on windows to encode an audio file; the code works fine on linux but on windows the function avcodec_fill_audio_frame returns an -22 which as a negative number is an error :-/
[00:48] <wm4> rcombs: kind of... the general lack of control, and also his initial implementation was naive at best
[00:50] <rcombs> control from the consumer's perspective?
[00:51] <wm4> yes
[00:51] <wm4> anyway, I realize that this kind of stuff is probably important only for ffmpeg.c
[00:52] <wm4> it's mostly about glueing some libraries together (enca, libguess, chardet, iconv)
[00:52] <wm4> and the rest is trivial
[00:52] <wm4> maybe it should just be part of ffmpeg.c
[00:53] <rcombs> I think it's sufficiently useful for players that it'd be worth having in lav* (either format like my patch or util like Nicolas's concept)
[00:53] <jamrial> neXyon: that's probably EINVAL
[00:53] <neXyon> jamrial: why does it work on linux then? :-/
[00:53] <rcombs> I think with a good callback system, the consumer could have a fine level of control over which guess is used, or override the guesses altogether (much like you can with my patch)
[00:54] <rcombs> that leaves switching the encoding later, which that system wouldn't allow
[00:55] <wm4> rcombs: and the important point is that ffmpeg is probably not going to link with these libs
[00:55] <wm4> because ffmpeg is so nazi about external libs
[00:55] <Daemon404> as a hard dep? never. ever.
[00:55] <rcombs> seems like consensus was that they were fine as optional deps, with a preference for explicit enable flags over auto detect
[00:56] <rcombs> and my patch is designed to keep chugging whenever possible with multiple layers of fallbacks per-packet; I think it's about as robust as you can get here (unless I have a bug)
[00:57] <neXyon> jamrial: ah wait, same problem on linux with the settings
[00:57] <rcombs> you can't really do that on a per-packet level with an implementation in FFTextReader
[00:59] <wm4> I don't think packets are a meaningful unit in any way in this case
[00:59] <rcombs> yeah, you don't expect the charenc to actually change within the file
[01:01] <wm4> it could be that idiots (i.e. the people who create subtitle files) mix encodings or so while editing (because they don#t care)
[01:01] <wm4> wouldn't be too surprising
[01:01] <wm4> now the thing is that Nicolas' favorite part about the charset conversion code in lavc is that it crashes and burns if conversion fails
[01:02] <rcombs> I suppose that could happen, but I did it at a packet level because it allows for frequent feedback and retries with a different encoding
[01:02] <rcombs> yeah, that's bad
[01:02] <wm4> because he's too shitheaded to understand that transcoding isn't the only thing libav* is used for
[01:02] <wm4> so I'm not sure what your goal for robustness is
[01:02] <rcombs> maybe have a flag to enable a fail-spectacularly-if-something-goes-wrong mode, but not the default :/
[01:03] <wm4> for transcoding, refusing conversion might be reasonable behavior, but for playback you obviously want to display the shit SOMEHOW
[01:03] <rcombs> right, which is why my code tries so hard to fall back
[01:03] <wm4> and since you're working on an automatic transcoding server or something (?) you probably also prefer a more lenient behavior
[01:04] <rcombs> right
[01:04] <rcombs> (that server is Plex Media Server)
[01:04] <rcombs> and displaying something that might be the wrong encoding is better than displaying nothing at all
[01:04] <Daemon404> [00:02] < rcombs> maybe have a flag to enable a fail-spectacularly-if-something-goes-wrong mode, but not the default :/
[01:04] <Daemon404> this exists
[01:04] <Daemon404> it's called explode mode.
[01:05] <rcombs> the only case where you'd want to crash and burn on a recode failure is if a human is looking at stderr and will look at the file and figure out what's wrong if an error is logged
[01:05] <rcombs> but if it's being called programmatically for streaming, or by a video player, you don't want that
[01:06] <wm4> Daemon404: and of course it somehow can't be applied to subtitles
[01:06] <Daemon404> wut
[01:06] <wm4> because Nicolas
[01:06] <Daemon404> oh right, it's an avctx flag
[01:06] <Daemon404> or something
[01:07] <wm4> and I've spent at least 2 big flames on trying to get something that doesn't necessarily explode
[01:07] <wm4> because that utf-8 check is ALWAYS active
[01:07] <wm4> so now I filter all input data for utf-8 manually
[01:08] <wm4> the shit ffmpeg makes you do
[01:08] <wm4> even better that this utf-8 code in lavc contains some bugs
[01:08] <rcombs> wm4: so my patch has iconv discard illegal sequences, which should always output valid UTF-8
[01:08] <wm4> that's bad
[01:08] <rcombs> it only does that if all else fails
[01:08] <wm4> can't you make it insert replacement characters? or interpret it as latin-1
[01:08] <wm4> I think the latin-1 thing is most reasonable, at least for playback
[01:09] <rcombs> for my use-case, I don't think my patch can really be functionally improved a lot. Maybe by improving the decision process if the guess engines return different encodings (right now it's just libguess>enca>uchardet), or adding an implicit fallback on latin1
[01:10] <rcombs> but I'd like to have something that's useful for other cases as well :3
[01:36] <rieve> hello, I think I've found a bug in ffmpeg subtitle parsing or something like that
[01:37] <rieve> try the following:
[01:37] <rieve>  wget http://blender-mirror.kino3d.org/mango/download.blender.org/demo/movies/ToS/tears_of_steel_720p.mkv
[01:37] <rieve> wget https://download.blender.org/demo/movies/ToS/subtitles/TOS-en.srt
[01:37] <rieve> cat TOS-en.srt | sed '1d;2d;3d;4d' > TOS-en-cut.srt
[01:37] <rieve> ffmpeg -i tears_of_steel_720p.mkv -i TOS-en.srt -map 0 -map 1 -c:v copy -c:a copy -c:s mov_text out.mkv
[01:37] <rieve> that works
[01:38] <rieve> and then try the ffmpeg call with TOS-en-cut.srt.
[01:39] <rieve> oh sorry it should be out.mp4, not out.mkv
[01:40] <wm4> what does this sed command do?
[01:40] <rieve> it removes the first 4 lines
[01:43] <rcombs> what goes wrong for you? (and this seems like more of an #ffmpeg question)
[01:44] <rieve> I get "TOS-en-cut.srt: Invalid data found when processing input".
[01:44] <rieve> and it doesnt output anything
[01:44] <rcombs> sounds like you're running an old ffmpeg
[01:44] <rieve> sorry when its the wrong channel :(
[01:44] <rieve> 2.4.3
[01:44] <rcombs> try on master
[01:45] <rieve> ok
[01:45] <rcombs> there was an issue with SRT files failing to probe if they didn't start with 0 or 1 a bit ago
[01:45] <rcombs> *fixed a bit ago
[01:45] <rieve> oh great
[01:48] <wm4> but this one starts with 1
[01:49] <rieve> if you remove the first entry it doesnt anymore.
[01:49] <rcombs> ^
[01:51] <rieve> master works. thanks.
[01:52] <rcombs> :D
[02:22] <cone-962> ffmpeg.git 03Michael Niedermayer 07master:add46edf33a7: avformat/utils: use r_frame_rate only in the demuxer for ff_compute_frame_duration()
[02:22] <cone-962> ffmpeg.git 03Michael Niedermayer 07master:28a6f970f64c: ffmpeg: forward r_frame_rate to the muxer in case of stream copy
[02:22] <cone-962> ffmpeg.git 03Michael Niedermayer 07master:3b537eab27bb: avformat/nutenc: store the actual r_frame_rate in the corresponding field if available
[02:27] <aetas> Do you guys happen to know if commits into the rtmpdump project are still going on?  The project barely has a presence any longer and I asked on their mail list and got no response on if they're taking patch commits.  Was hoping someone here might know the status of it.
[02:31] <Compn> aetas : yes, still going
[02:31] <Compn> i should fix the mailing list
[02:33] <aetas> I had posted a patch on there for rtmpsuck and a segfault error that popped up previously but never got a response to my question of how to get it into upstream
[02:34] <aetas> all the project info was quite dated so I thought I'd ask here
[02:34] <Compn> i want to say ask wbs
[02:34] <Compn> i cant remember if he is now the lead devel
[02:35] <Compn> i need to recruit some people to work on the project :)
[02:35] <aetas> this was something random and hard to debug due to inconsistency so its been alive for all the versions of rtmpdump I've ever used
[02:35] <Compn> yes wbs (martin) has taken over 
[02:36] <aetas> suggest I just hang out or something?  I can get a patch into the package system I'm using but then it would never actually fix the problem for everyone else outside of it
[02:37] <Compn> yes irc is ok or you can mail him martin at martin.st
[02:38] <aetas> Ill jot that down as a backup in case I miss him
[02:38] <aetas> thanks for helping me out
[02:38] <Compn> no prob
[13:13] <ubitux> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f6b7c0008c0] Detected moov in a free atom.
[13:13] <ubitux> damn
[13:13] <ubitux> so this kind of stuff really happens
[14:47] <cone-864> ffmpeg.git 03Michael Niedermayer 07master:ad2deb02e5d8: avcodec/xiph: mark returned header pointers const from avpriv_split_xiph_headers()
[15:39] <ubitux> this subtitle api is maze :(
[15:47] <ubitux> we want ref counting, right?
[15:51] <ubitux> well, maybe we can ignore the ref counting
[16:08] <cone-864> ffmpeg.git 03Michael Niedermayer 07master:eb055295bda0: avfilter/f_sendcmd: Use av_freep() to avoid leaving stale pointers in memory
[16:08] <cone-864> ffmpeg.git 03Michael Niedermayer 07master:6de2f027cd60: avfilter/vf_dctdnoiz: use av_freep() to avoid leaving stale pointers in memory
[16:30] <ubitux> if i add a function in lavu, can i use it in lavc without version guards?
[16:30] <ubitux> (i'm assuming yes but..)
[16:48] <ubitux> damn i forget the subject all the time
[16:50] <nevcairiel> yes, lavc can depend on the lavu version to be at least as new as itself, the only gotcha is that it needs to be forward compatible, ie. lavu can be newer than lavc, but thats only a problem if you use sizeof(struct) or something equally ABI unstable
[17:14] <timothy_gu> whats the difference between a rect and a subtitle for text subtitlles like SRT?
[17:41] <cone-864> ffmpeg.git 03Michael Niedermayer 07master:ed86dbd05d61: avformat/aviobuf: Check that avio_seek() target is non negative
[18:13] <ubitux> timothy_gu: you just get 1 rect
[18:22] <timothy_gu> ubitux: OK. Why does a rect have a flags member while sub doesn't when the only flag available is clearly a subtitle flag (AV_SUBTITLE_FLAG_FORCED)?
[18:25] <nevcairiel> you cna have multiple rects on bitmap subs, and the flag only applies to one rect
[18:28] <timothy_gu> nevcairiel: ok what does "forced" mean in this context? Does it mean a "forced" subtitle stream like in MOV or does it mean something else? If the entire stream is forced how can you have multiple rects, some forced some not forced?
[18:29] <nevcairiel> PGS or VOB streams can have individual rects marked as forced
[18:29] <nevcairiel> blurays use that, and DVDs also, but more rarely
[18:33] <timothy_gu> ok
[19:47] <BBB> michaelni: https://github.com/rbultje/ffmpeg/commits/vp9-32bit if you feel like merging (enables 32bit and sse2 vp9 itxfm assembly)
[19:47] <BBB> michaelni: Im wondering if I should squash it all together since some intermediate steps wont compile or will break fate
[19:53] <michaelni> no strong oppinon on it but if intermediates dont build what are they usefull for? one could not use them to bisect
[19:55] <BBB> Im quite literally just committing as I go
[19:55] <BBB> some steps split between idct4, 8, 16 and 32
[19:55] <BBB> or idct/iadst
[19:56] <BBB> other steps are just various days of work inside the idct32 or idct16
[19:56] <BBB> they compile/work on x86-64 (always)
[19:56] <BBB> but only the final pieces work on x86-32
[19:57] <michaelni> if intermediate steps build fine it would be good to keep them otherwise, i would suggest to squash them or refactor/rebase so that intermediates build
[19:59] <BBB> ok, Ill do something along these lines
[19:59] <michaelni> seems to fail to build on ming64 "ffmpeg/libavcodec/x86/vp9itxfm.asm:797: error: (WIN64_SPILL_XMM:1) expecting `)'"
[19:59] <michaelni> also same error on other lines
[20:01] <akira4> ubitux, are you free right now ?
[20:05] <BBB> oh thats because I use expressions for xmm spills
[20:05] <BBB> lemme fix that
[20:08] <BBB> michaelni: fixed
[20:08] <BBB> Im thinking I should just squash the whole thing for final commit, much easier...
[20:08] <BBB> I dont think anyone else than me finds the intermediate steps helpful anyway
[20:09] <michaelni> sure, if you prefer
[20:16] <cone-864> ffmpeg.git 03Michael Niedermayer 07master:8ddfc00ab7ac: avformat/mp3dec: Name the dummy variable as what it is, to avoid confusion
[20:57] <cone-864> ffmpeg.git 03Michael Niedermayer 07master:a29524bf2e19: avformat/utils: Do not update programs streams from program-less streams in update_wrap_reference()
[21:02] <michaelni> BBB, ffmpeg/libavcodec/x86/vp9itxfm.asm:969: error: (WIN64_SPILL_XMM:1) expecting `)' 
[21:02] <michaelni> also in lines 970..978
[21:05] <BBB> oh
[21:06] <BBB> fixed again
[21:13] <ubitux> akira4: i'm here now :)
[21:14] <ubitux> BBB: oh so you got trolled into doing 32-bit? :)
[21:14] <akira4> alrighty.
[21:15] <akira4> so I checked the patch again and I have a few things that I'm not sure about 
[21:16] <akira4> there is something that occurs quite frequently..URLContext..not sure what exactly it is
[21:16] <ubitux> you won't need this since you're going to write an input device
[21:17] <akira4> okay. cool.
[21:17] <ubitux> you'll deal with an AVFormatContext, just like with the stl demuxer
[21:18] <akira4> Oh. btw,what exactly is the difference between a device and demuxer? 
[21:18] <ubitux> the directory 
[21:18] <ubitux> :)
[21:18] <ubitux> it's really just the same technically
[21:18] <ubitux> you just end up adding it in libavdevice instead of libavformat
[21:18] <akira4> so then nothing at all?
[21:19] <akira4> why make a new directory :P
[21:19] <ubitux> yeah well then you register it in libavdevice/alldevices.c and the associated Makefile
[21:19] <ubitux> just to separate :)
[21:19] <ubitux> like, it's kind of different from a user perspective
[21:19] <ubitux> but technically that's the same
[21:19] <akira4> hmm. alright
[21:20] <ubitux> some users also want to just support all the formats without all the weird devices
[21:20] <akira4> hmm
[21:20] <ubitux> so it's easier for them to choose to compile only libavformat
[21:20] <ubitux> maybe there are some other aspects, but that's all i know about it
[21:21] <akira4> :) cool.
[21:21] <akira4> right now I'm using /mnt/iso or do I change it to /mnt to make it more general or let it be ?
[21:21] <akira4> as the mount point I mean
[21:21] <ubitux> you have the input from the AVFormatContext.filename
[21:22] <ubitux> you will use -f dvd -i /mnt/iso; and AVFormatContext.filename will be "/mnt/iso"
[21:22] <akira4> oh.
[21:23] <ubitux> i think libavdevice/openal-dec.c might be a relatively simple example
[21:24] <akira4> uhm I know its a little stupid to ask but what exactly does a Context structure generally contain?
[21:24] <ubitux> what context in particular?
[21:24] <ubitux> AVFormatContext?
[21:25] <akira4> I mean in the patch
[21:25] <ubitux> can you share the link to the patch again?
[21:25] <akira4> just a sec
[21:27] <akira4> http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2012-January/119842.html 
[21:27] <akira4> finally :D
[21:28] <ubitux> you will probably have only one context
[21:28] <ubitux> i would guess this patch is kind of complicated because of the layer it's trying to deal with
[21:29] <ubitux> by working on demuxer/device layer, a lot of things will be way simpler for you
[21:29] <ubitux> akira4: i suggest you use this code just as a demonstration of the dvdnav api usage
[21:30] <akira4> hmm. got it.
[21:30] <akira4> so then I'll make everything from scratch?
[21:30] <ubitux> akira4: typically, i would suggest to pick libavdevice/openal-dec.c as a base, drop everything openal specific, and then try to dvdnav_open of the AVFormatContext.filename etc
[21:30] <ubitux> yeah
[21:30] <akira4> cool
[21:31] <ubitux> it's easy to make it by small step actually
[21:31] <ubitux> first make an input device that makes nothing
[21:31] <ubitux> like, ffmpeg -f dvd -i /mnt/iso -f null -  make this print "hello /mnt/iso"
[21:31] <ubitux> then add the basic dvd_nav layer
[21:32] <ubitux> to create all the streams (video, audio, subtitles, ...)
[21:32] <ubitux> so at least ffprobe can work, even if it outputs no packets
[21:32] <akira4> got it. For ffprobe to work I need to register it right?
[21:33] <akira4> the device I mean
[21:33] <ubitux> yeah sure
[21:33] <ubitux> well it's really just like what you did for the stl demuxer
[21:33] <ubitux> you can pick from Stefano patch the configure stuff for dvdnav though
[21:34] <ubitux> anyway, also
[21:34] <ubitux> as i said in the mail, "/join #libdvd*"
[21:34] <ubitux> if you need help with the dvdnav api directly
[21:35] <akira4> In the mail it was dvdcss*...I went and joined some random channel :-/
[21:35] <akira4> I'll do that then :)
[21:38] <akira4> ubitux, I do get an error when I try to run my sample test code with libdvdcss
[21:39] <ubitux> ?
[21:39] <akira4> http://pastebin.com/wXvN3Z1B
[21:39] <ubitux> what did you do exactly?
[21:39] <ubitux> like, what code is that?
[21:39] <akira4> link to the code http://pastebin.com/TDSuQpsH
[21:39] <ubitux> ah, standalone code
[21:41] <ubitux> i don't know the api, maybe try asking #libdvd*? :)
[21:41] <JEEB> I think those are now maintained by #videolan ?
[21:42] <ubitux> JEEB: j-b redirected me on #libdvd* the other day
[21:43] <JEEB> ah
[21:44] <akira4> I just asked it on the channel. *fingers crossed*
[21:46] <akira4> for the time being I'll  started with adding a  simple device then.
[21:46] <akira4> *get
[21:46] <ubitux> yeah
[21:47] <ubitux> did you get an iso with subtitles btw?
[21:47] <akira4> I did. but its in Portuguese :(
[21:47] <akira4> well better than nothing 
[21:47] <ubitux> good enough :)
[21:48] <akira4> oh yeah, do we have a demuxer/device which outputs multiple streams?
[21:48] <ubitux> let me check
[21:48] <akira4> sure
[21:49] <ubitux> akira4: lavfi :)
[21:49] <akira4> haha. Okay I'll check it out :)
[21:58] <ubitux> akira4: btw, i tried your code, and while it doesn't work when i specify the mount point, it seems to work when i specify the iso file
[21:59] <akira4> strange..gives me a segfault
[22:00] <ubitux> http://pastie.org/pastes/9780539/text
[22:00] <ubitux> (just tweaked a bit the code to use argv[1] as input)
[22:01] <akira4> you're right. Worked for me too..hmm
[22:01] <akira4> so I guess no need for a mount point then?
[22:02] <ubitux> seems so
[22:02] <ubitux> not sure what's going on here though
[22:02] <michaelni> BBB, thx seems working, should i merge it,? should i squash things in 1 commit?, should i wait?
[22:03] <ubitux> akira4: raise the problem on the libdvd channel, maybe we're doing something stupid in the way we mount the image
[22:04] <akira4> cool. I'm on it
[22:13] <cone-864> ffmpeg.git 03Anton Khirnov 07master:e10e6651b50b: thread: use "" instead of <> for including the w32pthreads wrapper
[22:13] <cone-864> ffmpeg.git 03Rémi Denis-Courmont 07master:8b51bcfed757: vdpau: revector macro to reduce line span
[22:13] <cone-864> ffmpeg.git 03Michael Niedermayer 07master:add040ff01cd: Merge commit 'e10e6651b50b4087f08813f3e503620db7413d3a'
[22:13] <cone-864> ffmpeg.git 03Michael Niedermayer 07master:0b30d186f1a2: Merge commit '8b51bcfed75721e0d20832e5a90e1d585318c9d9'
[22:22] <cone-864> ffmpeg.git 03Rémi Denis-Courmont 07master:8502c1e9ff9c: vdpau: add mapping for H.264 Extended profile
[22:22] <cone-864> ffmpeg.git 03Michael Niedermayer 07master:3f679f73a2ee: Merge commit '8502c1e9ff9c1dbb6e467630c048d098f4064021'
[22:33] <cone-864> ffmpeg.git 03Rémi Denis-Courmont 07master:559fa0d41b5c: vdpau: add mapping for H.264 Constrained Baseline profile and fallback
[22:33] <cone-864> ffmpeg.git 03Michael Niedermayer 07master:27f2e211aa6d: Merge commit '559fa0d41b5cf8f7e1ba89d1ac70e74712eb2816'
[23:06] <cone-864> ffmpeg.git 03Julien Ramseier 07master:fd665f7f48fa: avconv: Use the mpeg12 private option scan_offset
[23:06] <cone-864> ffmpeg.git 03Michael Niedermayer 07master:829099545bf3: Merge commit 'fd665f7f48fa7db89eb9a93ac33919f6adc40f9d'
[23:58] <cone-864> ffmpeg.git 03Lukasz Marek 07master:279412c83340: lavd/avdevice: use better option types for caps options
[23:58] <cone-864> ffmpeg.git 03Lukasz Marek 07master:b3311f3cc9ff: lavd/alsa-audio-common: mark default device in device list
[23:58] <cone-864> ffmpeg.git 03Lukasz Marek 07master:00dc2859f050: cmdutils: use macros for device test
[00:00] --- Mon Dec 15 2014