No audio in recordings

  • Hi guys,


    I'm stuck and could do with some help.


    I am setting up VDR to be used with XBMC (pvr-testing) and all is working okay with the streamdev plugin. I can stream live TV with audio no problem.


    However if I record something with VDR I am getting no audio streams.


    Opening the file with mplayer I get the following:


    Playing /var/lib/video.00/Real_Life#3A_The_Great_Sperm_Race/2009-08-11.21.28.1-0.rec/00001.ts.
    TS file format detected.
    VIDEO H264(pid=250) NO AUDIO! NO SUBS (yet)! PROGRAM N. 132
    FPS seems to be: 50.000000
    open: No such file or directory
    [MGA] Couldn't open: /dev/mga_vid
    open: No such file or directory
    [MGA] Couldn't open: /dev/mga_vid
    [VO_TDFXFB] Can't open /dev/fb0: No such file or directory.
    [VO_3DFX] Unable to open /dev/3dfx.
    ==========================================================================
    Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
    Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
    ==========================================================================
    Audio: no sound


    I'm not sure how to debug this, would really appreciate some help in understanding what is going wrong.


    If it makes a difference I am in NZ using dvb-t freeview which uses LATM AAC - xbmc is compiled to decode this and it works fine with live tv and with mythtv.


    TIA.


    Alex

  • Hi


    I can't help with a solution, but I would like to revive this rather old thread as it may affect a growing number of users/countries...


    I think the problem is missing native support for LATM AAC decoding/demuxing in vdr and possibly in the ffmpeg libraries that it relies on. Apparently streamdev server passes the raw mpeg4+aac stream on without modification, which allows external apps like XBMC to decode the audio themselves.
    VDR itself though does not appear to understand the format and simply ignores it all the way down to the channel audio PID and thus in direct viewing and recordings.


    Here in Denmark we have a combination of MPEG-2 and MPEG-4 DVB-T channels where the latter use LATM HE-AAC audio. With ubuntu 9.10 and VDR 1.7.10 the MPEG-2 channels just work whereas the MPEG-4 ones lack sound when recorded or played directly with e.g. the xine plugins. When passed through the streamdev plugin they can be played fine with audio in e.g. XBMC just like your experience.
    However, the VDR plugin for XBMC is not yet stable, so this is not really a solution in a living room setup.


    There's a short thread on a Danish news group touching the subject but with no native VDR solution[1] - use the translate link at the top to get a weird but okay'ish translation.


    I expect the same to be the case in all the countries where LATM AAC sound is used. AFAICT this includes at least NZ, DK, NO and PT[2]. However, I do not think it is used much in Germany yet, where most VDR development takes place, so there probably isn't a very big incentive to add the feature.


    Perhaps someone with better knowledge about the VDR code internals and external dependencies can elaborate on the issue and any development plans?


    Cheers, Jonas


    [1] http://groups.google.com/group…a7a11a/fa2e4b707c9530b8?#
    [2] http://www.mythtv.org/wiki/HE-AAC

  • Great, it looks like somebody beat me and the solution entered the recent 1.7.15 release!


    I'll give it a go ASAP.


    Edit:
    vdr-1.7.15 improves the situation a lot, but I still can't get the final bits right.
    Now VDR does handle the audio part of the stream including recordings and all, so the problem of the original poster may be solved. You probably have to rescan channels to get the program IDs right.


    I still can't get the LATM AAC audio working using the xine frontends, though.
    The audio works if I connect e.g. vlc to the raw xineliboutput stream on localhost:37890, so it is probably a decoding problem in the xine/ffmpeg player. Recordings now play with sound in XBMC with the vnsiserver plugin, too.


    I found a couple of ffmpeg tickets that indicate missing support for this particular audio encapsulation and encoding:
    https://roundup.ffmpeg.org/issue1891
    https://roundup.ffmpeg.org/issue244
    so maybe it is just a matter of waiting for full ffmpeg support.


    Cheers, Jonas