Định dạng OGV phát đúng trên máy tính của tôi nhưng chuyển mã giảm (trùng lặp?)

Tôi đã tạo một bộ screencasts bằng recordmydesktop trên ubfox 12.10. Đầu ra là một tệp ogv. Khi tôi xem tệp ogv bằng trình phát phim mặc định (totem), nó trông ổn - âm thanh và video được đồng bộ hóa. Khi được chuyển mã (bởi tôi hoặc youtube), âm thanh và video không đồng bộ. Có vẻ như tôi bỏ qua một hoặc hai slide trong khi kể chuyện.

Cập nhật

Tôi nghi ngờ vấn đề được mô tả đúng hơn là bỏ các khung trùng lặp trong quá trình chuyển mã. Chuyển đổi video nơi chuột di chuyển dường như thường hoạt động tốt. Nhưng khi tôi chỉ nói chuyện trong một slide thì những khung hình trùng lặp đó bị bỏ đi.

Tôi đã thấy điều này nhưng đó không phải là tình huống của tôi (cố gắng đi từ ogv -> bất cứ điều gì) /superuser/436187/ffmpeg-convert-video-w-dropping-frames-out-of-sync

Tập tin AVI dường như dịch chính xác! Tôi cho rằng đây sẽ là một gợi ý lớn cho ai đó. Tôi vẫn muốn theo dõi vấn đề cơ bản. Tôi đang thử nghiệm chuyển đổi các video trước đây của mình sang AVI nhưng phải mất một thời gian vì tôi phải kiểm tra từng chuyển đổi.

Ví dụ

Đây là tệp OGV gốc từ gtk-recordmydesktop: http://dl.dropbox.com/u/64693533/sync_test/sync_test1.ogv

Video bắt đầu với một slide trong 10 giây, sau đó tiến lên 3 slide 5 mỗi lần. Mỗi lần tôi tiến lên các slide tôi cũng chạm vào micrô (10 giây, 15 giây, 20 giây, 25 giây).

Dưới đây là một số chuyển đổi đã được thực hiện (mỗi màn hình hiển thị các vấn đề về thời gian video của riêng nó):

http://dl.dropbox.com/u/64693533/sync_test/sync_test1.mp4

• cái này hiển thị slide đầu tiên trong khung đầu tiên nhưng nhanh chóng vượt qua nó
• điều này đã được thực hiện bằng cách sử dụng ffmpeg stock

http://dl.dropbox.com/u/64693533/sync_test/sync_test1.ffmpeg-static.mp4

• cái này khá gần - vì một số lý do ở tuổi 13, nó quyết định tiến lên
• điều này đã được thực hiện bằng cách sử dụng bản dựng tĩnh của ffmpeg từ vài ngày trước

Đây là trên youtube - bạn có thể thấy rằng vào khoảng 13 giây, nó tiến bộ sớm (từ slide 1 -> slide 2):

Dưới đây là bằng chứng tệp OGV hoạt động chính xác:

dịch ffmpeg

Sử dụng ffmpeg hoặc avconv tôi dường như nhận được kết quả tương tự như youtube (quá trình chuyển đổi dường như xảy ra sớm nhưng không nhất thiết phải cùng một lúc).

Đây là lệnh tôi sử dụng (với một bản dựng tĩnh gần đây của ffmpeg) và đầu ra:

$ ~ / ffmpeg / ffmpeg -i JSP.ogv JSP.mp4
phiên bản ffmpeg N-50025-gb8bb661 Bản quyền (c) 2000-2013 các nhà phát triển FFmpeg
  được xây dựng vào ngày 17 tháng 2 năm 2013 05:23:03 với gcc 4.6 (Debian 4.6.3-1)
  cấu hình: --prefix = / root / ffmpeg-static / 64bit --extra-cflags = '- I / root / ffmpeg-static / 64bit / include -static' --extra-ldflags = '- L / root / ffmpeg- static / 64bit / lib -static '--extra-libs =' - lxml2 -lexpat -lfreetype '--enable-static --disable-shared --disable-ffserver --disable-doc --enable-bzlib --enable -zlib --enable-postproc --enable-runtime-cpudetect --enable-libx264 --enable-gpl --enable-libtheora --enable-libvorbis --enable-libmp3lame --enable-Gray --enable-libass - -enable-libfreetype --enable-libopenjpeg --enable-libspeex --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-version3 --enable-libvpx
  libavutil 52. 17.101 / 52. 17.101
  libavcodec 54. 91.103 / 54. 91.103
  libavformat 54. 63.100 / 54. 63.100
  libavdevice 54. 3.103 / 54. 3.103
  libavfilter 3. 38.100 / 3. 38.100
  libswscale 2. 2.100 / 2. 2.100
  libswresample 0. 17.102 / 0. 17.102
  libpostproc 52. 2.100 / 52. 2.100
[ogg @ 0x34d4640] Nhiều fvdone cho cùng một luồng không được triển khai. Cập nhật phiên bản FFmpeg của bạn lên phiên bản mới nhất từ ​​Git. Nếu sự cố vẫn xảy ra, điều đó có nghĩa là tệp của bạn có một tính năng chưa được triển khai.
[ogg @ 0x34d4640] Phân tích cú pháp tiêu đề không thành công cho luồng 0
[ogg @ 0x34d4640] Tệp bị hỏng, khung hình chính không được đánh dấu chính xác.
Đầu vào # 0, ogg, từ 'JSP.ogv':
  Thời lượng: 00: 12: 49,67, bắt đầu: 0,000000, bitrate: 224 kb / s
    Luồng # 0: 0: Dữ liệu: không có
    Luồng # 0: 1: Video: theora, yuv420p, 1600x880 [SAR 1: 1 DAR 20:11], 15 khung hình / giây, 15 tbr, 15 tbn, 15 tbc
    Metadata:
      RECORDMYDESKTOP: 0.3.8.1
    Luồng # 0: 2: Âm thanh: vorbis, 22050 Hz, đơn âm, fltp, 89 kb / s
[libx264 @ 0x369c5e0] bằng SAR = 1/1
[libx264 @ 0x369c5e0] bằng cách sử dụng các khả năng của cpu: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
[libx264 @ 0x369c5e0] hồ sơ Cao, cấp 4.0
[libx264 @ 0x369c5e0] 264 - lõi 129 r2230 1cffe9f - H.264 / MPEG-4 AVC codec - Copyleft 2003-2012 - http://www.videolan.org/x264.html - tùy chọn: cabac = 1 ref = 3 deblock = 1: 0: 0 analyse = 0x3: 0x113 me = hex subme = 7 psy = 1 psy_rd = 1,00: 0,00 hỗn hợpf = 1 me_range = 16 chroma_me = 1 trellis = 1 8x8dct = 1 cqm = 0 deadzone = 21,11 1 chroma_qp_offset = -2 chủ đề = 6 lookahead_threads = 1 lát cắt_threads = 0 nr = 0 decimate = 1 interloped = 0 Bluray_compat = 0 ràng buộc = 0 bframes = 3 b_pyramid = 2 b_ad = 1 weightp = 2 keyint = 250 keyint_min = 15 perspectiveecut = 40 int numfresh = 0 rc_lookahead = 40 rc = crf mbtree = 1 crf = 23.0 qcomp = 0.60 qpmin = 0 qpmax = 69 qpstep = 4 ip_ratio = 1.40
Đầu ra # 0, mp4, thành 'JSP.mp4':
  Metadata:
    bộ mã hóa: Lavf54.63.100
    Luồng # 0: 0: Video: h264 ([33] [0] [0] [0] / 0x0021), yuv420p, 1600x880 [SAR 1: 1 DAR 20:11], q = -1--1, 15360 tbn , 15 tbc
    Metadata:
      RECORDMYDESKTOP: 0.3.8.1
    Luồng # 0: 1: Âm thanh: aac ([64] [0] [0] [0] / 0x0040), 22050 Hz, đơn âm, s16, 128 kb / s
Ánh xạ dòng:
  Luồng # 0: 1 -> # 0: 0 (theora -> libx264)
  Luồng # 0: 2 -> # 0: 1 (vorbis -> libvo_aacenc)
Nhấn [q] để dừng, [?] Để được trợ giúp
[ogg @ 0x34d4640] Tệp bị hỏng, không phải khung hình chính không được đánh dấu chính xác.
    Tin nhắn cuối cùng được lặp lại 2 lần
Tệp bị hỏng, không phải khung hình chính không được đánh dấu chính xác. = 00: 00: 08.37 bitrate = 28.7kbit / s dup = 66 drop = 0    
Tệp bị hỏng, keyframe không được đánh dấu chính xác.time = 00: 00: 51,01 bitrate = 125.3kbits / s dup = 675 drop = 0    
Tệp bị hỏng, keyframe không được đánh dấu chính xác.time = 00: 00: 55.05 bitrate = 140.2kbits / s dup = 782 drop = 0    
Tệp bị hỏng, keyframe không được đánh dấu chính xác.time = 00: 00: 59.60 bitrate = 140.5kbits / s dup = 836 drop = 0    
[ogg @ 0x34d4640] Tệp bị hỏng, khung hình chính không được đánh dấu chính xác.
Tệp bị hỏng, keyframe không được đánh dấu chính xác.time = 00: 01: 08.00 bitrate = 143.0kbits / s dup = 900 drop = 0    
Tệp bị hỏng, keyframe không được đánh dấu chính xác.time = 00: 01: 11,86 bitrate = 141,6kbits / s dup = 910 drop = 0    

... lặp đi lặp lại nhiều lần ...

Tệp bị hỏng, keyframe không được đánh dấu chính xác.time = 00: 12: 47.62 bitrate = 153.0kbits / s dup = 9087 drop = 0    
khung = 11521 fps = 87 q = -1.0 Lsize = 14849kB thời gian = 00: 12: 49,48 bitrate = 158,1kbits / s dup = 9087 drop = 0    
video: 2401kB âm thanh: 12024kB phụ đề: 0 tiêu đề toàn cầu: 0kB muxing trên đầu 2,938094%
[libx264 @ 0x369c5e0] khung I: 49 QP trung bình: 16,05 kích thước: 29658
[libx264 @ 0x369c5e0] khung P: 2912 Trung bình QP: 9,88 kích thước: 114
[libx264 @ 0x369c5e0] khung B: 8560 QP trung bình: 12,76 kích thước: 78
[libx264 @ 0x369c5e0] khung B liên tiếp: 0,9% 0,1% 0,2% 98,9%
[libx264 @ 0x369c5e0] mb I I16..4: 90.8% 0.4% 8.8%
[libx264 @ 0x369c5e0] mb P I16..4: 0.0% 0.0% 0.0% P16..4: 0.0% 0.0% 0.0% 0.0% 0.0% bỏ qua: 99.9%
[libx264 @ 0x369c5e0] mb B I16..4: 0,0% 0,0% 0,0% B16..8: 0,3% 0,0% 0,0% trực tiếp: bỏ qua 0,0%: 99,7% L0: 65,3% L1: 34,6% BI: 0,1%
[libx264 @ 0x369c5e0] Chuyển đổi nội bộ 8x8: 0,5% liên: 15,8%
[libx264 @ 0x369c5e0] được mã hóa y, uvDC, uvAC trong: 6,4% 0,1% 0,1% liên: 0,0% 0,0% 0,0%
[libx264 @ 0x369c5e0] i16 v, h, dc, p: 94% 4% 2% 0%
[libx264 @ 0x369c5e0] i8 v, h, dc, ddl, ddr, vr, hd, vl, hu: 19% 22% 44% 1% 2% 2% 3% 1% 6%
[libx264 @ 0x369c5e0] i4 v, h, dc, ddl, ddr, vr, hd, vl, hu: 35% 17% 19% 4% 5% 5% 5% 5% 5%
[libx264 @ 0x369c5e0] i8c dc, h, v, p: 100% 0% 0% 0%
[libx264 @ 0x369c5e0] Khung P có trọng số: Y: 0,0% UV: 0,0%
[libx264 @ 0x369c5e0] ref P L0: 82,5% 1,4% 11,9% 4,3%
[libx264 @ 0x369c5e0] ref B L0: 47,2% 52,4% 0,4%
[libx264 @ 0x369c5e0] ref B L1: 99,2% 0,8%
[libx264 @ 0x369c5e0] kb / s: 25,60

Video vẫn tiến bộ sớm nhưng vào những thời điểm khác nhau. Có vẻ như gtk-recordmydesktop đang tạo ra một "tệp bị hỏng". Điều khó chịu là OGV hoạt động tốt nên có vẻ như tôi sẽ có thể thực hiện công việc này với một số tùy chọn.

Tôi đã thấy rằng tôi có thể kết xuất video trong kdenlive và dường như nó đang hoạt động ở đó. Tôi vẫn muốn biết chuyện gì đang xảy ra. kdenlive làm một công việc tốt hơn nhiều, nhưng đôi khi nó vẫn tiến bộ sớm.

Tại sao chuyển đổi sang OGV khi tải lên cuối cùng của bạn sẽ là youtube, tôi có thể sai nhưng bạn có thể chuyển đổi sang codec video x264 với AAC Audio ngay cả trên linux và tải lên youtube xem đó là những gì họ thích được tải lên. Bạn đã thử tạo một h264 và tải lên youtube thay vì tệp OGV và xem đó có phải là vấn đề không. Bởi vì tôi cá rằng nếu điều đó giải quyết được thì bạn sẽ biết đó là vấn đề với OGV được tải lên youtube và nếu nó không giải quyết được thì đó có thể là vấn đề về tốc độ khung hình với cách giải thích của youtube hoặc một cái gì đó tương tự.

Đã có rất nhiều vấn đề với các tệp OGV được tải lên youtube trong quá khứ. Tôi không thể tưởng tượng rằng nó được cố định 100% ngay cả tại thời điểm này.

http://support.google.com.vn/youtube/ theo dõi các thành viên khác

EDIT: cũng chỉ nhận thấy rằng đoạn phim gốc của bạn ở mức 15 khung hình / giây ... đây rất có thể là nguồn gốc của vấn đề

EDIT 2: Tôi dường như hơi đọc sai câu hỏi một chút ... rằng bạn đang bắt đầu với một tệp video là OGV, và tôi thấy rằng bạn sẽ chuyển sang MP4 ... điều này thay đổi mọi thứ một chút .. .Nhưng tôi sẽ đoán nó có liên quan đến âm thanh 15fps và 22050 Hz ... Tôi biết tốc độ mẫu không liên quan gì đến việc đồng bộ hóa âm thanh, nhưng từ kinh nghiệm khi sử dụng tốc độ khung hình và bộ lấy mẫu âm thanh không chuẩn, Tôi có xu hướng thấy trôi dạt ... để những thứ này được đồng bộ hóa có thể khá khó khăn trong khi không thể chỉnh sửa chúng sau khi ghi ban đầu với trình chỉnh sửa video giá rẻ ...

Mặc dù phần mềm đã tốt hơn về việc làm trôi âm thanh, nhưng đây vẫn là một vấn đề phổ biến khi sử dụng các bộ khung và bộ lấy mẫu không phổ biến vì các điểm đồng bộ có khung không chuẩn và có thể làm tròn các khung chính, v.v ...

Bạn thấy nơi nó nói "Tệp bị hỏng, khung hình chính không được đánh dấu chính xác." đó là những gì nó đề cập đến ...

Lời khuyên của tôi dành cho bạn là hãy đưa nó đến gần nhất có thể, đưa nó vào trình chỉnh sửa video và trượt và cắt âm thanh để làm cho nó phù hợp với cách bạn muốn. Thật không may, đôi khi đây là cách nó được sửa chữa ...

Bộ chuyển mã dựa trên phần mềm không phải lúc nào cũng hoạt động vì chúng nên ... giải thích tại sao thiết lập protools và / hoặc thiết lập khao khát sẽ đi kèm với phần cứng để đảm bảo khả năng đồng bộ hóa và tốc độ khung hình không đổi, v.v ...

Một điều khác bạn có thể thử là chuyển đổi cảnh quay thành tốc độ khung hình tiêu chuẩn và cố gắng phát lại âm thanh ... vì tôi chắc chắn rằng đó là video trôi ... có lẽ hơi chậm lại và sau đó tăng tốc về phía kết thúc hoặc ngược lại.

EDIT: Tôi đã có thể khiến video đồng bộ hóa với bản gốc bằng lệnh ffmpeg này ... nó có thể cần mệnh đề tỷ lệ, đó là điều tôi nghi ngờ

ffmpeg -i sync_test1.ogv -strict experimental -pix_fmt yuv420p -r 15 -vcodec h264 -acodec aac sync_test1.mp4

Tôi đã vật lộn với một vấn đề tương tự trên Ubuntu 12.04.3 LTS. Tôi đã khắc phục sự cố bằng cách sử dụng bản dựng ffmpeg tĩnh có sẵn từ http://johnvansickle.com/ffmpeg/

Hãy thử chỉ thay đổi container thành avi thay vì chuyển mã, có vẻ như hoạt động tốt hơn cho youtube:

ffmpeg -i JSP.ogv -vcodec copy -acodec copy JSP.avi