FFmbc-0.7-rc8

[Baptiste Coudurier]

FFmbc-0.7-rc8:
* Improved MXF muxer compatibility with Sony Vegas Pro 11
* Support encoding H.264 10 bit and 4:2:2 with x264
* Improved Quicktime muxer compatibility with Final Cut Pro and XDCAMHD 422
* Commandline options -vcodec,-acodec,-scodec are not reset anymore between streams
* Faster V210 decoding
* Support writing MXF DNxHD files
* .mpg extension will now produce MPEG-2 PS by default
* Removed IMX bitstream filters, formatting is now done automatically
* Framerate now needs to be explicitely specified when reading raw uncompressed video files
* H264 encoding in MXF format is now supported
* Progressive Quicktime files created will now be properly recognized by FCP
* New filters from BBC: waveform monitor, w3fdif deinterlacing, stretch4to3, repeatframe
* New -metadata_tags cli option to see what metadata tags are supported in each output format
* Export MPEG-2 GOP timecode as metadata
* Correctly read interlaced information from DV files
* DV files produced are now more standard compliant
* Improved quality for the ProRes encoder

FFmbc-0.7-rc7:
* Various minor fixes

FFmbc-0.7-rc6:
* Support P2 MXF files.
* Support Op1a MXF DNxHD files.
* Fix avisynth RGB24/32 upside-down decoding.
* Fix DPX encoding, now compatible with Nuke.

FFmbc-0.7-rc5:
* DV muxer changed to only accept big endian pcm.
* Audio sync disabled by default for GXF files.
* Prores encoder with support for interlaced, 422 and 444.
* Support writing AFD information in MXF files.
* Support V210 and uncompressed 4:2:2 UYVY in MXF files.

FFmbc-0.7-rc4:
* New 'dvcam', 'dvcpro', 'dvcpro50', 'dvcprohd' targets.
* Detect right to left languages in subtitle burning filter.
* Correctly write drop frame system timecode and continuity count in MXF files.
* Correctly use global file duration when displaying information about Quicktime files.
* Correctly compute aspect ratio from clean aperture in Quicktime files.
* Display starting system timecode for MXF files.
* FFprobe now correctly displays width and height for files using h264 cropping.

FFmbc-0.7-rc3:
* Bug fixes

FFmbc-0.7-rc2:
* Support reading AVID MXF OpAtom DNxHD files.
* New video filter 'sub' to burn ASS and SRT subtitles.

FFmbc-0.7-rc1:
* Sync on FFmpeg git 7cbb856efe6ccab7485bb96ad3887472a6519ffa
* New -tff and -bff cli options, -top is removed.
* AVCIntra decoding is now supported.
* Parallel frame multi-threaded decoding is now enabled.
* Prores 422 and Prores 4444 decoding.
* When writing MXF files, use more correct key for KLV Fill packets.
* DVCPROHD encoding in Quicktime or MXF format is now supported.
* Fix detection of some DVCAM files.
* Fix decoding artefact in bottom rows of Quantel DVCPROHD 1080i files.

--
Baptiste COUDURIER
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org

[andrew.k...@gmail.com]

Hi,

Thanks a lot!

No -timecode copy?

Faster ProRes encoder?

Could someone compile it please.

Andrew

[rens.di...@gmail.com]

Hi Baptiste,

Thanks for the update, the new DNxHD in MXF support is very handy
in combination with bmx to create Avid Compatible OP-ATOM files
works great.

Still need to check out H264 in MXF i.c.m. with Avid but looks very
promisising.

Regards Rens

[Phillip Barnett]

That's fantastic news! Thank you very much on behalf of very many grateful people!


Sent from my iPhone

> --
>
> ---
> You received this message because you are subscribed to the Google Groups "ffmbc-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ffmbc-discus...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Phillip Barnett]

Did the one frame difference between audio and video tracks get fixed in this version? ( email thread from 19/06/2012)
Phillip

Sent from my iPhone

On 13 Mar 2013, at 22:55, Baptiste Coudurier <baptiste....@gmail.com> wrote:

[Baptiste Coudurier]

On 03/14/2013 09:46 AM, Phillip Barnett wrote:
> Did the one frame difference between audio and video tracks get fixed in this version? ( email thread from 19/06/2012)
> Phillip
>

Yes, it should be fixed.

[cspar...@gmail.com]

I still seem to be getting the "could not find essence container ul" when trying to remux AVCHD into an MXF. Am I missing something?

[Baptiste Coudurier]

On 03/26/2013 02:11 PM, cspar...@gmail.com wrote:
> I still seem to be getting the "could not find essence container ul" when trying to remux AVCHD into
> an MXF. Am I missing something?

Can you please post the full output ?

[cspar...@gmail.com]

media$ ffmbc -i "20120926 - Jesse Hoagg Interview - FS700 - 00000 - Setup.MTS" -vcodec copy -acodec copy "remuxtest.MXF"
FFmbc version 0.7-rc8
Copyright (c) 2008-2013 Baptiste Coudurier and the FFmpeg developers
Input #0, mpegts, from '20120926 - Jesse Hoagg Interview - FS700 - 00000 - Setup.MTS':
  Duration: 00:00:09.07, bitrate: 22834 kb/s
  Program 1
    Stream #0.0[0x1011](und): Video: h264 (High), yuv420p, 1920x1080p [PAR 1:1 DAR 16:9], 29.97 fps
    Stream #0.1[0x1100](und): Audio: pcm_bluray, 48000 Hz, stereo, s16, 1536 kb/s
    Stream #0.2[0x1200](und): Subtitle: pgssub
[mxf @ 0x101807c00] track 1: could not find essence container ul, codec not currently supported in container
Could not write header for output file #0

[cspar...@gmail.com]

I've also tried mapping in a pcm_f32le audio track just in case the audio was a problem. Same result.

[Baptiste Coudurier]

On 03/26/2013 02:38 PM, cspar...@gmail.com wrote:
> I've also tried mapping in a pcm_f32le audio track just in case the audio was a problem. Same result.
>
> On Tuesday, March 26, 2013 5:35:24 PM UTC-4, cspar...@gmail.com wrote:
>
> media$ ffmbc -i "20120926 - Jesse Hoagg Interview - FS700 - 00000 - Setup.MTS" -vcodec copy
> -acodec copy "remuxtest.MXF"
> FFmbc version 0.7-rc8
> Copyright (c) 2008-2013 Baptiste Coudurier and the FFmpeg developers
> Input #0, mpegts, from '20120926 - Jesse Hoagg Interview - FS700 - 00000 - Setup.MTS':
> Duration: 00:00:09.07, bitrate: 22834 kb/s
> Program 1
> Stream #0.0[0x1011](und): Video: h264 (High), yuv420p, 1920x1080p [PAR 1:1 DAR 16:9],
> 29.97 fps
> Stream #0.1[0x1100](und): Audio: pcm_bluray, 48000 Hz, stereo, s16, 1536 kb/s
> Stream #0.2[0x1200](und): Subtitle: pgssub
> [mxf @ 0x101807c00] track 1: could not find essence container ul, codec not currently
> supported in container
> Could not write header for output file #0
>

It's the audio track that's causing problem, use s16le or s24le

[adam...@gmail.com]

PLEASE make the ProRes encoder faster - ffmpeg is still at least 3x faster than this latest build of ffmbc at prores encoding.

PS. please please please!

On Wednesday, March 13, 2013 10:55:29 PM UTC, Baptiste Coudurier wrote:

[Baptiste Coudurier]

Hi

On 03/27/2013 06:19 AM, adam...@gmail.com wrote:
> PLEASE make the ProRes encoder faster - ffmpeg is still at least 3x faster than this latest build of
> ffmbc at prores encoding.

FFmpeg quality is way lower and target bitrate is way higher so I don't think you can compare
them fairly.

I don't think the encoder will get significantly faster any time soon unless somebody less
jump on it or it get sponsored.

[andrew.k...@gmail.com]

As much as ffmpeg has not much to do with Apples bitrate levels for each mode quality is about the same as ffmbc.

It's around -1dB in PSNR difference at the same bitrate, so I would not call it big difference (if any).

Andrew

[Baptiste Coudurier]

On 03/28/2013 03:43 AM, andrew.k...@gmail.com wrote:
>
> As much as ffmpeg has not much to do with Apples bitrate levels for each mode quality is about the
> same as ffmbc.
> It's around -1dB in PSNR difference at the same bitrate, so I would not call it big difference (if any).

I did not see that at all. Could you please share your samples and numbers ?

[andrew.k...@gmail.com]

Hi

Here is PSNR graph for some different modes/apps. Source is 720 frames extract from STEM evaluation footage- 8bit YUY2 source (it was never compressed).

PRO HQ comes from one of the Apple licensed ProRes implementation on PC. PSNR values based on avisynth (8bit mode). If you look at Apples white paper numbers about match theirs- they also used STEM footage (my extract is just after opening titles).

If you look by bitrate- ffmbc is more efficient, but not by huge number. If you look by "modes" than it's clearly way better than ffmpeg.

If I have time I will make graphs for bitrate allocation, which may be quite interesting.

[andrew.k...@gmail.com]

Here is bitrate graph- very interesting, as predicted. It's done with some Japanese software for analyzing AVIs (all ProRes files need to be re-wrapped to AVI). Looks like app is accurate or at least accurate enough for some conclusions.

ffmpeg does not use "bitrate clipping" as per Apple spec- bitrate jumps for difficult scene very high.

ffmbc is strict, thought PRO solution is even more strict. 

Apple's peak restrictions are good in some way, but cause some very difficult scenes loosing a lot of quality. Relative quality is not constant over whole sample. PSNR around 40 is not that great for intermediate codec.

ffmbc with q=6 should look like ffmpeg- no peak restrictions, so I did not include it.

Quite new GV HQX codes is interesting and more flexible- it can clip max bitrate to set value or use Q setting to keep constant quality for trade of big peaks (all user selectable).

Andrew

[Baptiste Coudurier]

Andrew,

Thanks a lot for the data, I really appreciate it.

Humm, if we compare the 220Mb version, the difference is very close to 2db for many frames. IMHO 2db
is pretty big difference.
We should also be able to use -b 220Mb to compare.
If we compare the PSNR equivalent files, 45Mb difference is pretty big too IMHO.

About speed, -cqp/-qscale should be pretty fast. And FFmbc is focusing on quality instead of speed,
and tends to follow apple's encoder behaviour.

I'm sure there are some speed optimizations left to be done but I don't have much time currently,
but if somebody wants to give it a shot, please do.

--
Baptiste COUDURIER
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org

On 03/29/2013 12:15 PM, andrew.k...@gmail.com wrote:
> Hi
>
> Here is PSNR graph for some different modes/apps. Source is 720 frames extract from STEM evaluation
> footage- 8bit YUY2 source (it was never compressed).
> PRO HQ comes from one of the Apple licensed ProRes implementation on PC. PSNR values based on
> avisynth (8bit mode). If you look at Apples white paper numbers about match theirs- they also used
> STEM footage (my extract is just after opening titles).
>

> <https://lh6.googleusercontent.com/-pFalCLnVSL0/UVXm9frf-9I/AAAAAAAAAAM/KWrrMvvJRDs/s1600/prores.png>

>
>
> If you look by bitrate- ffmbc is more efficient, but not by huge number. If you look by "modes" than
> it's clearly way better than ffmpeg.
> If I have time I will make graphs for bitrate allocation, which may be quite interesting.
>
>
>
>
>
>
> On Friday, March 29, 2013 12:38:36 AM UTC, Baptiste Coudurier wrote:
>

> On 03/28/2013 03:43 AM, andrew.k...@gmail.com <javascript:> wrote:
> >
> > As much as ffmpeg has not much to do with Apples bitrate levels for each mode quality is about
> the
> > same as ffmbc.
> > It's around -1dB in PSNR difference at the same bitrate, so I would not call it big difference
> (if any).
>
> I did not see that at all. Could you please share your samples and numbers ?
>
> --
> Baptiste COUDURIER
> Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
> FFmpeg maintainer http://www.ffmpeg.org
>

[andrew.k...@gmail.com]

Hi,

Most important- it's as good as Apple certified implementation.

2nd- it's not restricted to Apple's modes.

I assume more speed will come- it's not that bad, but in the same time GV HQX is 10x faster than realtime (if you RAID is fats enough :)).

It just needs a bit of work on threading- more cores, less efficiency/core for now.

Andrew

[andrew.k...@gmail.com]

Hi,

Here is some codec table:

it shows how good/bad modern intermediate codecs are. It's not some big study- just quick work, even if so, it took a bit of time to do. Tests done on 8bit sample, even if most codecs are 10bit capable. 10bit source usually compresses better than 8bit, so PSNR would be rather higher (1-2dB maybe). Yellow/dark blue- surprisingly bad/good results. Maybe it will be useful for some open source development (free for non-business use).

Main conclusions:

- all intermediate codecs have about the same efficiency (maybe with small exception for Cineform, which is also non-DCT based),

- SR codec is good, but does not shine or represent anything special in terms of efficiency (it's also strictly CBR, so problems with very difficult scenes even with SR 440 mode)

- AVC-I, JPEG2000 at 100Mbit are good, but can't be really called intermediate codecs- to big quality loss,

- Cineform, (also related to GV HQX, but bit less) is "very VBR" and deliver very consistent quality (min PSNR close to avg) regardless of scenes complexity- for offline use great feature, can be a problem for eg, some recorders with limited bandwidth/processing power,  

- ProRes, DNxHD seams to struggle a bit with difficult scenes (mainly due to peak restriction, but maybe not only?),

- lossless codecs can produces files at the same size (avg bitrate) as eg. SR codec, but for the price of high peaks- but encoding is 100% lossless,

- why there is no 10bit lossless codec (not JPEG2000 or AVC based, which are bit CPU hungry)?

- Cineform with HigherHD setting puts SR Lite into shame (of course for trade of some bitrate peaks), 

- out of all of them Cineform stands out and represents most technically advanced one, with huge possibilities (also due to features packed SDK). GV HQX is also great, thought unknown.

And no- I'm not related to any mentioned company in any way.

Andrew

[Baptiste Coudurier]

Wow this is great. Thanks a lot.

About lossless codes in 10bits you might

want to try FFV1 that should support it

-- 

Baptiste Coudurier

--

[andrew.k...@gmail.com]

Hi,

Yes, but very slow and with very limited support.

In the same time very efficient: 243Mbit/342Mbit peak. Video has 2.35:1 AR, so quite a lot of black, but even so good result.

Andrew

[Baptiste Coudurier]

Andrew,

Nice. I believe there is threading available in the most recent versions so it should help a bit.

Btw I noticed something strange in the results, the quality of FFmbc DNxHD 0.7rc8 does not seem
right. Are you using very recent FFmpeg to decode or FFmbc ? There was a big bug in decoding.

Otherwise I might have to double check, since on my side I got better results with 0.7rc8 since
I fixed the quant bias.

--
Baptiste COUDURIER
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org

On 04/01/2013 01:26 PM, andrew.k...@gmail.com wrote:
> Hi,
>
> Yes, but very slow and with very limited support.
>
> In the same time very efficient: 243Mbit/342Mbit peak. Video has 2.35:1 AR, so quite a lot of black,
> but even so good result.
>
>
> Andrew
>
>
>
> On Sunday, March 31, 2013 4:58:33 AM UTC+1, Baptiste Coudurier wrote:
>
> Wow this is great. Thanks a lot.
> About lossless codes in 10bits you might
> want to try FFV1 that should support it
>
> --
> Baptiste Coudurier
>

> On Mar 30, 2013, at 11:09 AM, andrew.k...@gmail.com <javascript:> wrote:
>
>> Hi,
>>
>> Here is some codec table:
>>
>>

>> <https://lh3.googleusercontent.com/-AatV6UB3vAQ/UVcpWTE2_xI/AAAAAAAAAAk/VZvPkE8TdNs/s1600/codecs.png>

>> ffmbc-discus...@googlegroups.com <javascript:>.

>> For more options, visit https://groups.google.com/groups/opt_out

>> <https://groups.google.com/groups/opt_out>.

[andrew.k...@gmail.com]

Hi,

Well- I did double check as result was so low. Than I tried rc7 and ffmpeg and these were fine.

File gets decoded by qt plugin for avisynth and as per 2 other results everything seams to be fine.

I can check again.

Andrew

[andrew.k...@gmail.com]

This time I decoded DNxHD back to YUV in ffmbc, but results are about the same- tiny difference in min PSNR (40.49)

PSNR drops<42 only for 10 most difficult frames.


Andrew

[Baptiste Coudurier]

Andrew,

This is strange. So you confirm that rc7 is better than rc8 ? Could you please point me to the
sample you are using ? I need to fix this.

Thanks

--
Baptiste COUDURIER
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org

On 04/01/2013 02:15 PM, andrew.k...@gmail.com wrote:
> Hi,

>
>
> This time I decoded DNxHD back to YUV in ffmbc, but results are about the same- tiny difference in
> min PSNR (40.49)

> PSNR drops<43 only for 10 most difficult frames.
>
>
> Andrew
>
>

> On Monday, April 1, 2013 10:07:12 PM UTC+1, andrew.k...@gmail.com wrote:
>

[andrew.k...@gmail.com]

Hi,

Yes- I will cut out 40 frames where PSNR drops so much and send you link (my internet upload is slow :()

It may be also issue with ProRes, as even at q=2 (with peak at 480Mbit) PSNR is only at 43dB- other codecs deliver >50 with peak at 350Mbit.

Andrew

[in...@opsomai.com]

Hi,

First of all: thank you for this new release that gives us a unified version for H264 MXF 10 bit encoding and all our other needs, as H264 browsing generation or DNxHD / ProRes delivery.

One question about your release notes:

>  * Export MPEG-2 GOP timecode as metadata 

What does it mean? We currently use our own code for getting MPEG-2 files timecode, since ffmbc does not give it. According to that point, I thought we could use ffmbc instead, but I tried with some samples and rc8 did not display any timecode. I may have misunderstood your point.

Thanks again

David

[Baptiste Coudurier]

Indeed, this is not intended, the code is there. Let me fix this.

[in...@opsomai.com]

Hi,

I tested the new feature:

 * Support writing MXF DNxHD files

and found some compatibility issues with VLC.

I took a MXF / H264 Intra 4:2:2 10 bits tff / 2 stereo tracks as input and used the following command:

ffmbc -i $Source -f mxf -vcodec dnxhd -pix_fmt yuv422p10le -tff -b 185000k -acodec copy -timecode 01:00:00:00 $Target -newaudio

The target file can be found at the following URL:

http://www.opsomai.com/download/CFRT/Pivot_HD_TFF_4A_DNxHD.mxf

This file may be Avid compatible, but it cannot be played by VLC that says it has a "undf" video format. Nevertheless, it can be played by MXF4mac, with the 4 audio channels. The same command line with a "mov" target produced a file that can be read by VLC.

After all, this may be a VLC bug!

David

[Baptiste Coudurier]

On 04/23/2013 09:34 AM, in...@opsomai.com wrote:
> Hi,
>
> I tested the new feature:
>
> * Support writing MXF DNxHD files
>
>
> and found some compatibility issues with VLC.
>
> I took a MXF / H264 Intra 4:2:2 10 bits tff / 2 stereo tracks as input and used the following command:
>

> /ffmbc -i $Source -f mxf -vcodec dnxhd -pix_fmt yuv422p10le -tff -b 185000k -acodec copy -timecode
> 01:00:00:00 $Target -newaudio/
> /
> /

> The target file can be found at the following URL:
>
> http://www.opsomai.com/download/CFRT/Pivot_HD_TFF_4A_DNxHD.mxf
>
> This file may be Avid compatible, but it cannot be played by VLC that says it has a "undf" video
> format. Nevertheless, it can be played by MXF4mac, with the 4 audio channels. The same command line
> with a "mov" target produced a file that can be read by VLC.
>
> After all, this may be a VLC bug!

VLC might just not supported DNxHD in MXF yet. If MXF4mac plays it, it is probably somewhat correct :)