[FFmpeg-devel] [PATCH] asf-format doesn't work as stream for XBox360

[Michael Niedermayer]

Hi

On Mon, Oct 15, 2007 at 01:36:58AM +0200, Patric Stout wrote:
> Michael Niedermayer schreef:
> > On Mon, Oct 15, 2007 at 12:09:13AM +0200, Patric Stout wrote:
> >   
> >> Michael Niedermayer schreef:
> >>     
> >>> On Sun, Oct 14, 2007 at 11:35:38PM +0200, Patric Stout wrote:
> >>>   
> >>>       
> >>>> Hi all,
> >>>>
> >>>> As I was trying to get ffmpeg to do some on-demand streaming of WMV2 to
> >>>> my XBox360, I noticed it was always rejected. When I converted the file
> >>>> to a wmv first, and tried to playback that file, it went okay. So it
> >>>> made me wonder why that was. After a short search, I found out that my
> >>>> XBox doesn't like the fact that in the asf-container it is told the
> >>>> filelength is 0 (which, when writing to a file, is later replaced by the
> >>>> real number, but of course this can't be done on a stream).
> >>>>
> >>>> Now this is done on several places, but only one places my XBox cares
> >>>> about. So, I made a small patch that fills in a huge value by default
> >>>> (which normally gets overwritten later on by the real value), which
> >>>> makes streaming to my XBox via ffmpeg work perfectly. Attached is that
> >>>> patch. I hope it is useful for more people. Now I can finally watch
> >>>> movies on my XBox via an on-demand stream from my Linux computer.. too
> >>>> bad you can't encode HR movies in WMV2 format, but that is an other story ;)
> >>>>     
> >>>>         
> >>> do wmvs which are generated and streamed by the official tools also contain
> >>> a -1 in there? 
> >>>
> >>>   
> >>>       
> >> First of, the value (uint64)-1 failed. It in fact are 12 F's, not 16.
> >> The reason for this is unknown for me, but I settled with the first
> >> value that did work.
> >>     
> >
> > this doesnt sound correct at all ...
> > have you tried to set some different values for the flags instead of changing
> > the data size?
> >
> > and you did try -f asf_stream ?
> >   
> You are right, it doesn't sound correct. I all of a sudden understood
> why the value -1 didn't work. The data_chunk_size is a SIGNED integer,
> and read as such.. and negative values of course don't work as length
> value. So if we fill in the biggest positive value of an int64_t, it
> works perfectly too. And this value does make sense. Attached is the
> patch with the correct value.

the problem with this is that the little bit of public asf docs 
say it should be 0 if its unknown
so unless you can provide some official docs stating otherwise or some
information about some official tool setting it differently i cant
accept this patch

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored awnser#1 FFmpeg bugs should be sent to our bugtracker, user
questions for the command line tools ffmpeg, ffplay, ... as well as questions
about how to use libav* should be sent to the ffmpeg-user mailinglist.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071015/f0dfc993/attachment.pgp>