Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#237 closed defect (fixed)

ffv1 v2

Reported by: dericed Owned by:
Priority: normal Component: avcodec
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

Using ffv1 version 2 to encode yuv422p10le and then decoding back to yuv422p10le results in the loss the right 25% of the image. See samples attached.

v210 to ffv1 v2

ffmpeg -y -vsync 0 -i unc_10_bit.mov -vcodec ffv1 -coder 1 -an unc_10_bit_ffv1.mov
ffmpeg version git-N-30179-g8d95317, Copyright (c) 2000-2011 the FFmpeg developers
  built on May 24 2011 13:40:22 with gcc 4.2.1 (Apple Inc. build 5666) (dot 3)
  configuration: 
  libavutil    51.  2. 1 / 51.  2. 1
  libavcodec   53.  6. 0 / 53.  6. 0
  libavformat  53.  2. 0 / 53.  2. 0
  libavdevice  53.  0. 0 / 53.  0. 0
  libavfilter   2. 10. 0 /  2. 10. 0
  libswscale    0. 14. 0 /  0. 14. 0
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x101012400] Could not find codec parameters (Data: tmcd / 0x64636D74)

Seems stream 0 codec frame rate differs from container frame rate: 2997.00 (2997/1) -> 29.97 (2997/100)
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'unc_10_bit.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 537199360
    compatible_brands: qt  
    creation_time   : 2009-12-14 22:30:48
  Duration: 00:10:32.86, start: -88.288288, bitrate: 47 kb/s
    Stream #0.0(eng): Video: v210, yuv422p10le, 720x486, 223724 kb/s, PAR 10:11 DAR 400:297, 29.97 fps, 29.97 tbr, 2997 tbn, 2997 tbc
    Metadata:
      creation_time   : 2009-12-14 22:30:48
    Stream #0.1(eng): Audio: pcm_s16be, 48000 Hz, 2 channels, s16, 1536 kb/s
    Metadata:
      creation_time   : 2009-12-14 22:30:48
    Stream #0.2(eng): Data: tmcd / 0x64636D74
    Metadata:
      creation_time   : 2009-12-14 22:30:48
[buffer @ 0x100d02000] w:720 h:486 pixfmt:yuv422p10le tb:1/1000000 sar:10/11 sws_param:
[mov @ 0x10102c400] Warning, using MS style video codec tag, the file may be unplayable!
Output #0, mov, to 'unc_10_bit_ffv1.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 537199360
    compatible_brands: qt  
    creation_time   : 2009-12-14 22:30:48
    encoder         : Lavf53.2.0
    Stream #0.0(eng): Video: ffv1, yuv422p10le, 720x486 [PAR 10:11 DAR 400:297], q=2-31, 200 kb/s, 2997 tbn, 29.97 tbc
    Metadata:
      creation_time   : 2009-12-14 22:30:48
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop, [?] for help
frame=    4 fps=  0 q=0.0 Lsize=    1042kB time=88.42 bitrate=  96.6kbits/s    
video:1041kB audio:0kB global headers:0kB muxing overhead 0.074731%

ffv1 back into v210

ffmpeg -y -i unc_10_bit_ffv1.mov -vcodec v210 unc_10_bit_ffv1_back_to_v210.mov
ffmpeg version git-N-30179-g8d95317, Copyright (c) 2000-2011 the FFmpeg developers
  built on May 24 2011 13:40:22 with gcc 4.2.1 (Apple Inc. build 5666) (dot 3)
  configuration: 
  libavutil    51.  2. 1 / 51.  2. 1
  libavcodec   53.  6. 0 / 53.  6. 0
  libavformat  53.  2. 0 / 53.  2. 0
  libavdevice  53.  0. 0 / 53.  0. 0
  libavfilter   2. 10. 0 /  2. 10. 0
  libswscale    0. 14. 0 /  0. 14. 0

Seems stream 0 codec frame rate differs from container frame rate: 2997.00 (2997/1) -> 29.97 (2997/100)
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'unc_10_bit_ffv1.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 512
    compatible_brands: qt  
    creation_time   : 1970-01-01 00:00:00
    encoder         : Lavf53.2.0
  Duration: 00:00:00.13, start: 0.000000, bitrate: 63973 kb/s
    Stream #0.0(eng): Video: ffv1, yuv422p10le, 720x486, 63914 kb/s, PAR 10:11 DAR 400:297, 29.97 fps, 29.97 tbr, 2997 tbn, 2997 tbc
    Metadata:
      creation_time   : 1970-01-01 00:00:00
[buffer @ 0x100d012e0] w:720 h:486 pixfmt:yuv422p10le tb:1/1000000 sar:10/11 sws_param:
Output #0, mov, to 'unc_10_bit_ffv1_back_to_v210.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 512
    compatible_brands: qt  
    creation_time   : 1970-01-01 00:00:00
    encoder         : Lavf53.2.0
    Stream #0.0(eng): Video: v210, yuv422p10le, 720x486 [PAR 10:11 DAR 400:297], q=2-31, 200 kb/s, 2997 tbn, 29.97 tbc
    Metadata:
      creation_time   : 1970-01-01 00:00:00
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop, [?] for help
frame=    4 fps=  0 q=0.0 Lsize=    3646kB time=0.13 bitrate=223770.0kbits/s    
video:3645kB audio:0kB global headers:0kB muxing overhead 0.020174%

Attachments (3)

unc_10_bit.mov.zip (1.9 MB) - added by dericed 6 years ago.
original v210
unc_10_bit_ffv1.mov (1.0 MB) - added by dericed 6 years ago.
to ffv1 version 2
unc_10_bit_ffv1_back_to_v210.mov.zip (1.5 MB) - added by dericed 6 years ago.
and back to v210

Change History (12)

Changed 6 years ago by dericed

original v210

Changed 6 years ago by dericed

to ffv1 version 2

Changed 6 years ago by dericed

and back to v210

comment:1 Changed 6 years ago by cehoyos

  • Status changed from new to open

I cannot reproduce this:
I encoded unc_10_bit.mov with above command line on 32 and 64 bit Linux and PPC OSX, and in all cases, the result plays fine (while your file unc_10_bit_ffv1.mov is broken).

comment:2 Changed 6 years ago by cehoyos

md5sum of the resulting mov file (with -an!) is bb5a77c0e436a464290b005c19612410

comment:3 Changed 6 years ago by dericed

cehoyos: Did you test with ffv1 version 2? Changing line 935 of ffv1.c to " s->version=2;". ffv1 version <2 works fine for me, but version 2 (multithreading support) doesn't.

comment:4 Changed 6 years ago by michael

  • Reproduced by developer set
  • Resolution set to fixed
  • Status changed from open to closed
  • Version changed from unspecified to git-master

Will be fixed with my next git push

comment:5 Changed 6 years ago by dericed

testing from the new version
new output: http://www.avpreserve.com/v210_ffv2X2.mov

ffmpeg -i v210.mov -vcodec ffv1 -coder 1 -threads 0 -an v210_ffv1X.mov
ffmpeg version git-N-30166-g1bc81bf, Copyright (c) 2000-2011 the FFmpeg developers
  built on May 23 2011 22:42:17 with gcc 4.2.1 (Apple Inc. build 5666) (dot 3)
  configuration: --enable-gpl --enable-libfreetype --enable-frei0r --enable-libx264 --enable-shared
  libavutil    51.  2. 1 / 51.  2. 1
  libavcodec   53.  6. 0 / 53.  6. 0
  libavformat  53.  2. 0 / 53.  2. 0
  libavdevice  53.  0. 0 / 53.  0. 0
  libavfilter   2. 10. 0 /  2. 10. 0
  libswscale    0. 14. 0 /  0. 14. 0
  libpostproc  51.  2. 0 / 51.  2. 0

Seems stream 0 codec frame rate differs from container frame rate: 2997.00 (2997/1) -> 29.97 (2997/100)
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'v210.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 537199360
    compatible_brands: qt  
    creation_time   : 2010-06-22 04:33:09
  Duration: 00:00:10.21, start: 0.000000, bitrate: 223727 kb/s
    Stream #0.0(eng): Video: v210, yuv422p10le, 720x486, 223724 kb/s, PAR 10:11 DAR 400:297, 29.97 fps, 29.97 tbr, 2997 tbn, 2997 tbc
    Metadata:
      creation_time   : 2010-06-22 04:33:09
[buffer @ 0x100f01140] w:720 h:486 pixfmt:yuv422p10le tb:1/1000000 sar:10/11 sws_param:
[mov @ 0x101000600] Warning, using MS style video codec tag, the file may be unplayable!
Output #0, mov, to 'v210_ffv1X.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 537199360
    compatible_brands: qt  
    creation_time   : 2010-06-22 04:33:09
    encoder         : Lavf53.2.0
    Stream #0.0(eng): Video: ffv1, yuv422p10le, 720x486 [PAR 10:11 DAR 400:297], q=2-31, 200 kb/s, 2997 tbn, 29.97 tbc
    Metadata:
      creation_time   : 2010-06-22 04:33:09
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop, [?] for help
frame=  306 fps= 17 q=0.0 Lsize=   73454kB time=10.21 bitrate=58934.4kbits/s    
video:73450kB audio:0kB global headers:0kB muxing overhead 0.004394%

comment:6 Changed 6 years ago by cehoyos

  • Resolution fixed deleted
  • Status changed from closed to reopened

If you want your problems fixed, please consider explaining them (as you did originally).

comment:7 Changed 6 years ago by dericed

cehoyos: To explain it, the resulting ffv1(version 2) encoded file displays improperly at the right most quarter of the image (as before). The update from yesterday now adds visual issues to the right half of the left half of the image (2nd verical quarter). In this quarter the images are jumpy and misplaced, see: http://www.avpreserve.com/v210_ffv2X2.mov.

comment:8 Changed 6 years ago by cehoyos

  • Resolution set to fixed
  • Status changed from reopened to closed

I believe this really was fixed, but you have to update both your encoding and your decoding application.
(There is some indication that the version 2 format was not frozen yet.)

Please test again.

comment:9 Changed 6 years ago by michael

btw, to elaborate on the original bug, the issue was that the slices encoded & decoded by multiple threads where using positions calculated based on 8bit while they really worked with 16bit thus the right side was never encoded, while the middle was encoded (and decoded) twice
I also was not able to reproduce an issue with http://www.avpreserve.com/v210_ffv2X2.mov.

Note: See TracTickets for help on using tickets.