VideoHelp Forum

Try DVDFab and download streaming video, copy, convert or make Blu-rays,DVDs! Download free trial !
+ Reply to Thread
Page 2 of 2
FirstFirst 1 2
Results 31 to 49 of 49
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 23: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 17: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 23: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 16: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 11: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 17: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:	61
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  
  12. Hi, would it be possible to use the magewell card together with mpchc in order to process the video output using madvr as render, and at the same time have the audio ac3 in passthrough without recording the streams a/v? thanks.
    Quote Quote  
  13. Member
    Join Date
    Mar 2015
    Location
    Europe
    Search Comp PM
    Im not sure what you pretend to do with MPC-HC with madVR.
    If your idea is use MPC-HC to capture with a Magewell card yes it does works fine, no problem .File/open device and it connects with the magewell card. You do have access immediately to essential options and through filters / card name ( video 00 pro capture hdmi) or /and (audio 00 pro capture hdmi) to more extensive properties like card general properties, capture (pin) properties and preview (pin ) properties so you have access to more or less everything you may need , formats , resolutions ,fps, codecs,, etc.
    In terms of codecs it seems more limited as apparently it does not show installed vfw codecs, but if you have utvideo installed for instance it will show up DMO ( direct show) codec versions so you can still use lossless codecs.

    In terms of preview it does seems to use MadVR ( see filters loaded by default) but I dont think MadVr will be used for capture itself. You can use a screen recorder program but not sure about the final quality you will get.


    Filters currently loaded
    Preview
    - Default DirectSound Device
    - madVR
    - Audio Switcher
    - Deinterlacer
    - Smart Tee (audio)
    - LAV Video Decoder
    - Audio (00 Pro Capture HDMI)
    - Smart Tee (video)
    - Video (00 Pro Capture HDMI)

    Related to audio and if you do want to capture ac3 sound you can eventually do it if MPC HC does support a bit accurate audio recording ( no idea if it does) you can do a similar process as with virtualdub record video+audio ,extract audio , process it externally and merge again. The problem with ac3 audio is the fact that it is a raw ac3 stream that needs to be decoded or processed to get a standard ac3 stream.

    There is a possibility but I have not tried it that installing the AC-3 ACM codec an AC3 decoder that theoretical can convert/decompress directly to wav/mp3 that ac3 audio would work ( converted to multi channel wave instead) but probably it will more granted to work with virtualdub that with MPC HC as I dont think MPC HC does support multi-channel audio. With Virtualdub2 and the AC3 ACM codec installed there is the possibility to record the converted multi channel wav audio or convert it on the fly to ac3 with the ac3 acm encoder included in Vdub 2.

    There is also the FccHandler Ac-3 plug-in to Vdub and one possibility was letting the ac3 raw files load from this filter instead of the caching input driver . This theoretical pass through the ac3 audio track directly and packs it into the created video file unchanged.

    I must say I have not tried these last ac3 codec possibilities, so I have not a clue if they will work.
    Quote Quote  
  14. many thanks for the reply!
    I don't want to record any stream, I would like to use mpchc together with madvr to process the video stream captured by magewell on the fly, while I would like the ac3 audio stream to pass through the pc. Do you think it is possible to do this?
    thanks
    Quote Quote  
  15. Member
    Join Date
    Mar 2015
    Location
    Europe
    Search Comp PM
    You will have to ellaborate a little further in order to understand what you want to achieve.
    What is your source video/ audio, what type of processing do you intend to do with mpc hc/madvr , why do you need to do it with this player/render and why do you need to capture and do the video processing simultaneous. What will be your final result/goal.
    Quote Quote  
  16. I would like to use the PC as a video processor, I would like to connect the magewell input to the sky satellite decoder in order to improve the images through the use of madvr. The problem is the audio because I would like to acquire it in AC3 and try to make the pass through. for this purpose for example madshi created envy (https://www.madvrlabs.llc)
    Quote Quote  
  17. Member
    Join Date
    Mar 2015
    Location
    Europe
    Search Comp PM
    Well , envy from madshi/madvrlabs must be an exceptional video processor but with a price tag off almost 10000 usd is out of reach for most.

    Related to your idea of using the pc and mpcHC/madvr in particular as an efficient video processor in between your satellite set top box and monitor / HR TV and an audio amplifier/home theater system I have no idea if using your workflow vs connecting your satellite set top box directly to a high performance TV/monitor and/ or to a home theater system/audio amplifier will provide better results or not.

    Assuming you are right and that your workflow could provide a better image here are some thoughts.

    Video
    If in preview MPC hc does use madvr probably the best and easier is to open device in mpchc and connect directly to the magewell you will have almost full control of the magewell card and you can adjust all madvr setting and preview in full screen. You can eventually even capture video in 10 bit it can eventually be useful when applying complex post processing algorithms reducing losses.

    You can also capture with obs studio for instance stream the video and open the stream with mpc hc , but it seems more complicated and present higher risks linked to pc performance.

    Audio
    1- One possibility could be an hdmi + audio decoder extractor splitter supporting dolby digital ac3 . You can avoid entirely the pc and feed the analog 5.1 audio output directly to an audio amplifier/home theater system

    2- An Hdmi spliter one output for video (magewell) and other for audio to your audio system / arc

    3- Use an usb audio interface that do support audio 5.1 ac3 ( not easy to find) and connect the spdif output to your audio system. Almost all audio interfaces/ Daw software do connect easily to the magewell audio capture pin the problem is spdif output and ac3 support.

    4- Virtual sound card emulation not sure if you can connect to the magewell card and assure the output through your internal pc audio card

    These are only some ideas not sure if they will work its more a sort of brainstorming, If they work due to the different paths for audio and video you can get audio /video out of synchro. Some home theater systems/audio amplifiers do allow for audio delay adjustments.
    Quote Quote  
  18. I too had thought of separating the video from the audio and processing only the video through the PC. However it would take me much longer to have the pass through the audio. How do you get a virtual sound card? (your hypothesis No. 4)
    Quote Quote  
  19. Member
    Join Date
    Mar 2015
    Location
    Europe
    Search Comp PM
    Virtual sound card one example is e2eSoft VSC Sound Card Emulation

    What you do need is to root the 5.1 ac3 raw audio from the Magewell capture pin to the optical output as a digital signal or output it as a 5.1 analog signal. However ensure the raw audio signal pass through from the Magewell capture pin to the optical or analog audio outputs could not be an easy task as there is a strong possibility the signal will not be rooted raw.

    It can be as easy as enabling in the playback devices the optical output and defining it as default device. With luck you can root the audio output from an application connected to the Magewell audio capture pin to the PC digital audio output ( however usually this is never that simple). Virtual dub I know can produce a bit accurate audio record ( at least export raw audio) not sure if it does provide a bit accurate audio stream in standard previewing , not sure also what MPC HC can provide. However you can connect more than one application in simultaneous to the Magewell audio capture pin. If you do find one application with which it is possible to root the digital audio output to the PC optical output you can use that application for audio and MPC HC /mad VR for video. There is not a strong impact in the CPU for using more than one application simultaneous over the Magewell card.

    There is also the possibility you can use the AC3 ACM codec to convert the AC3 audio to a 5.1 multi-channel wav stream and root these analog signals to the pc audio output.

    All of this have to be tested, unless you can find someone who has already done so, not my case in this moment.

    I hope you do have a good GPU, I do have a NVidia GTX 960 with 4Gb memory and it glitches and drop frames with Full HD using MPC HC with Mad VR ( obviously it will depend on your Mad VR settings but you are going to want the ones that will give the best performance and these will be very GPU demanding)
    Quote Quote  



Similar Threads