Support creating AVC-Intra files with -vcodec libx264

[Patrick Dung]

Summary of the bug:
Source file is a large 2vuy file, mediainfo is attached.
After using ffmpeg to create a h.264 file, the playback of the file is not smooth. It hang when there is a transition from the black screen at the beginning to video.
You can check the playback at here:
​https://drive.google.com/file/d/0B1SgNlcZrQJ1ak5Qb2gxeDRld1E/edit?usp=sharing

How to reproduce:
The command to do the conversion:
ffmpeg -v info -i /mnt-data/backup4/vol0/export/CUHK\ 2014-1/V017b.mov -vcodec libx264 -intra -pix_fmt yuv422p10le -vb 100M -x264opts avcintra-class=100 -x264opts colorprim=bt709 -x264opts transfer=bt709 -x264opts colormatrix=bt709 -threads 4 -acodec copy V017b-ffmpeg-git-avcintra100.mov

Please see the attached files for details.

[Carl Eugen Hoyos]

Are you reporting a performance issue of your system?

If not, please provide the input sample, either upload it to ​http://www.datafilehost.com/ or read https://ffmpeg.org/bugreports.html (there is NO filesize limit), do not upload to a sharing site that needs a login!
Is the problem only reproducible with an external library (-vcodec libx264) or also with -vcodec mpeg4?
Which application do you use to test playback? What happens if you use a much smaller resolution or -pix_fmt yuv420p?

[Patrick Dung]

ffmbc produce a smooth output.

1. The sample and output files is located in here:

​https://drive.google.com/folderview?id=0B1SgNlcZrQJ1M051bFVLeGdIYjA&usp=sharing

a) source file is source3.mov
b) ffmpeg produced file: ffmpeg-output.mov. Notice after the opening screen, the playback is sluggish.
c) ffmbc produce a smooth output.

Attached is the conversion details for ffmpeg. I need to use high quality h.264 so I did no test with smaller resolution.

[Patrick Dung]

comment #2

[Patrick Dung]

Note for Comment #2 I used DNxHD as the source file.
The uncompressed source file in the original bugreport is too large.

[Carl Eugen Hoyos]

Sorry if I was unclear:
You did not explain what kind of problems you see when decoding the output file - which application do you use (with what arguments)? The output file you uploaded plays fine here (absolutely no hanging) but it needs a lot of CPU power.
If this is not a performance problem, you should be able to also reproduce it with a much lower resolution, if the problem disappears at a lower resolution, I don't see how it would not be a performance problem.

[Patrick Dung]

The slow problem is written in comment 2 point b.
I have tried to view in ffplay , mpchc player, mplayer and light works editor. Result is the same.

[Carl Eugen Hoyos]

Please provide your MPlayer command line (I was unable to find it in comment:2).
I don't think there is current hardware that allows ffplay to watch your output video in realtime.

[Carl Eugen Hoyos]

Replying to dkt:

c) ffmbc produce a smooth output.

Please provide ffmpeg -i console output for the ffmbc output video.

[Patrick Dung]

for comment #8

[Patrick Dung]

1. Details for using Mplayer to playback attached.

2. for using ffmbc to do conversion:

Originally, I have use AVC-intra 100, ffmbc produced a file with overall bitrate around 90Mbps.
Note I have provide the command to use ffmpeg to do conversion (conversion.txt). Although I have specired AVC-intra 100, it produced a overall bitrate of 175 Mbps (This is another issue with ffmpeg).

In that case, in order to produce a similar bitrate with ffmpeg, I do the conversion with ffmbc to produce AVC-intra 200. It produced a overall bitrate of around 183 Mbps.

3. I have no problem playing back the file produced by ffmbc. I have done side by side playback of the both files and the same time. The file produced by ffmpeg is not smooth, especially after the transition.

4. Please check the files from my google drive, instead of the upload.ffmpeg.org (incomplete upload).

​https://drive.google.com/folderview?id=0B1SgNlcZrQJ1M051bFVLeGdIYjA&usp=sharing

[Carl Eugen Hoyos]

Is there a reason why you can neither post your MPlayer command line nor ffmpeg -i console output?

[Patrick Dung]

Replying to cehoyos:

Is there a reason why you can neither post your MPlayer command line nor ffmpeg -i console output?

Attachment ticket-3597.zip​ added
for comment #8

Is there anything missing?

[Carl Eugen Hoyos]

Replying to dkt:

Is there anything missing?

Yes, an explanation why it makes sense to attach a compressed file that has to be downloaded and uncompressed to get information that fits in one line on this tracker.

I can reproduce the difference between the output files - decoding takes five times as long for the FFmpeg sample - but when this will be analyzed the "bug" will most likely either be a different (older) x264 version in ffmbc (or is this dynamic linking so both ffmpeg and ffmbc use the same x264 library?) or a missing option for ffmpeg that is default for ffmbc: I don't disagree though that we could copy this behaviour.
Could you test -tune fastdecode with ffmpeg in the meantime?

I can play the ffmpeg output file here in realtime with:
$ mplayer -lavdopts threads=8 -vo gl_nosw ffmpeg-output.mov

[Patrick Dung]

Replying to cehoyos:

Replying to dkt:

I can reproduce the difference between the output files - decoding takes five times as long for the FFmpeg sample - but when this will be analyzed the "bug" will most likely either be a different (older) x264 version in ffmbc (or is this dynamic linking so both ffmpeg and ffmbc use the same x264 library?) or a missing option for ffmpeg that is default for ffmbc: I don't disagree though that we could copy this behaviour.
Could you test -tune fastdecode with ffmpeg in the meantime?

I can play the ffmpeg output file here in realtime with:
$ mplayer -lavdopts threads=8 -vo gl_nosw ffmpeg-output.mov

Ok, the fastdecode option produce much better result.
BTW, users expect the playback of the converted files by ffplay and in other NLE is smooth.

When I used ffmpeg to produce 4k yuv444 AVC-intra files (using default settings) in 2014 Jan, I can't playback those file smoothly by a reasonably fast machine (Quad core eight threads desktop).

[Patrick Dung]

For the libx264 library, ffmpeg/ffmbc linked to the same file.
See attached file 'ldd for ffmpeg and ffmbc.txt​'.

[Kieran Kunhya]

Replying to dkt:

Replying to cehoyos:

Replying to dkt:

I can reproduce the difference between the output files - decoding takes five times as long for the FFmpeg sample - but when this will be analyzed the "bug" will most likely either be a different (older) x264 version in ffmbc (or is this dynamic linking so both ffmpeg and ffmbc use the same x264 library?) or a missing option for ffmpeg that is default for ffmbc: I don't disagree though that we could copy this behaviour.
Could you test -tune fastdecode with ffmpeg in the meantime?

I can play the ffmpeg output file here in realtime with:
$ mplayer -lavdopts threads=8 -vo gl_nosw ffmpeg-output.mov

Ok, the fastdecode option produce much better result.

This is almost certainly not AVC-Intra compliant. I'm not sure if FFmpeg supports passing through that option and -vb 100M does not help because AVC-Intra 100 is not 100mbps exactly.

[Carl Eugen Hoyos]

This may have been fixed today, please test with current FFmpeg git head.

[Carl Eugen Hoyos]

Please reopen this ticket if creating AVC-Intra files does not work with current FFmpeg git head / since f2e53808