https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #22 from Thomas Schmitt <***@gmx.net> ---
Hi,
I already have a directory containing a BDMV subtree (and CERTIFICATE).
I can only google for these terms to learn what they mean.
But in general this looks like a good start for exercising the last
steps of Blu-ray video production.
(When this part is achieved, there will arise the question how to make
that subtree from own video files which are given in some common video
codec's format.)
I have read rumors about DVD video that mkisofs -udf has to take care
not only to produce a valid UDF filesystem but also has to obey some
further layout prescriptions.
See in man genisoimage (or man mkisofs) the description of option -dvd-video.
It has two paragraphs. The first talks briefly of that layout, the second
mentions DVD-specific input files like VIDEO_TS. The equivalent of this
second part is hopefully covered by your BDMV tree.
But the first part will simply have to be tested. If it does not work
with a picky test player, then one will have to compare the byte-level
layout of a commercial Blu-ray video medium with the own UDF-2.50 result.
Burning to BD media is not a hard job then. Recent K3B should do. We know
from Bug 387765 that Archlinux already has it. (It warns of unknown image
format. After confirming, it burned a Nero made UDF-only image.)
If there are difficulties to get such a recent K3B, use the command line:
growisofs -dvd-compat -Z /dev/sr0=image.udf
or
cdrskin -v dev=/dev/sr0 fs=32m -eject image.udf
I'd use growisofs option -dvd-compat to get BD-R media closed. At lest
with DVD there are hints that appendable media won't work on all players.
(With BD-RE there is no closing on hardware level.)
For full nominal writing speed use
cdrskin -v dev=/dev/sr0 fs=32m -eject stream_recording=on image.udf
This disables the immediate checkreding by Defect Management which slows
down writing by a factor 2 or 3.
On flaky media or drives, you paradoxically get better chances of success
if you do _not_ let the drive to this check-and-replace game.
So as I see it as a user, K3B should just do the same thing as ImgBurn: you
select the directories you want to burn, ImgBurn guesses from the tree
structure that it's a video disk and asks if you want to use UDF 2.5 and
make a video disk indeed. Then you press ok and wait for it to finish.
Well, that would rather be Leslie's desk. :))
He will probably need:
- The description of the command line program runs needed to produce
the Blu-ray video disc image.
- Example input data (e.g. some commercial Blu-ray video discs)
- A computer Blu-ray burner.
- Testers who then verify that K3B indeed produces BDs which are
playable on all Blu-ray video players.
But I argue that I don't need real equipment, CDEmu[1] is enough
I dare to contradict. A K3B developer should have a BD burner and
test media.
I as burn backend developer have 3 BD burners and 3 DVD burners.
Just to be able to distinguish individual burner flaws from general problems.
(It also helps to have slightly ill burners which challenge the program's
error handling.)
A frontend programmer would only need 1 well working burner, although
a second one will help to check program behavior when multiple burners
are available in the system.
Have a nice day :)
Thomas
--
You are receiving this mail because:
You are the assignee for the bug.
