Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > New and alternative video codecs

Reply
 
Thread Tools Search this Thread Display Modes
Old 30th December 2010, 09:15   #12861  |  Link
Gingko
Registered User
 
Gingko's Avatar
 
Join Date: Sep 2007
Location: France (IDF)
Posts: 3
Audio AAC in transport stream with LOAS and LATM

Quote:
Originally Posted by Gingko View Post
I am trying to decode digital TV with audio as "AAC in transport stream with a synchronization layer (LOAS) and a multiplex layer (LATM)" used in some countries, and to find codecs working with this.

I more or less succeeded with Monogram AAC Decoder, but I had to modify and recompile it in order to get it working, because the proper Media Type was not exposed to DirectShow (although internally used). Now it works, but with some instabilities.

This Media Type, as far as I understand correctly, is defined (at least by Microsoft) as MEDIASUBTYPE_MPEG_LOAS, and its value is {00001602-0000-0010-8000-00AA00389B71}.

Monogram AAC Decoder is a wrapper for libfaad2, which is used also by ffdshow-tryouts, so logically, ffdshow-tryouts should be able to decode it, but unfortunately, it does not expose this Media Type either.

I'm wondering if it wouldn't be possible to include it in future versions of ffdshow-tryouts in order to make possible, or more easy, to get ffdshow-tryouts decoding AAC+LOAD+LATM?

If you need some sample, you can use this file :
http://gingko.homeip.net/misc/TDT_Co...09_19-20-02.ts

This is a 30 seconds record of a full DVB-T Transport Stream multiplex (from Portuguese TV) with 4 TV channels (plus an empty one), all encoded as H264 (for video) and AAC+LATM+LOAS for audio.

Regards,

Gingko
Hello,

Is there any chance that I could get an answer to this ?

I am developer on a DVB-T application, and the lack of this mediasubtype makes problematic for me to find a codec able to decode soundtracks in this kind of video stream.

Even Media Player Classic HC, for example, seems to be unable to play it.

Gingko
Gingko is offline   Reply With Quote
Old 30th December 2010, 11:11   #12862  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 4,895
@ clsid and STaRGaZeR:

A first verbose reply from Tom Keller. Brief translation:

Due to a rather slow capturing system, he needs a both fast and easily cuttable (keyframe only) and high quality video format as VfW codec. So ffdshow's MJPEG is the optimum for his case because:
  • it is fast
  • it is free of charge
  • it provides acceptably high quality
  • and even though ffdshow is "just a VfW wrapper for ffmpeg", he needs exactly that
  • Xvid is no substitute because it is neither fast enough on his system nor freely cuttable (or who would try to set it up for 0 P-frames?)
  • FFV1 is no substitute because even though it compresses tightly for a lossless codec and can provide I-frames only, it is too slow on his system
  • Huffyuv is no substitute because although it is fast enough and even lossless, the result is way too big

Recommendations like "buy bigger harddisks" or "buy a faster PC" are easy. But not every user is able to do that. If they were, then ffdshow would need no encoder at all, and we could use "lossless x264vfw" for capturing.

So much about Tom's opinion. Now I have at least one specific person I can point at.
__________________

German doom9 / Gleitz video board
CQME – change the Matrix!
BeSweet 1.5b31 All In One | HeadAC3he 0.24a13

Rémoulade is spoiled
LigH is online now   Reply With Quote
Old 30th December 2010, 13:29   #12863  |  Link
clsid
Registered User
 
Join Date: Feb 2005
Posts: 4,668
Quote:
Originally Posted by Gingko View Post
Hello,

Is there any chance that I could get an answer to this ?

I am developer on a DVB-T application, and the lack of this mediasubtype makes problematic for me to find a codec able to decode soundtracks in this kind of video stream.

Even Media Player Classic HC, for example, seems to be unable to play it.

Gingko
LATM/LOAS are not supported by ffdshow. It would require adding a parser for such headers.

If you want to see this capability added to ffdshow you need to submit a patch for it. We have no manpower available to do it.
clsid is offline   Reply With Quote
Old 30th December 2010, 17:21   #12864  |  Link
Ger
Registered User
 
Join Date: May 2007
Location: Norway
Posts: 192
Quote:
Originally Posted by Gingko View Post
Even Media Player Classic HC, for example, seems to be unable to play it.
Your sample plays with audio in MPC-HC if you use the latest LAVFSplitter beta and Monogram AAC decoder.

LAVFSplitter gets the duration of your sample wrong though, like it does with most H.264/HD samples, due to limited TS support in libavformat, but hopefully the TS duration issue will be resolved in LAFVSplitter eventually, since it is supposed to replace the internal MPC-HC splitters for the supported formats when it's deemed ready.

You may want to check out the LAVFSplitter thread. We've discussed LATM there before.

If you are a developer with the necessary time and skill to create a patch for LATM/LOAS support in ffdshow it would be appreciated though, since we wouldn't need the Monogram AAC decoder for those particular streams anymore.
Ger is offline   Reply With Quote
Old 30th December 2010, 18:14   #12865  |  Link
roozhou
Registered User
 
Join Date: Apr 2008
Posts: 1,181
Hi clsid,

Is it possible to use ffdshow DXVA in encoding apps? It seems ffdshow gets the decoded frame back to main memory via IAMVideoAccelerator::GetBuffer or IDirectXVideoDecoder::GetBuffer in overlay mode. If ffdshow provide a new interface, the encoding app could pass a callback function to ffdshow and ffdshow calls it when it gets the frame. This should be useful for ATI and Intel graphic card users.
roozhou is offline   Reply With Quote
Old 31st December 2010, 00:53   #12866  |  Link
clsid
Registered User
 
Join Date: Feb 2005
Posts: 4,668
Quote:
Originally Posted by roozhou View Post
Hi clsid,

Is it possible to use ffdshow DXVA in encoding apps? It seems ffdshow gets the decoded frame back to main memory via IAMVideoAccelerator::GetBuffer or IDirectXVideoDecoder::GetBuffer in overlay mode. If ffdshow provide a new interface, the encoding app could pass a callback function to ffdshow and ffdshow calls it when it gets the frame. This should be useful for ATI and Intel graphic card users.
Even if it would be possible, the performance will probably be disappointing. But more importantly, I doubt any of the current developers has any interest in implementing this. So if you want it you need to code it yourself.
clsid is offline   Reply With Quote
Old 31st December 2010, 01:38   #12867  |  Link
Gingko
Registered User
 
Gingko's Avatar
 
Join Date: Sep 2007
Location: France (IDF)
Posts: 3
LATM/LOAS support

Quote:
Originally Posted by clsid View Post
LATM/LOAS are not supported by ffdshow. It would require adding a parser for such headers.

If you want to see this capability added to ffdshow you need to submit a patch for it. We have no manpower available to do it.
Quote:
Originally Posted by Ger View Post
If you are a developer with the necessary time and skill to create a patch for LATM/LOAS support in ffdshow it would be appreciated though, since we wouldn't need the Monogram AAC decoder for those particular streams anymore.
I see.

Necessary time is probably the most needed resource for me if I want to do that (difficult to work on several projects in the same time), but maybe I will try it anyway one day or another.

Gingko
Gingko is offline   Reply With Quote
Old 31st December 2010, 02:31   #12868  |  Link
STaRGaZeR
4:2:0 hater
 
Join Date: Apr 2008
Posts: 1,307
Quote:
Originally Posted by LigH View Post
@ clsid and STaRGaZeR:

A first verbose reply from Tom Keller. Brief translation:

Due to a rather slow capturing system, he needs a both fast and easily cuttable (keyframe only) and high quality video format as VfW codec. So ffdshow's MJPEG is the optimum for his case because:
  • it is fast
  • it is free of charge
  • it provides acceptably high quality
  • and even though ffdshow is "just a VfW wrapper for ffmpeg", he needs exactly that
  • Xvid is no substitute because it is neither fast enough on his system nor freely cuttable (or who would try to set it up for 0 P-frames?)
  • FFV1 is no substitute because even though it compresses tightly for a lossless codec and can provide I-frames only, it is too slow on his system
  • Huffyuv is no substitute because although it is fast enough and even lossless, the result is way too big

Recommendations like "buy bigger harddisks" or "buy a faster PC" are easy. But not every user is able to do that. If they were, then ffdshow would need no encoder at all, and we could use "lossless x264vfw" for capturing.

So much about Tom's opinion. Now I have at least one specific person I can point at.
It was hard, huh? It would have been inmediate if you would have proposed the poll in a less biased and more informative tone. 6 "Yes, absolutely - must stay inside!" explanations left for you

Quote:
Originally Posted by clsid View Post
@STaRGaZeR
If you want and have time, you could remove 2-pass mode for MJPEG. I assume that those who use MJPEG use it as an intermediate format during capturing.
Since it was easy, I've done it in r3709. 2 pass and 1 pass bitrate are no longer available for MJPEG.
__________________
Specs, GTX970 - PLS 1440p@96Hz
Quote:
Originally Posted by Manao View Post
That way, you have xxxx[p|i]yyy, where xxxx is the vertical resolution, yyy is the temporal resolution, and 'i' says the image has been irremediably destroyed.
STaRGaZeR is offline   Reply With Quote
Old 31st December 2010, 11:28   #12869  |  Link
fastplayer
Registered User
 
Join Date: Nov 2006
Posts: 799
Quote:
Originally Posted by STaRGaZeR View Post
It was hard, huh?
Since Tom Keller has a small disk and slow system in general, he can stick with older builds of ffdshow. Nobody is taking that away from him.

By the way, I still see no "Keep MJPEG or die!" petition on PetitionOnline.com...
fastplayer is offline   Reply With Quote
Old 31st December 2010, 13:59   #12870  |  Link
dann23
Registered User
 
Join Date: Apr 2009
Posts: 89
Quote:
Originally Posted by fastplayer View Post
By the way, I still see no "Keep MJPEG or die!" petition on PetitionOnline.com...
+1

I also need mpeg4 encoder from ffdshow and I'm sure I can make a poll and gather a few votes for this. But what's the point? So I believe it's better to remove all of the old and buggy encoders or let them just the way they were.
dann23 is offline   Reply With Quote
Old 31st December 2010, 16:43   #12871  |  Link
clsid
Registered User
 
Join Date: Feb 2005
Posts: 4,668
Can anyone with a S/PDIF setup please test the AC3 encoding functionality? I got a report that it is not working properly after its recent update, and I need confirmation.
clsid is offline   Reply With Quote
Old 1st January 2011, 00:32   #12872  |  Link
VipZ
Registered User
 
Join Date: Jun 2009
Location: London
Posts: 373
Quote:
Originally Posted by clsid View Post
Can anyone with a S/PDIF setup please test the AC3 encoding functionality? I got a report that it is not working properly after its recent update, and I need confirmation.
EDIT: Sorry my bad, tested with 3661, indeed 3708 doesn't work for me either. After testing it seems 3681 broke AC3 encoding.
__________________
Windows 10 Pro x64, CPU: Core i7 6700K, GPU: GeForce GTX 980 /w 355.60, Audio: HDMI to Yamaha RX-A3010 (5.1)

Last edited by VipZ; 1st January 2011 at 17:04. Reason: Correct Info
VipZ is offline   Reply With Quote
Old 1st January 2011, 14:51   #12873  |  Link
Perls
Registered User
 
Join Date: Apr 2009
Posts: 11
Quote:
Originally Posted by VipZ View Post
Tested encoding via HDMI both 2.0 and 5.1 @ 48kHz, working fine for me. 44.1kHz doesn't work natively for me, re sampling to 48kHz solves it, this could be the issue being reported.

Maybe automatically re sampling to 48kHz on AC3 encoding could be a solution?
For me, updating from 3626 to 3707 broke AC3 encoding of 2.0 at 48 kHz. Haven't tested anything else.
Perls is offline   Reply With Quote
Old 1st January 2011, 18:59   #12874  |  Link
tetrahex
Registered User
 
Join Date: Oct 2006
Posts: 4
+1 for keeping encoders

Hi!

I'd like to express my (somewhat lengthy ) opinion about moving the encoders out of ffdshow. I don't like it.

For me, the ffdshow was a very welcome alternative after years and years of using first all kinds of codec packs and suffering for that, after which I used specific codecs or encoding apps for anything I needed. But even with a few codecs/splitters and a couple of encoding apps (like VirtualDub/Mod, Megui, AviDemux) I felt that simpler solution would be better, especially after I bought my first laptop. I wanted to keep the number of individual apps/codecs/whatever as small as possible, so as not to clutter the system too much and keeping it light and simple. And it worked, very well for my needs: all I needed was ffdshow for any kind of encoding/decoding, VHScreenCapture codec for capturing flash videos from web browser window (from national broadcasting company; not possible to download) and VirtualDub to put it all together.

Mainly I used XviD (and sometimes x264 for testing hardware etc.) from ffdshow, though I tried some other codecs too just for the experience. Now that almost all the possibly useful encoders have been taken out, I tried separate XviD for capturing. It worked of course (despite a few crashes which didn't happen with ffdshow, probably due to updating VirtualDub), but for my eyes/hardware, the quality and the speed seem to be pretty much the same as with ffdshow. So now I don't really know what use I'd have for ffdshow, since I can get the decoders with the encoders. Which means more apps/codecs for no apparent benefit for me, only more clutter and hassle.

The one thing that ffdshow is (was?) known for (at least for me & people I know & the magazines I read) is it's ability to handle almost all kinds of encoding/decoding needs, with possibly 1-3 additional codecs/splitters, and you could do anything. But remove the encoders (I REALLY have no use for FFV1, MJPEG, DV, HuffYuv..) and all you've got is a playback addon, which needs the splitter anyway for anything else than avi basically. Of course there's the filters/postprocessing stuff etc., of which subtitles would be the only one I needed, but since it's so inferior to DirectVobSub, that's no good either.

So what would I do with ffdshow? I can playback movies with the codecs I now need to install anyway, if they haven't come with the OS already. I really liked the vfw interface, similar GUI for audio/video decoding and for different video encodings, nice to try some filters/more rare codecs just for fun if there was no actual need. But now the fun & the experience seems to be over, which is really a pitty. If the encoders are taken out, I simply have no (practical) use for ffdshow.

Anyway, it was fun while it lasted. And I do understand your reasons for minimizing outdated/buggy/inferior code from the app, I've coded too and I know how precious time is, and how frustrating it is to do things that seem to only consume time and not bring any benefits.
I just hope that the large masses of people that are using ffdshow for things I mentioned would notice the changes you've done in time and have the ability (ie. language skills, finding the forum, time to read your reasons & know-how to explain use cases which you asked for) to express their opinions before it's too late, before another great app is being taken down the road not everybody's happy about, by the decision of a small number of developers. Those kind of situations we've all come across, I'm sure, just see eg. Firefox's disappearing features, or OpenOffice/LibreOffice, even Mac not being able to play flash videos, or Oracle's acquiring Sun and the worries and disappointments that's brought out (way out of proportion to this situation, I know, but basically the same issue).

Thank you if you've read all this, and thank you for your efforts and for your accomplishments; any way you go, you still deserve to be applauded!!
tetrahex is offline   Reply With Quote
Old 1st January 2011, 21:18   #12875  |  Link
clsid
Registered User
 
Join Date: Feb 2005
Posts: 4,668
What is the total size of your Windows and program files folders combined? Several gigabytes I guess? But installing a single extra codec suddenly creates a clutter? Oh, the horror.

Your heartwarming story is just more and more confirmation that our decision was in fact excellent.

By using the official Xvid codec you will soon be able to enjoy several nice improvement that have been recently committed to its CVS. Like better MT encoding and MT deblocking during playback. But if you prefer what you had, then you can just keep using an old version of ffdshow.

Last edited by clsid; 1st January 2011 at 21:20.
clsid is offline   Reply With Quote
Old 1st January 2011, 21:50   #12876  |  Link
kieranrk
Registered User
 
Join Date: Jun 2009
Location: London, United Kingdom
Posts: 713
Quote:
Originally Posted by clsid View Post
What is the total size of your Windows and program files folders combined? Several gigabytes I guess? But installing a single extra codec suddenly creates a clutter? Oh, the horror.

Your heartwarming story is just more and more confirmation that our decision was in fact excellent.
K-lite methodology on ffdshow. It's no wonder ffdshow is a total mess as acknowledged by ffmpeg developers themselves...
kieranrk is offline   Reply With Quote
Old 1st January 2011, 22:33   #12877  |  Link
clsid
Registered User
 
Join Date: Feb 2005
Posts: 4,668
It is a mess that we are trying to clean up. The Xvid encoding in ffdshow was merely an unmaintained wrapper for an old version of xvidcore.dll. Are you suggesting we should keep that? What is wrong with the official Xvid codec?

Also, if you are suggesting that I am somehow responsible for the messy code in ffdshow then you know very little about the history of ffdshow.

Idiot.
clsid is offline   Reply With Quote
Old 2nd January 2011, 03:55   #12878  |  Link
kieranrk
Registered User
 
Join Date: Jun 2009
Location: London, United Kingdom
Posts: 713
Quote:
Originally Posted by clsid View Post
It is a mess that we are trying to clean up. The Xvid encoding in ffdshow was merely an unmaintained wrapper for an old version of xvidcore.dll. Are you suggesting we should keep that? What is wrong with the official Xvid codec?

Also, if you are suggesting that I am somehow responsible for the messy code in ffdshow then you know very little about the history of ffdshow.
I was commenting on your response about bloat. Never said that anything about you being responsible for ffdshow's mess...
kieranrk is offline   Reply With Quote
Old 2nd January 2011, 12:41   #12879  |  Link
iron2000
Questioning User
 
Join Date: Jan 2005
Posts: 163
Seem like MPC-HC's DXVA is more compatible.
Still having the freezing problem with ffdshow DXVA in 3713.
__________________
8 Pro x64 | i5-3470 | 8GB ram | GT430 | Xonar DX | MPC-HC x86
iron2000 is offline   Reply With Quote
Old 2nd January 2011, 14:48   #12880  |  Link
avih
Capture, Deinterlace
 
avih's Avatar
 
Join Date: Feb 2002
Location: Right there
Posts: 1,949
Guys, take it easy please. Keep the discussion on topic. Thanks.
__________________
E8400/P43, 4G, GTX260+, Win7-64.
Get Firefox. Get SmoothWheel Firefox extension.
avih is offline   Reply With Quote
Reply

Tags
ffdshow, ffdshow tryouts, ffdshow-mt, ffplay, icl

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 19:16.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2017, vBulletin Solutions Inc.