Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(438)

Unified Diff: third_party/ffmpeg/patched-ffmpeg-mt/mt-work/todo.txt

Issue 566011: FFmpeg add mt-work folder for completeness. (Closed) Base URL: svn://chrome-svn/chrome/trunk/deps/
Patch Set: Created 10 years, 11 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View side-by-side diff with in-line comments
Download patch
Index: third_party/ffmpeg/patched-ffmpeg-mt/mt-work/todo.txt
===================================================================
--- third_party/ffmpeg/patched-ffmpeg-mt/mt-work/todo.txt (revision 0)
+++ third_party/ffmpeg/patched-ffmpeg-mt/mt-work/todo.txt (revision 0)
@@ -0,0 +1,83 @@
+Todo
+
+-- Bug fixes
+
+Prove correct:
+- decode_update_progress() in h264.c
+h264_race_checking branch has some work on h264,
+but not that function. It might be worth putting
+the branch under #ifdef DEBUG in mainline, but
+the code would have to be cleaner.
+- MPV_lowest_referenced_row() and co in mpegvideo.c
+
+mpeg4:
+- Packed B-frames need to be explicitly split up
+when frame threading is on. ATM frame threading
+is disabled for this codec, since it showed major
+decoding problems in mplayer (but not ffplay for
+some reason). This is probably the reason.
+- Support interlaced.
+
+other:
+- frame_thread_free has memory leaks when called
+from error label in frame_thread_init.
+- ffmpeg with -vsync != 0 breaks A/V sync because
+it can't handle more than 1 frame of decoder delay.
+This can be seen with H.264 on mainline.
+- Error resilience has to run before ff_report_
+frame_progress() is called.
+- 'make test' must pass. This means pthread emulation
+must work the same way without --enable-pthreads.
+There also seems to be some problem related to
+draw_edges and the mpeg4 encoder.
+- There is a harmless warning about unreleased
+buffers emitted after mpeg* decoding, caused
+by it calling avcodec_default_free_buffers too early.
+
+-- Optimization
+
+- avail_motion() in h264 spends too much time
+skipping zeros in refs[].
+- fill_edges() is disabled for h264 PAFF+MT
+because it writes into the other field's
+thread's pixels.
+- Support frame+slice threading.
+- Use a context array for thread_opaque instead
+of mallocing every time.
+
+-- Style
+
+- See if AVCodec init_copy and update_context
+can be merged.
+- Get rid of the IS_* macros in thread.h and
+use explicit checks instead.
+- Rename avail_motion and ONLY_IF_THREADS_ENABLED
+to something better.
+- Try merging avail_motion() and hl_motion() code.
+- Document that FF_THREAD_FRAME doesn't work if
+clients expect certain DTS (like mplayer without
+-correct-pts), or if they can't submit future frames
+(like quicktime).
+
+-- Features
+
+- Support streams with width/height changing. This
+requires flushing all current frames (and buffering
+the input in the meantime), closing the codec and
+reopening it. Or don't support it.
+- Support encoding. Might need more threading primitives
+for good ratecontrol; would be nice for audio too.
+- Add an API for clients that waits until a given
+AVFrame is finished decoding. May not be useful.
+- After merging to mainline, deprecate avcodec_thread_init
+and just set thread_count.
+- Maybe make thread_count == 0 mean automatic.
+
+-- Samples
+
+http://astrange.ithinksw.net/ffmpeg/mt-samples/
+
+See yuvcmp.c in this directory to compare decoded samples.
+Try commenting out ff_report_frame_setup_done calls so
+only one thread runs at once, and then binary search+
+scattering printfs to look for differences in codec contexts.
« no previous file with comments | « third_party/ffmpeg/patched-ffmpeg-mt/mt-work/test.sh ('k') | third_party/ffmpeg/patched-ffmpeg-mt/mt-work/valgrind-check.sh » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698