From eacce255b0a462493155f2e85cdd06cf03de0eae Mon Sep 17 00:00:00 2001 From: diego Date: Tue, 25 May 2010 23:09:20 +0000 Subject: Remove obsolete new policy proposal draft from Michael. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31219 b3059339-0415-0410-9bf9-f77b7e298cf2 --- DOCS/tech/new_policy_proposal.txt | 309 -------------------------------------- 1 file changed, 309 deletions(-) delete mode 100644 DOCS/tech/new_policy_proposal.txt diff --git a/DOCS/tech/new_policy_proposal.txt b/DOCS/tech/new_policy_proposal.txt deleted file mode 100644 index d6fbfbc6b3..0000000000 --- a/DOCS/tech/new_policy_proposal.txt +++ /dev/null @@ -1,309 +0,0 @@ -New Policy Draft -Version 20070301 - -Intro: ------- -This document is an attempt to write a new policy as the old is fairly -confusing and easy to misunderstand, its intention is not really to -change the rules but rather to write them down clearer ... -also for simplicity and to prevent flamewars, i would suggest that you -fork this document and propose that fork as alternative if you have a -significant disagreement with me on some part - -Author: -------- -Michael Niedermayer -the authors of the old policy as I liberally copy and pasted from it - -TODO: -add more explanations, justifications and examples -how to become/loose maintainer status -review patches.txt -security/exploit rules ------------------------- - - -1. Definitions --------------- -* MPlayer developer, generally referred to simply as developer in this document - is any person who has a open (not cracked, not suspended) svn write account -* MPlayer leader, generally referred to simply as leader in this document, every - leader is also a developer -* CAN/MUST/SHOULD descriptions ... -* public developer mailing list (mplayer-dev-eng at mplayerhq in hungary) - - -C. Code and SVN Rules ------------------------------ -Renaming/moving/copying files or contents of files - Do not move, rename or copy files of which you are not the maintainer without - discussing it on the public developer mailinglist first! - - Never copy or move a file by using 'svn delete' and 'svn add'. Always use - 'svn move' or 'svn copy' instead in order to preserve history and minimize - the size of diffs. - - To split a file, use 'svn copy' and remove the unneeded lines from each file. - - Don't do a lot of cut'n'paste from one file to another without a very good - reason and discuss it on the mplayer-dev-eng mailing list first. It will make - those changes hard to trace. - - Such actions are useless and treated as cosmetics in 99% of cases, - so try to avoid them. - -Reverting broken commits - There are 2 ways to reverse a change, they differ significantly in what they - do to the svn repository - The recommit old method: - svn merge - svn ci - This simply changes the file(s) back to their old version localy and then - the change is commited as if it is a new change - The svn copy method - svn rm - svn ci - svn cp -r svn://svn.mplayerhq.hu/mplayer/trunk/[/] - svn ci - This simply removes the file and then copies the last good version with - its history over it, this method can only be used to revert the n last - commits but not to revert a bad commit in the middle of its history - Neither method will change the history, checking out an old version will - always return exactly that revision with all its bugs and features. The - difference is that with the svn copy method the broken commit will not be - part of the directly visible history of the revisions after the reversal - So if the change was completely broken like reindenting a file against the - maintainers decision, or a change which mixed functional and cosmetic - changes then it is better if it is not part of the visible history as it - would make it hard to read, review and would also break svn annotate - For the example of a change which mixed functional and cosmetic parts they - should of course be committed again after the reversal but separately, so one - change with the functional stuff and one with the cosmetics - OTOH if the change which you want to reverse was simply buggy but not - totally broken then it should be reversed with svn merge as otherwise - the fact that the change was bad would be hidden - One method to decide which reversal method is best is to ask yourself - if there is any value in seeing the whole bad change and its removal - in SVN vs just seeing a comment that says what has been reversed while - the actual change does not clutter the immediately visible history and - svn annotate. - If you are even just slightly uncertain how to revert something then ask on - the mplayer-dev-eng mailing list. - -Broken code - You must not commit code which breaks MPlayer! (Meaning unfinished but - enabled code which breaks compilation or compiles but does not work.) - You can commit unfinished stuff (for testing etc), but it must be disabled - (#ifdef etc) by default so it does not interfere with other developers' - work. - -Testing code - You don't have to over-test things. If it works for you, and you think it - should work for others, too, then commit. If your code has problems - (portability, exploits compiler bugs, unusual environment etc) they will be - reported and eventually fixed. - -Splitting changes - Do not commit unrelated changes together, split them into self-contained - pieces. Also dont forget that if part B depends on part A but A doesnt - depend on B, then A can and should be commited first and seperately from B. - Keeping changes well split into self contained parts makes reviewing and - understanding them on svn log at the time of commit and later when - debugging a bug much easier. - Also if you have doubt about spliting or not spliting, dont hesitate to - ask/disscuss it on the developer mailing list. - -4. Do not change behavior of the program (renaming options etc) or - remove functionality from the code without approval in a discussion on - the mplayer-dev-eng mailing list. - - -5. Do not commit changes to the build system (Makefiles, configure script) - which change behaviour, defaults etc, without asking first. The same - applies to compiler warning fixes, trivial looking fixes and to code - maintained by other developers. We usually have a reason for doing things - the way we do. Send your changes as patches to the mplayer-dev-eng mailing - list, and if the code maintainers say OK, you may commit. This does not - apply to files you wrote and/or maintain. - - -Cosmetics - We refuse source indentation and other cosmetic changes if they are mixed - with functional changes, such commits will be reverted. Every - developer has his own indentation style, you should not change it. Of course - if you (re)write something, you can use your own style... (Many projects - force a given indentation style - we don't.) If you really need to make - indentation changes (try to avoid this), separate them strictly from real - changes. - - NOTE: If you had to put if()@{ .. @} over a large (> 5 lines) chunk of code, - then either do NOT change the indentation of the inner part within (don't - move it to the right)! or do so in a separate commit - - -Commit log message - Always fill out the commit log message. Describe in a few lines what you - changed and why. You can refer to mailing list postings if you fix a - particular bug. Comments such as "fixed!" or "Changed it." are unacceptable. - - -Applying patches - If you apply a patch by someone else, include the name and email address in - the log message. Since the mplayer-cvslog mailing list is publicly - archived you should add some spam protection to the email address. Send an - answer to mplayer-dev-eng (or wherever you got the patch from) saying that - you applied the patch. If the patch contains a documentation change, commit - that as well; do not leave it to the documentation maintainers. - - -messing with other developers code - Do NOT commit to code actively maintained by others without permission. Send - a patch to mplayer-dev-eng instead. - - -Subscribe to svnlog - Subscribe to the mplayer-cvslog mailing list. The diffs of all commits - are sent there and reviewed by all the other developers. Bugs and possible - improvements or general questions regarding commits are discussed there. We - expect you to react if problems with your code are uncovered. - - -Documentation - Update the documentation if you change behavior or add features. If you are - unsure how best to do this, send a patch to mplayer-docs, the documentation - maintainers will review and commit your stuff. - - -Controversial changes - Always send a patch to the mplayer-dev-eng mailing list before committing - if you suspect that the change is going to be controversial. Based on past - experience, these changes are likely to be controversial: - - feature removal, even if obsolete - - changes to "special" output messages (like the "Core dumped ;)" message) - - verbosity changes from default (info) level - - changes to "historical" parts of docs and webpages - - use of internal or external libraries - - changes to the internal architecture - - non trivial changes to very fundamental parts of mplayer - - -Public discussions - Try to keep important discussions and requests (also) on the - mplayer-dev-eng mailing list, so that all developers can benefit from them. - IRC is good for quick discussions, but nobody is there 24/7. - also subscribe to the public developer mailing list - - -Compiler Warning fixes - Do not change code to hide warnings without ensuring that the underlaying - logic is correct and thus the warning was inappropriate - - -Patches - read and follow patches.txt when sending patches for mplayer - - -Insults - Do not insult other people in relation to mplayer on any public mailing - list, that is calling code from someone else a pile of broken shit is - perfectly fine but calling the developer herself a retarded f*cking moron - is not acceptable - - -Forking - People disagreeing with the developers or leaders may fork the project, - the leaders MUST in that case provide a svn dump with all history if - the person forking wants one - - -Communicating passwords - Developers who have provided a public gpg key shall only receive - passwords or other sensitive information related to mplayer encrypted - with their gpg key or in another secure way - - -V. Votes --------- -Its inevitable that some things will be decided by voting, votes in the past -have due to total lack of rules been problematic for example as many people -rather wrote long texts and voted based on some condition instead of saying -a clear yes or no, still its important that people can vote based on a -condition -The result of a vote is binding for all developers and leaders, though of -course they can leave the project and thus cease to be a developer or leader -any time - -Vs. Starting a vote -Any single developer can start a vote, to do so she has to send a mail to the -public developer mailing list of the project with a subject containing [VOTE] -and a clear and concise description, a longer descrition can be in the body -of the mail - -Vp. Proposing an option (point on the ballot, better term?) -Any single developer can propose an option up to 7 days after a vote has -been started, to do so she has to reply to the original vote mail on the -public developer mailing list and clearly, concise and unmistakably describe -the option and place [VOTE-OPTION] instead of [VOTE] in the subject -in addition to proposed options, there always exists the default option -of doing nothing -options can be conditional on anything which at the end of the vote can -be clearly and unmistakably be answered with true or false - -Vv. Voting -Any developer can cast a vote up to 10 days days after a vote has been -started, to do so she has to reply to the original vote mail on the -public developer mailing list and rate options each with an integer -unrated options shall be counted equal to the default option -Any leader can cast a veto against any option except the default up to 10 days -days after a vote has been started, to do so she has to reply to the original -vote mail on the public developer mailing list and replace -[VOTE] by [VOTE-VETO] -Developers and leaders who use gpg/pgp MUST sign their votes and vetoes - -Vc. Counting votes -The person starting the vote has to count the votes and vetoes and publish -the result on the public developer mailing list as reply to the original vote -with [VOTE-RESULTS] instead of [VOTE] in the subject -Vcv. Counting vetoes -if the majority of leaders that is yes >= no && yes>0 cast a veto against an -option then it has a required supermajority of 2:1 otherwise it has a -required supermajority of 0:1 and in either case no quorum requirement -Vcc. the votes shall be counted by using the Condorcet/Clone Proof SSD -Voting Method described in http://www.debian.org/devel/constitution A.6 - -Reasoning behind avoiding of a quorum and majority requirement except in -the case of vetoes -short awnser its stupid and has catastrophical failure modes -example of one such failure mode, lets assume a 1:1 majority requirement -as debian uses by default, there are 101 developers who vote, there are -3 options A,B and D the default (doing nothing / further discussions) -50 developers prefer A over B and B over discussions (A>B>D) -50 developers prefer discussions over A and A over B (D>A>B) -1 developer prefers B over discussions and discussions over A (B>D>A) -in this case A is approved by 50 of 101 developers and is droped due to -the lack of majority, B is approved by 51 of 101 developers and is not -furthermore B wins even though 100 of 101 developers prefer A over B - - -S. Changes to developer and Leader status ----------------------------------------- -The majority of leaders, that is yes>no can give and take away -developer and leader status to people -furthermore any developer or leader can step back and thus loose -his leader and or developer status -People disagreeing with the leaders are free to fork the project -new developers should be asked for real name, public gpg key, phone -number and email addresses, none of this is mandatory though, it is asked -so as to be able to contact the developer if the need arises and one -contact method fails - - -O. Violations -------------- -Any leader can after at least one leader has warned another developer -due to breaking policy, suspend his account if he repeats the violation -Ow. A policy violation warning MUST be CCed to the developer who violated -the policy - - -We think our rules are not too hard. If you have comments, contact us. -- cgit v1.2.3 From ab1c858071ac93fc4736582f259b580c4734cc71 Mon Sep 17 00:00:00 2001 From: diego Date: Tue, 25 May 2010 23:41:30 +0000 Subject: Add support for decoding VP8 through libvpx wrapper in FFmpeg. patch by James Zern, jzern google com git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31220 b3059339-0415-0410-9bf9-f77b7e298cf2 --- Changelog | 1 + configure | 28 ++++++++++++++++++++++++++++ etc/codecs.conf | 8 ++++++++ 3 files changed, 37 insertions(+) diff --git a/Changelog b/Changelog index b15c7fb655..9a24914a59 100644 --- a/Changelog +++ b/Changelog @@ -17,6 +17,7 @@ MPlayer (1.0) * JPEG 2000 support via OpenJPEG * internal liba52 copy removed * CineForm HD (CFHD) via binary DLL + * VP8 decoding through libvpx wrapper in FFmpeg Demuxers: * support for TrueHD in Blu-ray streams in libmpdemux diff --git a/configure b/configure index 021708e83d..0e851da0be 100755 --- a/configure +++ b/configure @@ -299,6 +299,7 @@ Codecs: --disable-libdirac-lavc disable Dirac in libavcodec [autodetect] --disable-libschroedinger-lavc disable Dirac in libavcodec (Schroedinger decoder) [autodetect] + --disable-libvpx-lavc disable libvpx in libavcodec [autodetect] --disable-libnut disable libnut [autodetect] --disable-libavutil_a disable static libavutil [autodetect] --disable-libavcodec_a disable static libavcodec [autodetect] @@ -693,6 +694,7 @@ _x264=auto _x264_lavc=auto _libdirac_lavc=auto _libschroedinger_lavc=auto +_libvpx_lavc=auto _libnut=auto _lirc=auto _lircc=auto @@ -1137,6 +1139,8 @@ for ac_option do --disable-libdirac-lavc) _libdirac_lavc=no ;; --enable-libschroedinger-lavc) _libschroedinger_lavc=yes ;; --disable-libschroedinger-lavc) _libschroedinger_lavc=no ;; + --enable-libvpx-lavc) _libvpx_lavc=yes ;; + --disable-libvpx-lavc) _libvpx_lavc=no ;; --enable-libnut) _libnut=yes ;; --disable-libnut) _libnut=no ;; --enable-libavutil_a) _libavutil_a=yes ;; @@ -7596,6 +7600,30 @@ else fi echores "$_libschroedinger_lavc" +echocheck "libvpx" +if test "$_libvpx_lavc" = auto; then + _libvpx_lavc=no + if test "$_libavcodec_a" != yes; then + res_comment="libavcodec (static) is required by libvpx, sorry" + else + cat > $TMPC << EOF +#include +#include +int main(void) { vpx_codec_dec_init(NULL, &vpx_codec_vp8_dx_algo, NULL, 0); return 0; } +EOF + cc_check -lvpx && _libvpx_lavc=yes && extra_ldflags="$extra_ldflags -lvpx" + fi +fi +if test "$_libvpx_lavc" = yes ; then + def_libvpx_lavc='#define CONFIG_LIBVPX 1' + _libavdecoders="$_libavdecoders LIBVPX_DECODER" + codecmodules="libvpx $codecmodules" +else + def_libvpx_lavc='#define CONFIG_LIBVPX 0' + nocodecmodules="libvpx $nocodecmodules" +fi +echores "$_libvpx_lavc" + echocheck "libnut" if test "$_libnut" = auto ; then cat > $TMPC << EOF diff --git a/etc/codecs.conf b/etc/codecs.conf index 3b1e356662..23bff5dc8e 100644 --- a/etc/codecs.conf +++ b/etc/codecs.conf @@ -2173,6 +2173,14 @@ videocodec vp7 out YUY2 out BGR32,BGR24 +videocodec fflibvpx + info "FFmpeg wrapper for libvpx/VP8" + status working + fourcc VP80 + driver ffmpeg + dll "libvpx" + out YV12 + videocodec mwv1 info "Motion Wavelets" status working -- cgit v1.2.3 From 7bb3c3b68129d9429bba59c8b8de0741e6a54153 Mon Sep 17 00:00:00 2001 From: diego Date: Wed, 26 May 2010 00:47:22 +0000 Subject: Add missing RGB12 version of the fast OSD table. patch by Janusz Krzysztofik, jkrzyszt tis.icnet pl git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31221 b3059339-0415-0410-9bf9-f77b7e298cf2 --- libvo/osd.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libvo/osd.c b/libvo/osd.c index 54854c785f..992ffc01f3 100644 --- a/libvo/osd.c +++ b/libvo/osd.c @@ -284,6 +284,7 @@ void vo_draw_alpha_rgb32(int w,int h, unsigned char* src, unsigned char *srca, i } #ifdef FAST_OSD_TABLE +static unsigned short fast_osd_12bpp_table[256]; static unsigned short fast_osd_15bpp_table[256]; static unsigned short fast_osd_16bpp_table[256]; #endif @@ -292,6 +293,7 @@ void vo_draw_alpha_init(void){ #ifdef FAST_OSD_TABLE int i; for(i=0;i<256;i++){ + fast_osd_12bpp_table[i]=((i>>4)<< 8)|((i>>4)<<4)|(i>>4); fast_osd_15bpp_table[i]=((i>>3)<<10)|((i>>3)<<5)|(i>>3); fast_osd_16bpp_table[i]=((i>>3)<<11)|((i>>2)<<5)|(i>>3); } -- cgit v1.2.3 From e43d1dd2472a378d96d1da9d81699791e3de4b9c Mon Sep 17 00:00:00 2001 From: cehoyos Date: Wed, 26 May 2010 10:05:36 +0000 Subject: Both XVID and VDPAU decode our SIPP sample better than current libavcodec. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31222 b3059339-0415-0410-9bf9-f77b7e298cf2 --- etc/codecs.conf | 2 ++ 1 file changed, 2 insertions(+) diff --git a/etc/codecs.conf b/etc/codecs.conf index 23bff5dc8e..515f313ba6 100644 --- a/etc/codecs.conf +++ b/etc/codecs.conf @@ -1037,6 +1037,7 @@ videocodec ffodivxvdpau fourcc M4T3,DMK2,DIGI,INMC fourcc EPHV,SN40 fourcc uldx,ULDX,VSPX + fourcc SIPP ; Samsung SHR-6040 driver ffmpeg dll mpeg4_vdpau out VDPAU_MPEG4 @@ -1090,6 +1091,7 @@ videocodec xvid fourcc EPHV,SN40 fourcc uldx,ULDX,VSPX format 0x10000004 ; mpeg 4 es + fourcc SIPP ; Samsung SHR-6040 driver xvid out YV12 out I420 -- cgit v1.2.3 From d304c1d56c5ffc242a0ffefcc2a1c9fedb12f56c Mon Sep 17 00:00:00 2001 From: reimar Date: Wed, 26 May 2010 17:27:38 +0000 Subject: Disable waking the cache process up via a signal, it currently causes read errors due to not handling EINTR. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31223 b3059339-0415-0410-9bf9-f77b7e298cf2 --- stream/cache2.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/stream/cache2.c b/stream/cache2.c index 51989ebd2a..fef316f627 100644 --- a/stream/cache2.c +++ b/stream/cache2.c @@ -102,7 +102,10 @@ static void cache_wakeup(stream_t *s) { #if FORKED_CACHE // signal process to wake up immediately - kill(s->cache_pid, SIGUSR1); + // Disabled for now since it causes incorrect EOFs + // due to interrupting read syscalls - this should be + // fixed instead though +// kill(s->cache_pid, SIGUSR1); #endif } -- cgit v1.2.3 From 328306708f6687e9cf43a32930b252bc18ba851f Mon Sep 17 00:00:00 2001 From: reimar Date: Wed, 26 May 2010 17:56:11 +0000 Subject: Re-enable wakeup-on-signal for cache process. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31224 b3059339-0415-0410-9bf9-f77b7e298cf2 --- stream/cache2.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/stream/cache2.c b/stream/cache2.c index fef316f627..e936e47dca 100644 --- a/stream/cache2.c +++ b/stream/cache2.c @@ -102,10 +102,7 @@ static void cache_wakeup(stream_t *s) { #if FORKED_CACHE // signal process to wake up immediately - // Disabled for now since it causes incorrect EOFs - // due to interrupting read syscalls - this should be - // fixed instead though -// kill(s->cache_pid, SIGUSR1); + kill(s->cache_pid, SIGUSR1); #endif } @@ -356,11 +353,20 @@ static void cache_mainloop(cache_vars_t *s) { int sleep_count = 0; do { if (!cache_fill(s)) { +#if FORKED_CACHE + // Let signal wake us up, we cannot leave this + // enabled since we do not handle EINTR in most places. + // This might need extra code to work on BSD. + signal(SIGUSR1, dummy_sighandler); +#endif if (sleep_count < INITIAL_FILL_USLEEP_COUNT) { sleep_count++; usec_sleep(INITIAL_FILL_USLEEP_TIME); } else usec_sleep(FILL_USLEEP_TIME); // idle +#if FORKED_CACHE + signal(SIGUSR1, SIG_IGN); +#endif } else sleep_count = 0; // cache_stats(s->cache_data); @@ -449,7 +455,6 @@ err_out: use_gui = 0; // mp_msg may not use gui stuff in forked code #endif signal(SIGTERM,exit_sighandler); // kill - signal(SIGUSR1, dummy_sighandler); // wakeup cache_mainloop(s); // make sure forked code never leaves this function exit(0); -- cgit v1.2.3 From 1e0b9a97fd840c547bc22591ce225f998d0cf3c5 Mon Sep 17 00:00:00 2001 From: reimar Date: Wed, 26 May 2010 18:01:38 +0000 Subject: Switch ogg demuxing to lavf by default. This has the side-effect of using fftheora by default instead of theora, which possibly should be changed. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31225 b3059339-0415-0410-9bf9-f77b7e298cf2 --- libmpdemux/demux_lavf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libmpdemux/demux_lavf.c b/libmpdemux/demux_lavf.c index 3305611876..dea34b72c2 100644 --- a/libmpdemux/demux_lavf.c +++ b/libmpdemux/demux_lavf.c @@ -216,6 +216,7 @@ static const char * const preferred_list[] = { "mpc", "mpc8", "mxf", + "ogg", "swf", "vqf", "w64", -- cgit v1.2.3 From c36de0867fc576ad5fd58fc28bd5fe3322579f36 Mon Sep 17 00:00:00 2001 From: reimar Date: Wed, 26 May 2010 18:23:43 +0000 Subject: Retry reading even if we hit eof before. This allows playing growing files even with a large cache. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31226 b3059339-0415-0410-9bf9-f77b7e298cf2 --- stream/cache2.c | 4 ++-- stream/stream.c | 5 ++++- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/stream/cache2.c b/stream/cache2.c index e936e47dca..533781104b 100644 --- a/stream/cache2.c +++ b/stream/cache2.c @@ -225,7 +225,7 @@ static int cache_fill(cache_vars_t *s) //memcpy(&s->buffer[pos],s->stream->buffer,len); // avoid this extra copy! // .... len=stream_read(s->stream,&s->buffer[pos],space); - if(!len) s->eof=1; + s->eof= !len; s->max_filepos+=len; if(pos+len>=s->buffer_size){ @@ -477,7 +477,6 @@ static void *ThreadProc( void *s ){ int cache_stream_fill_buffer(stream_t *s){ int len; - if(s->eof){ s->buf_pos=s->buf_len=0; return 0; } if(!s->cache_pid) return stream_fill_buffer(s); // cache_stats(s->cache_data); @@ -488,6 +487,7 @@ int cache_stream_fill_buffer(stream_t *s){ //printf("cache_stream_fill_buffer->read -> %d\n",len); if(len<=0){ s->eof=1; s->buf_pos=s->buf_len=0; return 0; } + s->eof=0; s->buf_pos=0; s->buf_len=len; s->pos+=len; diff --git a/stream/stream.c b/stream/stream.c index d4abc69343..cdd9713a20 100644 --- a/stream/stream.c +++ b/stream/stream.c @@ -263,7 +263,7 @@ stream_t* open_output_stream(const char* filename, char** options) { int stream_fill_buffer(stream_t *s){ int len; - if (/*s->fd == NULL ||*/ s->eof) { return 0; } + // we will retry even if we already reached EOF previously. switch(s->type){ case STREAMTYPE_STREAM: #ifdef CONFIG_NETWORK @@ -285,6 +285,9 @@ int stream_fill_buffer(stream_t *s){ len= s->fill_buffer ? s->fill_buffer(s,s->buffer,STREAM_BUFFER_SIZE) : 0; } if(len<=0){ s->eof=1; return 0; } + // When reading succeeded we are obviously not at eof. + // This e.g. avoids issues with eof getting stuck when lavf seeks in MPEG-TS + s->eof=0; s->buf_pos=0; s->buf_len=len; s->pos+=len; -- cgit v1.2.3