[streaming] Re: Other output messing the binary Stdout?

[Sigmund Augdal Helberg]

On Thu, 2005-11-17 at 11:19 +0100, Polyphem wrote:
> Thanks for the answer Derk.
> Does this really apply for all kind of codecs? I thougth that this
> only applies to certain kinds like AVI, and that MPEG1 for example can
> also be played without a correct header. And what is than the
> difference to streaming a transcoded file over HTTP, there VLC also
> can not go back to the header and correct it, because the information
> is streamed permanently.
> What makes me wonder is, that of a ~3MB large file only some 1-2 KB
> seem to be different between output to STDOUT and output to a file.
> And the difference is in the Header AND the Footer (last few KBs),
> thats why i think some other stuff is messing it up, maybe some
> line-breaks sent or something like that.
Make sure that you use --quiet and that you do _not_ use the rc
interface (at least not without --rc-host or --rc-socket or what those
options are called). Even more do not use the ncurses interface or the
aa/caca video outputs. Most likely it is the rc interface that messes
stuff up for you, so try -I dummy next time.

As for codecs and such this is somewhat complex. VLC can take different
actions based on what output it is using. Some containers require no
header at all (like mpeg2 ts) and is easily used for streaming purposes.
Some require a simple header that can be generated up front, for these
the header can be remembered so each time a client connects to http the
header is sent first, then streaming data is sent. The final case is
avi, mp4 etc. For these containers vlc will have to rewind and create a
index at the start of the file after fully generating the contents.

Sigmund
> Best Regards
> 
> On 11/16/05, Derk-Jan Hartman <hartman at videolan.org> wrote:
>         If you used --quiet you should be fine regardless.
>         I think it's more that stdout is a stream instead of a file,
>         so VLC
>         cannot go back in the file and update the headers with the
>         correct
>         information and stuff.
>         
>         DJ
>         
>         On 16-nov-2005, at 11:07, Polyphem wrote:
>         
>         > Hello VLC-Community,
>         >
>         > I'm currently playing around with the binary Stdout option
>         an run
>         > into a problem.
>         >
>         > When I use 
>         > standard{access=file,mux=asf,url='test.mpeg'}
>         >
>         > the resulting local file is healthy and plays in VLC and
>         WMP. When
>         > I try to capture the binary output from Stdout with
>         >
>         > standard{access=file,mux=asf,url=-} 
>         >
>         > and than create the movie with an external program, it is
>         > corrupted. I took hex look at the binaries and it seems that
>         99.9%
>         > are identical. Only in the top 2-3 header rows and the
>         bottom 2-3 
>         > footer rows the Stdout file looks sligtly different.
>         > I looked up the Stdout function here:
>         >
>         https://trac.videolan.org/vlc/file/trunk/modules/access_output/file.c
>         >
>         > Is it possible that these:
>         >
>         > msg_Dbg( p_access, "using stdout" );
>         > msg_Dbg( p_access, "file access output opened (`%s')",
>         p_access-
>         > >psz_name );
>         > msg_Dbg( p_access, "file access output closed" );
>         >
>         > come in my way? Are they also parsed to the Stdout and I
>         have to
>         > deactivate them somehow, or do those Messages need to be
>         invoked by 
>         > a special debug option (which I did not found until now)?
>         >
>         > Anyone had this problem before? Is it possible that VLC
>         mixes other
>         > Stdout output into the stream? Invoked it with -q, --quiet,
>         but are 
>         > there other parameters to tell VLC not to write other output
>         to
>         > Stdout?
>         >
>         > Thanks and Best Regards
>         >
>         >
>         >
>         
>         --
>         This is the streaming mailing-list, see
>         http://www.videolan.org/streaming/
>         To unsubscribe, please read
>         http://www.videolan.org/support/lists.html
>         
> 

-- 
This is the streaming mailing-list, see http://www.videolan.org/streaming/
To unsubscribe, please read http://www.videolan.org/support/lists.html