Re: [xine-devel] [PATCH] Count preview frames separately for all audio and video streams

[Petri H. <phi...@us...>]

Torsten Jager wrote:
[...]
> Furthermore, hg cant deal with more complex changes comprehensively.
> I have rewritten demux_flv almost completely, and demux_real a great
> deal. Diffs do confuse more than they explain there. Quite a few
> compatibilty enhancements though. No idea how to post these.

If those can't be split to smaller chunks there are at least two
options:
- just send the gigantic patch
- create an alternative demuxer for the format: save your code in
another file (demux_real_tj.c) and add it to Makefile. Change demuxer
name, identifier (real_tj) and default priority in the sources. Then
test it with something like

xine file:/.../x.flv#demux:real_tj

This way others can test it with the old demuxer in the same system.

You could also write short list of enhancements and possibly list some
urls that work with the new demuxer but fail with the old one.

> * LATM is *not* a new codec. It is a new container, allowing for
>   multiple AAC streams merged into one. Xine concept does not
>   support chaining demuxers, so the correct way would be implementing
>   an LATM sub-demuxer within demux_ts. It should scan for available
>   audio tracks, present them to the user for selection, and finally
>   pass data as plain AAC to the decoder. See the ff source on this.

That's true. But complete LATM support is lot more work to add.
So far all DVB mpeg-ts samples I've seen use only single channel inside
LATM. Such streams should work with the current (minimal-effort)
implementation.

> * PID autodetection is still needed if you have early DVB recordings.
>   Back then, there was no PAT/PMT, just the plain PIDs muxed together.
>   You had to visit your local newsstand, buy some good TV mag, look
>   up the audio and video PIDs of your favourite stations, and then
>   enter them manually into your receiver. Yes, all receivers used
>   to have that feature. I sometimes want it back today as it would be
>   a quick workaround for buggy receiver firmware...

If someone really needs PID autodetection, it is easy to restore there
under some kind of configuration option (so that it kicks in only when
requested).
Well, one could scan the stream for missing PAT/PMT and enable
autodetection if PAT/PMT are not found in first second of the stream.
Autodetection (as it was implemented) can't be enabled by default: it
does not try to detect stream types from content and it won't work if
there are more than one program in the mux.

[...]
> I am now trying to figure out the protocol behind "hg clone",
> then to write a plain C emulator which I can use. Maybe it helps.

No need. If you want the latest version in single package, just ask
someone. I can pack it to somewhere where you can download it. I can
even make it update daily or provide update bundles ...
See http://phivdr.dyndns.org/xine-lib/hg/

And, it is not big problem if the patch does not apply over latest
revision. If it is enough useful, someone will port it to the latest
revision.


- Petri