Based on your reply I have the following comments and suggestions.
1. Is it possible that you find some time and create a "bitrate finder
table" that contains Video resolutions, quality and suggested
bitrates. I suggest something like the following:
Bitrate finder
=========
Portable Standard
Pro (use VLC)
Format low normal high low normal high low normal high
lossless
----------------------------------------------------------------------------------------------------------------------------
SD formats here
720p/23.976 36Mb
60Mb 90Mb 120Mb
720p/24 36Mb
60Mb 90Mb 120Mb
720p/25 36Mb
60Mb 90Mb 120Mb
720p/48 90Mb
120Mb 180Mb 220Mb
720p/50 90Mb
120Mb 180Mb 220Mb
720p/59.94
1080p/23.976
1080p/24
1080p/25
1080p/48
1080p/50
1080p/59.94
2k - 8k resolution here
-----------------------------------------------------------------------------------------------------------------------------
I know there are profiles defined in the dirac and diracpro
specification, but these profiles are in my eyes not suitable for
"customers". Normal people are not very interested what a decoder can
do, they want a video for a purpose (Portable device, Home Theatre,
Streaming, Web site ...).
Based on the table above, I suggest to create some standard, customer
aware, profiles, like the Divx ones. Specially hardware vendors like
profiles, because they can verify and promote that their hardware
works well up to resolution xy with profile yz. This would also add
the possibility to add these profiles direct to encoding tools like
gstreamers schrödinger plugin. "profile=pro-lossless" or
"profile=portable-low". For the pro ones, probably the BBC has already
created some profiles for internal use?
If you want, I create the base table in the wiki. For the content, I
would need some example bitrates, based on your experiences and some
informations on how the Dirac codec scales. Does it scale linearly or
more exponentially?
I think such a table could help every new Dirac user like me.
2. I know this is definitely not a gstreamer mailing list, but
gstreamer need definitely a "Coding Manual". I have managed to get it
working, but I think, I needed a way to long to find out what options
I can add to the various codecs. For a lot of plugins the gstreamer
website does not provide any info.
Regards
@Anuradha: Thanks, I would really appreciate if I could use ffmpeg in
the future for DiracPro coding.
On Mon, Aug 25, 2008 at 10:04 PM, David Schleef <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 25, 2008 at 12:09:56PM +0200, Kevin Bortis wrote:
>> Hi,
>>
>> Is there a way to encode DiracPro video under linux or mac os x at the
>> current development stage? I have here some uncompressed 4:2:2 video
>> files with Dolby A/52 audio I would like to convert to DiracPro
>> embedded in mpegts files.
>>
>> I have read some ffmpeg docu and have compiled ffmpeg under linux with
>> libschroedinger support. Do I have only to add the "-intra" option to
>> get DiracPro instead of Dirac?
>>
>> If someone could give a working ffmpeg example I would be very happy.
>
> This is what I use for intermediate work in HD720. Constant bitrate
> at 100 Mbit/sec, disable arithmetic coding, intra-only:
>
> gop-structure=1 enable-noarith=1 rate-control=1 bitrate=100000000
>
> I use 100 Mbit/sec as a bit rate because it's nearly lossless and
> disk usage isn't a concern for me. Another, but variable bit rate:
>
> gop-structure=1 enable-noarith=1 rate-control=0 noise-threshold=50
>
> I'm not certain how these convert into ffmpeg options. I use gstreamer
> almost exclusively, which exposes the schroedinger options directly.
>
> Explanation:
>
> gop-structure=1: Intra-only. There isn't an explicit "use VC-2"
> option currently, but this does exactly that. You pretty much
> need this for any intermediate format currently.
>
> enable-noarith=1: Uses VLC coding instead of arithmetic coding.
> VLC coding is a *lot* faster for both encoding and decoding, which
> is convenient at really high bit rates.
>
> rate-control=1: Encodes at a constant bit rate. Each picture is
> usually within a few percent of the target size.
>
> bitrate=100000000: Bit rate, in bits per second.
>
> rate-control=0: Encodes at a constant quantisation noise threshold.
> The quantisation noise will never be higher than this threshold,
> although it can often be lower. This is a variable bit rate
> method that isn't very good.
>
> noise-threshold: The quantisation noise threshold converts directly
> into quantisation factors, and is roughly correlated with PSNR.
>
> Optional:
>
> au-distance=1: This adds a sequence header to every frame, which
> is good for seeking.
>
> Future directions:
>
> I'm currently working on a rate distortion method for variable bit
> rate which is much better than the current "constant noise threshold"
> method. One of the points of using a variable bit rate method is to
> spend bits wisely at a global level -- i.e., use bits to compress
> pictures, not noise. CNT has the problem that it spends a lot of
> bits on pictures that have noise levels above the noise threshold.
>
> Also, at some point, I'd like someone to implement (or hire me to
> implement) a GOP structure that is highly seekable, but uses some
> motion compensation. The most relevant limit is "number of reference
> pictures that need to be decoded to decode picture N". For intra-only,
> this is 1. For a highly seekable stream, this should be small, say
> 2-4.
>
> Both of these techniques would be useful for intermediate storage.
>
>
>
> dave...
>
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Schrodinger-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/schrodinger-devel
