xine-devel — internal xine developers' list

Re: [xine-devel] Fix for visible OSD corruption

[Torsten J. <t....@gm...>]

 > When C-i is used to view stream information via OSD then often
 > corruption appears after the "Audio:" prefix.

Made a better fix (I think). Thanks.

Torsten

Re: [xine-devel] subtitle and transport stream patches

[Torsten J. <t....@gm...>]

Thanks for your commitment :-)

 > This patch corrects the very poor synchronization between transport
 > streams and external subtitles. It is all very well using bit rate to
 > estimate a seek amount but it is not a good idea to feed such a coarse
 > estimate into a subtitle stream which is trying to synchronize its output
 > when there already exists a highly accurate pts.

Not applied because it breaks many TV streams that jump midway through.
This is the reason for that bitrate estimation thing.
Made some compromise patch instead, try that one.

 > This patch corrects the disconnect between the independent
 > subtitle stream and the selection of the subtitle channel.
 > It also undoes the hack which would mask the problem by
 > disabling the entire osd.

 > Unfortunately there is also a gap between the creation of the
 > subtitle stream and it becoming a slaved stream so there is an
 > additional re-invocation of the subtitle channel selection (this
 > becomes evident when the -u command-line option is used).

Applied for now, please test for possible regressions.

 > Given the correction for control of the slaved subtitle stream
 > it becomes necessary for text subtitles to properly implement
 > channel matching. In particular, the subtitle stream must continue
 > to synchronize with the video decoder and therefore must pause
 > properly even if the subtitle channel does not currently match
 > what the user wants.

Applied.

 > The problem with a construct such as 'sscanf(s, "%d.%d", &a1, &a2)'
 > is that it can produce erroneous results. For example, given input
 > such as "2.1" or "2.01" or "2.001" then a2 will always be 1. So one
 > cannot automatically assume it mean 1/10 or 1/100 or 1/1000.
 > This is the very reason why sscanf has a "%f" conversion.

Applied.

Torsten

[xine-devel] Fix for visible OSD corruption

[JW <kv...@za...>]

When C-i is used to view stream information via OSD then often 
corruption appears after the "Audio:" prefix. Somewhat surprised that 
nobody has seen this or ever bothered to fixed it, but it is caused by 
the commandeering of caller's buffer to communicate with demuxer or 
input, and the failure to restore the zapped null character.

That awful kludge merits another kludge to compensate.

A patch is attached.

:JW

[xine-devel] subtitle and transport stream patches

[JW <kv...@za...>]

I have attached a few patches to fix some problems mostly relating to
subtitles and transport streams. There is a patch to account for the
disconnect between the main stream and the separate subtitle slave
stream. And another patch to greatly improve transport stream seek and
synchronization.

Each patch contains relevant comments.

:JW

Re: [xine-devel] [patch] xine-ui snapshot build error with lirc

[Petri H. <phi...@us...>]

to, 2020-07-02 kello 23:20 +0200, Xavier Bachelot kirjoitti:
> Hi,
> 
> When building a snapshot of xine-ui (commit 301adf) with lirc
> support 
> enabled, the builds error out with the following :
> 
> lirc.c: In function 'lirc_start':
> lirc.c:149:3: error: implicit declaration of function 'fcntl' 
> [-Werror=implicit-function-declaration]
>    149 |   fcntl(lirc.fd, F_SETFD, FD_CLOEXEC);
>        |   ^~~~~
> lirc.c:149:3: warning: nested extern declaration of 'fcntl' 
> [-Wnested-externs]
> lirc.c:149:18: error: 'F_SETFD' undeclared (first use in this
> function)
>    149 |   fcntl(lirc.fd, F_SETFD, FD_CLOEXEC);
>        |                  ^~~~~~~
> lirc.c:149:18: note: each undeclared identifier is reported only
> once 
> for each function it appears in
> lirc.c:149:27: error: 'FD_CLOEXEC' undeclared (first use in this
> function)
>    149 |   fcntl(lirc.fd, F_SETFD, FD_CLOEXEC);
>        |                           ^~~~~~~~~~
> lirc.c:150:18: error: 'F_SETOWN' undeclared (first use in this
> function)
>    150 |   fcntl(lirc.fd, F_SETOWN, getpid());
>        |                  ^~~~~~~~
> lirc.c:151:26: error: 'F_GETFL' undeclared (first use in this
> function)
>    151 |   flags = fcntl(lirc.fd, F_GETFL, 0);
>        |                          ^~~~~~~
> lirc.c:153:20: error: 'F_SETFL' undeclared (first use in this
> function)
>    153 |     fcntl(lirc.fd, F_SETFL, flags|O_NONBLOCK);
>        |                    ^~~~~~~
> lirc.c:153:35: error: 'O_NONBLOCK' undeclared (first use in this
> function)
>    153 |     fcntl(lirc.fd, F_SETFL, flags|O_NONBLOCK);
>        |                                   ^~~~~~~~~~
> cc1: some warnings being treated as errors
> make[4]: *** [Makefile:934: lirc.o] Error 1
> 
> 
> Patch attached.

Applied. Thanks!

> Regards,
> Xavier
> _______________________________________________
> xine-devel mailing list
> xin...@li...
> https://lists.sourceforge.net/lists/listinfo/xine-devel

[xine-devel] [patch] xine-ui snapshot build error with lirc

[Xavier B. <xa...@ba...>]

Hi,

When building a snapshot of xine-ui (commit 301adf) with lirc support 
enabled, the builds error out with the following :

lirc.c: In function 'lirc_start':
lirc.c:149:3: error: implicit declaration of function 'fcntl' 
[-Werror=implicit-function-declaration]
   149 |   fcntl(lirc.fd, F_SETFD, FD_CLOEXEC);
       |   ^~~~~
lirc.c:149:3: warning: nested extern declaration of 'fcntl' 
[-Wnested-externs]
lirc.c:149:18: error: 'F_SETFD' undeclared (first use in this function)
   149 |   fcntl(lirc.fd, F_SETFD, FD_CLOEXEC);
       |                  ^~~~~~~
lirc.c:149:18: note: each undeclared identifier is reported only once 
for each function it appears in
lirc.c:149:27: error: 'FD_CLOEXEC' undeclared (first use in this function)
   149 |   fcntl(lirc.fd, F_SETFD, FD_CLOEXEC);
       |                           ^~~~~~~~~~
lirc.c:150:18: error: 'F_SETOWN' undeclared (first use in this function)
   150 |   fcntl(lirc.fd, F_SETOWN, getpid());
       |                  ^~~~~~~~
lirc.c:151:26: error: 'F_GETFL' undeclared (first use in this function)
   151 |   flags = fcntl(lirc.fd, F_GETFL, 0);
       |                          ^~~~~~~
lirc.c:153:20: error: 'F_SETFL' undeclared (first use in this function)
   153 |     fcntl(lirc.fd, F_SETFL, flags|O_NONBLOCK);
       |                    ^~~~~~~
lirc.c:153:35: error: 'O_NONBLOCK' undeclared (first use in this function)
   153 |     fcntl(lirc.fd, F_SETFL, flags|O_NONBLOCK);
       |                                   ^~~~~~~~~~
cc1: some warnings being treated as errors
make[4]: *** [Makefile:934: lirc.o] Error 1


Patch attached.

Regards,
Xavier

Re: [xine-devel] Xine-lib release?

[Torsten J. <t....@gm...>]

Hello Brad,

> It has been awhile since the last xine-lib release. I see you guys
> have made a lot of commits
> since then. Any interest in rolling a new release?
>
Theoretically, yes.

Would be nice to

a) get a notice whether Opus and EAC3 audio fixes really work now, and

b) find a way of build testing with your BSD before an official release.

Torsten

Re: [xine-devel] Submit a bug report

[Torsten J. <t....@gm...>]

Hii Michael,

> I am quite happy with xine, but lately running into problems with
> videos that use eac3 or opus audio streams. They play with mplayer and
> vlc, but xine in case of eac3 generates "not enough data to encode"
> messages when playing eac3 streams (producing sound which is
> interrupted by ~0.5s of silence every second or so.
Should be fixed now.
> opus streams are simply not recognized (no plugin available to handle
> 'Opus Audio').

Sounds like an issue I fixed before.

Now, try to build current xine-lib from hg.

You will need binutils, gcc, make, automake, autoconf, perl, bison, and
the relevant "-devel" packages (unless you have built such pack yourself
already). Then, say

$ ./autogen.sh <foo>

instead of the usual ./configure, and

$ make

$ sudo make install


> I am using Fedora 32, xine-ui-0.99-12-2, xine-lib-1.2.10-3, and
> xine-lib-extras-1.2.10-3 - and are happy to provide some test cases if
> you think this will help - provided that I can find a way to submit it ;-)
I can only build binaries for OpenSuSe, and I probably dont use the same
ffmpeg version as you (they wear out major versions very quickly...).

Torsten

[xine-devel] Problem resolved.

[Александр К. <a.g...@gm...>]

Hi Torsten and Petri. Thank you very much for the tip. Without you, I would
never know how to fix it. You are absolutely right. Сancel a patch:

       this-> props [property] .value = this-> sc.output_yoffset;
       break;
     case VO_PROP_MAX_NUM_FRAMES:
- # if 0 / * WTF !!!! * /
       if (! this-> guarded_render)
         this-> props [property] .value = RENDER_SURFACES;
       else
         this-> props [property] .value = 2;
- # else
- this-> props [property] .value = RENDER_SURFACES;
- # endif
       break;
   }

solves my problem. Otherwise, I could not use turning off guarded render
(as received segfault) in a project https://github.com/ag1455/OpenPLi-PC
started by cougar_enigma more than 10 years ago. I'm just trying to keep it
working and improve. You can try it without a dvb card to receive IPTV and
play files. Even watch and play 4k now works great with integrated Intel
GPU (610) in my last commit. Load 40...50% on Intel Celeron G3930.

Thank you for your wonderful work and I hope that you will help with tips
in the future, as I understand that I am just a copypaster. :)

Re: [xine-devel] Can't play file

[Petri H. <phi...@us...>]

Hello,

ke, 2020-06-03 kello 23:36 +0200, Torsten Jager kirjoitti:
> Hi Alex,
> 
>  > How can I play this file using vaapi with 'video.driver:vaapi' and
>  > 'video.processing.ffmpeg_enable_vaapi:1'?
>  > Why are key frames not read in Xine and the video jerking?
> 
>  > All packages from official Ubuntu repositories. CPU Intel G3220.
> 
> Lets try an extended bug report first.
> 
>   - The bug can be reproduced with VDPAU wrapper (the only VAAPI
> device I got).
>   - Frame timestamps (--verbose=3) look OK.
>   - Applies to many h264 videos.
>   - Frames jump back and forth.
>   - Sometimes, screen flashes bright green before the actual image.
>   - Both is unaffected by playback speed. It happens even in single
> step
> mode.
>   - GLX rendering shows less jumping.
>   - Turning off guarded render fixes the issue here on my sys.
>
> 2 additional, unrelated video_out_vaapi bugs:
> 
>   - Turning on GLX on the fly segfaults. Maybe this setting should
> not be live changeable.

Yes. Also, OpenGL could be removed from vaapi plugin, and vaapi made
loadable sub-module so that it can be used by OpenGL2 video out. OpenGL
code is more or less duplicated in both plugins. I've been thinking to
do this for a long time, it could "fix" vaapi with Wayland.
(maintaining three different OpenGL plugins for N windowing systems
seems unnecessarily...).

>   - No redraw_needed notification when video window gets uncovered by
> another
>     window (does work with opengl2, though).
> 
> In other words: what do you think, Petri?

Sounds like frame recycling issue. I think I've seen similar issues ~
long time ago when there are frame drops (-> vaapi surfaces stay
"locked" in frames when frames are dropped in vout). But I don't
remember if it was guarded_mode or not.

I can't test this currently (vaapi doesnt work with XWayland), but if
it is only in guarded_mode, it could be triggered by commit
13100:d1659be4d7a1.

Limiting frames, something like

       if(!this->guarded_render)
         this->props[property].value = RENDER_SURFACES;
       else
         this->props[property].value = RENDER_SURFACES/2;

could make it disappear.

>
> Torsten
> 
> 
> 
> 
> _______________________________________________
> xine-devel mailing list
> xin...@li...
> https://lists.sourceforge.net/lists/listinfo/xine-devel

Re: [xine-devel] Can't play file

[Torsten J. <t....@gm...>]

Hi Alex,

 > How can I play this file using vaapi with 'video.driver:vaapi' and
 > 'video.processing.ffmpeg_enable_vaapi:1'?
 > Why are key frames not read in Xine and the video jerking?

 > All packages from official Ubuntu repositories. CPU Intel G3220.

Lets try an extended bug report first.

  - The bug can be reproduced with VDPAU wrapper (the only VAAPI device
I got).
  - Frame timestamps (--verbose=3) look OK.
  - Applies to many h264 videos.
  - Frames jump back and forth.
  - Sometimes, screen flashes bright green before the actual image.
  - Both is unaffected by playback speed. It happens even in single step
mode.
  - GLX rendering shows less jumping.
  - Turning off guarded render fixes the issue here on my sys.

2 additional, unrelated video_out_vaapi bugs:

  - Turning on GLX on the fly segfaults. Maybe this setting should not
be live
    changeable.
  - No redraw_needed notification when video window gets uncovered by
another
    window (does work with opengl2, though).

In other words: what do you think, Petri?

Torsten

[xine-devel] Can't play file

[Александр К. <a.g...@gm...>]

How can I play this file using vaapi with 'video.driver:vaapi' and
'video.processing.ffmpeg_enable_vaapi:1'?
https://drive.google.com/file/d/1xkykYo-fU6l_M_Ie0S0kNF_97joKSYsB/view?usp=sharing
Why are key frames not read in Xine and the video jerking?
It plays in VLC with hardware acceleration normally.
All packages from official Ubuntu repositories. CPU Intel G3220.

Re: [xine-devel] No passthrough for Dolby TrueHD

[Torsten J. <t....@gm...>]

Hi Mikko,

 > I'm using HDMI (1.3a I think) and not an actual S/PDIF link.
 >  But even with HDMI the compressed data gets wrapped in an S/PDIF header.

Right.

 > It is my understanding that the header is not strictly required and
 > receivers can autodetect supported compressed formats, but an unsupported
 > format would get played as PCM audio.

No, as far as I found so far. There needs to be sent a correct object type.
Official specs are for registered paying customers only. But I found an
indirect source that lists the type IDs for MPEG layers 1 ~ 4, A52, DTS,
DTS-HD - and - 3 incompatible versions of TrueHD :-/
This seems to be trickier than I thought.

 > Maybe the presence of the header can serve as a hint that it's not PCM
 > and the receiver can choose to be silent instead?

True for traditional one way SPDIF link. For HDMI, the Enhanced Display
IDentification (EDID) also lists the supported audio codecs. Unortunately,
there seems to be no ALSA call for it.

 > In my xine config the passthrough audio device is configured correctly
 > to use the HDMI output, but since the ffmpeg plugin does not support
 > passthrough it picks the 5.1 surround device instead.

Yes. For now, I keep it like that.

 > I can configure it to output decoded 5.1 sound to HDMI as well,

Please do so, but _not_ using the same "iecxxx:" string. Try to find the
regular "hdmi:" for it. On my brothers Laptop, a TV set on the external
HDMI is "hdmi:CARD=NVidia,DEV=1".

 > though all of the movies with a TrueHD audio track also have alternative
 > formats which can be passed through.

When TrueHD came out, first BluRay spec and quite a few hardware players
already had spammed the streets. This is why TrueHD is _required_ to come
with the same track again in plain A52 or so. This is bad for total bitrate.
DTS-HD takes a different uproach. It also brings in a lossy compatibility
part, but then only adds the _difference_ between the original and the
decompressed lossy audio, to save space there.

 > This is what I want to do, so the question is what it would take to
 > implement the support?  I'm not sure if the ffmpeg plugin is the best
 > place for it due to its wide format support;

I am thining about a new, separate, general "passthrough" plugin.


[Unrelated] In recent weeks, I patched demux_ts as well. I can only test
the standard format (DVB, HLS) but not hdmv (BluRay).

Please try new HG with xine --verbose=2, and send me the lines starting with
"demux_ts:" and "audio_alsa_out:".

Torsten

Re: [xine-devel] No passthrough for Dolby TrueHD

[Mikko R. <td...@td...>]

On 18.5.2020 21.29, Torsten Jager wrote:
> Bad news: An actual SPDIF link (RCA or TOSLINK) does _not_ support
> TrueHD, because the interface is too slow for the high bitrates that will
> appear at least temporarily there. For the same reason, software decoded
> 5.1 audio cannot be transferred this way.

Right, I could have been clearer with this.  I'm using HDMI (1.3a I 
think) and not an actual S/PDIF link.  But even with HDMI the compressed 
data gets wrapped in an S/PDIF header.  It is my understanding that the 
header is not strictly required and receivers can autodetect supported 
compressed formats, but an unsupported format would get played as PCM 
audio.  Maybe the presence of the header can serve as a hint that it's 
not PCM and the receiver can choose to be silent instead?

In my xine config the passthrough audio device is configured correctly 
to use the HDMI output, but since the ffmpeg plugin does not support 
passthrough it picks the 5.1 surround device instead.  I can configure 
it to output decoded 5.1 sound to HDMI as well, though all of the movies 
with a TrueHD audio track also have alternative formats which can be 
passed through.

> b) pass the compressed TrueHD stream to an ALSA HDMI dev.
>     This is not (yet?) supported by xine.

This is what I want to do, so the question is what it would take to 
implement the support?  I'm not sure if the ffmpeg plugin is the best 
place for it due to its wide format support; but if there's no dedicated 
TrueHD decoder library, it would seem stupid to duplicate the ffmpeg 
code into a separate plugin just for passthrough.  So maybe it would be 
best after all for the ffmpeg plugin to check if the format is among the 
ones supported for passthrough.

-- 
Mikko

Re: [xine-devel] No passthrough for Dolby TrueHD

[Torsten J. <t....@gm...>]

Hi Mikko,

please excuse my late answer. I had to learn about all this myself first.

Bad news: An actual SPDIF link (RCA or TOSLINK) does _not_ support
TrueHD, because the interface is too slow for the high bitrates that will
appear at least temporarily there. For the same reason, software decoded
5.1 audio cannot be transferred this way.

What you can do is:

a) software decode (eg. ffmpeg), and pass the result to your AV receiver
    by either 3/6 analouge wires, or by HDMI 1.3 or higher. Type

    $ aplay -L

    to get a list of valid ALSA devices that can go into xine config
    audio.device.alsa_surround51_device.
    On my main sys, suitable devs are

    default:CARD=Live
        SB Live! Value [CT4670], ADC Capture/Standard PCM Playback
        Default Audio Device
    surround51:CARD=Live,DEV=0
        SB Live! Value [CT4670], ADC Capture/Standard PCM Playback
        5.1 Surround output to Front, Center, Rear and Subwoofer speakers

    You can also try to prefix a plain stereo dev by "plughw:" which
    enables auto downmix.

b) pass the compressed TrueHD stream to an ALSA HDMI dev.
    This is not (yet?) supported by xine.

Beside that, I am working on a less ambigous set of xine config entries.
That will allow software downmixing at least.

Torsten

Re: [xine-devel] Playing certain downloaded youtube video files with audio works with vlc-player, but not with xine

[Xavier B. <xa...@ba...>]

On 4/24/20 8:25 PM, Ken Moffat via xine-devel wrote:
> On Fri, Apr 24, 2020 at 02:19:51PM +0000, Tirili via xine-devel wrote:
>> Using version 2020.03.24 of youtube-dl (see https://youtube-dl.org/) and running
>>
>> python youtube-dl https://www.youtube.com/watch?v=oDAFPDqQ7Yk
>>
>> to download a video (in this case it is a small example), an .mkv-file is created.
>> When you try to run this file using the vlc-player, everything works including audio,
>> but when you run it with xine on the same machine, you get the error message
>> "The stream '(filename)' uses an unsupported codec:
>> (null)Audio Codec: Opus Audio (ffmpeg)(0x0)
>> Sart playback anyway?"
>> with the two options "Yes" and "No".
>> When you click "yes", the file is played without sound.
>>
>> This bug could be reproduced by two other users in the freenode channel #xine,
>> so it seems to be independent of the user's system setup.
>>
>> I have already sent this bug to the xine-bugs mailing list, but I was told, that it might not be used anymore.
> 
> Youtube, and youtube-dl, have used opus for a while now.  Sounds
> like a distro problem, ffmpeg should be built against libopus, which
> comes from https://archive.mozilla.org/pub/opus/ - if you are
> building ffmpeg yourself, ensure that libopus is mentioned as an
> external library by the configure output, and similarly in Enabled
> decoders.  Otherwise, raise a ticket at your distro.
> 

I'm one of the 2 that tested the video after Tirili's request on IRC.
I'm testing on Fedora with xine-ui 0.99.12, xine-lib 1.2.10 and ffmpeg 
4.4.2 from RPM Fusion and no audio.

xine --verbose says :

ffmpeg_audio_dec: couldn't open decoder
audio_decoder: no plugin available to handle 'Opus Audio'

ffplay is playing the video with sound, so it seems to support the fact 
that the ffmpeg build is not the issue.

That is confirmed by the following :

$ ffplay -formats | grep -i opus
ffplay version 4.2.2 Copyright (c) 2003-2019 the FFmpeg developers
   built with gcc 10 (GCC)
   configuration: --prefix=/usr --bindir=/usr/bin 
--datadir=/usr/share/ffmpeg --docdir=/usr/share/doc/ffmpeg 
--incdir=/usr/include/ffmpeg --libdir=/usr/lib64 --mandir=/usr/share/man 
--arch=x86_64 --optflags='-O2 -g -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions 
-fstack-protector-strong -grecord-gcc-switches 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 
--extra-ldflags='-Wl,-z,relro -Wl,--as-needed -Wl,-z,now 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld ' --extra-cflags=' ' 
--enable-libopencore-amrnb --enable-libopencore-amrwb 
--enable-libvo-amrwbenc --enable-version3 --enable-bzlib 
--disable-crystalhd --enable-fontconfig --enable-frei0r --enable-gcrypt 
--enable-gnutls --enable-ladspa --enable-libaom --enable-libdav1d 
--enable-libass --enable-libbluray --enable-libcdio --enable-libdrm 
--enable-libjack --enable-libfreetype --enable-libfribidi 
--enable-libgsm --enable-libmp3lame --enable-nvenc --enable-openal 
--enable-opencl --enable-opengl --enable-libopenjpeg --enable-libopus 
--enable-libpulse --enable-librsvg --enable-libsrt --enable-libsoxr 
--enable-libspeex --enable-libssh --enable-libtheora --enable-libvorbis 
--enable-libv4l2 --enable-libvidstab --enable-libvmaf --enable-libvpx 
--enable-libx264 --enable-libx265 --enable-libxvid --enable-libzimg 
--enable-libzvbi --enable-avfilter --enable-avresample --enable-postproc 
--enable-pthreads --disable-static --enable-shared --enable-gpl 
--disable-debug --disable-stripping --shlibdir=/usr/lib64 
--enable-libmfx --enable-runtime-cpudetect
   libavutil      56. 31.100 / 56. 31.100
   libavcodec     58. 54.100 / 58. 54.100
   libavformat    58. 29.100 / 58. 29.100
   libavdevice    58.  8.100 / 58.  8.100
   libavfilter     7. 57.100 /  7. 57.100
   libavresample   4.  0.  0 /  4.  0.  0
   libswscale      5.  5.100 /  5.  5.100
   libswresample   3.  5.100 /  3.  5.100
   libpostproc    55.  5.100 / 55.  5.100
   E opus            Ogg Opus

I'm probably missing something, but I don't know what...
Any advice to debug further ?

Regards,
Xavier

[xine-devel] No passthrough for Dolby TrueHD

[Mikko R. <td...@td...>]

Hi,

I have a few BluRay rips with Dolby TrueHD audio tracks.  I noticed that 
Xine will refuse to play such track, and after some troubleshooting 
found out that it's trying to open an ALSA device called 
plug:surround51:0.  This is the default setting but it's invalid on my 
systems since I have only ever listened to surround sound through my 
home theater A/V receiver and have always used digital passthrough with 
it.  It looks like TrueHD gets handled by the ffmpeg_audio_dec plugin 
which does not support passthrough.

Would this be possible to implement?  I'm at a bit of a loss about where 
to start.  The ffmpeg plugin handles a whole lot of different formats, 
not all of which are appropriate for passthrough.  I also don't know how 
to wrap the TrueHD data; The AC3 and DTS plugins wrap the data with an 
S/PDIF header, but I couldn't find the appropriate values to use for TrueHD.

-- 
Mikko

Re: [xine-devel] Playing certain downloaded youtube video files with audio works with vlc-player, but not with xine

[Carlos E. R. <car...@op...>]

On 24/04/2020 16.19, Tirili via xine-devel wrote:
> Using version 2020.03.24 of youtube-dl (see https://youtube-dl.org/) and 
> running
> 
> python youtube-dl https://www.youtube.com/watch?v=oDAFPDqQ7Yk
> 
> to download a video (in this case it is a small example), an .mkv-file 
> is created.
> When you try to run this file using the vlc-player, everything works 
> including audio,
> but when you run it with xine on the same machine, you get the error message
> "The stream '(filename)' uses an unsupported codec:
> (null)Audio Codec: Opus Audio (ffmpeg)(0x0)
> Sart playback anyway?"
> with the two options "Yes" and "No".
> When you click "yes", the file is played without sound.
> 
> This bug could be reproduced by two other users in the freenode channel 
> #xine,
> so it seems to be independent of the user's system setup.

Plays fine here.

Mediainfo says audio type is:


Audio
ID                                       : 2
Format                                   : Opus
Codec ID                                 : A_OPUS
Duration                                 : 1 min 0 s
Channel(s)                               : 2 channels
Channel positions                        : Front: L R
Sampling rate                            : 48.0 kHz
Bit depth                                : 32 bits
Compression mode                         : Lossy
Language                                 : English
Default                                  : Yes
Forced                                   : No

I am using openSUSE Leap 15.1


cer@Telcontar:~> cat ~/.config/youtube-dl.conf
# youtube-dl config - see http://rg3.github.io/youtube-dl/documentation.html
#
# Template I want to use
#
--output '%(uploader)s-%(uploader_id)s-%(title)s-%(id)s.%(ext)s'
cer@Telcontar:~> 


The available types today are:

cer@Telcontar:~/tmp/xine> youtube-dl --list-formats https://www.youtube.com/watch?v=oDAFPDqQ7Yk
[youtube] oDAFPDqQ7Yk: Downloading webpage
[info] Available formats for oDAFPDqQ7Yk:
format code  extension  resolution note
249          webm       audio only tiny   65k , opus @ 50k (48000Hz), 444.55KiB
250          webm       audio only tiny   84k , opus @ 70k (48000Hz), 554.56KiB
140          m4a        audio only tiny  134k , m4a_dash container, mp4a.40.2@128k (44100Hz), 934.80KiB
251          webm       audio only tiny  173k , opus @160k (48000Hz), 1.01MiB
278          webm       256x144    144p   99k , webm container, vp9, 25fps, video only, 707.01KiB
160          mp4        256x144    144p  114k , avc1.4d400c, 25fps, video only, 817.62KiB
242          webm       426x240    240p  223k , vp9, 25fps, video only, 1.52MiB
133          mp4        426x240    240p  250k , avc1.4d4015, 25fps, video only, 1.76MiB
243          webm       640x360    360p  400k , vp9, 25fps, video only, 2.71MiB
134          mp4        640x360    360p  591k , avc1.4d401e, 25fps, video only, 3.73MiB
18           mp4        640x360    360p  625k , avc1.42001E, mp4a.40.2@ 96k (44100Hz), 4.48MiB (best)
cer@Telcontar:~/tmp/xine> 

It has used the "18".



-- 
Cheers / Saludos,

		Carlos E. R.
		(from 15.1 x86_64 at Telcontar)

Re: [xine-devel] Playing certain downloaded youtube video files with audio works with vlc-player, but not with xine

[Dale M. <an...@an...>]

On 25/4/20 4:25 am, Ken Moffat via xine-devel wrote:
> On Fri, Apr 24, 2020 at 02:19:51PM +0000, Tirili via xine-devel wrote:
>> Using version 2020.03.24 of youtube-dl (see https://youtube-dl.org/) and running
>>
>> python youtube-dl https://www.youtube.com/watch?v=oDAFPDqQ7Yk
>>
>> to download a video (in this case it is a small example), an .mkv-file is created.
>> When you try to run this file using the vlc-player, everything works including audio,
>> but when you run it with xine on the same machine, you get the error message
>> "The stream '(filename)' uses an unsupported codec:
>> (null)Audio Codec: Opus Audio (ffmpeg)(0x0)
>> Sart playback anyway?"
>> with the two options "Yes" and "No".
>> When you click "yes", the file is played without sound.
>>
>> This bug could be reproduced by two other users in the freenode channel #xine,
>> so it seems to be independent of the user's system setup.
>>
>> I have already sent this bug to the xine-bugs mailing list, but I was told, that it might not be used anymore.
> 
> Youtube, and youtube-dl, have used opus for a while now.  Sounds
> like a distro problem, ffmpeg should be built against libopus, which
> comes from https://archive.mozilla.org/pub/opus/ - if you are
> building ffmpeg yourself, ensure that libopus is mentioned as an
> external library by the configure output, and similarly in Enabled
> decoders.  Otherwise, raise a ticket at your distro.
> 
> I build my own systems, and I've been building opus for youtube-dl
> since November 2016, but in July 2017 I moved it to before ffmpeg.
> 
> But what youtube chooses to give you seems to vary over time, I
> think webm is now much more common there than it used to be.
> 
> ĸen
> 

As a workaround, you might find it easier to use:

youtube-dl --list-formats <URL>

and then:

youtube-dl --format <CODE> <URL>

to tell it to download a format that isn't opus.

Re: [xine-devel] Playing certain downloaded youtube video files with audio works with vlc-player, but not with xine

[Ken M. <zar...@nt...>]

On Fri, Apr 24, 2020 at 02:19:51PM +0000, Tirili via xine-devel wrote:
> Using version 2020.03.24 of youtube-dl (see https://youtube-dl.org/) and running
> 
> python youtube-dl https://www.youtube.com/watch?v=oDAFPDqQ7Yk
> 
> to download a video (in this case it is a small example), an .mkv-file is created.
> When you try to run this file using the vlc-player, everything works including audio,
> but when you run it with xine on the same machine, you get the error message
> "The stream '(filename)' uses an unsupported codec:
> (null)Audio Codec: Opus Audio (ffmpeg)(0x0)
> Sart playback anyway?"
> with the two options "Yes" and "No".
> When you click "yes", the file is played without sound.
> 
> This bug could be reproduced by two other users in the freenode channel #xine,
> so it seems to be independent of the user's system setup.
> 
> I have already sent this bug to the xine-bugs mailing list, but I was told, that it might not be used anymore.

Youtube, and youtube-dl, have used opus for a while now.  Sounds
like a distro problem, ffmpeg should be built against libopus, which
comes from https://archive.mozilla.org/pub/opus/ - if you are
building ffmpeg yourself, ensure that libopus is mentioned as an
external library by the configure output, and similarly in Enabled
decoders.  Otherwise, raise a ticket at your distro.

I build my own systems, and I've been building opus for youtube-dl
since November 2016, but in July 2017 I moved it to before ffmpeg.

But what youtube chooses to give you seems to vary over time, I
think webm is now much more common there than it used to be.

ĸen
-- 
He could send for Ptraci, his favourite handmaiden. She was special.
Her singing always cheered him up. Life seemed so much brighter when
she stopped.   -- Pyramids

[xine-devel] Playing certain downloaded youtube video files with audio works with vlc-player, but not with xine

[Tirili <Ti...@pr...>]

Using version 2020.03.24 of youtube-dl (see https://youtube-dl.org/) and running

python youtube-dl https://www.youtube.com/watch?v=oDAFPDqQ7Yk

to download a video (in this case it is a small example), an .mkv-file is created.
When you try to run this file using the vlc-player, everything works including audio,
but when you run it with xine on the same machine, you get the error message
"The stream '(filename)' uses an unsupported codec:
(null)Audio Codec: Opus Audio (ffmpeg)(0x0)
Sart playback anyway?"
with the two options "Yes" and "No".
When you click "yes", the file is played without sound.

This bug could be reproduced by two other users in the freenode channel #xine,
so it seems to be independent of the user's system setup.

I have already sent this bug to the xine-bugs mailing list, but I was told, that it might not be used anymore.

Re: [xine-devel] xine-project.org gone, redirecting to sourceforge

[Dale M. <an...@an...>]

HI,

I have a server which may be able to host some stuff for the project.
I'd want to know some more details. Please feel free to contact me
directly to discuss off-list :)

Dale


On 15/12/19 12:41 am, Petri Hintukainen wrote:
> Hello,
> 
> to, 2019-12-12 kello 15:33 +0100, Xavier Bachelot kirjoitti:
>> Hi,
>>
>> As in subject, https://xine-project.org redirects to sourceforge.
>> Was that expected or is there something weird going on ?
> 
> I was told there has been a major hardware failure, and the virtual
> machine is unbootable. There should be backups, but we're looking for
> alternatives without the need to maintain the server.
> 
>> As a side effect, the URLs I had for all the xine-ui skins are now 
>> invalid. Fortunately, I still have the tarballs locally.
> 
> Ok, I didn't realize/remember skins are downloaded from there too.
> 
> As you know, bugzilla has been broken for quite long time, so I didn't
> think this was very urgent issue.
> 
> 
> - Petri
> 
> 
> 
> 
> _______________________________________________
> xine-devel mailing list
> xin...@li...
> https://lists.sourceforge.net/lists/listinfo/xine-devel
> 

Re: [xine-devel] xine-lib-1.2.10 and xine-ui-0.99.12 releases

[Petri H. <phi...@gm...>]

Hello,

Both releases are now available at 
https://sourceforge.net/projects/xine/files/

- Petri

Re: [xine-devel] xine-project.org gone, redirecting to sourceforge

[Petri H. <phi...@gm...>]

Hello,

to, 2019-12-12 kello 15:33 +0100, Xavier Bachelot kirjoitti:
> Hi,
> 
> As in subject, https://xine-project.org redirects to sourceforge.
> Was that expected or is there something weird going on ?

I was told there has been a major hardware failure, and the virtual
machine is unbootable. There should be backups, but we're looking for
alternatives without the need to maintain the server.

> As a side effect, the URLs I had for all the xine-ui skins are now 
> invalid. Fortunately, I still have the tarballs locally.

Ok, I didn't realize/remember skins are downloaded from there too.

As you know, bugzilla has been broken for quite long time, so I didn't
think this was very urgent issue.


- Petri

[xine-devel] xine-project.org gone, redirecting to sourceforge

[Xavier B. <xa...@ba...>]

Hi,

As in subject, https://xine-project.org redirects to sourceforge.
Was that expected or is there something weird going on ?

As a side effect, the URLs I had for all the xine-ui skins are now 
invalid. Fortunately, I still have the tarballs locally.

Regards,
Xavier