Hi all Do you know any release blocker bugs in svn? Current list (from a discussion #mplayerdev): - --enable-debug is broken - vidix linking on ppc - stack alignment in lavc (win only? can it happen with mplayer?) - i remember also something about ffmpeg and amd64, is it related to mplayer? - mingw and/or cygwin compilation is broken - mencoder a/v sync with -oac lavc is broken Please confirm/deny these bugs and extend the list. Ciao, Roberto
Hello, On Mon, Apr 09, 2007 at 12:42:15AM +0200, Roberto Togni wrote:
- i remember also something about ffmpeg and amd64, is it related to mplayer?
Only dynamic linking should be affected. I definitely don't have any problems. Greetings, Reimar Döffinger
Hi On Mon, Apr 09, 2007 at 12:51:26AM +0200, Reimar Döffinger wrote:
Hello, On Mon, Apr 09, 2007 at 12:42:15AM +0200, Roberto Togni wrote:
- i remember also something about ffmpeg and amd64, is it related to mplayer?
Only dynamic linking should be affected. I definitely don't have any problems.
and theres a ok-ed patch on ffmpeg-dev which should fix that ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle
Hi On Mon, Apr 09, 2007 at 12:42:15AM +0200, Roberto Togni wrote: [...]
- stack alignment in lavc
theres nothing lavc specific here, SSE* code needs aligned data outside lavc too
(win only?
can it happen with mplayer?)
if (gcc doesnt maintain alignment || main or another entry point like thread stuff is called with missalged stack && gcc doesnt align the stack) && the stack is used for something which needs proper alignment the gcc behavior depends on version and flags given to it (and no i dont know the details RTFgccM ) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin
Hi,
theres nothing lavc specific here, SSE* code needs aligned data outside lavc too
(win only?
can it happen with mplayer?)
if (gcc doesnt maintain alignment || main or another entry point like thread stuff is called with missalged stack && gcc doesnt align the stack) && the stack is used for something which needs proper alignment
the gcc behavior depends on version and flags given to it (and no i dont know the details RTFgccM )
it was (and probably still is) a problem with mingw32-compiled win32 mplayer binaries. cygwin has no problem, it uses own memory allocator, but mingw relies on windows' memory functions which has no memalign() :( there was 2 ideas to solve this, one is using some 3rd-party memory library when compiling with mingw, the other is changing all the code (mostly in libavcodec) which needs alignment to do the alignment for itself, like: buffer1_base=malloc(buffer1_size+15); buffer1=(buffer1_base+15)&(~15); but it's quite ugly and hackish, and as only win32/mingw needs it nobody would support it... the workaround is/was to disable sse in mingw builds :( A'rpi
Hi, 2007/4/9, Arpi <arpi@thot.banki.hu>:
Hi,
theres nothing lavc specific here, SSE* code needs aligned data outside lavc too
(win only?
can it happen with mplayer?)
if (gcc doesnt maintain alignment || main or another entry point like thread stuff is called with missalged stack && gcc doesnt align the stack) && the stack is used for something which needs proper alignment
the gcc behavior depends on version and flags given to it (and no i dont know the details RTFgccM )
it was (and probably still is) a problem with mingw32-compiled win32 mplayer binaries. cygwin has no problem, it uses own memory allocator, but mingw relies on windows' memory functions which has no memalign() :(
there was 2 ideas to solve this, one is using some 3rd-party memory library when compiling with mingw, the other is changing all the code (mostly in libavcodec) which needs alignment to do the alignment for itself, like: buffer1_base=malloc(buffer1_size+15); buffer1=(buffer1_base+15)&(~15); but it's quite ugly and hackish, and as only win32/mingw needs it nobody would support it... the workaround is/was to disable sse in mingw builds :(
FFmpeg uses its own routine to detect CPU capabilities at runtime so SSE can't be completely disabled unless something is also done from ffmpeg's side. -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
Hi On Mon, Apr 09, 2007 at 09:26:44AM +0800, Zuxy Meng wrote:
Hi,
2007/4/9, Arpi <arpi@thot.banki.hu>:
Hi,
theres nothing lavc specific here, SSE* code needs aligned data outside lavc too
(win only?
can it happen with mplayer?)
if (gcc doesnt maintain alignment || main or another entry point like thread stuff is called with missalged stack && gcc doesnt align the stack) && the stack is used for something which needs proper alignment
the gcc behavior depends on version and flags given to it (and no i dont know the details RTFgccM )
it was (and probably still is) a problem with mingw32-compiled win32 mplayer binaries. cygwin has no problem, it uses own memory allocator, but mingw relies on windows' memory functions which has no memalign() :(
there was 2 ideas to solve this, one is using some 3rd-party memory library when compiling with mingw, the other is changing all the code (mostly in libavcodec) which needs alignment to do the alignment for itself, like: buffer1_base=malloc(buffer1_size+15); buffer1=(buffer1_base+15)&(~15); but it's quite ugly and hackish, and as only win32/mingw needs it nobody would support it... the workaround is/was to disable sse in mingw builds :(
FFmpeg uses its own routine to detect CPU capabilities at runtime so SSE can't be completely disabled unless something is also done from ffmpeg's side.
you should be able to disable via AVCodecContext->dsp_mask though iam not sure if all SSE code checks that ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB 1. write clean, simple and working code 2. high level optimizations 3. low level optimizations
Hi On Mon, Apr 09, 2007 at 12:23:09AM +0000, Arpi wrote:
Hi,
theres nothing lavc specific here, SSE* code needs aligned data outside lavc too
(win only?
can it happen with mplayer?)
if (gcc doesnt maintain alignment || main or another entry point like thread stuff is called with missalged stack && gcc doesnt align the stack) && the stack is used for something which needs proper alignment
the gcc behavior depends on version and flags given to it (and no i dont know the details RTFgccM )
it was (and probably still is) a problem with mingw32-compiled win32 mplayer binaries. cygwin has no problem, it uses own memory allocator, but mingw relies on windows' memory functions which has no memalign() :(
there was 2 ideas to solve this, one is using some 3rd-party memory library when compiling with mingw, the other is changing all the code (mostly in libavcodec) which needs alignment to do the alignment for itself, like: buffer1_base=malloc(buffer1_size+15); buffer1=(buffer1_base+15)&(~15); but it's quite ugly and hackish, and as only win32/mingw needs it nobody would support it... the workaround is/was to disable sse in mingw builds :(
lav* uses av_malloc() which takes care of aligning if theres no other way to get aligned data (memalign() or malloc()) roberto was (if i understood him correctly) talking about stack alignment gcc before 4.something simply assumed correct alignment on function entry which is not true under some circumstances on win32 (ive no faint clue when or if theres a relation to mingw/cygwin ...) (and xine on linux with their overriden -mpreferred-stack-boundary too breaks stack alignment on entry to lavc functions and there are probably other cases ...) the only reason why things dont completely fall apart is that theres not much code which needs a aligned stack, still there is some, mostly mmx though and that dosnt die its just slower :( so ive added a warning message to lavc a while ago which warns the loo/u-ser about the problem if a missaligned stack is detected though it seems the message could benefit from being rewritten to be more understandable [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle
On Mon, 2007-04-09 at 03:31 +0200, Michael Niedermayer wrote:
gcc before 4.something simply assumed correct alignment on function entry which is not true under some circumstances on win32 (ive no faint clue when or if theres a relation to mingw/cygwin ...)
gcc still assumes that by default. Here are the relevant gcc changes I'm aware of: - gcc versions older than 4 ignored alignment attributes for stack variables - gcc 4+ handles alignment up to 16 bytes correctly. However it relies on the stack itself being 16-byte aligned. gcc will automatically align the stack when entering main() and maintain alignment in functions it generates itself, but if you mix code from some other compiler which doesn't keep the stack aligned (mainly happens on Windows) then things can break. - gcc 4.2+ supports an option and a per-function attribute to generate extra code to realign the stack on function entry. So if you intend to mix the code with some that doesn't keep the stack aligned then you can either set the option or if you have a limited set of interface functions then set the attribute for those only.
(and xine on linux with their overriden -mpreferred-stack-boundary too breaks stack alignment on entry to lavc functions and there are probably other cases ...)
Seems xine has fixed those nonsense options on 2007-02-18.
On Mon, Apr 09, 2007 at 12:23:09AM +0000, Arpi wrote:
there was 2 ideas to solve this, one is using some 3rd-party memory library when compiling with mingw, the other is changing all the code (mostly in libavcodec) which needs alignment to do the alignment for itself, like:
One idea I've thought about that we should consider is making a libc replacement for use on windows, which is actually C99-compliant and has proper UTF-8 and sockets support. I'd actually be interested in seeing the libc code I wrote be reused for this purpose - I don't have the time or testing resources to write it myself but I'd be happy to discuss with someone else working on it. Such a project could remain at a 'wrapper' stage, just replacing the broken parts of MS's implementation, or it could be aimed at providing a complete and free libc on windows. Rich
Hi, 2007/4/9, Rich Felker <dalias@aerifal.cx>:
On Mon, Apr 09, 2007 at 12:23:09AM +0000, Arpi wrote:
there was 2 ideas to solve this, one is using some 3rd-party memory library when compiling with mingw, the other is changing all the code (mostly in libavcodec) which needs alignment to do the alignment for itself, like:
One idea I've thought about that we should consider is making a libc replacement for use on windows, which is actually C99-compliant and has proper UTF-8 and sockets support. I'd actually be interested in seeing the libc code I wrote be reused for this purpose - I don't have the time or testing resources to write it myself but I'd be happy to discuss with someone else working on it. Such a project could remain at a 'wrapper' stage, just replacing the broken parts of MS's implementation, or it could be aimed at providing a complete and free libc on windows.
There's something called libgw32c: gnuwin32.sourceforge.net/packages/libgw32c.htm -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
On Mon, Apr 09, 2007 at 09:52:40AM +0800, Zuxy Meng wrote:
Hi,
2007/4/9, Rich Felker <dalias@aerifal.cx>:
there was 2 ideas to solve this, one is using some 3rd-party memory
On Mon, Apr 09, 2007 at 12:23:09AM +0000, Arpi wrote: library
when compiling with mingw, the other is changing all the code (mostly in libavcodec) which needs alignment to do the alignment for itself, like:
One idea I've thought about that we should consider is making a libc replacement for use on windows, which is actually C99-compliant and has proper UTF-8 and sockets support. I'd actually be interested in seeing the libc code I wrote be reused for this purpose - I don't have the time or testing resources to write it myself but I'd be happy to discuss with someone else working on it. Such a project could remain at a 'wrapper' stage, just replacing the broken parts of MS's implementation, or it could be aimed at providing a complete and free libc on windows.
There's something called libgw32c: gnuwin32.sourceforge.net/packages/libgw32c.htm
Interesting, I hadn't seen this. However as far as I can tell, it doesn't solve the other main problems which are sockets (incompatibility with POSIX file descriptor API requiring special-casing for windows code) and lack of UTF-8 support. I don't know if it solves the memory alignment problem or not. Rich
On Mon, 2007-04-09 at 00:42 +0200, Roberto Togni wrote:
- --enable-debug is broken
Would need changing CONFIG_EBP_AVAILABLE to false in configure (the problem is that --enable-debug turns off -fomit-frame-pointer and after that ebp is reserved; the asm in FFmpeg which breaks should be under #ifdef CONFIG_EBP_AVAILABLE now).
- stack alignment in lavc (win only? can it happen with mplayer?)
gcc versions older than 4 ignored alignment attributes of stack variables. If you use gcc 4+ then this shouldn't be an issue for MPlayer. FFmpeg has another issue in that its library code might get called by code from another compiler that doesn't keep the stack itself aligned (in practice most likely to happen on Windows), but this shouldn't concern MPlayer unless you somehow mix compilers during the build. In short: if you compile with gcc 4+ then there should be no problems. gcc versions older than 4 may have problems (but probably not more than they did with the previous MPlayer version, probably mainly slowdown).
- i remember also something about ffmpeg and amd64, is it related to mplayer?
As Reimar already said only --enable-shared in FFmpeg is broken, doesn't concern MPlayer.
Please confirm/deny these bugs and extend the list.
DTS downmixing to stereo is broken after the FFmpeg DTS decoder changes. -channels 2 has no effect. I think fixing this properly requires changes in FFmpeg (the current decoder in FFmpeg has some downmixing logic but no way for the caller to trigger it that I see - also several FIXMEs...).
Hi On Mon, Apr 09, 2007 at 03:40:50AM +0300, Uoti Urpala wrote: [...]
Please confirm/deny these bugs and extend the list.
DTS downmixing to stereo is broken after the FFmpeg DTS decoder changes. -channels 2 has no effect. I think fixing this properly requires changes in FFmpeg (the current decoder in FFmpeg has some downmixing logic but no way for the caller to trigger it that I see - also several FIXMEs...).
thers no and never was any working and clean downmix code in lavc just a bunch of half working hacks justin ruggles though is working on a clean channel layout and downmixing API currently so this should probably be solved soon [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato
On Mon, 2007-04-09 at 03:43 +0200, Michael Niedermayer wrote:
DTS downmixing to stereo is broken after the FFmpeg DTS decoder changes. -channels 2 has no effect. I think fixing this properly requires changes in FFmpeg (the current decoder in FFmpeg has some downmixing logic but no way for the caller to trigger it that I see - also several FIXMEs...).
thers no and never was any working and clean downmix code in lavc just a bunch of half working hacks
The previous code was not particularly nice either (it always downmixed to stereo even if you had support for more), but I think the current situation is still a serious regression for most users compared to the previous MPlayer release. Now they only way to play DTS audio with a stereo ao is to manually give coefficients to -af pan.
Hi, 2007/4/9, Uoti Urpala <uoti.urpala@pp1.inet.fi>:
On Mon, 2007-04-09 at 00:42 +0200, Roberto Togni wrote:
- --enable-debug is broken
Would need changing CONFIG_EBP_AVAILABLE to false in configure (the problem is that --enable-debug turns off -fomit-frame-pointer and after that ebp is reserved; the asm in FFmpeg which breaks should be under #ifdef CONFIG_EBP_AVAILABLE now).
- stack alignment in lavc (win only? can it happen with mplayer?)
gcc versions older than 4 ignored alignment attributes of stack variables. If you use gcc 4+ then this shouldn't be an issue for MPlayer. FFmpeg has another issue in that its library code might get called by code from another compiler that doesn't keep the stack itself aligned (in practice most likely to happen on Windows), but this shouldn't concern MPlayer unless you somehow mix compilers during the build.
In short: if you compile with gcc 4+ then there should be no problems. gcc versions older than 4 may have problems (but probably not more than they did with the previous MPlayer version, probably mainly slowdown).
I've always turned SSE on with my personal builds (compiled by gcc 4.1.1) and I've never seen a single occurance of SIGSEV caused by unaligned access of SSE instructions, unless I turned on threaded en/decoding. -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
DTS downmixing to stereo is broken after the FFmpeg DTS decoder changes. -channels 2 has no effect. I think fixing this properly requires changes in FFmpeg (the current decoder in FFmpeg has some downmixing logic but no way for the caller to trigger it that I see - also several FIXMEs...).
Yes, I think it is very important that Joe user doesn't run into trouble with that. I saw a post where Reimar mentioned that using -ac ffdca helps, and that worked for me once I tried. If the channels downmixing capabilities of ffmpeg aren't ready soon enough (whatever that means), maybe making ffdca default for dts playback would help in the meantime. Sebastian
2007/4/9, mail@kraymer.de <mail@kraymer.de>:
DTS downmixing to stereo is broken after the FFmpeg DTS decoder changes. -channels 2 has no effect. I think fixing this properly requires changes in FFmpeg (the current decoder in FFmpeg has some downmixing logic but no way for the caller to trigger it that I see - also several FIXMEs...).
Yes, I think it is very important that Joe user doesn't run into trouble with that. I saw a post where Reimar mentioned that using -ac ffdca helps, and that worked for me once I tried. If the channels downmixing capabilities of ffmpeg aren't ready soon enough (whatever that means), maybe making ffdca default for dts playback would help in the meantime.
ffdca is the native ffmpeg dts decoder, isn' it? Is there some reason not to use it? Known bugs, missing features?
Hi all
Do you know any release blocker bugs in svn? Current list (from a discussion #mplayerdev):
- --enable-debug is broken - vidix linking on ppc - stack alignment in lavc (win only? can it happen with mplayer?) - i remember also something about ffmpeg and amd64, is it related to mplayer? - mingw and/or cygwin compilation is broken - mencoder a/v sync with -oac lavc is broken mencoder -ovc lavc -oac lavc in.avi -o out.avi
2007/4/9, Roberto Togni <rxt@rtogni.it>: produces file with broken A/V sync at least under MinGW (Audio pts is 1000 times larger than video one), AFAIR. I can provide more details tonight. -- Regards, Vladimir Voroshilov mailto:voroshil@gmail.com JID: voroshil@jabber.ru ICQ: 95587719
2007/4/9, Vladimir Voroshilov <voroshil@gmail.com>:
Hi all
Do you know any release blocker bugs in svn? Current list (from a discussion #mplayerdev):
- --enable-debug is broken - vidix linking on ppc - stack alignment in lavc (win only? can it happen with mplayer?) - i remember also something about ffmpeg and amd64, is it related to mplayer? - mingw and/or cygwin compilation is broken - mencoder a/v sync with -oac lavc is broken mencoder -ovc lavc -oac lavc in.avi -o out.avi
2007/4/9, Roberto Togni <rxt@rtogni.it>: produces file with broken A/V sync at least under MinGW (Audio pts is 1000 times larger than video one), AFAIR. I can provide more details tonight.
Same behaviour under Linux. mencoder -ovc lavc -oac lavc in.avi -o out.avi produces file with audio pts about 1000 times larger than video one. (mencoder.conf contains only names sections and no default) -- Regards, Vladimir Voroshilov mailto:voroshil@gmail.com JID: voroshil@jabber.ru ICQ: 95587719
On Mon, 09 Apr 2007 00:42:15 +0200, Roberto Togni scribed:
Hi all
Do you know any release blocker bugs in svn? Current list (from a discussion #mplayerdev):
- mingw and/or cygwin compilation is broken
i broke cygwin compile with the win32 vcd patch i applied. i'll test this later. i think its still broken unless someone fixed it while i was gone... -compn
Compn <tempn <at> twmi.rr.com> writes:
On Mon, 09 Apr 2007 00:42:15 +0200, Roberto Togni scribed:
Hi all
Do you know any release blocker bugs in svn? Current list (from a discussion #mplayerdev):
- mingw and/or cygwin compilation is broken
i broke cygwin compile with the win32 vcd patch i applied.
yep. its still broken. solution is to disable vcd support on cygwin. also libavcodec/mpegaudiodec.c has a problem, llrint does not exist on cygwin: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-September/016214.html below is current svn make error: cc -o mplayer.exe mplayer.o m_property.o mp_fifo.o mp_msg.o mixer.o parser-mpcmd .o subopt-helper.o command.o osdep/mplayer-rc.o asxparser.o codec-cfg.o cpudetec t.o edl.o find_sub.o m_config.o m_option.o m_struct.o mpcommon.o parser-cfg.o pl aytree.o playtreeparser.o spudec.o sub_cc.o subreader.o vobsub.o unrarlib.o libv o/libvo.a libao2/libao2.a input/libinput.a vidix/libvidix.a libmpcodecs/libmpcod ecs.a libaf/libaf.a libmpdemux/libmpdemux.a stream/stream.a libswscale/libswscal e.a libvo/libosd.a libavformat/libavformat.a libavcodec/libavcodec.a libavutil/l ibavutil.a libpostproc/libpostproc.a mp3lib/libmp3.a liba52/liba52.a libmpeg2/li bmpeg2.a libfaad2/libfaad2.a tremor/libvorbisidec.a dvdread/libdvdread.a libdvdc ss/libdvdcss.a libass/libass.a osdep/libosdep.a -lopengl32 -lgdi32 -laa -laa -lw inmm -lgdi32 -lgdi32 -lwinmm -liconv -lncurses -lpng -lz -lungif -lfreetype -lz -lz -ldts -lm stream/stream.a(stream_vcd.o):stream_vcd.c:(.text+0x5c6): undefined reference to `__open_osfhandle' libavcodec/libavcodec.a(mpegaudiodec.o):mpegaudiodec.c:(.text+0x5a0): undefined reference to `_llrint' collect2: ld returned 1 exit status make: *** [mplayer.exe] Error 1
Roberto Togni <rxt <at> rtogni.it> writes:
Do you know any release blocker bugs in svn?
Quoting http://www.mplayerhq.hu/DOCS/HTML/en/mpeg_decoders.html: Make sure that you have have only Free to Air channels in your channels.conf file, or MPlayer will try to skip to the next visible one, but it may take long if there are many consecutive encrypted channels. Since r20478 (or so, right now, I only tested rc1 and svn, and they show different behaviour), mplayer just prints "TS file format detected" and waits forever (or until encryption ends) instead of skipping. I prefer this new behaviour, because it allows to wait for unencrypted transmissions on otherwise encrypted channels (Euro1080), but in any case, documentation and behaviour differ. Carl Eugen
Carl Eugen Hoyos wrote:
Roberto Togni <rxt <at> rtogni.it> writes:
Do you know any release blocker bugs in svn?
Quoting http://www.mplayerhq.hu/DOCS/HTML/en/mpeg_decoders.html:
Make sure that you have have only Free to Air channels in your channels.conf file, or MPlayer will try to skip to the next visible one, but it may take long if there are many consecutive encrypted channels.
Since r20478 (or so, right now, I only tested rc1 and svn, and they show different behaviour), mplayer just prints "TS file format detected" and waits forever (or until encryption ends) instead of skipping. I prefer this new behaviour, because it allows to wait for unencrypted transmissions on otherwise encrypted channels (Euro1080), but in any case, documentation and behaviour differ.
Carl Eugen
uhm, it's unexpected. the ts demuxer should only probe up to -tsprobe and quit if nothing useful is found. Maybe you overrode that value with something insane? -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Lo sai che hai un tesoro in soffitta? Quello che non serve pi� a te, pu� servire agli altri. * Vendi GRATIS ci� che vuoi con AdBoom.it Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6418&d=10-4
Hi Nico! Nico Sabbi <nsabbi <at> email.it> writes:
Quoting http://www.mplayerhq.hu/DOCS/HTML/en/mpeg_decoders.html:
Make sure that you have have only Free to Air channels in your channels.conf file, or MPlayer will try to skip to the next visible one, but it may take long if there are many consecutive encrypted channels.
Since r20478 (or so, right now, I only tested rc1 and svn, and they show different behaviour), mplayer just prints "TS file format detected" and waits forever (or until encryption ends) instead of skipping. I prefer this new behaviour, because it allows to wait for unencrypted transmissions on otherwise encrypted channels (Euro1080), but in any case, documentation and behaviour differ.
uhm, it's unexpected. the ts demuxer should only probe up to -tsprobe and quit if nothing useful is found. Maybe you overrode that value with something insane?
Just to clarify: I just did svn up && svn update -r20477 libmpdemux/demux_ts.c, merged 22623 (s/stream.h/stream/stream.h) and 21547 (s/min/FFMIN), compiled and tried ./mplayer dvb://HD1 (CA1572 Irdeto encrypted channel) Result for 20477: mplayer quit with "NO VIDEO! NO AUDIO! NO SUBS (yet)!" after a very short time. (Note the two spaces between AUDIO! and NO: Are they intended?) Then I updated libmpdemux/demux_ts.c to 20478, made sure that the necessary changes for compilation (stream and FFMIN) were still there, compiled and tried ./mplayer dvb://HD1 (still encrypted): Result for 20478: mplayer is still waiting for unencrypted packets ("TS file format detected.") Since rc1 (my installed version) shows the same behaviour as 20477, I did not search for overriden default values. Again: I personally like the change (because it allows to wait for an unencrypted program), but since it contradicts DOCS, either documentation or source should probably be changed before release. Thanks for your time, Carl Eugen
Carl Eugen Hoyos wrote:
Just to clarify: I just did svn up && svn update -r20477 libmpdemux/demux_ts.c, merged 22623 (s/stream.h/stream/stream.h) and 21547 (s/min/FFMIN), compiled and tried ./mplayer dvb://HD1 (CA1572 Irdeto encrypted channel) Result for 20477: mplayer quit with "NO VIDEO! NO AUDIO! NO SUBS (yet)!" after a very short time. (Note the two spaces between AUDIO! and NO: Are they intended?) Then I updated libmpdemux/demux_ts.c to 20478, made sure that the necessary changes for compilation (stream and FFMIN) were still there, compiled and tried ./mplayer dvb://HD1 (still encrypted): Result for 20478: mplayer is still waiting for unencrypted packets ("TS file format detected.")
Since rc1 (my installed version) shows the same behaviour as 20477, I did not search for overriden default values.
Again: I personally like the change (because it allows to wait for an unencrypted program), but since it contradicts DOCS, either documentation or source should probably be changed before release.
Thanks for your time, Carl Eugen
try this, and if it works as expected commit it directly, please.
Nico Sabbi wrote:
try this, and if it works as expected commit it directly, please.
------------------------------------------------------------------------
Index: libmpdemux/demux_ts.c =================================================================== --- libmpdemux/demux_ts.c (revisione 22925) +++ libmpdemux/demux_ts.c (copia locale) @@ -999,6 +999,8 @@ demuxer->sub->id = params.spid; priv->prog = params.prog;
+ if((params.vtype == UNKNOWN) && (params.atype == UNKNOWN)) return NULL; + if(params.vtype != UNKNOWN) { ts_add_stream(demuxer, priv->ts.pids[params.vpid]);
although I have to clarify that if this patch works something must have changed either in the demuxer layer or in mplayer itself without me realizing it (without demuxer->video->sh and demuxer->audio-sh there's really nothing to play with)
Hi Nico! Nico Sabbi <nicola_sabbi <at> fastwebnet.it> writes:
try this, and if it works as expected commit it directly, please.
The patch doesn't change behaviour: mplayer still waits forever for unencrypted packets. Carl Eugen
Carl Eugen Hoyos wrote:
Hi Nico!
Nico Sabbi <nicola_sabbi <at> fastwebnet.it> writes:
try this, and if it works as expected commit it directly, please.
The patch doesn't change behaviour: mplayer still waits forever for unencrypted packets.
Carl Eugen
please, upload a sample to incoming. when it comes back online I'll give it a look
Nico Sabbi <nicola_sabbi <at> fastwebnet.it> writes:
please, upload a sample to incoming. when it comes back online I'll give it a look
Why not changing the documentation to the new behaviour? btw: Could somebody test if my claims are actually true? I don't have a DVB-S card that would help to test and my cable provider only sends two channel bundles, that are encrypted in a normal way and they are both HDTV. Carl Eugen
Carl Eugen Hoyos wrote:
Nico Sabbi <nicola_sabbi <at> fastwebnet.it> writes:
please, upload a sample to incoming. when it comes back online I'll give it a look
Why not changing the documentation to the new behaviour?
because it's not the intended behaviour
btw: Could somebody test if my claims are actually true?
I need a sample (at least 100MB)
I don't have a DVB-S card that would help to test and my cable provider only sends two channel bundles, that are encrypted in a normal way and they are both HDTV.
upload it somewhere accessible please -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Problemi di Liquidit�? Con Logos Finanziaria 30.000 � in 24 ore a dipendenti e lavoratori autonomi con rimborsi fino a 120 mesi clicca qui * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2907&d=20-4
Carl Eugen Hoyos wrote:
Again: I personally like the change (because it allows to wait for an unencrypted program), but since it contradicts DOCS, either documentation or source should probably be changed before release.
Thanks for your time, Carl Eugen
hopefully fixed to be consistent with common sense and current docs. You can still use -tsprobe 10000000000 if you need :)
Hi Nico! Nico Sabbi <nsabbi <at> email.it> writes:
Carl Eugen Hoyos wrote:
Again: I personally like the change (because it allows to wait for an unencrypted program), but since it contradicts DOCS, either documentation or source should probably be changed before release.
hopefully fixed to be consistent with common sense and current docs. You can still use -tsprobe 10000000000 if you need :)
Unfortunately not (tested with r24617). When I tune to a (Nagra) encrypted DVB channel with current svn, mplayer waits for unencrypted data forever; with rc1, it quits (nearly) immediately. When I try to play HD1MP4enc.ts, current svn succeeds, rc1 fails (as documented). Should I prepare a documentation fix for the current behaviour? Carl Eugen
Il Wednesday 26 September 2007 00:10:06 Carl Eugen Hoyos ha scritto:
Hi Nico!
Nico Sabbi <nsabbi <at> email.it> writes:
Carl Eugen Hoyos wrote:
Again: I personally like the change (because it allows to wait for an unencrypted program), but since it contradicts DOCS, either documentation or source should probably be changed before release.
hopefully fixed to be consistent with common sense and current docs. You can still use -tsprobe 10000000000 if you need :)
Unfortunately not (tested with r24617).
When I tune to a (Nagra) encrypted DVB channel with current svn, mplayer waits for unencrypted data forever; with rc1, it quits (nearly) immediately. When I try to play HD1MP4enc.ts, current svn succeeds, rc1 fails (as documented).
Should I prepare a documentation fix for the current behaviour?
Carl Eugen
if you want, but if you searched where the hang happens it would be still better
On Apr 09, 07 00:42:15 +0200, Roberto Togni wrote:
Do you know any release blocker bugs in svn?
Well, let's see... - PAFF segfaults H.264 codec - multiplexing external audio into any stream with -ovc copy -oac copy -audiofile xyz doesn't work as intended at least for AC3 and DTS (is this actually known? I remember reading something) (*) - mkv demuxing obviously does something wrong with PTS (*) (+) - native MPEG2 TS demuxer adds offset to PTS, lavf works on most (*) And since yesterday: - MPEG2 TS: DTS in private stream not detected (+) - lavf TS demuxer fails for some streams (+) - lavf TS demuxer segfaults for some streams w/ DTS (+) - DTS decoder doesn't work correctly for mencoder at all (*) (+) At least for MPEG2 TS w/ DTS. Plays fine in mplayer, but transcoding to mp3 fails with strange results. (*) only or mainly visible in mencoder (+) Yes, valid/better bug report and/or samples missing, there is oh so little time :-( Hopefully tonight. Since most of these issues are known / existent for a long time now, I would agree that close to none of them are blocker bugs. Perhaps the PAFF segfault, because we *do* have an at least partially working workaround. Thanks Matthias -- Matthias Hopf <mhopf@suse.de> __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de
Matthias Hopf wrote:
On Apr 09, 07 00:42:15 +0200, Roberto Togni wrote:
Do you know any release blocker bugs in svn?
Well, let's see...
- PAFF segfaults H.264 codec - multiplexing external audio into any stream with -ovc copy -oac copy -audiofile xyz doesn't work as intended at least for AC3 and DTS (is this actually known? I remember reading something) (*) - mkv demuxing obviously does something wrong with PTS (*) (+) - native MPEG2 TS demuxer adds offset to PTS, lavf works on most (*)
no, it doesn't add any offset, but since lavf uses a frame parser every packet has 1 complete frame with a correct pts
And since yesterday: - MPEG2 TS: DTS in private stream not detected (+)
I didn't update the demuxer recently, either this lack is older than today or ... sample needed
- lavf TS demuxer fails for some streams (+) - lavf TS demuxer segfaults for some streams w/ DTS (+) - DTS decoder doesn't work correctly for mencoder at all (*) (+)
probably learn to use -tsprobe
At least for MPEG2 TS w/ DTS. Plays fine in mplayer, but transcoding to mp3 fails with strange results.
(*) only or mainly visible in mencoder (+) Yes, valid/better bug report and/or samples missing, there is oh so little time :-( Hopefully tonight.
Since most of these issues are known / existent for a long time now, I would agree that close to none of them are blocker bugs. Perhaps the PAFF segfault, because we *do* have an at least partially working workaround.
Thanks
Matthias
-- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Fai crescere i tuoi sogni. Scegli il prestito fino a 5.000 euro. * Rate da 20 euro Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6331&d=11-4
On Apr 11, 07 17:37:17 +0200, Nico Sabbi wrote:
- native MPEG2 TS demuxer adds offset to PTS, lavf works on most (*)
no, it doesn't add any offset, but since lavf uses a frame parser every packet has 1 complete frame with a correct pts
I don't think that is all. An ac3 frame has a length of 32ms for 48k audio, and I found (per-file constant) offsets of -200 to 200ms with the native TS demuxer.
And since yesterday: - MPEG2 TS: DTS in private stream not detected (+) I didn't update the demuxer recently, either this lack is older than today or ... sample needed
(+): I only noticed that yesterday, now I finally was able to reduce the sample size to something like 10MB. I'll report the issues with this sample, but it could well be that this is very ill-formed.
- lavf TS demuxer fails for some streams (+) - lavf TS demuxer segfaults for some streams w/ DTS (+) - DTS decoder doesn't work correctly for mencoder at all (*) (+)
probably learn to use -tsprobe
I know -tsprobe and the according lavf option :^P This is different. (+) bug report pending. Matthias -- Matthias Hopf <mhopf@suse.de> __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de
Matthias Hopf wrote:
On Apr 11, 07 17:37:17 +0200, Nico Sabbi wrote:
- native MPEG2 TS demuxer adds offset to PTS, lavf works on most (*)
no, it doesn't add any offset, but since lavf uses a frame parser every packet has 1 complete frame with a correct pts
I don't think that is all. An ac3 frame has a length of 32ms for 48k audio, and I found (per-file constant) offsets of -200 to 200ms with the native TS demuxer.
there's usually an initial preload in broadcast transmissions (audio transmitted somewhat ahead of time wrt to video), that is: "near" packet N there's a video packet with Vpts(N) and an audio packet with Apts(N)=Vpts(N)-K. Mplayer will initially play them as if they corresponded to the same pts, but after few seconds the sync stabilizes. IIUC lavf seems to discard the initial packets corresponding to the pre-loaded stream
On Apr 11, 07 21:44:41 +0200, Nico Sabbi wrote:
I don't think that is all. An ac3 frame has a length of 32ms for 48k audio, and I found (per-file constant) offsets of -200 to 200ms with the native TS demuxer.
there's usually an initial preload in broadcast transmissions (audio transmitted somewhat ahead of time wrt to video), that is: "near" packet N there's a video packet with Vpts(N) and an audio packet with Apts(N)=Vpts(N)-K. Mplayer will initially play them as if they corresponded to the same pts, but after few seconds the sync stabilizes.
In that case mencoder somehow doesn't respect these. The offset I was taking about was all in transcoded files (to XVid/avi) with -oac copy.
IIUC lavf seems to discard the initial packets corresponding to the pre-loaded stream
Sounds reasonable given the symptoms. Thanks Matthias -- Matthias Hopf <mhopf@suse.de> __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de
Nico, On Apr 11, 07 20:25:07 +0200, Matthias Hopf wrote:
- MPEG2 TS: DTS in private stream not detected (+) I didn't update the demuxer recently, either this lack is older than today or ... sample needed
I just uploaded it to upload.mplayerhq.hu/MPlayer/incoming/mpeg2_dts.ts Now what happens with current SVN mplayer is: - Without [-ac *] the demuxer assumes ac3 data, and uses a52 for decoding... - Same with [-ac ffdts] and [-ac ffdca] - With [-ac +ffdts] and [-ac +ffdca] we get sound, quite different, but I assume due to channel downmixing in dca. AFAICS dca implements *only* stereo downmixing ATM. What happens with current SVN mencoder is: (General options: mencoder -vf scale=320:240 -ovc xvid -xvidencopts fixed_quant=3 -o /var/tmp/tst.avi mpeg2_dts.ts) - With [-demuxer lavf] mencoder segfaults (both with [-oac copy] and [-oac mp3lame -ac +ffdca]) - With default demuxer [-demuxer mpegts -oac copy] mencoder duplicates about 1 frame every 10 frames, and the resulting avi has strange and partially broken audio, that can only be played with [-ac +ffdts], but not with [-ac +ffdca], and not without option. - With [-demuxer mpegts -oac mp3lame] we get an empty file (no sound, no output?) - With [-demuxer mpegts -oac mp3lame -ac +ffdts] mencoder duplicates about 1 frame every 10 frames, and audio is completely broken (probably due to channel numbers) - With [-demuxer mpegts -oac mp3lame -ac +ffdca] it works pretty well. So AFAICS we have the following issues: - DTS isn't detected correctly in this file - libavformat demuxer segfaults for this file - ffmpeg dts decoder delivers 5.1 channels, but mp3 encoders only allow for 2, and this is neither corrected nor detected - native demuxer with -oac copy doesn't get PTS values right (or something else messes up A/V sync) - same for native demuxer with ffdts decoder - ffdca decoder works fine, but might need a little bit more advertising (well, I didn't know about it until Reimar pushed me to it) Maybe DTS detection and libavformat segfaults are blockers, but not the others.
- lavf TS demuxer fails for some streams (+) - lavf TS demuxer segfaults for some streams w/ DTS (+) - DTS decoder doesn't work correctly for mencoder at all (*) (+)
probably learn to use -tsprobe
Just to make sure I tried -lavfdopts probesize=10000000 (the file has a size of 10MB, so it certainly has less than 10m pakets) - no change. Segfault. Hope I didn't forget anything. In any case, just ask. Thanks Matthias -- Matthias Hopf <mhopf@suse.de> __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de
Matthias Hopf wrote:
Nico,
On Apr 11, 07 20:25:07 +0200, Matthias Hopf wrote:
- MPEG2 TS: DTS in private stream not detected (+)
I didn't update the demuxer recently, either this lack is older than today or ... sample needed
I just uploaded it to upload.mplayerhq.hu/MPlayer/incoming/mpeg2_dts.ts
now, if only incoming worked ...
On Apr 12, 07 23:33:12 +0200, Nico Sabbi wrote:
I just uploaded it to upload.mplayerhq.hu/MPlayer/incoming/mpeg2_dts.ts
now, if only incoming worked ...
Hm. Maybe I'm lacking vital information... This is the location mentioned in the bug report page. Ah. Now, I missed to upload a .txt file. Is this necessary for stuff discussed on the mailing list as well? Thanks Matthias -- Matthias Hopf <mhopf@suse.de> __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de
On Fri, 13 Apr 2007 19:58:47 +0200, Matthias Hopf scribed:
On Apr 12, 07 23:33:12 +0200, Nico Sabbi wrote:
I just uploaded it to upload.mplayerhq.hu/MPlayer/incoming/mpeg2_dts.ts
now, if only incoming worked ...
Hm. Maybe I'm lacking vital information... This is the location mentioned in the bug report page.
Ah. Now, I missed to upload a .txt file. Is this necessary for stuff discussed on the mailing list as well?
txt files are always important, just so those investigating incoming can do so without reading every single mail in the mailing list :) what nico ment was that incoming was not accessible by the devs... we cant even ls it right now! -compn
Hello, On Fri, Apr 13, 2007 at 07:02:02PM -0400, Compn wrote:
On Fri, 13 Apr 2007 19:58:47 +0200, Matthias Hopf scribed:
On Apr 12, 07 23:33:12 +0200, Nico Sabbi wrote:
I just uploaded it to upload.mplayerhq.hu/MPlayer/incoming/mpeg2_dts.ts
now, if only incoming worked ...
Hm. Maybe I'm lacking vital information... This is the location mentioned in the bug report page.
Ah. Now, I missed to upload a .txt file. Is this necessary for stuff discussed on the mailing list as well?
txt files are always important, just so those investigating incoming can do so without reading every single mail in the mailing list :)
what nico ment was that incoming was not accessible by the devs...
we cant even ls it right now!
I copied the file here for now: http://www1.mplayerhq.hu/~reimar/mpeg2_dts.ts Greetings, Reimar Döffinger
Matthias Hopf wrote:
Nico,
On Apr 11, 07 20:25:07 +0200, Matthias Hopf wrote:
- MPEG2 TS: DTS in private stream not detected (+)
I didn't update the demuxer recently, either this lack is older than today or ... sample needed
I just uploaded it to upload.mplayerhq.hu/MPlayer/incoming/mpeg2_dts.ts
there's only AC3 in that sample: New active PMT program_number : 258 version_number : 0 PCR_PID : 0xe0 (224) | type @ elementary_PID | 0x02 (ISO/IEC 13818-2 Video) @ 0xe0 (224) | ] 0x52 : Component tag: 1 | 0x06 (ISO/IEC 13818-1 Private PES data packets) @ 0x80 (128) | ] 0x52 : Component tag: 2 | ] 0x6a : "" | ] 0x0a : "deu" | 0x81 (User Private) @ 0x80 (128) | ] 0x52 : Component tag: 2 | ] 0x0a : "eng" | ] 0x05 : "AC-3" | 0x06 (ISO/IEC 13818-1 Private PES data packets) @ 0x81 (129) | ] 0x52 : Component tag: 3 | ] 0x6a : "" | ] 0x0a : "deu" | 0x81 (User Private) @ 0x81 (129) | ] 0x52 : Component tag: 3 | ] 0x0a : "eng" | ] 0x05 : "AC-3"
Nico Sabbi wrote:
Matthias Hopf wrote:
Nico,
On Apr 11, 07 20:25:07 +0200, Matthias Hopf wrote:
- MPEG2 TS: DTS in private stream not detected (+)
I didn't update the demuxer recently, either this lack is older than today or ... sample needed
I just uploaded it to upload.mplayerhq.hu/MPlayer/incoming/mpeg2_dts.ts
there's only AC3 in that sample:
New active PMT program_number : 258 version_number : 0 PCR_PID : 0xe0 (224) | type @ elementary_PID | 0x02 (ISO/IEC 13818-2 Video) @ 0xe0 (224) | ] 0x52 : Component tag: 1 | 0x06 (ISO/IEC 13818-1 Private PES data packets) @ 0x80 (128) | ] 0x52 : Component tag: 2 | ] 0x6a : "" | ] 0x0a : "deu" | 0x81 (User Private) @ 0x80 (128) | ] 0x52 : Component tag: 2 | ] 0x0a : "eng" | ] 0x05 : "AC-3" | 0x06 (ISO/IEC 13818-1 Private PES data packets) @ 0x81 (129) | ] 0x52 : Component tag: 3 | ] 0x6a : "" | ] 0x0a : "deu" | 0x81 (User Private) @ 0x81 (129) | ] 0x52 : Component tag: 3 | ] 0x0a : "eng" | ] 0x05 : "AC-3"
clarification: although pid 128 is reported to contain AC-3 it actually contains DTS, so you are screwed because of the extreme idiocy of whover inserted the wrong descriptors in the PMT. Bad luck, but unfortunately it happens
Hello, On Wed, Apr 11, 2007 at 05:13:07PM +0200, Matthias Hopf wrote:
- multiplexing external audio into any stream with -ovc copy -oac copy -audiofile xyz doesn't work as intended at least for AC3 and DTS (is this actually known? I remember reading something) (*)
-ovc copy -oac copy is something where always a lot can go wrong. I am not aware of anyone using it with -audiofile though. I guess with AC3 and dts there is no proper packetization. Unless it's a regression I don't think that really is release-relevant.
- DTS decoder doesn't work correctly for mencoder at all (*) (+) At least for MPEG2 TS w/ DTS. Plays fine in mplayer, but transcoding to mp3 fails with strange results.
ffdts or ffdca? ffdts produces multi-channel audio, you can't put that into MP3. Probably mencoder should warn about this though. Greetings, Reimar Döffinger
On Wed, 11 Apr 2007 18:02:10 +0200, Reimar Döffinger scribed:
Hello, On Wed, Apr 11, 2007 at 05:13:07PM +0200, Matthias Hopf wrote:
- multiplexing external audio into any stream with -ovc copy -oac copy -audiofile xyz doesn't work as intended at least for AC3 and DTS (is this actually known? I remember reading something) (*)
-ovc copy -oac copy is something where always a lot can go wrong. I am not aware of anyone using it with -audiofile though. I guess with AC3 and dts there is no proper packetization. Unless it's a regression I don't think that really is release-relevant.
i remember running into this problem a long time ago.. maybe someone could check it out using pre7 or so.
- DTS decoder doesn't work correctly for mencoder at all (*) (+) At least for MPEG2 TS w/ DTS. Plays fine in mplayer, but transcoding to mp3 fails with strange results.
ffdts or ffdca? ffdts produces multi-channel audio, you can't put that into MP3. Probably mencoder should warn about this though.
another point for making ffdca default? -compn
On Apr 11, 07 13:13:47 -0400, Compn wrote:
-ovc copy -oac copy is something where always a lot can go wrong. I am not aware of anyone using it with -audiofile though. I guess with AC3 and dts there is no proper packetization. Unless it's a regression I don't think that really is release-relevant.
No, at least not for quite some time.
i remember running into this problem a long time ago.. maybe someone could check it out using pre7 or so.
Can do that. Will take some time, though. Matthias -- Matthias Hopf <mhopf@suse.de> __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de
On Apr 11, 07 18:02:10 +0200, Reimar Döffinger wrote:
- DTS decoder doesn't work correctly for mencoder at all (*) (+) At least for MPEG2 TS w/ DTS. Plays fine in mplayer, but transcoding to mp3 fails with strange results.
ffdts or ffdca? ffdts produces multi-channel audio, you can't put that into MP3. Probably mencoder should warn about this though.
Woha! That could be the problem. At least on one part. I'll try libdca at home. Thanks Matthias -- Matthias Hopf <mhopf@suse.de> __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de
Hello, On Wed, Apr 11, 2007 at 08:40:53PM +0200, Matthias Hopf wrote:
On Apr 11, 07 18:02:10 +0200, Reimar Döffinger wrote:
- DTS decoder doesn't work correctly for mencoder at all (*) (+) At least for MPEG2 TS w/ DTS. Plays fine in mplayer, but transcoding to mp3 fails with strange results.
ffdts or ffdca? ffdts produces multi-channel audio, you can't put that into MP3. Probably mencoder should warn about this though.
Woha! That could be the problem. At least on one part. I'll try libdca at home.
I fear there might be some confusion, ffdts is what use libdca (formerly known as libdts), ffdca is the native decoder (although it based on libdca), you don't need any extra lib for that. Greetings, Reimar Döffinger
On Apr 11, 07 21:30:46 +0200, Reimar Döffinger wrote:
ffdts or ffdca? ffdts produces multi-channel audio, you can't put that into MP3. Probably mencoder should warn about this though. Woha! That could be the problem. At least on one part. I'll try libdca at home. I fear there might be some confusion, ffdts is what use libdca (formerly known as libdts), ffdca is the native decoder (although it based on libdca), you don't need any extra lib for that.
I might even add to that confusion, as I really have libdts-devel on my system at home (stone age). The tests above were ffdts/libdts on the one hand and ffdca on the other. I didn't try ffdts/libdca, but I assume that it won't change much. Thanks for clarification Matthias -- Matthias Hopf <mhopf@suse.de> __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de
On Mon, 9 Apr 2007 00:42:15 +0200 Roberto Togni <rxt@rtogni.it> wrote:
Do you know any release blocker bugs in svn? Current list (from a discussion #mplayerdev):
Not a bug, but how about shipping rc2 with a copy of our dvdnav fork integreated? Attila Kinali -- Praised are the Fountains of Shelieth, the silver harp of the waters, But blest in my name forever this stream that stanched my thirst! -- Deed of Morred
Attila Kinali wrote:
On Mon, 9 Apr 2007 00:42:15 +0200 Roberto Togni <rxt@rtogni.it> wrote:
Do you know any release blocker bugs in svn? Current list (from a discussion #mplayerdev):
Not a bug, but how about shipping rc2 with a copy of our dvdnav fork integreated?
Attila Kinali
maybe, but stating clearly that the new build system is still incomplete -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Vendi l'auto? La moto? La barca? Il Camper? Affitti un appartamento? * Per concludere i tuoi affari pubblica gli annunci con AdBoom.it! Facile. Veloce. Gratuito Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6419&d=19-4
On Thu, 19 Apr 2007 11:54:56 +0200 Nico Sabbi <nsabbi@email.it> wrote:
Not a bug, but how about shipping rc2 with a copy of our dvdnav fork integreated? maybe, but stating clearly that the new build system is still incomplete
Ok, then it isn't a good idea yet. Attila Kinali -- Praised are the Fountains of Shelieth, the silver harp of the waters, But blest in my name forever this stream that stanched my thirst! -- Deed of Morred
Hi! Roberto Togni <rxt <at> rtogni.it> writes:
Do you know any release blocker bugs in svn?
AMR documentation in section 7.2.6 is outdated: http://www.mplayerhq.hu/DOCS/HTML/en/audio-codecs.html#amr Probably also for comments on top of libavcodec/amr.c Carl Eugen
On Mon, Apr 23, 2007 at 12:24:37PM +0000, Carl Eugen Hoyos wrote:
Roberto Togni <rxt <at> rtogni.it> writes:
Do you know any release blocker bugs in svn?
AMR documentation in section 7.2.6 is outdated: http://www.mplayerhq.hu/DOCS/HTML/en/audio-codecs.html#amr
Fixed.
Probably also for comments on top of libavcodec/amr.c
Hmmm? I changed them some time ago... Diego
Diego Biurrun <diego <at> biurrun.de> writes:
AMR documentation in section 7.2.6 is outdated: http://www.mplayerhq.hu/DOCS/HTML/en/audio-codecs.html#amr
Fixed.
Thank you.
Probably also for comments on top of libavcodec/amr.c
Hmmm? I changed them some time ago...
It contains no reference to penguin.cz. I did not succeed in building a working floating point decoder by only using the reference codec (without penguin.cz's installer). Is it possible? For a user reading the comment, I mean. Carl Eugen
On Tue, Apr 24, 2007 at 09:27:45AM +0000, Carl Eugen Hoyos wrote:
Diego Biurrun <diego <at> biurrun.de> writes:
Probably also for comments on top of libavcodec/amr.c
Hmmm? I changed them some time ago...
It contains no reference to penguin.cz. I did not succeed in building a working floating point decoder by only using the reference codec (without penguin.cz's installer). Is it possible? For a user reading the comment, I mean.
User reading a comment in a source file? Sounds like an oxymoron to me. The user documentation explains what needs to be done to get AMR working. I think that's enough. Diego
On Mon, Apr 09, 2007 at 12:42:15AM +0200, Roberto Togni wrote:
Do you know any release blocker bugs in svn?
DTS playback is completely broken for me, I can play none of the samples in http://samples.mplayerhq.hu/A-codecs/DTS/ correctly. ffdts prints lots of errors, ffdca crashes. Diego
On Thu, 26 Apr 2007 22:00:21 +0200, Diego Biurrun scribed:
On Mon, Apr 09, 2007 at 12:42:15AM +0200, Roberto Togni wrote:
Do you know any release blocker bugs in svn?
DTS playback is completely broken for me, I can play none of the samples in
http://samples.mplayerhq.hu/A-codecs/DTS/
correctly. ffdts prints lots of errors, ffdca crashes.
Diego
didnt test dts... http://samples.mplayerhq.hu/A-codecs/DTS/ mplayer Fire__VooDoo_Studio_30_sec.wav -v -demuxer lavf -ac +ffdca MPlayer dev-SVN-r23146-3.3 (C) 2000-2007 MPlayer Team works for me, but native mplayer demuxer causes crash in init_audio_codec -compn
On Thu, Apr 26, 2007 at 10:00:21PM +0200, Diego Biurrun wrote:
On Mon, Apr 09, 2007 at 12:42:15AM +0200, Roberto Togni wrote:
Do you know any release blocker bugs in svn?
DTS playback is completely broken for me, I can play none of the samples in
http://samples.mplayerhq.hu/A-codecs/DTS/
correctly. ffdts prints lots of errors, ffdca crashes.
Now that libdts support was removed from FFmpeg, DTS playback in MPlayer has basically stopped working AFAICT. Diego
2007/5/18, Diego Biurrun <diego@biurrun.de>:
On Thu, Apr 26, 2007 at 10:00:21PM +0200, Diego Biurrun wrote:
On Mon, Apr 09, 2007 at 12:42:15AM +0200, Roberto Togni wrote:
Do you know any release blocker bugs in svn?
DTS playback is completely broken for me, I can play none of the samples in
http://samples.mplayerhq.hu/A-codecs/DTS/
correctly. ffdts prints lots of errors, ffdca crashes.
Now that libdts support was removed from FFmpeg, DTS playback in MPlayer has basically stopped working AFAICT.
Did you forgot the native libdca audio driver that Roberto wrote?
On Sat, Sep 22, 2007 at 03:10:25PM +0300, Ivan Kalvachev wrote:
2007/5/18, Diego Biurrun <diego@biurrun.de>:
On Thu, Apr 26, 2007 at 10:00:21PM +0200, Diego Biurrun wrote:
On Mon, Apr 09, 2007 at 12:42:15AM +0200, Roberto Togni wrote:
Do you know any release blocker bugs in svn?
DTS playback is completely broken for me, I can play none of the samples in
http://samples.mplayerhq.hu/A-codecs/DTS/
correctly. ffdts prints lots of errors, ffdca crashes.
Now that libdts support was removed from FFmpeg, DTS playback in MPlayer has basically stopped working AFAICT.
Did you forgot the native libdca audio driver that Roberto wrote?
Look at the dates of my mail and Roberto's commit. Diego
2007/9/23, Diego Biurrun <diego@biurrun.de>:
On Sat, Sep 22, 2007 at 03:10:25PM +0300, Ivan Kalvachev wrote:
2007/5/18, Diego Biurrun <diego@biurrun.de>:
On Thu, Apr 26, 2007 at 10:00:21PM +0200, Diego Biurrun wrote:
On Mon, Apr 09, 2007 at 12:42:15AM +0200, Roberto Togni wrote:
Do you know any release blocker bugs in svn?
DTS playback is completely broken for me, I can play none of the samples in
http://samples.mplayerhq.hu/A-codecs/DTS/
correctly. ffdts prints lots of errors, ffdca crashes.
Now that libdts support was removed from FFmpeg, DTS playback in MPlayer has basically stopped working AFAICT.
Did you forgot the native libdca audio driver that Roberto wrote?
Look at the dates of my mail and Roberto's commit.
Sorry, it must be gmail bug, I got this mail as new at the end of the stack, didn't notice the date at all.
participants (18)
-
Arpi -
Attila Kinali -
Carl Eugen Hoyos -
Compn -
Diego Biurrun -
Ivan Kalvachev -
mail＠kraymer.de -
Matthias Hopf -
Michael Niedermayer -
Nico Sabbi -
Nico Sabbi -
Nico Sabbi -
Reimar Döffinger -
Rich Felker -
Roberto Togni -
Uoti Urpala -
Vladimir Voroshilov -
Zuxy Meng