VideoHelp Forum

Our website is made possible by displaying online advertisements to our visitors. Consider supporting us by disable your adblocker or Try ConvertXtoDVD and convert all your movies to DVD. Free trial ! :)
+ Reply to Thread
Page 2 of 2
FirstFirst 1 2
Results 31 to 41 of 41
Thread
  1. Originally Posted by usually_quiet View Post
    Yes, kmttg only works for converting recordings which are marked "copy-freely". All recordings from local OTA broadcast sources should be marked copy-freely and I thought that the recordings that you wanted to save fit that description.
    Most of them do fit that description. One of my concerns about freestanding TIVO units is that I don't think they directly record the transport stream. If I recall correctly, they further compress the OTA MPEG-2 transport stream onto the TIVO and then uncompress it when you play it/capture it, e.g. TIVO Bolt OTA. Whereas the DirecTV Tivo DVR units hooked up to an AM21 tuner record the transport stream directly without compression like a Hauppauge tuner card. Does that sound right?

    If I'm incorrect on this and standalone TIVO units do actually capture the transport stream directly as MPEG-2, I might actually buy one as a backup or use it to experiment and see if the video recorded by the TIVO (which would then be transferrable to my computer hard drive via kmttg) is better than the video recorded directly onto my hard drive by a Hauppauge tuner card, which is currently being discussed in my other thread. Does anyone know?

    Of course another problem is that standalone TIVO units can't be used with DirecTV but I might be willing to forego that on one TV set.
    Quote Quote  
  2. Member
    Join Date
    Aug 2006
    Location
    United States
    Search Comp PM
    Originally Posted by end-user View Post
    Originally Posted by usually_quiet View Post
    Yes, kmttg only works for converting recordings which are marked "copy-freely". All recordings from local OTA broadcast sources should be marked copy-freely and I thought that the recordings that you wanted to save fit that description.
    Most of them do fit that description. One of my concerns about freestanding TIVO units is that I don't think they directly record the transport stream. If I recall correctly, they further compress the OTA MPEG-2 transport stream onto the TIVO and then uncompress it when you play it/capture it, e.g. TIVO Bolt OTA. Whereas the DirecTV Tivo DVR units hooked up to an AM21 tuner record the transport stream directly without compression like a Hauppauge tuner card. Does that sound right?

    If I'm incorrect on this and standalone TIVO units do actually capture the transport stream directly as MPEG-2, I might actually buy one as a backup or use it to experiment and see if the video recorded by the TIVO (which would then be transferrable to my computer hard drive via kmttg) is better than the video recorded directly onto my hard drive by a Hauppauge tuner card, which is currently being discussed in my other thread. Does anyone know?

    Of course another problem is that standalone TIVO units can't be used with DirecTV but I might be willing to forego that on one TV set.
    As I understand it, a TiVo Bolt DVR captures the MPEG-2 transport stream from a local TV channel's broadcast as-is, but wraps it in the proprietary .TIVO container along with the broadcast's metadata. The Bolt only compresses video (probably using H.264) on-the-fly when streaming over a network to other devices but recordings stored on the Bolt remains unchanged.

    I've read reports that say the Bolt does a good job playing its recordings but most buyers want the TiVo for its great program guide and advanced scheduling features for recordings. I'd rather save some money and use a 4-tuner Hauppauge TV card or 4-tuner Silicondust Connect Quatro instead.

    Note that VideoReDo TV Suite is supposed to be able to work with .TIVO files as well as .ts and .mpg files from TV tuner cards.
    Last edited by usually_quiet; 2nd May 2019 at 22:42.
    Ignore list: hello_hello, tried, TechLord
    Quote Quote  
  3. Member
    Join Date
    Mar 2015
    Location
    Europe
    Search Comp PM
    Some thoughts:
    When delivering encoded audio formats over HDMI, the data space normally taken up by the PCM audio data can instead be thought of as one big data pipe where the clock rate determines how much data can be sent across the pipe. The 3 main clock rates that are important for Dolby codecs are 48 kHz, 192 kHz and 768 kHz. The data pipe is 2 channels with 16 bits per channel, so when you multiply the pipe size and the clock rate, you correspondingly get 1.5 Mbps, 6 Mbps, and 24.5 Mbps (AC3, Dolby digital plus, Dolby True Hd).

    It's common for televisions to support stereo PCM, Dolby Digital, Dolby Digital Plus and it's common for AVRs and sound bars to additionally support Dolby TrueHD. When a source device connects to a sink device, it reads the E-EDID to see what codecs it supports before sending audio. In the case where the sink device doesn't support the source's audio codec, the source device will decode the audio and send stereo or 5.1 PCM audio.

    Regarding the EDID information the Magewell sends to source ( attached) it do says it supports LPCM 8 channels so if the original source is up to 8 ch. lpcm the audio is sent as it is, it seems that for DTS the source do decode the audio and send up to 7.1 Lpcm ch. However in case of Dolby AC3 ,Dolby digital plus and Dolby True Hd instead of sending from 5.1 to 7.1 LPCM channels the sources ( I tried more them one ) do send 2 Pcm channels (stereo) .Additionally the source upconverts the original 16 bit depth audio to 20 or 24 bit. The apparent processing difference, between DTS and Dolby makes the dolby multi audio capture difficult.

    It seems also that everything is easier for linux see attached magewell info.
    obs suit can apparently now capture multi channel audio but it seems Dolby is tricky again.
    OBS Suite
    "Capture of dolby can be tricky if the channels are lumped into two PCM channels; in order
    to be decoded correctly and encoded all the channels should be held in different PCM
    channels".
    Image Attached Thumbnails Magewell_EDID.pdf  

    Dolby Audio over HDMI part 1_ Codecs _ Dolby Developer.pdf  

    Dolby Audio over HDMI part 2_ Signaling and Carriage _ Dolby Developer.pdf  

    magewell.com-Use audio 51 or audio 71 in Linux.pdf  

    obsproject.com-Surround Sound Streaming And Recording.pdf  

    Last edited by FLP437; 5th May 2019 at 16:06.
    Quote Quote  
  4. Member
    Join Date
    Mar 2015
    Location
    Europe
    Search Comp PM
    Some additional information received from Magewell today

    1) To capture encoded audio stream, Magewell custom APIs is the only choice. Because our capture device are incapable to decode audio data, DShow can not work as you wish.
    (2) MutilAudioCapture save encoded data to file with different suffix which depend on the type of encoded system. For example, if the input audio is DDPlus, the data is saved to "MultiAudioCapture.eac3". The location of the file is C:\Users\$USER_NAME\Magewell.
    (3) MutilAudioCapture shows how to get audio data and here are some key code snippet.

    a) Get a frame of audio data. This frame will rerturn 8 channel audio data, but only channel 1&2 are valid.
    if (MW_SUCCEEDED != MWCaptureAudioFrame(m_hChannel, &m_audioFrame))
    break;

    b) Because the arrangement of the 8 channels data is "L1,L2,L3,L4,R1,R2,R3,R4", you need to extract valid data to "L1,R1".
    int nEncodedFrameSize = 0;
    for (int j = 0; j < 1; ++j) {
    for (int i = 0; i < MWCAP_AUDIO_SAMPLES_PER_FRAME; i++) {
    int nWritePos = (i * 2 + j * 2) * m_nBitDepthInByte;
    int nReadPos = (i * MWCAP_AUDIO_MAX_NUM_CHANNELS + j) * MAX_BIT_DEPTH_IN_BYTE;
    int nReadPos2 = (i * MWCAP_AUDIO_MAX_NUM_CHANNELS + j + MWCAP_AUDIO_MAX_NUM_CHANNELS / 2) * MAX_BIT_DEPTH_IN_BYTE;
    for (int k = 0; k < m_nBitDepthInByte; ++k) {
    m_byEncodedAudioSamples[nWritePos + k]= pbAudioFrame[nReadPos + MAX_BIT_DEPTH_IN_BYTE - k - 1];
    m_byEncodedAudioSamples[nWritePos + m_nBitDepthInByte + k] = pbAudioFrame[nReadPos2 + MAX_BIT_DEPTH_IN_BYTE - k - 1];
    }
    }
    }

    c) Get synchronize code (by Pa, Pb in IEC 61937-1).
    for (; (nReadSize < nTotallSize) && !m_bGotSyncTag; ++nReadSize)
    {
    if(m_byEncodedAudioSamples[nReadSize] == 0xf8 && m_byEncodedAudioSamples[nReadSize + 1] == 0x72 &&
    m_byEncodedAudioSamples[nReadSize + 2] == 0x4e && m_byEncodedAudioSamples[nReadSize + 3] == 0x1f)
    {
    m_bGotSyncTag = true;
    nReadSize += 2 * sizeof(WORD);
    break;
    }
    }

    d) Get the type and size of audio data(by Pc, Pd in IEC 61937-1).
    int nValid = min(nTotallSize - nReadSize, 4 - m_cbBurstHead);
    memcpy(m_byBurstHead, m_byEncodedAudioSamples + nReadSize, nValid);
    m_cbBurstHead += nValid;
    nReadSize += nValid;
    if (strlen(m_szEncodedFmt) == 0) {
    switch(m_byBurstHead[1] & 0x7f) {
    case 0x01:
    strcpy_s(m_szEncodedFmt, "AC-3");
    strcpy_s(m_szEncodedFileFmt,"ac3");
    break;
    case 0x04:
    strcpy_s(m_szEncodedFmt, "MPEG1");
    strcpy_s(m_szEncodedFileFmt,"mpeg1");
    break;
    ......
    }
    m_nBurstSize = (((WORD)m_byBurstHead[2] << 8) + (WORD)m_byBurstHead[3]) / 8;
    switch(m_byBurstHead[1] & 0x7f)
    {
    case 0x11:
    case 0x15:
    case 0x16:
    m_nBurstSize *= 8;
    break;
    case 0x17:
    case 0x58:
    case 0x39:
    case 0x59:
    m_nBurstSize *= 64;
    break;
    }

    d) The copy burst_payload which is audio data to file.
    if (m_nBurstSize > 0) {
    int nValid = min(m_nBurstSize, nTotallSize - nReadSize);
    m_nBurstSize -= nValid;

    if (m_bRecording && m_bStartRecord && m_pEncodedFile) {
    if (1 == fwrite(m_byEncodedAudioSamples + nReadSize, nValid, 1, m_pEncodedFile))
    m_nFileSize += nValid;
    }
    nReadSize += nValid;
    }


    It seems to me now that the Magewell card is a capable 8 LPCM audio channel capture card and it identifies as so to a multimedia source. If the source do have audio content in LPCM up to 8 ch. format it will send it as it is to the capture card if not and if the source content is in a different format (Dolby, DTS ) and if source player/device do have a decoder for that specific format it will decode it and send LPCM instead over hdmi. However I don't understand why the sources do decode DTS even DTS HD master audio and don't decode any dolby version. Could it be because of different number of channels , padding problems or any other unidentified problem ??

    Theoretical if the source do include a Dolby decoder and I think many or almost all do provide one, the problem would be solved but as we can see it's not the case.

    I tried to edit the magewell edid file to say the capture device could support Ac3 but the editor did not let me do it . Adding 5.1 channel support to the already included 7,1 and 2.0 did not change anything either.

    The stuff from magewell is a little too complicated, at least for me but if anyone have some ideas based on that information please tell.

    I will try when I have time ( not in the next few days ) to interpose an a/v receiver in between the multimedia source and the capture card and see if anything changes.

    A problem that I see in this moment is how to force the source media device to send an ac3 bitstream because if it does send an already decoded and downmixed stream it's impossible to record the raw ac3 stream to process afterwards or how to force the source player to decode to multi channel lpcm.
    Image Attached Files
    Last edited by FLP437; 6th May 2019 at 22:08.
    Quote Quote  
  5. FLP 437, thanks for taking the time to do your testing and post all of that incredibly useful and educational information. It took me a while to go through and digest it all. It does shed some light on why capturing DD 5.1 as a 6 ch LPCM stream is so difficult. By the way, which software program are the last 3 screenshot captures in your .zip file in your last post from, i.e. the black and orange screens with the audio descriptors on them?

    What I don't understand is that it can't be that hard for lossless capture card manufacturers to incorporate recording of an AC3 stream into their software, so why don't they do it? Hauppauge Colossus does it but the video isn't lossless. The Korean Skydigital CaptureX U3.0 did it, but that card isn't made anymore.
    Quote Quote  
  6. Member
    Join Date
    Mar 2015
    Location
    Europe
    Search Comp PM
    Don't give up there is some hope.

    Magewell just send me a modified EDID file so that the card sends information to the source saying it's a capable ac3 , eac3 decoding device ( by the way they just have a fantastic support if you do own already one of their products). With this new edid file the source does indeed delivery raw ac3 bitstream instead of an already decoded and downmixed pcm stereo.
    The card also have this terrific possibility to easily change the edid file and presents herself to the hdmi source player as we want to.
    The last screenshots (black and orange screens on the previous post) are from an EDID editor an application to change the edid file according to ours needs.
    The problems we have had so far has nothing to do with the ability of the Magewell card to capture an ac3 or eac3 stream, only it happens that by default it identifies herself to the source as a no capable ac3, eac3 decoding device ( only able to accept up to 8 lpcm ch.) and so the source does delivery something that the final device can decode/use ( in my case it was sending instead of ac3 a decoded and downmixed to stereo lpcm stream upconverted to 24 bits however it could instead be sending a 6 lpcm already decoded stream in which case the problem would be already solved as the magewell would capture the lpcm streams directly) . this situation is also multimedia source dependent in the sense that it depends on the decoders existing in the source and the selection delivery format that the source makes according to the characteristics of the final device

    The card can capture whatever type of audio (compressed or uncompressed up to 8 ch.) you send to it but it can not directly decode an encoded stream so if they are encoded it can capture but it's necessary to do some additional decoding. Also if you want the raw encoded bitstream you have to inform the source player ( through EDID) that the final device ( in this case the capture card) is able to decode the encoded stream ( even if it's not true, but necessary to fool the source) if not it will send whatever will be compatible with the final device characteristics.

    I just made some additional tests.
    With the new edid just received from Magewell the card works fine ( see fig1 and 2 ) the sources do indeed now delivery ac3 or eac3 and the capture is possible with the multiaudiocapture utility ( see fig 3) it says it does have 2 ch , 48000 hz 16 bit encoded however we can not see the waveform. The result is a file with a raw extension. If I change the extension from raw to ac3 and submit the file to ac3rec utility ( fig4 ) it does says its a valid ac3 file, submitting the file to besweet (fig 5 and 6 ) it does transcode the file from ac3 to 6 lpcm wav that are clear audible . A simple ffmpeg -i MultiAudioCapture-2019-05-08-16-43-56.ac3 test-wav.wav does convert the file to 6 lpcm decoded ch. see fig 7 to fig8 (mediainfo) with no identifiable problems and ffmpeg conversion is faster than besweat.Also VD2 with a dummy video file does accept with audio /audio from other file ( audio type ffmpeg audio ) this file so it can be used / converted directly in VD2.

    I tried capturing using VD2 . the sound captured fig 9 is inaudible only noise and clicks ( encoded pcm files). it identifies however audio as a 6 channel stream (but with a 7.1 channel layout) and seems to try to transcode to pcm but it fails. I tried to save the audio file in order to try to decode it externally but its a 6 ch. wav file fig10 (clicks and noise- still encoded ) and its not recognized as a valid ac3 file .

    If VD2 could record the correct bit accurate stream we could extract the audio and transcode it externally and remux afterwards. I Have spoken with Virtualdub 2 developer to see if he can do something about this,it would be interesting.

    In this moment it's already possible to capture the raw ac3 with magewell multiaudiocapture utility and video with VD2 and use an utility as mouse record (macro mouse record utility) to reduce /eliminate synchronization problems as you will able to launch and terminate both capture applications almost at same time .You can also correct minor audio/video synchronization problems afterwards. However is not a good workflow. If VD2 developer can find a way to record bit accurate ac3 stream ( to be decoded afterwards) or support the ac3 stream these would be in my opinion the optimal solutions.

    I have also found a device "InLine HIFI Audio to USB Converter, RCA and Toslink Audio 192kHz/24-bit" that could be of interest for someone wanting to capture the audio from a s/pdif output. It seems a theoretically feasible solution but as I do not have one to test I can not be sure it do works .
    https://www.amazon.de/gp/product/B0147RHV3K/ref=ox_sc_act_title_3?smid=A3JWKAKR8XB7XF&psc=1
    Image Attached Files
    Last edited by FLP437; 8th May 2019 at 15:44.
    Quote Quote  
  7. FLP437, again that's just amazing work/research that you're doing! Great work! Again, it took me a few days to digest it all. It's great to know that at least the audio can be transferred and recorded in DD 5.1 when the Magewell card IDs itself to the source as being able to decode AC3. But what puzzles me is that this is a high end video capture card, so why can't it capture video at the same time as the DD 5.1 AC3 stream? Why should we even need Virtualdub at all? That being said, it would be nice to have any kind of solution and I wish I could help you more. It sounds like if Vdub supported the AC3 audio recording simultaneous with the video, we'd be home free as far as a reasonable workflow is concerned.

    Regarding the "InLine HIFI Audio to USB Converter, RCA and Toslink Audio 192kHz/24-bit", I couldn't quite translate every German word, but it looks like it "supports recording of S/PDIF audio signals in 16/24-bit to 192 KHz". I see the USB port but I'm not sure what it does. Is the idea that the USB is an output that could be connected to a video card input? It seems to be marketed more for its other capability of converting analog audio to digital audio.
    Quote Quote  
  8. Member
    Join Date
    Mar 2015
    Location
    Europe
    Search Comp PM
    Well the Magewell can capture video and audio at the same time and it's what it does however no software working over the card fulfilling yours specifics needs do exist, probably do to license problems and also because it's a market niche. With the workaround that I have proposed ( I understand it's not a good one) one application do capture sound (multiaudiocapture utility from Magewell) and other do capture video (Virtualdub2 , Obs, amarec whatever) but both pieces of software are acting simultaneous over the Magewell card and a macro could assure that both applications launch and close simultaneous, after you have only to remux video and audio ( however not a good workflow as I already said.)
    In these circumstances is the magewell that is doing both captures audio and video simultaneous, only there are two pieces of software acting over the same card at the same time one managing the video capture and the other the audio capture.

    All these capture cards even medium and high end do capture audio ( but only a very strict lot do capture multichannel) but dont decode it. Im no expert in licensing but its probably related to licensing costs. These cards are from 2014/15 and probably developed 2/3 years before and DTS and Dolby licenses had not expired at that time and not even now. I think now most of DTS licences expired in 2017 but Dolby have not, only ac3 I think. Also it seems licenses fees are in a per year base and not indexed to business dimension, so a large business like Denon, Yamaha or similar will have no problems but a medium/small company will have and the large majority of these companies are small.

    These card makers do usually only provide basic software as drivers and utilities ,as magewell capture express that can do both video and audio ( also multichannel but only from uncompressed lpcm) but are usually limited in terms of codecs and formats supported, they do pretend to fit only users basic purposes. These companies are basically hardware companies usually others do develop specialized software like NDE from Adobe and others not to speak the fantastic utilities like Virtualdub2 developed by enthusiasts and for free.

    The need of the SDK/API from Magewell ( parts included in the multi audio capture utility) in what compressed audio is related its because as you dont have decoders you need some sort of smart software to interpret key concepts of capturing encoded audio, the code is supposed to detect the encoded format like AC3 and treat it accordingly, detecting stream specs/ format based on headers information, need to extract / insert padding bytes, etc in order that capture data complies with the applicable standards (IEC60958/IEC61937).

    I think however that you must explore in full your device settings as one possibility would be changing settings in your device so that you can force it to decode the AC3 stream itself and delivery uncompressed lpcm over hdmi., usually there are setting to convert ac3 to lpcm but sometimes only affects spdif output.
    The Magewell will happily capture this stream and you can maintain it as uncompressed or compress it again to ac3 with Virtualdub2 and in this situation you will be using only one application ( Virtualdub2)

    Another possibility will be providing some sort of edid that could force the source to decode itself and delivery lpcm.In my case for DTS the source based on the edid card information does decode itself to lpcm multi channel so DTS problem is solved , why it doesnt happen for Dolby I dont known and this type of behavior can change with the source and the edid of the final device. if my sources did not decode for themselves DTS to lpcm I would have to declare through capture card edid that it was a DTS capable device and capture afterwards with multiaudiocapture.

    However both possibilities are source dependent

    The other possibility ( the better one ) is that someone dives into Magewell SDK/API and do some interface/plug in. However even if I have spoke with Virtualdub2 developer this development could not be easier and probably not a priority for him now ,as he could have already a developing roadmap and this was not for sure in it, also not a feature that everyone needs and one that is hardware/capture card dependent ( and he does not have one of these cards probably).

    Regarding the "InLine HIFI Audio to USB Converter, RCA and Toslink Audio 192kHz/24-bit" I thought I have read that it do support dolby over spdif but now I dont see nothing about that in which case it will probably only supports 2 channels and is not fit for the job.
    If dolby was supported the capture would be done with only one software (Virtualdub2 for instance) but selecting in it two different sources one for audio (this device) and another one for video (magewell) but the software would make the synchronized capture) so no problem.

    This type of alternative or a audio capture card with spdif supporting dolby is also extremely difficult to find and obtain guarantees regarding its correct functioning.

    I have one or two things yet to test but I'm not very hopeful probably the only hypothesis for now is the proposed workaround.
    Last edited by FLP437; 12th May 2019 at 10:12.
    Quote Quote  
  9. Member
    Join Date
    Mar 2015
    Location
    Europe
    Search Comp PM
    After exchanging information with the developer of VD2 he proposed a new workaround based on ffmpeg spdif (IEC-61937 encapsulation of various formats, used by S/PDIF) that seems to work well and seems much better than mine.

    He found the audio file consists of packets which begin with burst header 72F81F4E01000038, then follows payload of 3800h bits = 1792 bytes (bigendian value 0038 from burst header), then zeroed padding, then new packet.
    First 2 bytes of the payload (770B) are also magic bytes for ac3 stream, and format 01 from burst header also identifies ac3 (for some reason this does not match magewell sdk example where code 03 is used).

    The idea is simple capture a video with a bit accurate audio stream in VD2, demux audio, process externally to get a valid ac3 stream and remux again.

    Before capturing load the modified edid file(declaring its a capable ac3 decoding device ) in Magewell card so that the multimedia source do delivery 5.1 ac3 raw audio

    1- So to avoid distorted audio packets (resampled) packets, it's necessary to turn off resampling selecting,- Capture / timing /resync mode ( do not resync between audio and video streams.

    2- Select 1Audio / Audio (00 Pro Capture HDMI ) WDM, 2- Audio compression/ no compression ( PCM ) , 3- Audio / Channel mask only channel 0 and 1, 4- Audio / raw capture format PCM 48000Hz 16 bit

    3- Proceed as usual for a capture selecting color space, image size , frame rate , video codec, pixel format , etc

    4- After capture load the captured file and File / Export / raw audio, you can give it a raw extension

    5- Process externally the audio file with the follow ffmpeg command line ffmpeg.exe -f spdif -i audio_ac3.raw -c copy -f ac3 audio_ac3_c.ac3

    6- The ffmpeg spdif demuxer understands and strips automatically header, padding bytes, swapping litttle/big endian, etc and delivery a valid AC3 audio stream

    7- With the captured avi (video and audio) select Audio/ Audio from other file and load the valid ac3 file with files of type ffmpeg audio

    8- Save as your final file , loaded video with ac3 audio will result in video with 5.1 uncompressed lpcm or remux with ffmpeg (ffmpeg -i video_only.avi -i audio-only.ac3 -c copy final.avi ) and do keep video with the original ac3 audio
    Last edited by FLP437; 17th May 2019 at 16:46.
    Quote Quote  
  10. Member
    Join Date
    Mar 2015
    Location
    Europe
    Search Comp PM
    in addition to the previous information, lossless capture ( with utvideo as an example- ULH2 YUV2 709) with audio ac3 in GraphStudioNext worked also flawless (however only 2 channels should be selected)

    After capture
    audio demux - ffmpeg -i E:\YUV2UTvideo_ac3.avi -vn -acodec copy -y E:\YUV2UTvideo_ac3.wav
    audio post processing - ffmpeg -f spdif -i E:\YUV2UTvideo_ac3.wav -c copy -f ac3 -y E:\YUV2UTvideo_ac3.ac3
    audio remux - ffmpeg -i video.avi -i YUV2UTvideo_ac3.ac3 -c copy final.avi

    A direct FFmpeg capture command , eventually with on the fly spdif processing proved to be more complicated as the Magewell wdm audio capture pin the one that matters ( it allow up to 8 channels and sample rates from 48 to 192khz ) doesn't show off in ffmpeg dshow devices )
    Image Attached Thumbnails Click image for larger version

Name:	GraphStudio-utvideo_ac3.jpg
Views:	21
Size:	427.7 KB
ID:	49193  

    Quote Quote  
  11. Member
    Join Date
    Mar 2015
    Location
    Europe
    Search Comp PM
    So as to try not to leave too many loose ends and simultaneous trying to get the maximum information about this subject in this thread I tried to see if I could use FFmpeg to capture multichannel audio with native sample rates of 48kzh and up and see if it was possible to find a way to process on the fly the raw ac3 or e-ac3 to standard ac3 e-ac3.

    However it turned out it was impossible to get FFmpeg to enumerate the Magewell wdm audio capture device the one necessary for this purpose.

    After contacting Magewell I have been told that a specific custom made compilation was necessary to allow FFmpeg to enumerate the wdm audio devices classs, and that they could provide it to me. I received a specific version ( a lean version , without the usual external libraries x264,x265 ,etc ) . That was really able to enumerate the wdm capture device and so capture up to 8 channels with native sample rates from 48 kzh up to 192 khz , spdif muxer was also supported so raw ac3 to standard ac3 conversion was also possible.

    Some test examples made with the custom compiled FFmpeg version:

    Capturing up to 8 channels is now possible using FFmpeg ( 6 ch and 8 ch. examples )

    Code:
    ffmpeg -rtbufsize 1500000k -f dshow -channels 6 -channel_layout 63 -sample_rate 48000 -acodec pcm_s16le -i audio="Audio (00 Pro Capture HDMI)" -c copy -f wav  E:\test_audio.wav
    Code:
    ffmpeg -rtbufsize 1500000k -f dshow -channels 8 -channel_layout 1599 -sample_rate 48000 -acodec pcm_s16le -i audio="Audio (00 Pro Capture HDMI)" -c copy -f wav  E:\test_audio.wav
    Capturing raw ac3 and converting on the fly to ac3

    Code:
    ffmpeg -rtbufsize 1500000k -f dshow -channels 2 -sample_rate 48000 -acodec pcm_s16le -i audio="Audio (00 Pro Capture HDMI)" -c copy -f wav - | ffmpeg -f spdif -i pipe:0 -c copy -f ac3  E:\Audioac3.ac3
    Capturing video with raw ac3 and converting raw ac3 to ac3 on the fly in the same workflow

    Code:
    ffmpeg -threads 8 -rtbufsize 1702000k -f dshow -channels 2 -sample_rate 48000 -acodec pcm_s16le -i audio="Audio (00 Pro Capture HDMI)" -c copy -f wav - | ffmpeg -f spdif -i pipe:0 -f dshow -i video="Video (00 Pro Capture HDMI)" -r 59.94 -c:v copy -c:a ac3 -map 0:a -map 1:v  E:\Video_audioac3.avi
    this command line does work but audio and video are not correctly synchronized, they do have a delay .The command line could eventually be optimized.
    Usually using i video="Video (00 Pro Capture HDMI)":audio="Audio (00 Pro Capture HDMI)" reduces/ eliminates synchronization problems, however I have not been able to accommodate that syntax, also piping adds probably to the synchro problems so if a more straightforward and or more optimized command line could be done perhaps the synchronization problems could be reduced/eliminated. Not sure however they can be completely eliminated.

    I didn't had time to play around, but "setpts" parameter to delay the timestamp of video frame, copyts and muxdelay flags,, audio-buffer_size, thread_queue_size are all options between others that could eventually be used to reduce the AV synchro problem.

    Related to 24 bit audio captures they are not possible right now as the dshow limit the native ability of the capture device ( not sure if its the dshow in general or the driver in particular). So for 24 bits or 32 bits audio captures the only way for now seems to be using Magewell SDK or the small utility that comes with it the multiaudiocapture or getting an external audio to usb converter supporting 24/32 bits.

    For anyone wanting to compile an FFmpeg version (able to enumerate the magewell wdm class device) its necessary to copy the file "dshow.c" in attachment to "libavdevice" to replace the original one. Then FFMPEG will enumerate the audio device from the WDM class. After to add third part encoders and libraries the procedure is the usual. However I have not tried yet myself.
    Image Attached Files
    Quote Quote  



Similar Threads