Hi all, this patch adds audio packet descrambling to mkv demuxer and changes extradata to conform to the new ad_realaudio decoder interface. The same extradata format and packet order is also used by lavc real decoders. There is one problem created by this patch: in the old version the codec filled sh->i_bps (nAvgBytesPerSec) based on the flavor value, while now the codecs don't do it anymore (and that would not be possible anyway with the lavc codecs). In real demuxer i solved the problem by taking i_bps from the MDPR header, is there some field in matroska that can be used to fill that value? Else the only option is to create a table with bitrates like it's done for sipr codec (sipr is the only codec where flavor or bitrate is used to select the codec subtype). Only cook is tested (samples/Matroska/realaudio/nosound.mkv). Mosu, can you comment on this? Ciao, Roberto
On Fri, Mar 24, 2006 at 12:46:07AM +0100, Roberto Togni wrote:
There is one problem created by this patch: in the old version the codec filled sh->i_bps (nAvgBytesPerSec) based on the flavor value, while now the codecs don't do it anymore (and that would not be possible anyway with the lavc codecs). In real demuxer i solved the problem by taking i_bps from the MDPR header, is there some field in matroska that can be used to fill that value? Else the only option is to create a table with bitrates like it's done for sipr codec (sipr is the only codec where flavor or bitrate is used to select the codec subtype).
I suppose this is why I get A: inf on the status line? Other than that the patch appears to work. Diego P.S.: Roberto, please create patches from the root of the src tree so that they can be conveniently applied from the root of the src tree as well, thanks.
Hey, On Friday 24 March 2006 08:56, Diego Biurrun wrote:
I suppose this is why I get
A: inf
on the status line? Other than that the patch appears to work.
I noticed this as well, and this completely destroys A/V sync. Therefore unacceptable. Why was that change to the decoder necessary in the first place? Seems like it created a lot of work and shifted code from the decoder to the demuxers... What's the benefit? Mosu -- LINET Services GbR Gotenweg 15 Tel.: 0531-280 191 71 38106 Braunschweig Fax.: 0531-280 191 72 http://www.linet-services.de mailto:info@linet-services.de
On Fri, 24 Mar 2006 11:42:41 +0100 Moritz Bunkus <m.bunkus@linet-services.de> wrote:
Hey,
On Friday 24 March 2006 08:56, Diego Biurrun wrote:
I suppose this is why I get
A: inf
on the status line? Other than that the patch appears to work.
I noticed this as well, and this completely destroys A/V sync. Therefore unacceptable.
The cause of it is the missing i_bps. Unfortunately the data is not available in the type specific data block of the MDPR, but it's in the general part of it (average bit rate).
Why was that change to the decoder necessary in the first place? Seems like it created a lot of work and shifted code from the decoder to the demuxers... What's the benefit?
Only the demuxer have all the correct info to reorder audio packet. If a packet was missing with the old method you got a permanent desync in the descrambling matrix. The old method also required to pass container-related data to the decoder to perform the reordering process. The i_bps problem is not caused by the reordering patch, it worked only with the binary codecs (native cook does not provide any flavor-related functions) I see some track->fix_i_bps in mkv demuxer, how does it work exactly? can it be used to solve this problem? Else the only solution is to create a flavor2bps array and use it. Ciao, Roberto
Hey, On Friday 24 March 2006 19:09, Roberto Togni wrote:
The cause of it is the missing i_bps. Unfortunately the data is not available in the type specific data block of the MDPR, but it's in the general part of it (average bit rate).
Why does mplayer need that if the demuxer provides timecodes? Ah well, doesn't really matter all that much to me :)
I see some track->fix_i_bps in mkv demuxer, how does it work exactly? can it be used to solve this problem? Else the only solution is to create a flavor2bps array and use it.
I think it simply does something like counting the amount of bytes during the first second. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds
On Fri, 24 Mar 2006 20:04:23 +0100 Moritz Bunkus <moritz@bunkus.org> wrote: [...] Attached a patch that solves the i_bps problem by getting that value from the flavor in the .ra header. As usual it's tested only with cook. Ciao, Roberto
On Sat, Apr 01, 2006 at 04:15:19PM +0200, Roberto Togni wrote:
On Fri, 24 Mar 2006 20:04:23 +0100 Moritz Bunkus <moritz@bunkus.org> wrote:
[...] Attached a patch that solves the i_bps problem by getting that value from the flavor in the .ra header.
As usual it's tested only with cook.
Works fine for me on PPC. Roberto, if I had a dollar for each time I test one of your patches and you did not create it from the root of the source tree... Diego
Hey, it's fine with me. Thanks for the patch. You can apply it yourself if you want. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds
On Sat, 1 Apr 2006 16:15:19 +0200 Roberto Togni <r_togni@tiscali.it> wrote:
On Fri, 24 Mar 2006 20:04:23 +0100 Moritz Bunkus <moritz@bunkus.org> wrote:
[...] Attached a patch that solves the i_bps problem by getting that value from the flavor in the .ra header.
As usual it's tested only with cook.
applied
Hey, (moderator: please discard the held one. thanks :)) On Friday 24 March 2006 08:56, Diego Biurrun wrote:
I suppose this is why I get
A: inf
on the status line? Other than that the patch appears to work.
I noticed this as well, and this completely destroys A/V sync. Therefore unacceptable. Why was that change to the decoder necessary in the first place? Seems like it created a lot of work and shifted code from the decoder to the demuxers... What's the benefit? Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds
Hi, On 3/24/06, Moritz Bunkus <moritz@bunkus.org> wrote:
Hey,
(moderator: please discard the held one. thanks :))
I added you other email "m.bunkus@.." in the "always reject" list so I won't have to manually reject these mails. I hope it's okay with you. If it's not, please say so. Guillaume -- I am disillusioned enough to know that no man's opinion on any subject is worth a damn unless backed up with enough genuine information to make him really know what he's talking about. -- H. P. Lovecraft (about the flamewars on FFmpeg and MPlayer-dev mailing lists) http://www.brainyquote.com/quotes/quotes/h/hplovecr278144.html
Hey, On Friday 24 March 2006 00:46, Roberto Togni wrote:
In real demuxer i solved the problem by taking i_bps from the MDPR header, is there some field in matroska that can be used to fill that value?
Hmmm... The CodecPrivate contains the MDPR.type_specific_data block. Does that help you? Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds
participants (5)
-
Diego Biurrun -
Guillaume POIRIER -
Moritz Bunkus -
Moritz Bunkus -
Roberto Togni