[Ffmpeg-devel-irc] ffmpeg-devel.log.20130925
burek
burek021 at gmail.com
Thu Sep 26 02:05:02 CEST 2013
[00:08] <BBB> michaelni__: that's a very sad solution, I'm trying to slowly update the whole tree to use ptrdiff_t where appropriate...
[00:08] <BBB> michaelni__: I really do think it makes more sense longer-term, as much as it's kind of a pain in the transition period
[00:08] <BBB> x264 did it too, they profit every day
[00:08] <BBB> and yay I finally have real internet
[00:12] <Skyler_> x264 uses intptr_t (I have no opinion on the ptrdiff vs intptr thing though)
[00:12] <BBB> I know :)
[00:12] <Skyler_> ah, okay
[00:12] <BBB> my point was you're not using int and suffer horribly every day
[00:15] <iive> BBB: you had not google fiber until now?
[00:15] <BBB> I don't think new york city has google fiber
[00:16] <BBB> (and yes I don't live in california anymore, me+family moved back)
[00:16] <iive> :(
[00:22] <kierank> BBB: did you leave google
[00:22] <BBB> yes
[00:22] <Compn> shh dont say it :D
[00:24] <Compn> the g word
[00:24] <Compn> BBB : neat, now you can tell us all of the secrets :P
[00:25] <gnafu> Ooh.
[00:28] <iive> BBB: did you start working of ffvp9 before or after you left google?
[00:31] <cone-906> ffmpeg.git 03Michael Niedermayer 07master:c88ac1e0233f: avcodec/g2meet: fix regression with rgb cursors
[00:33] <gnafu> And what are you going to do now (aside from going to Didney Worl)?
[00:36] <Compn> curious if he likes cali or ny better :P
[00:39] <BBB> Compn: ny ofcourse
[00:39] <iive> moving from one state to the other is no cheap or easy endeavor.
[00:40] <BBB> iive: I did ffvp9 while I was on leave between jobs, I did some work while at google and on leave I was officially still employed by google but it was sort of my private time
[00:40] <BBB> I finished a few bugs after starting my new job, but not a lot
[00:40] <BBB> gnafu: see linkedin ;) I work for http://www.twosigma.com/ now
[00:41] <Compn> now to make xvp9 encoder and make bank ?
[00:41] <Compn> too many makes
[00:41] <Compn> hmm
[00:42] <iive> so you are now in micro-transaction business?
[00:42] <kierank> BBB: heh you gave in like our old x264 gsoc student
[00:43] Action: kierank did an internship at one of these places a few years ago
[00:43] <iive> or how was the name.. of these automated stock trading systems ...
[00:43] <iive> high frequency trading.
[00:50] <BBB> kierank: ?
[00:50] <kierank> one of our old gsoc students went into a firm like yours
[00:50] <cone-906> ffmpeg.git 03Michael Niedermayer 07master:bb4b041df351: avcodec/mpegvideo_enc: check qmin/qmax
[00:50] <BBB> ah
[00:50] <BBB> also I don't do high frequency trading
[00:50] <BBB> it's a hedge fund primarily, not a hft firm
[00:54] <iive> i see.
[00:55] <BBB> kierank: which student? :)
[00:55] <kierank> dylan
[00:56] <kierank> i forget his surname
[00:56] <kierank> wrote weightp
[00:56] <BBB> ah, cool
[00:59] <Compn> BBB : lemme know good stock tips :)
[00:59] <Compn> if you find any
[00:59] <BBB> you know I'm not allowed to do that :)
[00:59] <Compn> even if you hear about them in a newspaper or tv broadcast?
[01:00] <BBB> how would I, you, or regulators, know the difference?
[01:00] <Compn> not asking you to do any illegal insider trading :P
[01:00] <BBB> safer I don't say anything :)
[01:01] Action: Compn facepalms
[01:02] <kierank> there were a lot of strict rules when i interned as well
[01:02] <kierank> it was taken very seriously
[01:03] <Compn> so is that health company google is starting
[01:03] <Compn> is that going to be a public company under a different stock name ?
[01:03] <Compn> i wonder if that would be a good investment
[01:20] <iive> Compn: i'll tell you a secret. stocks picked at random give same returns as these picked by skillful brokers.
[01:21] <iive> and maybe a little better
[01:23] <Compn> thats why i'm aksing for tips, from people in the technology field
[01:23] <Compn> new startups etc
[01:28] <iive> Compn: i guess you've read this before - http://www.newscientist.com/article/mg21228354.500-revealed--the-capitalist-network-that-runs-the-world.html?full=true&print=true ?
[01:29] <iive> the stock market is basically a casino and the odds are always in favor of the bank :)
[02:18] <cone-906> ffmpeg.git 03Michael Niedermayer 07master:65bf9a44d7b0: avcodec/pngdec: check for stream end in png_decode_idat()
[02:39] <Compn> iive : yes i know. :(
[02:39] <Compn> another research paper using zzuf fuzzer :)
[02:43] <Compn> hmm
[02:43] <Compn> 60gb / 50kb/s ?\\
[02:44] <Compn> argh enter key broken
[02:44] <Compn> 13 days to download all samples repo?
[02:45] <iive> Compn: i guess you are not with google fiber either :|
[02:47] <Compn> 50kb/s is reccomended speed in the readme
[02:50] <Compn> hmm what was the fuzz project that gave ffmpeg all of those automatically generated fuzz crash reports?
[02:51] <cone-906> ffmpeg.git 03Michael Niedermayer 07release/0.5:fde0b7d91c9c: avcodec/rpza: Perform pointer advance and checks before using the pointers
[02:51] <cone-906> ffmpeg.git 03Michael Niedermayer 07release/0.5:31f9e849a88b: matroska_read_seek: Fix used streams for subtitle index compensation
[02:51] <cone-906> ffmpeg.git 03Michael Niedermayer 07release/0.5:e7484d54252d: avcodec/dsputil: fix signedness in sizeof() comparissions
[02:51] <cone-906> ffmpeg.git 03Michael Niedermayer 07release/0.5:617a9eedc654: avcodec/ffv1enc: update buffer check for 16bps
[02:51] <iive> oh..
[02:55] <cone-906> ffmpeg.git 03Michael Niedermayer 07release/0.5:b012da4019e3: update for 0.5.13
[02:57] <iive> cu have fun
[02:58] <Compn> hmmmm
[02:58] <Compn> wait, gentoo has a test flag for libav that includes video samples?
[02:59] <Compn> we dont own the copyright on our samples repo...
[02:59] <Compn> seems odd to see a distro distributing copyrighted video clips :)
[03:00] <Compn> if indeed i am reading this correctly
[03:13] <cone-906> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n0.5.13': unknown revision or path not in the working tree.
[03:13] <cone-906> Use '--' to separate paths from revisions
[03:13] <cone-906> refs/tags/n0.5.13:HEAD: avcodec/pngdec: check for stream end in png_decode_idat()
[03:17] <Compn> ooo broke the cone
[06:18] <Compn> noooooo, cone is down
[09:58] <cone-867> ffmpeg.git 03Anton Khirnov 07master:668643b9239c: matroskadec: check av_strdup() when setting defaults
[09:58] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:57070d9892ad: Merge commit '668643b9239c70b777aea322eab411ebc960d9a0'
[10:12] <cone-867> ffmpeg.git 03Anton Khirnov 07master:e880418660c8: cabac: remove write-only h264_mps_state[]
[10:12] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:b0b66269f422: Merge commit 'e880418660c80e2f12a123e131975cdb6b12cd13'
[10:41] <cone-867> ffmpeg.git 03Anton Khirnov 07master:cab8c5f8e140: h264: do not reinitialize the global cabac tables at each slice header
[10:41] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:4a89868c5f9d: Merge commit 'cab8c5f8e140c96ba3725ab709d823abfd1e31a5'
[11:13] <cone-867> ffmpeg.git 03Anton Khirnov 07master:2725f2d40315: doc/filters: fix an option name in the unsharp docs
[11:13] <cone-867> ffmpeg.git 03Anton Khirnov 07master:5f4b1b1cbd06: lavc doxy: document that avcodec_flush_buffers() invalidates decoded frames
[11:13] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:9b3d4258d9f3: Merge commit '2725f2d40315b56f17c5dffe39dda7d94786302d'
[11:13] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:c3c6999ea1c3: Merge remote-tracking branch 'qatar/master'
[13:57] <wm4> at which point did request_channel_layout actually become reliable enough so that request_channels (now deprecated) is not needed anymore?
[13:58] <nevcairiel> has it actually? :p
[13:58] <wm4> dunno, currently I just set both
[13:58] <nevcairiel> request_channels has been deprecated ever since i started paying attention like 3 years ago
[13:58] <wm4> meh
[14:07] <cbsrobot> can anyone share "SMPTE 428-1: D-Cinema Distribution Master - Image Characteristics" ?
[16:02] <xlinkz0> avutil/timestamp.h still isn't c++ compatible :(
[16:04] <Daemon404> xlinkz0, which bit
[16:04] <Daemon404> and are you using a proper extern "C" {}
[16:05] <Daemon404> ah... i see compound literals
[16:06] <wm4> this specific use of compound literals is probably a bit too clever
[16:15] <xlinkz0> i did use extern "C"
[16:15] <xlinkz0> ..
[16:20] <j-b> BBB: *hug*
[16:20] <Daemon404> wm4, well yeah
[16:20] <Daemon404> it's a define
[16:20] <Daemon404> which will be used directly in the c++
[16:21] <ubitux> j-b: btw, if you had reported #8935, i would have explained to you the problem, and afaict the problem is from vlc
[16:21] <ubitux> do you want an explanation?
[16:22] <j-b> ubitux: yes
[16:22] <ubitux> j-b: in ffmpeg sense, AV_CODEC_ID_TEXT is verbatim text, no markup, SUBRIP is text with markup (and SRT is the old broken layouts of packets with timestamps in)
[16:23] <ubitux> matroska.c:
[16:23] <ubitux> {"S_TEXT/UTF8" , AV_CODEC_ID_SUBRIP},
[16:23] <ubitux> {"S_TEXT/UTF8" , AV_CODEC_ID_TEXT},
[16:23] <ubitux> {"S_TEXT/UTF8" , AV_CODEC_ID_SRT},
[16:23] <ubitux> (sorry extra spaces)
[16:23] <ubitux> what i read from the ticket
[16:23] <ubitux> VLC only supports "TEXT"
[16:23] <ubitux> it should support SUBRIP as well,
[16:23] <ubitux> because in Matroska, "TEXT" are actually text with markup
[16:23] <ubitux> there is no distinction between markup and no markup
[16:24] <ubitux> markup is assumed (subrip markup, aka <i> <b> etc)
[16:24] <ubitux> in ffmpeg, we should NOT change SUBRIP to TEXT
[16:24] <ubitux> because our decoders will not interpret the markup anymore
[16:25] <j-b> So?
[16:25] <ubitux> (the packet payload layout will likely be the same )
[16:25] <j-b> S_TEXT/UTF8 is VLC_CODEC_SUBT
[16:25] <ubitux> j-b: so... you need to support AV_CODEC_ID_SUBRIP, as consider it TEXT, likely
[16:25] <ubitux> this is how i understand the issue at least
[16:25] <ubitux> anyway, if you think there is a problem with ffmpeg, tell me
[16:26] <j-b> no, you just proved my point, thanks.
[16:26] <ubitux> which one?
[16:26] <wm4> yeah, TEXT needs to be for "real" plain text
[16:27] <ubitux> in matroska sense you can consider it subrip anyway
[16:27] <wm4> AV_CODEC_ID_SRT is the old codec ID for subrip with timestamps-in-packet-data, right?
[16:27] <ubitux> yes
[16:27] <wm4> libav still uses that
[16:27] <ubitux> yes
[16:27] Action: wm4 has a terrible hack to deal with that
[16:27] <j-b> that we should have our own demuxer.
[16:27] <ubitux> the packet are sane now
[16:28] <ubitux> you get clean subrip/text packet now
[16:28] <ubitux> not the crafted packets anymore
[16:28] <ubitux> j-b: want the commit hash where i explain all of this?
[16:28] <ubitux> i believe it was in APIChanges, and even the Changelog
[16:29] <ubitux> mmh maybe that one was just about ASS
[16:29] <ubitux> subrip is even older
[16:29] <ubitux> but it was in APIChanges as well it seems
[16:30] <ubitux> (look for SUBRIP in the APIChanges)
[16:41] <xlinkz0> how can I seek to the next keyframe using the API ?
[16:41] <Daemon404> pray
[16:42] <xlinkz0> mkay
[16:42] <xlinkz0> to whom?
[16:42] <xlinkz0> the ops?
[16:42] <wm4> maybe try to seek to PTS + 1/timebase
[16:43] <xlinkz0> on second thought i can afford to just read_frames
[16:43] <wm4> then it should seek forward, as long as you don't use AVSEEK_FLAG_BACKWARD
[16:43] <cone-549> ffmpeg.git 03Michael Niedermayer 07master:ab6fbe820628: avcodec/cabac: remove h264_lps_state
[16:44] <wm4> hm, that reminds me: does AV_PKT_FLAG_KEY mean you can use this packet and all following ones to resume decoding after you've reset the decoder?
[16:44] <xlinkz0> where are the flags defined?
[16:44] <wm4> which ones
[16:45] <xlinkz0> the seek ones
[16:45] <wm4> or in other words, does AV_PKT_FLAG_KEY always coincide with seek points in the seek index?
[16:45] <wm4> xlinkz0: avformat.h
[16:45] <xlinkz0> thanks
[16:45] <xlinkz0> so i should use av_seek_frame and not avformat_seek_file ?
[16:46] <wm4> both should work
[16:46] <wm4> I have no clue which you should use
[16:46] <wm4> and both suck
[16:46] <xlinkz0> is there anything in this entire project you guys are happy with? :\
[16:46] <wm4> no
[16:46] <xlinkz0> :(
[16:46] <wm4> some subtitle formats can be seeked only with avformat_seek_file() btw.
[16:48] <Daemon404> [15:43] <+wm4> then it should seek forward, as long as you don't use AVSEEK_FLAG_BACKWARD
[16:48] <Daemon404> on some formats
[16:48] <wm4> yeah
[16:48] <wm4> so unreliable
[16:48] <Daemon404> you cant rely on jack without indexing first
[16:49] <wm4> is there a way to make libavformat index a whole file?
[16:49] <Daemon404> no
[16:49] <Daemon404> i use ffms2 for this
[16:49] <Daemon404> ;)
[16:49] <wm4> lol ok
[16:49] <michaelni__> ubitux, about the delphi headers did you try to mail the guy who wrote them ?
[16:50] <ubitux> nope
[16:50] <ubitux> i thought it was just a relic of the past entry
[16:50] <ubitux> and didn't thought much about it
[16:50] <Daemon404> it is
[16:50] <Daemon404> i think delphi has much better support for c stuff now
[16:50] <Daemon404> (yes it still exists... somehow)
[16:52] <michaelni__> iam ok with removing the link but the guy who submited it originally should be notified that his page disappeared, he might not be aware ...
[16:52] <Plorkyeran> +wm4> or in other words, does AV_PKT_FLAG_KEY always coincide with seek points in the seek index? <-- no
[16:52] <xlinkz0> so tried seeking after getting some frames and apparently it doesn't work :\
[16:52] <Plorkyeran> it does for most formats
[16:52] <wm4> Plorkyeran: heh, just as expected
[16:52] <Plorkyeran> but it's set on the wrong frames for PIR h264
[16:52] <ubitux> michaelni__: ok i'll mail him
[16:52] <michaelni__> ubitux, thx
[16:53] <TheFluff> xlinkz0: how many different formats do you want to be able to deal with
[16:53] <xlinkz0> mp4 h264 only
[16:53] <TheFluff> if the answer is "all of them", you have a nontrivial problem on your hands
[16:53] <xlinkz0> i'd be happy navigating an mp4
[16:53] <TheFluff> then it shouldn't be that hard
[16:54] <xlinkz0> ok so i seeked once, got a frame with av_read_frame and decoded the frame
[16:54] <xlinkz0> then i seeked again, got another frame the same way
[16:55] <xlinkz0> but the second frame is the one after the first one, at the first seek point
[16:55] <xlinkz0> do i need to reset something if I want to seek again?
[16:55] <TheFluff> did you flush your buffers?
[16:55] <TheFluff> as in, call avcodec_flush_buffers()
[16:55] <TheFluff> after the seek
[16:56] <xlinkz0> the second one?
[16:56] <TheFluff> you should flush after each seek, iirc
[16:56] <xlinkz0> i didn't, will do now
[16:56] <TheFluff> actually I probably shouldn't give you advice on this because I can't remember shit and it's been ages since I did anything with avformat
[16:57] <xlinkz0> thanks ! it works
[16:57] <wm4> I really wonder why ffms2 isn't part of ffmpeg
[16:58] <xlinkz0> you should always give advice on ffmpeg, or noone else will and the person asking will be lost in oblivion :(
[16:58] <xlinkz0> sadly there are no examples with seeking
[17:00] <TheFluff> wm4: it's written in C++ and thus unclean
[17:00] <Daemon404> too high level
[17:00] <Daemon404> too usable
[17:00] <TheFluff> but I agree that for a lot of use cases it would be nice to have an API that works something like that
[17:01] <Plorkyeran> it's like 5k lines of code counting the avs and vapoursynth plugins
[17:01] <Daemon404> getframe() > writing that goddamn packet loop for the Nth time
[17:01] <Plorkyeran> writing something similar in C as part of ffmpeg should not be that big of a deal
[17:01] <Plorkyeran> (but I have no interest in doing it because fuck writing C)
[17:04] <pippin> why seek out cancer if you dislike having a cold?
[17:05] <xlinkz0> is my getframe loop any good? http://codepad.org/930B0Qvl
[17:05] <TheFluff> yes please try starting a c/c++ holy war with the lamest troll I've seen all week
[17:10] <wm4> xlinkz0: why it the code block doing video decoding duplicated?
[17:11] <xlinkz0> the one at the end is for decoding cached frames
[17:11] <xlinkz0> i should put that in a separate function indeed
[17:11] <Paranoialmaniac> xlinkz0: av_read_frame may return EAGAIN (which takes negative value). don't confuse with EOF
[17:11] <wm4> what's EAGAIN for?
[17:12] <Paranoialmaniac> "there is no data available right now, try again later"
[17:12] <wm4> libavdevice stuff?
[17:13] <Paranoialmaniac> dunno. but i often get EAGAIN when reading some flv files.
[17:14] <xlinkz0> thanks
[18:33] <cone-549> ffmpeg.git 03Michael Niedermayer 07master:45f0623ae3fa: avcodec/lagarith: check scaled probabilities
[20:05] <durandal_1707> have the emu edge issue been fixed?
[20:17] <cone-549> ffmpeg.git 03Michael Niedermayer 07master:c99d27287d9b: avcodec/wmaprodec: check that there are input bits left in decode_subframe_length()
[20:58] <wm4> haha the next group of fringe bugs
[21:01] Action: durandal_1707 here goes food
[21:06] <durandal_1707> michaelni: ^ is bug in parser
[21:49] <cone-549> ffmpeg.git 03Paul B Mahol 07master:f5498ef38daa: avcodec/flicvideo: fix infinite loops
[22:01] <cone-549> ffmpeg.git 03Michael Niedermayer 07master:851a6e2f1aee: avcodec/wmalosslessdec: Fix return code for invalid buffer sizes
[22:55] <cone-549> ffmpeg.git 03Luca Barbato 07release/0.10:ba5dfc25ee0a: indeo4: Do not access missing reference MV
[22:55] <cone-549> ffmpeg.git 03Luca Barbato 07release/0.10:06c52faef27e: indeo4: Check the quantization matrix index
[22:55] <cone-549> ffmpeg.git 03Michael Niedermayer 07release/0.10:91ad27e8f5fb: Merge commit '06c52faef27e5bded4ceda7e6d1541f9fb20e84c' into release/0.10
[22:56] <JEEB> avformat/mpegenc.c:remove_decoded_packets() -- what does the buffer underflow error actually mean?
[22:56] <JEEB> is it a VBV underflow, aka bits are going out too fast? or something else
[23:02] <cone-549> ffmpeg.git 03Luca Barbato 07release/0.10:609345cd5e2a: indeo4: Validate scantable dimension
[23:02] <cone-549> ffmpeg.git 03Luca Barbato 07release/0.10:e2dcb8208e8f: indeo5: return proper error codes
[23:02] <cone-549> ffmpeg.git 03Michael Niedermayer 07release/0.10:3308b443f934: Merge commit 'e2dcb8208e8f6cffef58a85127765047f5ef8868' into release/0.10
[23:16] <kolosos> http://pastebin.com/2A5ardCU <=== i get this strange buffer underflow error on several input formats of a youtube video - 480.flv, 720.mp4, 720.webm, 480.webm, etc.
[23:18] <kolosos> then dvdauthor confirms as follows : WARN: Discontinuity of 71 in audio channel 0; please remultiplex input
[23:34] <cone-549> ffmpeg.git 03Luca Barbato 07release/0.10:36921fcdd361: indeo: Reject impossible FRAMETYPE_NULL
[23:34] <cone-549> ffmpeg.git 03Martin Storsjö 07release/0.10:729143e2d27d: ac3dec: Don't consume more data than the actual input packet size
[23:34] <cone-549> ffmpeg.git 03Martin Storsjö 07release/0.10:a593d2e92e14: mov: Do not allow updating the time scale after it has been set
[23:34] <cone-549> ffmpeg.git 03Luca Barbato 07release/0.10:0d24adbe8d8e: dsicinav: Bound-check the source buffer when needed
[23:34] <cone-549> ffmpeg.git 03Luca Barbato 07release/0.10:246e0e2c994f: alsdec: Fix the clipping range
[23:35] <cone-549> ffmpeg.git 03Luca Barbato 07release/0.10:8006716f2155: xl: Make sure the width is valid
[23:35] <cone-549> ffmpeg.git 03Luca Barbato 07release/0.10:9c779b5dd0e8: bink: Bound check the quantization matrix.
[23:35] <cone-549> ffmpeg.git 03Luca Barbato 07release/0.10:54e03863691d: vc1: check the source buffer in vc1_mc functions
[23:35] <cone-549> ffmpeg.git 03Michael Niedermayer 07release/0.10:210a437e105f: Merge commit '54e03863691dcae73260f70108b3731b70773e7c' into release/0.10
[23:36] <kolosos> <cone-549> ffmpeg.git Martin Storsjö release/0.10:729143e2d27d: ac3dec: Don't consume more data than the actual input packet size
[23:37] Action: kolosos wonders if that could be related to http://pastebin.com/2A5ardCU
[23:37] <JEEBsv> not related to you :P
[23:37] <kolosos> meh ok
[23:37] <JEEBsv> the encoders seem to be working just fine for you, it's just the mpegenc muxer erroring out :P
[23:38] <JEEBsv> also do feel free to grab a static build of a newer ffmpeg version and see if that does the same thing
[23:38] Action: kolosos shudders
[23:38] <JEEBsv> fflogger> Static FFmpeg builds - 1) for 3.x+ kernels: http://ffmpeg.gusari.org/static/ or 2) for 2.6.32+ kernels:
[23:39] <JEEBsv> http://johnvansickle.com/ffmpeg
[23:39] <JEEBsv> a static binary you can just run from some directory :P
[23:39] <michaelni> kolosos, for VBV errors try change max/min bitrate, vbv size, also try higher quality encoding settings like trellis, mbd 2, they can help make the video fit better in the buffer
[23:39] <JEEBsv> michaelni: that seems to be a muxer VBV error, not a video encoder error, funny enough :s
[23:40] <JEEBsv> I tried to look at the code in mpegenc.c
[23:40] <JEEBsv> but I just couldn't read what exactly it was failing at
[23:40] <michaelni> hmm
[23:40] <JEEBsv> @ remove_decoded_packets()
[23:41] <michaelni> when the muxer fails, first question is, is the encoder producing vbv compliant output ?
[23:42] <JEEBsv> anyways, if I recall correctly the -target setting does set the VBV constraints at least
[23:42] <JEEBsv> it also changes rate and resizes the clip
[23:43] <JEEBsv> also it is correct to think of that error as a VBV underflow?
[23:45] <JEEBsv> kolosos: anyways do try with a static build
[23:45] <JEEBsv> that would at least tell that the thing still happens
[23:45] <JEEBsv> the 1.2.x branch is by now pretty old
[23:46] <kolosos> <michaelni> when the muxer fails, first question is, is the encoder producing vbv compliant output ?
[23:46] <kolosos> any way to check that?
[23:49] <kolosos> Here's the video: http://www.youtube.com/watch?v=yqGcZ6WBZnY
[23:50] <michaelni> probably better if you upload the flv somewhere, who knows if 2 people downloading from youtube get the exact same file
[23:50] <michaelni> also probably a good idea to open a ticket on trac
[23:51] <kolosos> ok - learning a lot, thought this morning i will "just quickly download a vid and burn to a dvd"
[23:52] <kolosos> that was 6 hours ago :)
[23:54] <kolosos> i basically tried all 6 the higher-res formats available for download using the firefox plugin "1-click Youtube Video Downloader 2.1.5"
[23:55] <kolosos> i'm off to the rink for practice but will be baaaak
[00:00] --- Thu Sep 26 2013
More information about the Ffmpeg-devel-irc
mailing list