Age | Commit message (Collapse) | Author |
|
I have only tested Stereo and Surround 5.1 modes so far.
Removes an annoying bias bug.
CVS patchset: 6568
CVS date: 2004/05/19 18:00:47
|
|
CVS patchset: 6567
CVS date: 2004/05/18 20:38:28
|
|
CVS patchset: 6566
CVS date: 2004/05/18 20:35:04
|
|
Do not like "make debug" with debug printf's.
CVS patchset: 6565
CVS date: 2004/05/18 20:04:53
|
|
rewiring a closed port won't cause the new destination to be opened.
CVS patchset: 6564
CVS date: 2004/05/18 03:16:12
|
|
(intercepting the audio_out port).
calling xine_post_wire_audio_port( post output, audio_out )
would close the audio_out and then reopen it with rate=0, bits=0, mode=0.
(see post_audio_rewire() in post.c)
CVS patchset: 6563
CVS date: 2004/05/18 02:01:39
|
|
If we change bits,rate or mode, we have to also provide our own status call.
CVS patchset: 6562
CVS date: 2004/05/17 21:47:01
|
|
CVS patchset: 6561
CVS date: 2004/05/17 21:28:06
|
|
CVS patchset: 6560
CVS date: 2004/05/17 16:19:05
|
|
Which frontends support the parameters api ?
CVS patchset: 6559
CVS date: 2004/05/17 16:12:48
|
|
It just causes the left and right channels to sound like they are coming from the center,
so one looses any good left/right effects.
CVS patchset: 6558
CVS date: 2004/05/17 15:10:20
|
|
The fix stopps dropping properly received data.
I realized the problem when switching channels in VDR. From time to time, it happend that switching took more than 50 ms (the timeout value used in _x_read_abort()), which caused the select() to timeout.
In the case where 'stream->demux_action_pending' was set, the already received data was dropped due to returning 0. This finally resulted in your demuxer to fail with DEMUX_END, as it couldn't read 6 bytes from the PES header.
So for the case, that there is some data available, it now takes twice the timeout (i. e. 100 ms), before a return 0 happens.
Some more information: as in rare cases switching channels could take even longer than 100 ms, I've also added a loop around _x_read_about() in my VDR input plugin, which returns 0 just after this state lasts for 5 seconds.
CVS patchset: 6557
CVS date: 2004/05/16 21:45:24
|
|
Under certain circumstances, the result caused an overflow in 'num_frames', so that it could get negative.
CVS patchset: 6556
CVS date: 2004/05/16 21:39:55
|
|
1) the 'size' of the A52 frame was calculated 'result' bytes to small.
2) a simpler "not jumbo detection": if 'size' was not changed, then it's not a jumbo and we're done.
CVS patchset: 6555
CVS date: 2004/05/16 21:35:16
|
|
CVS patchset: 6554
CVS date: 2004/05/16 19:32:36
|
|
0 for "raw" demuxers
10 for "normal" demuxers
CVS patchset: 6553
CVS date: 2004/05/16 18:01:26
|
|
CVS patchset: 6552
CVS date: 2004/05/16 17:58:16
|
|
xine-lib can now play 24bit .wav files, and output 24bits to the DAC if the sound card supports it.
CVS patchset: 6551
CVS date: 2004/05/16 16:27:56
|
|
CVS patchset: 6550
CVS date: 2004/05/16 16:23:09
|
|
e.g. changing // to /* */
CVS patchset: 6549
CVS date: 2004/05/16 15:13:34
|
|
Some updates so that upmixing 8,16,24 and floats works.
The output of the upmixer is currently 32bit floats, so it currently only works with alsa.
New audio plugins could be added to change it back to 16bit before reaching audio out so that it works with OSS etc.
We just need Frontend GUIs to catch up and support AUDIO_FILTER post plugins.
CVS patchset: 6548
CVS date: 2004/05/16 14:44:42
|
|
CVS patchset: 6547
CVS date: 2004/05/16 14:04:12
|
|
CVS patchset: 6546
CVS date: 2004/05/16 02:56:35
|
|
CVS patchset: 6545
CVS date: 2004/05/15 23:44:25
|
|
CVS patchset: 6544
CVS date: 2004/05/15 20:27:50
|
|
CVS patchset: 6543
CVS date: 2004/05/15 18:22:26
|
|
It can handle 16bit audio 2-channel to 5.1 channel upmix.
Currently, the .1 or LFE channel is not yet created.
CVS patchset: 6542
CVS date: 2004/05/15 15:32:47
|
|
developers have been informed.
CVS patchset: 6541
CVS date: 2004/05/15 14:23:15
|
|
CVS patchset: 6540
CVS date: 2004/05/15 09:58:29
|
|
edit removes it from the debian install file.
CVS patchset: 6539
CVS date: 2004/05/15 09:16:52
|
|
CVS patchset: 6538
CVS date: 2004/05/14 13:36:03
|
|
CVS patchset: 6537
CVS date: 2004/05/14 13:34:27
|
|
CVS patchset: 6536
CVS date: 2004/05/14 13:31:49
|
|
CVS patchset: 6535
CVS date: 2004/05/14 13:29:13
|
|
CVS patchset: 6534
CVS date: 2004/05/14 02:12:48
|
|
CVS patchset: 6533
CVS date: 2004/05/13 21:44:33
|
|
allows the code for handling this special case to actually be used
CVS patchset: 6532
CVS date: 2004/05/13 21:38:49
|
|
timestamp for all frames
CVS patchset: 6531
CVS date: 2004/05/13 21:17:09
|
|
the actual framerate
2) use the timestamp returned by the binary codec
CVS patchset: 6530
CVS date: 2004/05/13 21:15:33
|
|
CVS patchset: 6529
CVS date: 2004/05/13 19:39:07
|
|
CVS patchset: 6528
CVS date: 2004/05/13 01:56:10
|
|
CVS patchset: 6527
CVS date: 2004/05/12 20:11:22
|
|
CVS patchset: 6526
CVS date: 2004/05/12 19:07:33
|
|
CVS patchset: 6525
CVS date: 2004/05/12 17:50:09
|
|
CVS patchset: 6524
CVS date: 2004/05/12 16:21:41
|
|
is at 1 (otherwise, it will lie about the medium type)
CVS patchset: 6523
CVS date: 2004/05/12 11:19:13
|
|
Tested with mpeg1 and mpeg2 streams.
I've not checked if it's slower than libmpeg2...
Change the ffmpeg deocoder priority to test it.
CVS patchset: 6522
CVS date: 2004/05/12 07:41:43
|
|
CVS patchset: 6521
CVS date: 2004/05/11 22:21:44
|
|
quick fix for wma static noise.
(a more general solution should be employed in configure.ac)
CVS patchset: 6520
CVS date: 2004/05/11 21:31:55
|
|
CVS patchset: 6519
CVS date: 2004/05/11 21:21:39
|