H.264 encoding error in DM365 "encode" demo

I was able to record a h.264 file using the same command without the pink artifacting, though I am playing it back through VLC player on Windows, the .264 file is attached.

I am curious what DVSDK version you are running? I just tried this out with 2.10.00.17.

I am also curious what command you used to get the files to play in MPlayer? I am running Ubuntu 9.04 on which I installed MPlayer through Synaptic, but the files don't seem to open properly with the standard 'mplayer stock_480x360.264' command.

Have you tried any other media players? I am just wondering if this could be an artifact specific to MPlayer.

Bernie Thompson said:

I was able to record a h.264 file using the same command without the pink artifacting, though I am playing it back through VLC player on Windows, the .264 file is attached.

That clip plays fine for me with MPlayer.  Thanks!

Bernie Thompson said:

I am curious what DVSDK version you are running? I just tried this out with 2.10.00.17.

I'm on dvsdk_2_10_00_13.

Bernie Thompson said:

I am also curious what command you used to get the files to play in MPlayer? I am running Ubuntu 9.04 on which I installed MPlayer through Synaptic, but the files don't seem to open properly with the standard 'mplayer stock_480x360.264' command.

I typically need to add "-fps 30" to the command line / option file.

Bernie Thompson said:

Have you tried any other media players? I am just wondering if this could be an artifact specific to MPlayer.

That's certainly possible.  I can't get VLC for Linux to play either my clips or yours.  I'll try a Windows machine on Monday.  When I play my 480x360 clip in "Totem Movie Player 2.26.1" I see the same anomaly.

Interesting side note: when I tried to get a screen shot of Totem playing the clip, it logged me off.  Twice.  I've also had MPlayer log me off while playing generated clips (but those had been intentionally corrupted during debugging).

Do you have access to any h.264 format checkers/analyzers? I've attached my original clip just in case you do.  I'm curious if there's an actual syntax/protocol error in the file.

I had to put it in a ZIP file becuase the web site won't let me attach a .264 file.  How did you attach one??

Thanks!

Bernie Thompson said:

Have you tried any other media players? I am just wondering if this could be an artifact specific to MPlayer.

I've tried VLC and the latest, greatest MPlayer.  VLC will not play this clip (BUT this may be a codec config issue) and the latest MPlayer shows the same anomaly.  A co-worker pointed out that the icon generated by Linux for the video clip also shows the pink overlay.  This suggests that it is not just a player artifact.\

I've downloaded dvsdk_2_10_01_18 and will try it on the DVEVM board this morning.  I tried running it on the target board over the weekend and it won't run due to version incompatibilities.  The main one being that CMEM has been bumped up a major rev since my current version of the SDK.  This is interesting since my issue has the signature of a buffering problem.

Just confirmed that with dvsdk_2_10_01_18 software it records correctly on the DVEVM.  I'm now 90% sure it's a CMEM issue.

UPDATE: Details of what I did:

1) Rebuilt the dvsdk_demos_2_10_00_13 version of encode under dvsdk_2_10_01_18 (This required one code change from  "cAttrs.dim = gfxAttrs.dim;" to "cAttrs.captureDimension = &gfxAttrs.dim;")

2) Installed the v.13 encode demo in a directory in the target filesystem that was built with dvsdk_2_10_00_13.

3) Copied the dvsdk_2_10_01_18 versions of cmemk.ko and edmak.ko into the same directory.

4) Ran loadmodules_hd.sh from that directory.

5) Ran encode from that directory.

Everything worked fine with no anomaly. The only differences from my previous configuration were cmemk.ko and edmak.ko.

I am glad to hear it is working for you in the newer DVSDK release, there were a number of issues fixed in the GA release, and this could be a CMEM problem in the beta release, though it could just  as easily be some codec problem that was fixed. I imagine either way that you are migrating to the 2.10.01.18 release?

As to attaching arbitrary files (i.e. a .264 file), this is a limitation of the forums, as a typical user you have to wrap files into a zip file to post, I have additional moderator/admin privelages that allow me to post any file extension. I suspect this was due to concerns over security, perhaps someday it will change.

Bernie Thompson said:

I imagine either way that you are migrating to the 2.10.01.18 release?

I would really prefer to NOT migrate to 2.10.01.18.  I've got a customized version of encode based on dvsdk_2_10_00_13 and legacy code built on an even older version.  However, I may be forced to since this clearly fixes my issue.

Where are DVSDK bugs tracked? I'd like to see the details of this fix.  And probably others in the future.

Thanks!

This is unfortunately a common problem with beta releases like this, and why we try to stress that the beta versions before the GA release are really beta versions that are not meant for production. As a general rule for other readers of this thread, if you start work on a beta release it is expected that you plan to do any necessary porting effort to migrate to GA one day, otherwise you end up with limited support and potentially problems like this one.

Tom Hanson said:

Where are DVSDK bugs tracked? I'd like to see the details of this fix.  And probably others in the future.

All the bug tracking is done internally, there is no public place to examine bug tracking records, which is unfortunate and something I hope to see one day, at least for the majority of known bugs.

The closest to this would be the release notes for the various DVSDK components which will often list the bugs that have been fixed in the particular release, keep in mind that the DVSDK is actually a conglomeration of various smaller software components, each of which can have its own bugs.

Bernie Thompson said:

All the bug tracking is done internally, there is no public place to examine bug tracking records, which is unfortunate and something I hope to see one day, at least for the majority of known bugs.

The closest to this would be the release notes for the various DVSDK components which will often list the bugs that have been fixed in the particular release...

What I was hoping for was a way to search reported bugs.  Rather than each and every member of the community needing to track the same bug to its source, we should be able to see what others have found and short-circuit the process.

Tom Hanson said:

What I was hoping for was a way to search reported bugs.  Rather than each and every member of the community needing to track the same bug to its source, we should be able to see what others have found and short-circuit the process.

I could not agree more, this would certainly make my job easier.

It is a concept that has been brought up a few times over the years but has never made it out due to various internal complexities and cost. Having customers like you providing this sort of feedback will help to push for change though, so I thank you for taking the time to post this.

I remember seeing this issue in 2.10.00.13 as well.

The work-around was to set the maxWidth parameter in VIDENC1_Params
to a minimum value of 640.

    params->maxWidth          = (envp->imageWidth<640) ? 640 : envp->imageWidth;