search for: seekable

I'm seeing these recently: Feb 27 09:24:01 nihlus dovecot: imap(tlx at leuxner.net): Error: istream-seekable: safe_mkstemp(/tmp/dovecot.imap.) failed: No such file or directory Feb 27 09:24:01 nihlus dovecot: imap(tlx at leuxner.net): Error: istream-seekable: safe_mkstemp(/tmp/dovecot.imap.) failed: No such file or directory Feb 27 09:24:01 nihlus dovecot: imap(tlx at leuxner.net): Error: istream-seekable...

...nux and OS X, but not on Windows. I've found that code in vorbisfile.c tests the input stream for seekability by invoking fseek in the following way: int offsettest=(f?callbacks.seek_func(f,0,SEEK_CUR) : -1); Unfortunately, fseek succeeds for a socket on Windows (even though it's not seekable) with the parameters specified. A more definitive test (and one that does work on Windows) is to attempt to seek to the end. I've attached a patch to vorbisfile.c that fixes my problem. -------------- next part -------------- Index: vorbisfile.c =============================================...

...e following code: if (ov_open(NULL, &vf, const_cast<char*>(reinterpret_cast<const char*>(get_data())), get_size()) < 0) error = 0x100; else { vorbis_info* vi = ov_info(&vf, -1); Cvirtual_file f; const int cb_samples = ov_pcm_total(&vf, -1); const bool seekable = ov_seekable(&vf); So all data is already in memory and passed to ov_open. This stream is not seekable. Why not? And shouldn't it be seekable? Olaf van der Spek Almere, Holland Olaf@XCC.TMFWeb.NL http://xccu.sourceforge.net/ http://xcc.tiberian.com/ --- >8 ---- List archives: http:/...

...STREAMINFO block in the stream encoder metadata callback without having to know the specifics of the header format (or worry about endianness). How exactly to achieve this might take some thought, but what about this idea: 1. The correct way to respond to the metadata callback: i. If this is a seekable stream, seek to the beginning and return FLAC__STREAM_ENCODER_METADATA_OK (or something). ii. If this is not a seekable stream, return FLAC__STREAM_ENCODER_METADATA_NOT_SEEKABLE 2. If the callback indicated that the stream is seekable, FLAC calls the write callback again, writin...

I have checked in a few changes worth noting: 1. I split the file decoder into a more general 'seekable stream decoder' which, makes the file decoder just a special case of the seekable stream decoder. this is useful in situations where you are trying to add decoding support to something that has abstracted the file away. the file decoder interface is still identical, it is all backward compati...

Hi, Why is seekability necessary in case of multiplexed multiple logical streams? Isn't the differentiation based on serial number sufficient to continue decoding of pages in the sequence of their arrival? Regards, Patrick. _______________________________________________________________________ Odomos - the only mosquito protection outside 4 walls - Click here to know more!

...re my sub file (inside the pack file) is located. This did not work. It took about 10 seconds for the function to return so I am guessing it was seeking to the beginning of the stream and then scanning forward looking for the OGG headers. There are comments about using streams that are not "seekable" and I thought this also might be a solution, but I could find nothing on how to tell Vorbis that a stream was not seekable. Is it as simple as setting the callbacks.seek_func and callbacks.tell_func to NULL? Does anyone have any experience reading OGG data from a already open stream which m...

...tern is not decoded right in this case. In vorbisfile.c static long _get_data(OggVorbis_File *vf){ .... long bytes=(vf->callbacks.read_func)(buffer,1,CHUNKSIZE,vf->datasource); .. } The buffer should hold the header feild "oggs", however, it did not. I think the problem is vf->seekable = 1. if the vf->seekable = 1, is it the problem for streaming? How can I achieve ogg streaming? Thank you in advance! Leon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/vorbis-dev/attachments/20090604/a86ba624/attachment.htm

...02 ...about the feasibility and efficiency of reading id3v2 tags out of mp3's over http. I know that vorbisfile's callback model is well suited to handling this sort of scenario, but I'm curious to know whether ov_open will try to read enough stream to pull the comments out on a non-seekable stream. I've only played around with it on seekable streams, where it tries to scan the whole stream to get a count of the logical streams within. Would ov_test get enough header read to determine the size of the comment before sucking it all in for parsing? John --- >8 ---- List archive...

...uot;file %s: line %d (%s): assertion failed: (%s)") at failures.c:263 ctx = {type = LOG_TYPE_PANIC, exit_status = 0, timestamp = 0x0} args = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 0x7fff5fba6e40, reg_save_area = 0x7fff5fba6d80}} #5 0x00007fea0d786bb8 in i_stream_seekable_read (stream=0xd658a0) at istream-seekable.c:253 sstream = 0xd658a0 data = 0x7fff5fba6ea0 "\320n\272_\377\177" size = 14047392 pos = 27457 ret = 139638205298784 __FUNCTION__ = "i_stream_seekable_read" #6 0x00007fea0d77e866 in i_st...

...ot; for the frame. By requesting a specific "time", you get a the frames that correspong, thus you can seek without relying on client side buffering. Note that not all QuickTime or RealMedia files are served by proper streaming servers. You need two things for server side seeking.... a seekable source, and a seek-aware protocol. If all you want to do is get the file to the client, HTTP works just fine. And while the file, when it arrives, will be seekable, HTTP doesn't understand seeking, so downloading quicktime files off an HREF from a web page doesn't get you all the cool goo...

Note that raw_fd_ostream is not seekable, and hence will not be suitable as addPassesToEmitFile output stream. 2016-02-22 18:27 GMT+02:00 Rafael Espíndola <llvm-dev at lists.llvm.org>: > On 22 February 2016 at 11:16, Frank Winter <fwinter at jlab.org> wrote: > > TargetMachine::CGFT_AssemblyFile is exactly what I a...

...ich you don't want. If you add again the > metadata, it will apply to that single stream again. > > That said, Internet radio streams are usually handled fairly well by > various players, which detect new streams and update metadata > accordingly. These are typically live and not seekable though. > > Thanks for the reply. What I'm after is basically the conversion of a live stream to a seekable stream. The metadata is known and a wipe and reset is possible, but is it possible to wipe metadata segements across the whole file without re-encoding? Andy

Hi, Seems that on RWin 1.7.0 and 1.6.2 isSeekable returns F on binary files, while seek() works as expected on the same connection - see example below: > con = file(nm, "rb") > isSeekable(con) [1] FALSE > readBin(con, double(), 10) [1] 7.263824e-317 5.968155e-317 2.340685e-317 2.734062e-312 4.088386e-312 4.670335e-317 [...

...the test files from the test_libFLAC directory of the flac-1.1.3-beta2. The result of this hacking is this standalone C file: http://www.mega-nerd.com/tmp/erikd_test.c Directions for compiling this is in the comments at the top of the file. When the program is run, it generates 4 files: seekable.flac stream.flac seekable.ogg stream.ogg The problem is that the two OggFlac files are lacking an end-of-stream marker. For instance, the ogginfo program says: erikd@mingus > ogginfo stream.ogg Processing file "stream.ogg"... New logical stream (#1, serial:...

>From the documentation that I read, ov_time_tell is supposed to tell you the how many seconds the decoder is into in the stream. However, I'm getting some weird results from it. On my stream (which is seekable - I verified it), ov_time_total returns the correct total seconds. However, when I start playing, ov_time_tell first gives me a wrong floating point number (like 4.969.). when I call it a second later, I get something like 9. as I decode the stream, the time that ov_time_tell is not the right ti...

I hope that this is the appropriate venue for this question. If it's not, let me know and I'll take it elsewhere (perhaps vorbis-dev). Saved streams are great - it lets this norteamericano get his fill of BBC Radio 1's Essential Mix. Unfortunately, saved streams aren't seekable. Running ogginfo on the stream data gives: erial=1626603590 header_integrity=pass vendor=Xiphophorus libVorbis I 20011231 version=0 channels=2 rate=44100 bitrate_upper=none bitrate_nominal=128031 bitrate_lower=none stream_integrity=fail stream_truncated=true header_integrity=fail Reported length...

I hope that this is the appropriate venue for this question. If it's not, let me know and I'll take it elsewhere (perhaps vorbis-dev). Saved streams are great - it lets this norteamericano get his fill of BBC Radio 1's Essential Mix. Unfortunately, saved streams aren't seekable. Running ogginfo on the stream data gives: erial=1626603590 header_integrity=pass vendor=Xiphophorus libVorbis I 20011231 version=0 channels=2 rate=44100 bitrate_upper=none bitrate_nominal=128031 bitrate_lower=none stream_integrity=fail stream_truncated=true header_integrity=fail Reported length...

...er::bootstrap_inherit at C:\Programme\R\R-2.5 .1\share\perl/XSLoader.pm line 80. Compilation failed in require at c:/Programme/Perl/lib/IO/Handle.pm line 262. BEGIN failed--compilation aborted at c:/Programme/Perl/lib/IO/Handle.pm line 262 . Compilation failed in require at c:/Programme/Perl/lib/IO/Seekable.pm line 101. BEGIN failed--compilation aborted at c:/Programme/Perl/lib/IO/Seekable.pm line 1 01. Compilation failed in require at c:/Programme/Perl/lib/IO/File.pm line 133. BEGIN failed--compilation aborted at c:/Programme/Perl/lib/IO/File.pm line 133. Compilation failed in require at C:\Programme...

Hello all, I run the streaming for a community radio station. We're streaming 160k/s ogg via icecast. For an archive mechanism, I have a scheduler which starts a pseudo listener and archives to a file, via wget: wget http://stream/stream.ogg -O "show name.ogg" That works fine. The scheduler starts recording 30s before shows start and 2m after they end. We're also doing