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

[burek]

[00:00] <Daemon404> the dummy pas is what ymc.exe does
[00:00] <Daemon404> (ymc = yatta metrics collector)
[00:00] <Daemon404> and it des manual but guided manual ivtc correction
[00:00] <Daemon404> using loads an loads of undocumeted hotkeys
[00:00] <Daemon404> or poorly documented, rather
[00:01] <ubitux> ok, gonna read that stuff to understand the process
[00:01] <ubitux> because it's completely new to me.
[00:01] <Daemon404> im not sure reading helps wrt yatta.
[00:02] <Daemon404> afaik most people learn by some sort of ancient ritual wherein there is a teacher and student
[00:02] <ubitux> it might give me some hints about how you're using it, and how it interfaces with [tv]ivtc
[00:02] <Daemon404> https://vimeo.com/57569501
[00:02] <Daemon404> pw is yatta
[00:03] <llogan> Daemon404: I too have a poop.mp4 and a test.mp4.
[00:03] <Daemon404> someone from The Other Place doing a very poor (and slow) screencast
[00:03] <TheFluff> ubitux: http://mod16.org/samples/nastystuff/ updated
[00:03] <saste> what if i move the mentored tasks up in the page?
[00:03] <TheFluff> and added a readme.txt
[00:04] <saste> and list the other ones as "unmentored"?
[00:04] <TheFluff> my memory of some of these is sorta hazy, so the explanations are likewise
[00:04] <TheFluff> I can't be bothered to actually check this stuff out
[00:04] <ubitux> TheFluff: oh thx for the readme
[00:04] <saste> or we can keep the historical division, "1st tier" and "2nd tier"
[00:04] Action: wm4 still thinks actually porting vivtc to libavfiltert is a very bad idea
[00:04] <ubitux> Daemon404: "SAVE! SAVE! SAVE! SAVE!" :))
[00:04] <llogan> saste: i like your first idea better. the tier stuff is not clear for newsers.
[00:04] <ubitux> wm4: it will allow dropping at list 4 or 5 filters from libmpcodecs
[00:05] <Daemon404> ubitux, yea
[00:05] <wm4> eh
[00:05] <ubitux> and will stop some complains
[00:05] <wm4> ubitux: what if the MP filters are faster with the respective use cases
[00:05] <wm4> then politics will stop deletion
[00:06] <ubitux> i'll try to show how bad/unusable they are in comparison to the new filter if that's possible
[00:07] <saste> ubitux, that means that I'll have to remove some images
[00:07] <ubitux> saste: feel free to
[00:07] <wm4> and what's wrong with requiring an external dependency (like vsynth) for some features?
[00:08] <ubitux> wm4: some features are already in natively, vsynth might not be available in a lot of situations, it's a young project, etc etc etc
[00:08] <Daemon404> i would be satisified with a simple dlopen inteface
[00:08] <TheFluff> ubitux: added another one but that's all the obvious ones I can find right now
[00:08] <ubitux> wm4: i'm not saying a vsynth wrapper won't be welcome, but relying on it for an essential feature is not a good idea
[00:09] <TheFluff> might or might not have more on some usb disc somewhere
[00:09] <ubitux> TheFluff: perfect, thx a lot
[00:09] <Daemon404> lawl
[00:09] <Daemon404> Daa Daa Daa
[00:09] <Daemon404> i have all those dvds
[00:10] <Daemon404> (and am still working on them)
[00:10] <cone-791> ffmpeg.git 03Luca Barbato 07master:5cf7c7275777: shorten: use the unsigned type where needed
[00:10] <cone-791> ffmpeg.git 03Diego Biurrun 07master:5a4e9fe85528: avcodec/internal: Fix #if DECODE_AUDIO / ENCODE_AUDIO name mismatch
[00:10] <cone-791> ffmpeg.git 03Michael Niedermayer 07master:ff9b607489e6: Merge commit '5a4e9fe855282a99586050a507d0a486ad39df5b'
[00:10] <wm4> ubitux: what would you say if I started porting libavfilter filters to mpv?
[00:10] <TheFluff> I think House gave me that one sample
[00:10] <TheFluff> (which is why it's called "a clip of wealth and taste.vob")
[00:10] <ubitux> wm4: you already have a hard dep on ffmpeg, so that would be stupid
[00:11] <wm4> there's no hard dep on libavfilter yet
[00:11] <Daemon404> and here i just thought you liked the rolling stones.
[00:11] <TheFluff> I don't :(
[00:11] <ubitux> wm4: no problem in adding it ;)
[00:11] <TheFluff> oh man
[00:11] <ubitux> wm4: the situation is not comparable anyway
[00:11] <TheFluff> I found an old friend
[00:11] <TheFluff> axpintro2.ogm
[00:11] <Daemon404> you dont say
[00:12] <Daemon404> http://chromashift.org/img/%5bAXP%5d-Intro.ogm
[00:12] <Daemon404> me too.
[00:12] <TheFluff> yase
[00:14] <wm4> what is this video
[00:14] <wm4> somehow it is extremely disturbing
[00:15] <Daemon404> the anime dvd scene in like 2001
[00:15] <Daemon404> is what it is
[00:15] <Daemon404> or whenever love hina came out
[00:15] <ubitux> haha
[00:15] <ubitux> awesome
[00:16] <Daemon404> that prefixed every single episode
[00:17] <saste> llogan, i'll do
[00:17] <saste> ubitux, going to remove some of your images, sorry
[00:17] <ubitux> saste: as i said, go ahead
[00:19] <ubitux> TheFluff, Daemon404, this might be a stupid question but... how come these crazy mixed content actually renders good enough on analog tv devices without ppl noticing anything?
[00:19] <ubitux> "A music video DVD. Mixed hard/soft telecine, mixed framerates, mixed aspect ratios, weird pattern mismatches.
[00:19] <ubitux> A good introduction to weird IVTC in general."
[00:20] <ubitux> i mean... how that even not possible to notice it, even on a crappy tv?
[00:20] <Daemon404> a) it is noticable, and even some review sites note it
[00:20] <Daemon404> b) field based tvs
[00:20] <Daemon404> (dat flicker)
[00:20] <TheFluff> if you want something that should be impossible to not notice
[00:21] <gnafu> It's one of the reasons DVD players like the Oppo DV-971H are so loved :-P.
[00:21] <TheFluff> check out the tayutama .ts
[00:21] <saste> who is TBD?
[00:21] <TheFluff> to be determined
[00:21] Action: gnafu loves his Oppo DV-971H, but wonders if modern upscaling Blu-ray players might be just as good or better for DVD playback nowadays.
[00:22] <saste> TheFluff, seems likely
[00:24] <gnafu> I suppose my Oppo is still good for PAL and other region discs, though I have neither.
[00:25] <ubitux> i see no hentai in your samples
[00:25] <ubitux> it seems i'll have to rely on Daemon404 
[00:25] <TheFluff> lol
[00:25] <TheFluff> no, I never encoded hentai
[00:25] Action: Daemon404 sues ubitux for slander
[00:25] <TheFluff> it's reportedly nastier than most anime though (and not in the obvious way)
[00:25] <ubitux> :)
[00:26] <TheFluff> I guess I should ask kaverin if he still has some of his weird stuff somewhere
[00:26] <Daemon404> TheFluff, anything buy Japan-X
[00:26] <gnafu> Daemon404: s/slander/libel/
[00:26] <Daemon404> later, Japan Anime
[00:26] <Daemon404> or Kitty
[00:28] <cone-791> ffmpeg.git 03Ronald S. Bultje 07master:8d061989dd03: lavc: Split out ff_hwaccel_pixfmt_list_420[] over individual codecs
[00:28] <cone-791> ffmpeg.git 03Carl Eugen Hoyos 07master:5da512849376: cavs: Add a dependency on h264chroma
[00:28] <cone-791> ffmpeg.git 03Michael Niedermayer 07master:fa3a7b55ec1b: Merge commit '5da51284937649a8ebb84fa951c235438fcbf8ae'
[00:33] <cone-791> ffmpeg.git 03Martin Storsjö 07master:e760e1d40826: avconv: Make sure the encoder exists before inspecting supported_list
[00:33] <cone-791> ffmpeg.git 03Michael Niedermayer 07master:38d40ac18a38: Merge remote-tracking branch 'qatar/master'
[00:44] <Daemon404> some nostalgia for j-b -- http://www.animereactor.dk/jfs/vlc-options-ftw.png
[00:44] <ubitux> oh vimeo is providing a way to download the original file untouched
[00:44] <Daemon404> ubitux, i left it enabled
[00:44] <Daemon404> for my video
[00:44] <Daemon404> its optional
[00:44] <ubitux> that's a great thing
[00:45] <ubitux> tell your buddies they're doing a better job than youtube on a lot of points
[00:45] <Daemon404> lolk
[00:45] <ubitux> and well, you might impacting in that direction too :)
[00:45] <ubitux> +be
[00:51] <ubitux> Daemon404: so yatta calls avs, with tdecimate (and various stuff like the pp needi3), and you get a list of field matching failures, which you seem to be manually fixing
[00:51] <ubitux> what gives you that log?
[00:52] <ubitux> also, most of the work (the global pass) is done by the tdecimate?
[00:52] <Daemon404> it uses patter  guidance
[00:52] <Daemon404> that algorithm is not documented
[00:52] <Daemon404> other than the pascal code
[00:52] <Daemon404> based on collected metrics
[00:53] <ubitux> oh so yatta is doing the matching failure thing?
[00:53] <Daemon404> [18:52] <@ubitux> also, most of the work (the global pass) is done by the tdecimate? <-- tdecimate is only used for collecting dmetrics and applyign an override file
[00:53] <Daemon404> ubitux, yes
[00:53] <ubitux> as a second pass on the analysis of the tdecimate output?
[00:53] <Daemon404> not exactly
[00:53] <Daemon404> it doesnt just use decimate metrics
[00:54] <Daemon404> read warpsharp.info/yatta.txt
[00:54] <Daemon404> the YMC section
[00:54] <Daemon404> and thee PG section
[00:54] <ubitux> ok, will do, thx
[00:55] <ubitux> you seem to be struggling with some of the scenes
[00:55] <Daemon404> that is not me
[00:55] <ubitux> looks like black magic to me, that's fun
[00:55] <Daemon404> my name isn't Adam
[00:56] <ubitux> ah sorry, i didn't stalked info
[01:23] <Compn> ubitux : is 3d subs on your todo ?  ehe
[01:23] <Compn> not even sure how that works...
[01:34] <ubitux> 3d subs? erm.
[01:47] <cone-791> ffmpeg.git 03Stefano Sabatini 07master:9767ec6b865c: lavu: add escape API
[01:47] <cone-791> ffmpeg.git 03Stefano Sabatini 07master:9167db3829f3: doc/texi2pod: fix @ref substitution rule, disallow "}" within the fields
[01:47] <cone-791> ffmpeg.git 03Stefano Sabatini 07master:d95143ec82a0: lavf/segment: add support to ffconcat segment list
[01:48] <Compn> ubitux : maybe it will come when we get mvc supprot :P
[01:52] <saste> ubitux, what about the opencl patch?
[01:53] <ubitux> saste: i deleted the thread already
[01:53] <ubitux> so it's a pain for me to review it now :p
[01:53] <Compn> lol
[01:53] <ubitux> maybe in the next round
[01:53] <ubitux> when he'll send a new version
[01:53] <ubitux> saste: what's the status of av_eval_is_const?
[01:54] <ubitux> i really need your volume eval thing...
[01:54] <saste> ubitux, blocked
[01:54] <saste> not happy at all with that
[01:54] <ubitux> it's blocking my ebu normalization :(
[01:54] <ubitux> did you see Nicolas' reply and mine?
[01:54] <saste> i have a patch which allows to mark a function as const, but that's not helpful
[01:55] <ubitux> i'd like to have the normalization soon; so maybe i'll add a temporary hack in volume
[01:55] <ubitux> basically if volume=volume=r128.volume (strcmp on args)
[01:55] <ubitux> when eval will be in, this syntax will still work
[01:56] <ubitux> would that be ok with you?
[01:56] <saste> no way to specify which variables are constant in "w-10"
[01:56] <ubitux> honestly that's not important for a first version
[01:56] <ubitux> we can just improve it later..
[01:56] <saste> no can't be improved
[01:56] <saste> eval has no way to know what variables you're going to change
[01:57] <saste> unless you specify the list of constant variables (which unfortunately are named "constants" in eval jargon)
[01:58] <saste> ubitux, another solution may be to set a mode=dyn option
[01:59] <saste> this can be deprecated if/when someone finds a better solution
[01:59] <ubitux> why not
[02:00] <ubitux> ...but i prefer the const thing
[02:00] <saste> so you basically have: volume=volume=+3dB:eval=const
[02:00] <ubitux> i don't think it's important to fail with the use of w/h etc
[02:00] <ubitux> (especially since it can actually change mid-stream)
[02:01] <saste> ubitux, but i don't really know how do you want to implement the renormalization
[02:02] <saste> are you going to read from metadata, and use the corresponding variable (like for select/scene)?
[02:02] <ubitux> var_values[LAVFI_R128_VOLUME_ADJUST] = av_dict_get(...)
[02:03] <ubitux> then volume=r128.volume
[02:03] <ubitux> or volume=r128.volume*0.95 if you have some eval or anything
[02:03] <saste> what is this "r128.volume" thing?
[02:04] <saste> a variable name with a "."?
[02:04] <ubitux> injected metadata from ebur128 filter
[02:04] <ubitux> into each 100ms frame
[02:04] <ubitux> yeah well we can nitpick about the . etc
[02:04] <saste> why not "r128_volume"?
[02:04] <ubitux> it's just an example
[02:05] <ubitux> the idea is that i need volume filter to be able to have a proper user interface for controling the metadata
[02:05] <ubitux> and the eval was a great opportunity
[02:05] <ubitux> but, as i said, i can just add a temporary hack while waiting for your eval rework
[02:06] <ubitux> i won't wait much longer for it though, i actually need the normalization on the fly, and some ppl as well...
[02:08] <saste> ubitux, so basically you want a av_eval_is_const() that only recognize constant expressions like "1+2+sin(2*PI)"?
[02:08] <saste> my point is that it would be useless with overlay
[02:09] Action: saste needs to sleep
[02:10] <ubitux> yes i want av_eval_is_const() so we can have two path in volume filter
[02:10] <ubitux> one for the current optimized mode
[02:10] <ubitux> and one for extra eval or my loudness thing
[02:10] <ubitux> also it will allow no change to the syntax
[02:10] <ubitux> which would be great
[02:11] <ubitux> i agree that with overlay it's a problem
[02:11] <ubitux> but thing of width & height changing midstream maybe?
[02:11] <ubitux> or should we hardcode some constant strings in eval? (HACK!)
[02:11] <saste> ubitux, i can post my patches on eval, and show you how the thing can be implemented
[02:12] <ubitux> sure
[02:12] <saste> i hardly can work on it before the weekend
[02:12] <ubitux> i don't need to push the normalization tonight
[02:12] <ubitux> i'd just want not to delay it that much
[02:12] <ubitux> btw, any more comment on vf curves?
[02:12] <michaelni> the user could also provide a flag that says if it needs reevalutaion 
[02:13] <michaelni> some expressions may be non constant and the user still might want them evaluated just once
[02:13] <ubitux> so an "evalonce" option in some filters?
[02:14] <michaelni> its just a random idea ...
[02:14] <ubitux> doesn't sound like a bad one
[02:14] <ubitux> just a bit concerned about the code dup between filters, but why not
[02:14] <michaelni> also to check for constantness something like "make all non const functions and variable evaluate to NaN" could be used
[02:15] <michaelni> i dunno how saste plans to implement it so that nan idea may or may not be better
[02:21] <iive> is flag really needed? if there is variable in the expression, then it is not constant...
[02:22] <ubitux> iive: overlay filter with w/h
[02:22] <ubitux> the point saste was making
[02:22] <ubitux> but imo in the overlay filter case
[02:22] <ubitux> i think we could have "evalonce" at 1 per default
[02:23] <ubitux> in addition to the av_eval_is_const thing
[02:23] <ubitux> in "volume" filter we could have "evalonce" at 0 per default
[02:23] <ubitux> in addition to the av_eval_is_const thing as well
[02:23] <ubitux> saste ^ ?
[02:23] <saste> ubitux, yes
[02:24] <saste> that's an orthogonal solution
[02:24] <saste> btw we are evaluation expression per each frame in crop
[02:24] <saste> i never benchmarked it
[02:24] <michaelni> evaluation per frame should be negligible
[02:25] <michaelni> we have a filter that evaluates per pixel
[02:25] <ubitux> hello geq
[02:26] <ubitux> saste: btw, Derek ping'ed several times for the ffprobe/vp6 thing, do you stll want to look at it?
[02:26] <iive> ubitux: w/h are constants for a frame duration and for most of playback.
[02:26] <saste> ubitux, and I pinged michaelni back and still waiting for a reply
[02:27] <ubitux> iive: "most of"
[02:27] <iive> does the filter system reinit the whole chain of w/h change, or every filter handles this on its own?
[02:27] <saste> from my point of view the patch is acceptable, but maybe there is a better solution at the lib level
[02:27] <ubitux> iive: good point
[02:27] <ubitux> i might re-init
[02:28] <ubitux> it*
[02:29] <ubitux> saste: anyway, if eval per frame is considered negligible
[02:29] <ubitux> there is actually not a single problem
[02:29] <saste> ubitux, benchmark
[02:29] <ubitux> we might need a more optimized string lookup for av_get_dict thing though
[02:30] <ubitux> (yes that's unrelated to what we are talking about)
[02:30] <ubitux> my brain is starting to fart all around the head
[02:31] <michaelni> saste, which mail should i review / comment on ?
[02:31] <ubitux> michaelni: [PATCH] ffprobe: Stash and use width and height before opening the codec
[02:37] <ubitux> saste: thx
[02:37] <saste> michaelni, just posted a reply on ML
[02:38] <saste> good night everybody
[02:38] <ubitux> michaelni: there is a file in the ticket mentionned
[02:39] <ubitux> https://ffmpeg.org/trac/ffmpeg/ticket/1386
[02:39] <ubitux> 'night saste 
[03:24] <cone-791> ffmpeg.git 03Bojan Zivkovic 07master:1f5b5b806270: libavcodec: changed mathematical functions in aacpsy.c
[09:45] <durandal_1707> what about gsoc task to make frequently used decoders use slice and/or frame threading (the ones that are missing it)
[10:00] <av500> durandal_1707: you need to clearly define a task
[10:00] <av500> pick the decoder, see if a student could do it
[11:34] <cone-679> ffmpeg.git 03Martin Storsjö 07master:d65522e826fc: h264: Rename the jpeg_420 pixfmt list to match the common naming structure
[11:34] <cone-679> ffmpeg.git 03Stefano Sabatini 07master:70762508ec59: lavc: Prettify printing of codec tags containing non alphanumeric characters
[11:34] <cone-679> ffmpeg.git 03Michael Niedermayer 07master:47f1af47b6cb: Merge commit '70762508ec5919474edb92a5b1f266fd06640f9c'
[11:58] <cone-679> ffmpeg.git 03Ronald S. Bultje 07master:64e4386974b9: h264: Integrate draw_horiz_band into ff_h264_draw_horiz_band
[11:58] <cone-679> ffmpeg.git 03Ronald S. Bultje 07master:54b298fe5650: lavc: Deprecate the deinterlace functions in libavcodec
[11:58] <cone-679> ffmpeg.git 03Michael Niedermayer 07master:8cc5481d51bf: Merge remote-tracking branch 'qatar/master'
[13:47] <cone-679> ffmpeg.git 03Michael Niedermayer 07master:a12a618aa9c6: hls: fix timebase
[14:07] <cone-679> ffmpeg.git 03Michael Niedermayer 07master:cada99652842: avformat: Fix apics with aac
[16:56] <clkao> Hi, I'd like to add mmst media-change support to libavformat/mmst.  I've already patched msdl and it's working.  now for libavformat, how to I signal the consumer that we are now switching to a completely new stream?
[16:56] <clkao> it's similar to RTSP server-initiated ANNOUNCE
[16:57] <av500> wow, mms still exists
[16:57] <clkao> which isn't supported by libavformat either.  so i can't really find an example
[16:57] <clkao> yeah, sadly
[16:57] <av500> got a stream that does that?
[16:57] <av500> I remember implementing something like that in my mms stuff a few years ago
[16:58] <av500> IIRC is was just a new ASF header being pushed 
[16:59] <clkao> yes.  i can already process that.  but i think need to somehow signal whatever is demuxing that there's a new stream?
[16:59] <clkao> (sorry if this is stupid, but i haven't done much media processing)
[16:59] <av500> yes, I guess so
[17:01] <clkao> so is there aome similar format that emits that sort of thing?
[17:01] <Daemon404> humm.. lavfi has no tint filter?
[17:31] <ubitux> Daemon404: i'll soon push the curves filter
[17:31] <ubitux> which should allow you to play with colors a little
[17:31] <Daemon404> oic
[17:34] <cbsrobot_> Daemon404: or maybe you could extend the curves filter to change hsv
[19:41] <cone-942> ffmpeg.git 03Michael Niedermayer 07master:fee5da6b0a79: psymodel: dont apply lowpass filters with a cutoff close to the nyquist
[19:55] <cone-942> ffmpeg.git 03Michael Niedermayer 07release/1.0:16ac9edc2f0e: hls: fix timebase
[19:55] <cone-942> ffmpeg.git 03Michael Niedermayer 07release/1.0:e20a019c9171: avformat: Fix apics with aac
[19:55] <cone-942> ffmpeg.git 03Michael Niedermayer 07release/1.1:a8fc0bb60830: hls: fix timebase
[19:55] <cone-942> ffmpeg.git 03Michael Niedermayer 07release/1.1:b642e45d8ce8: avformat: Fix apics with aac
[19:57] <peper03> Hi, any suggestions on how to fix/avoid the negative seek in my DVD NAV patch?  I'd like to get this sorted out so I don't need to bother you any more :)
[19:59] <michaelni> peper03, iam not sure which is the best way to solve it ...
[20:00] <michaelni> one way may be to set request_probe and add means for the stuff to be probed
[20:00] <michaelni> this would add the stream independant of its content though ...
[20:02] <peper03> michaelni: I wondered about the probe mechanism but the same problem appeared to me too.  The other problem is the 'Sofdec' detection as that just changes the codec used for the audio stream.  I don't see how that could be crowbar'd into the probing mechanism.
[20:18] <peper03> michaelni: What about the negative seek on video packets?  If large negative seeks are problematic, one *could* assume that PRIVATE_STREAM_2 packets with a length of 980 or 1018 bytes and a first byte of 0 or 1 are NAV packets.  That would only require a negative seek of 3 bytes.
[20:18] <cone-942> ffmpeg.git 03Michael Niedermayer 07master:60dbf2eff92f: aacdec: Reconfigure output as needed, disable pop_output_configuration()
[20:24] <michaelni> the only case where negative seeks are safe is in the first few kb of a file, to make them safe in later parts would need changes to the avio code
[20:25] <michaelni> or we simply accept that the nav packets will be disabled when seeking isnt possible
[20:25] <michaelni> and check if the input is seekable
[20:29] <peper03> I don't think I'd have a problem with that.  So I'd just add '&& s->pb->seekable' to the check where I determine whether it's a NAV packet or not?  If it's not seekable, it'd fall into the 'else' block and skip what bytes remain.
[20:34] <peper03> Hmm.  Although I see that that flag is set to zero.  Probably because completely random seeks are going to cause problems.
[20:38] <peper03> A negative seek within the buffered data shouldn't be a problem but then you're presumably going to end up second-guessing avio.
[20:39] <cone-942> ffmpeg.git 03Michael Niedermayer 07release/1.0:08be125dde5f: psymodel: dont apply lowpass filters with a cutoff close to the nyquist
[20:39] <cone-942> ffmpeg.git 03Michael Niedermayer 07release/1.1:088ba9bc3e76: psymodel: dont apply lowpass filters with a cutoff close to the nyquist
[20:41] <michaelni> a (negative) seek into the buffer would be ok, yes ...
[20:42] <peper03> Can that be done/detected cleanly?
[20:43] <wm4> uh, so is it right that video packets can't be reordered in libavformat/libavcodec without decoding it, and this is one of the causes CCs can't be easily supported?
[20:51] <peper03> I guess you could do 'if ((s->buf_ptr-s->buffer) >= bytes_to_skip_back)'?  Is that clean enough?
[20:51] <michaelni> wm4, libavformat reorders pts into dts when they are missing for mpeg1/2 if the operation for CC is similar then something similar could be done i guess
[20:54] <michaelni> peper03, why is seekable 0 for you ? also checking the return code from avio_seek might work
[20:57] <peper03> michaelni: Almost certainly because the data blocks are not read directly from the DVD but via libdvdnav.  We call request the next block and provide a buffer.  The return value tells us the contents of the buffer.  It can be the contents of one sector from the DVD, or one of several structures defined in libdvdnav.  Random seeks would screw up libdvdnav's internals.
[21:01] <peper03> Wouldn't checking the return value of avio_seek be too late?  You've already done the seek in that instance, which would be potentially slow.
[21:04] <peper03> In the case of a DVD, both PRIVATE_STREAM_2 packets are together in their entirety in the same 2k sector.  Anything reading DVDs should be reading entire sectors, so the buffer passed to ffmpeg should be 2k and negative seek should be no problem.  Anything else isn't a DVD so an inability to seek far enough backwards wouldn't be a problem as we'd ignore that packet anyway.
[21:05] <peper03> If we can detect that, I think (from my point of view) that there shouldn't be any problems.
[21:06] <michaelni> the seek is just needed for identifying the stream, once idemtified it shouldnt be needed anymore so there should be no speedloss i think
[21:06] <michaelni> what about files on disk that originated from dvds ?
[21:06] <michaelni> there would be no 2k gurantee
[21:08] <peper03> Do you mean ISOs?  A DVD player shouldn't care about the physical sector size of the medium it's reading from.  It should just read 2k blocks.
[21:08] <peper03> With that, I mean the source of the data should be transparent to the DVD player.
[21:11] <michaelni> libavformat could read such data without being connected to something that reads in 2k blocks
[21:13] <peper03> michaelni: Possibly, but then it's unlikely that the calling application cares about NAV packets.
[21:18] <peper03> They're pure data packets.  Anything just streaming a VOB file is rarely going to have clean output.  For example, hit a section with multiple angles (used quite often to show text in different languages) and the output will look pretty horrible as the angles are interleaved.
[21:19] <peper03> The NAV packets and the IFO files are required to determine what order to read which sectors.  Usually it's sequential but it doesn't have to be.
[22:16] <peper03> michaelni: http://pastebin.com/Meys0BYr
[22:17] <peper03> michaelni: There's still a seek with -1 but the buffer must always be at least one byte long, mustn't it?
[22:18] <peper03> Line 22 works, but short of a change in the avio code, I don't see how else I can get at that information.
[22:27] <michaelni> wouldnt this as is produce non deterministic output when packets arent 2k aligned ?
[22:27] <michaelni> with random packets missing ?
[22:29] <michaelni> if so, i think either the stream should be identified and once identified it shouldnt depend anymore on seeking ability or maybe it could even use a temporary buffer to hold the packet so that no seekback is needed but i didnt think about how clean/messy that would end
[22:32] <peper03> This whole bit of code is messy!  The search for 'Sofdec' isn't very good because as soon as it finds the first 'S', it'll stop searching, whether it's followed by 'ofdec' or not.  Once 'sofdec yes/no?' has been determined, it never searches for it again.
[22:33] <peper03> I just don't know how to identify a packet based on its contents without reading its contents...
[22:35] <peper03> If you don't return the bytes to the buffer somehow, mpegps_read_packet won't get them and they won't be returned to the calling application.
[23:19] <peper03> michaelni: How acceptable would defining something like AVFMTCTX_DVD be?  If a bit were set in ctx_flags to indicate that a DVD is being read, that should solve the problem, shouldn't it?  We would have the context we need to know what's in the packets.
[23:37] <bcoudurier> anybody very familiar with dv/dvcprohd ?
[23:39] <kierank> bcoudurier: mark would be
[23:40] <bcoudurier> from specs ?
[23:40] <bcoudurier> could be
[23:43] <kierank> bcoudurier: i am not sure what you are trying to say
[23:43] <kierank> oh i see
[23:43] <kierank> not sure how low-level they are
[23:55] <michaelni> peper03, iam not sure what problem you try to solve, but it sounds less and less acceptable
[23:56] <michaelni> detect IF its a dvd belongs in libavformat
[23:56] <peper03> michaelni: I'm trying to solve the same problem as I've been trying to solve for the last few weeks!
[23:57] <peper03> How do you detect what sort of packet you have if you can only do that by reading the contents, but you can't read the contents?!
[23:58] <michaelni> there are many solutions
[23:58] <peper03> Such as?  I'm going round in circles here.
[23:58] <michaelni> you can seek and check the return code
[23:58] <michaelni> you can read in a buffer
[23:58] <michaelni> you can detect that its a dvd during format probing
[23:58] <peper03> But you said that seeking would be bad because that could be slow.
[23:58] <michaelni> you can use request:probe
[23:58] <michaelni> request_probe
[23:59] <michaelni> its bad if its done for every packet
[23:59] <michaelni> but if done once its no problem
[23:59] <peper03> Ah, that bit you didn't mention.
[23:59] <michaelni> my fault then
[00:00] --- Fri Mar  8 2013